-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1On Tuesday 04 February 2003 19:47, Calvin Spealman wrote:
Latimerius wrote:
You might not want to use C++ exception handling mechanism to handle a
relatively common condition as a state change unless you don’t care
about performance. I don’t know how often you change states in your
scheme so I’m not saying this will cause trouble for you but you might
want to consider that every try block entry costs you and leaving a
function due to throw might be considerably (Meyers says several orders
of magnitude) slower than simple return. I’m all for exceptions but
they are designed to handle exceptional conditions so think twice
before using them.
I didnt think they took much resources. It doesnt seem like that would
have to. Why would the throw statement have to be any different than
calling a function? Or, given that most exceptions are possibly 0 size,
the throw could be as simple as a jmp.
When you use exceptions, the compiler emits code that simply assumes nothing
goes wrong, i.e. no exception is thrown.
Now when an exception does occur, run-time library code is called which
unwinds the current stack frames (i.e. where your local function variables
are) to call destructors and to find the appropriate catch-block. It uses
"magic" structures and special cleanup code created by the compiler for
this task. This fixing “after the fact” simply cannot be as efficient as a
simple return. Exceptions basically trade error handling performance for
normal-case performance, which is a sensible thing to do.
Sure, in theory you could optimize exception handling away in very rare
cases (though I guess the only case where that’s possible is when the
try/catch block and the throw are in the same function). However, it
doesn’t make any sense to do this, because exceptions are just that:
exceptions, not the rule. A state change of an FSM is not an exception,
as it happens during perfectly normal operation.
This is all accurate, except for one thing: compared to, say, drawing a
polygon, a c++ exception is fantastically efficient, so nobody will ever
notice a performance hit just because an exception gets thrown in a user
interface transition.
I’d suggest a different argument: exceptions are mainly useful to keep error
processing details from obscuring the main flow of your program logic.
Conversely, if you implement your main logic using exceptions, you are hiding
part of the main flow, so you’d better have a good reason for doing that.
Regards,
DanielOn Tuesday 04 February 2003 20:09, Nicolai Haehnle wrote:
When you use exceptions, the compiler emits code that simply assumes
nothing goes wrong, i.e. no exception is thrown.
Now when an exception does occur, run-time library code is called which
unwinds the current stack frames (i.e. where your local function variables
are) to call destructors and to find the appropriate catch-block. It uses
"magic" structures and special cleanup code created by the compiler for
this task. This fixing “after the fact” simply cannot be as efficient as a
simple return. Exceptions basically trade error handling performance for
normal-case performance, which is a sensible thing to do.
Sure, in theory you could optimize exception handling away in very rare
cases (though I guess the only case where that’s possible is when the
try/catch block and the throw are in the same function). However, it
doesn’t make any sense to do this, because exceptions are just that:
exceptions, not the rule. A state change of an FSM is not an exception,
as it happens during perfectly normal operation.
This is all accurate, except for one thing: compared to, say, drawing a
polygon, a c++ exception is fantastically efficient, so nobody will ever
notice a performance hit just because an exception gets thrown in a user
interface transition.
Well, the way guys were talking about states, it seemed to me that a
"state" in this context could develop into a lot of things, namely it
seemed to me that, taken to extreme, anything that changes the way input
is processed could be turned into a state. So, you’re absolutely right if by a “state change” you mean something like pressing F10 in a
Blizzard game - the simulation pauses and a big fat menu covers the
significant portion of screen. But, if my above mentioned suspicion
is right, a state change could also be something smaller, e.g. something
like popping-up a bubble help window because it might change the meaning
of next button-down event (to erase the help window). Then, depending
on many things, it could be possible that exception handling with all
of its destructor calls etc. etc. would eat up a couple of milliseconds
that would be better spent somewhere else.
Then the code Calvin sent suggested to me that he might not be entirely
aware of costs and intended usage of exception handling which he kind of
confirmed. So I commented on this. No big deal, I can still
remember when I myself thought that exceptions are to replace diagnostic
codes returned from methods. It’s still relatively little known that
excpetions’ equivalent in C would be rather setjmp/longjmp combo than
a function’s return value.
I’d suggest a different argument: exceptions are mainly useful to keep error
processing details from obscuring the main flow of your program logic.
Conversely, if you implement your main logic using exceptions, you are hiding
part of the main flow, so you’d better have a good reason for doing that.
Yeah, that’s roughly what I meant when I wrote “exceptions are there for
exceptional events”.
latimeriusOn Tue, Feb 04, 2003 at 08:43:47PM +0100, Daniel Phillips wrote:
I hadnt thought of all the stack unwinding and object clean up needed.
And, the way I use states, they could become used enough that the
exceptions will be bad. But, the game is simple and the code is good for
now. I’ll find a better solution on my next game.
I took the exception road for this task because I need the state’s code
to be able to destroy itself immediately when it needed to, and I didnt
want to have if (State::foo() == State::CloseSignal) or something like
that at every line I call a state’s function.
Actually, I can get out of it easily now that I give it some thought.
All my states have their own class, all derived from State. I call
State’s static member functions to, in turn, call the correct state’s
function. I should just put the checks in the static functions.
I found this post in archive and wanetd to and wanted to examine
the source of Game Framework. But the site is defunc now.
Does anybody know where from can I download the source?
Original mail:
I’m starting to map out the various stages of my game, intro, tutorial,
game play, cut scenes, etc. and it is getting a little ugly when it
comes to what I envision as user input and the basic event loop. I’m
thinking I need to create a global that stores the current game state
and use a series of case statements within the PollEvent loop. This
seems a bit bulky though and could run pages long.
Has anyone had experience in developing a custom class that you can use
to wrap around the event to simplify the event structure with respect
to your game states? Or perhaps other ways that you have found
especially effective in keeping code clean and simple?
The first or second article in `Game Programming Gems 3’ is about a
similar topic to this. He talks about a thing which he calls a Game
Framework. It has a website - www.gameframework.com - which is updated
reasonably regularly.
The basic concept is that you have layers' which can each have control. The layers are, well,layered’ on top of one another. The top one gets
the first shot at the input, and if it doesn’t handle it, the next one
gets a go, and so on. (There can be exclusive layers which don’t give
anyone else a go at the input.) So the input cascades down the chain of
layers. A menu can be an exclusive layer which tacks onto the front of
the stack. You can have different layers for different parts of the
interface. It’s quite flexible, and works pretty well with SDL.
Hope that helps,
Dave.–
David Slutzkin, BCS (Hons)
Melbourne, Australia
The first or second article in `Game Programming Gems 3’ is about a
similar topic to this. He talks about a thing which he calls a Game
Framework. It has a website - www.gameframework.com - which is
updated
reasonably regularly.
This website doesn’t show up for me as anything other than a
placeholder website owned by a company wanting to sell it.
The basic concept is that you have layers' which can each have control. The layers are, well,layered’ on top of one another. The top one
gets
the first shot at the input, and if it doesn’t handle it, the next one
gets a go, and so on. (There can be exclusive layers which don’t give
anyone else a go at the input.) So the input cascades down the
chain of
layers. A menu can be an exclusive layer which tacks onto the front
of
the stack. You can have different layers for different parts of the
interface. It’s quite flexible, and works pretty well with SDL.
You probably can do something like this pretty easily without having
to resort to objects, but I’ve created a GameState class which I
create subclasses of for each game state (menus, intro videos, loading
screens, gameplay, etc…), and I maintain a stack structure of game
states, pushing and popping when necessary for new game states. So in
my render and process threads I just peek at the stack and run that
object’s process/render methods each time through the loop, and if at
some point the GameState object at the top of the stack doesn’t return
’true’ to say ‘rendered/processed normally’, then I presume it’s done
with whatever it wanted or was doing, and I pop the stack and start
working on the next lowest.
So what I came up with is kind of similar, I guess. I’m not sure
why or if the layers idea would be better, but either could be easily
done in SDL (on-topic!) and work rather nicely, I think.
So what I came up with is kind of similar, I guess. I’m not sure
why or if the layers idea would be better, but either could be easily
done in SDL (on-topic!) and work rather nicely, I think.
Great minds think alike? Our (http://www.mysterystudio.com) framework is
based on this same concept (we call them GameModes) and has been used in
quite a few commercially released games. So it the idea works
About input processing and stuff, our GameModes have a few flags :
GMF_PASS_INPUT, GMF_PASS_DRAW and GMF_PASS_UPDATE. The flags determine
whether or not input, a chance to draw, or timer ticks can pass to the mode
below it in the stack, respectively. Most combinations are useful - for
example, a full-screen mode (main menu, game screen) have none of the flags
set. Modal dialogs have PASS_DRAW - you see what’s below, but it’s stopped.
Non-modal dialogs have PASS_DRAW | PASS_INPUT | PASS_UPDATE - the mode below
continues to run while showing the dialog. Finally, remember Doom’s map,
where you saw the 2D overhead map but the game continued to run below?
PASS_INPUT | PASS_UPDATE. Actually, it was with this last example in mind I
designed the mode stack and the flags
This is exactly what I am looking for.
One thing that puzzles me is order of drawing. Suppose you have stack
(man menu, game screen, dialog). When dialog has to be drawn it is drawn
and PASS_DRAW to game screen. When game screen is drawn will it not
overdraw (hide) dialog? I thing that game screen should be drawn first,
then dialog while processing input and update should remain as it is.
Am I wrong?
Since I am not experienced programmer I am still looking for some
example code that has similar functionality as Gabriel and Scott
described. Is there any available?
MartinOn Sat, Feb 09, 2008 at 08:31:39PM -0200, Gabriel Gambetta wrote:
So what I came up with is kind of similar, I guess. I’m not sure
why or if the layers idea would be better, but either could be easily
done in SDL (on-topic!) and work rather nicely, I think.
Great minds think alike? Our (http://www.mysterystudio.com) framework is
based on this same concept (we call them GameModes) and has been used in
quite a few commercially released games. So it the idea works
About input processing and stuff, our GameModes have a few flags :
GMF_PASS_INPUT, GMF_PASS_DRAW and GMF_PASS_UPDATE. The flags determine
whether or not input, a chance to draw, or timer ticks can pass to the mode
below it in the stack, respectively. Most combinations are useful - for
example, a full-screen mode (main menu, game screen) have none of the flags
set. Modal dialogs have PASS_DRAW - you see what’s below, but it’s stopped.
Non-modal dialogs have PASS_DRAW | PASS_INPUT | PASS_UPDATE - the mode below
continues to run while showing the dialog. Finally, remember Doom’s map,
where you saw the 2D overhead map but the game continued to run below?
PASS_INPUT | PASS_UPDATE. Actually, it was with this last example in mind I
designed the mode stack and the flags
This is exactly what I am looking for.
One thing that puzzles me is order of drawing. Suppose you have stack (man
menu, game screen, dialog). When dialog has to be drawn it is drawn and
PASS_DRAW to game screen. When game screen is drawn will it not overdraw
(hide) dialog? I thing that game screen should be drawn first, then dialog
while processing input and update should remain as it is. Am I wrong?
No, you’re right. Drawing is done bottom to top to avoid the use of the
zbuffer (my framework has software(SDL), Direct3D and OpenGL renderers), in
a painter’s algorithm of sorts since the modes are few and you have them
ordered in a stack (keeping the drawing order of the images of a single mode
is a different matter). So what I do is to start from the top of the stack
and go down until I find a mode that does NOT have PASS_DRAW set. That’s the
last mode that will be drawn - everything beneath it will be hidden. I then
draw from that mode to the top of the stack.
For example if the stack looks like this :
Options Dialog (PASS_DRAW)
Game HUD (PASS_DRAW)
Game Screen (-)
Menu Screen (-)
my code goes down until it reaches Game Screen, then draws Game Screen, then
Game HUD, and finally Options Dialog.
Since I am not experienced programmer I am still looking for some example
code that has similar functionality as Gabriel and Scott described. Is there
any available?
Mine isn’t, but I don’t think it would do you any good - this mechanism is
so generic and high level that any particular implementation probably won’t
fit your particular needs. On the other hand, adding it to your framework
should be quite easy.
So I commented on this. No big deal, I can still
I’m not sure