gamedevlists-general — List for discussing general game development issues

RE: [GD-General] Key handling revisited

[Matt D. <ma...@co...>]

Yes, that's right.  The first mapping is set up, per platform, in our editor
so that we can handle input in a platform independent way. The so-called
'virtual' buttons cover all keyboards in a generic way.

As a summary:

Physical buttons  (platform dependent)
   |
   |   (Physical mapping)
   V
Virtual buttons   (platform independent)
   |
   |   (User mapping)
   V
Command buttons	(platform independent)
   |
   |   (Command mapping)
   V
Commands          (platform independent)


The user mapping is maintained by a 'define controls' screen but it is
intially set up as button 0 maps to 0, button 1 maps to 1, button 2 maps to
2, etc.  This means that the virtual buttons and the command buttons are
basically the same at default.

The command mapping has a 1 to many relationship.  So we can set up a
mapping that links our attack button to punch and kick commands.  If we
wanted to, it will be easy to have them on seperate buttons by changing the
mapping and not by changing the code.  This flexibility is useful.


Matt Davies
Programmer, Confounding Factor
ma...@co...
www.confounding-factor.com


--- Excerpt from Jamie Fowlston

> presumably the processing of the physical button also has to be platform
> dependent, as the buttons vary.

FW: [GD-General] Key handling revisited

[Tom F. <to...@mu...>]

Another victim of the list settings...

Tom Forsyth - Muckyfoot bloke.

-----Original Message-----
From: Ignacio Casta=F1o [mailto:cas...@ya...]
Sent: 11 February 2002 21:48
To: Tom Forsyth
Subject: Re: [GD-General] Key handling revisited


Or you can just use MapVirtualKeyEx followed by ToAsciiEx to map direct
input virtual keys, to ascii characters. That works well with special
characters (=E1=E9=F4=FC etc.), and also with key combinations if you =
get the
keyboard state with GetKeyboardState, and use it with ToAsciiEx.

The only problem I've found with that is that with low framerates you =
can
loose a shift or alt key because dinput is buffered and =
GetKeyboardState is
just polling, but that can be solved using your own buffer for key =
states.


Ignacio Casta=F1o
ca...@as...


Tom Forsyth wrote:
> I think there are two separate issues, which Brian sort-of talked =
about.
>
> -Text input. Need to handle international chars, =
shift-alt-meta-squiggle
> wierdness and all that. As much as possible, try to get the OS to do =
all
the
> hard work. Usually queue-driven, so you won't miss keypresses. I =
don't
know
> anything about macs, but on Windows you just use the WM_CHAR =
messages.
They
> will tell you what is printed on top of the key that the user =
pressed, and
> handle virtual keyboards and macros and so on. Probably exposed as a
stream
> of ASCII-like things, except probably 16-bits wide. Could possibly =
use
> UNICODE?
>
> -Game control input. You just want the keyboard to be returned as a =
big
> keypad with 100+ keys, and tell you which keys are pressed at any one
time.
> This is what DirectInput exposes. Usually polled, not queue-driven, =
it's
> just a big array of key states (up/down).
>
>
> The only crossover between the two is when the user is defining their
keys.
> Then you want to find what is printed on the top of the key that the
> "gamepad" has pressed down. Fortunately you can assume that when they =
are
> being defined, the user will be pressing exactly one key at a time, =
so
just
> watch both systems to see which WM_CHAR-like message corresponds to =
which
> keypad keydown.
>
>
> For Windows+DirectX, you're pretty sorted - WM_CHAR for the first,
> DirectInput for the second. I don't know much about other platforms.
>
>
> Tom Forsyth - Muckyfoot bloke.
>
> What's he up to now (and can I have a go)?
> http://www.eidosinteractive.com/downloads/search.html?gmid=3D86
>
> > -----Original Message-----
> > From: Jamie Fowlston [mailto:ja...@qu...]
> > Sent: 11 February 2002 10:36
> > To: gam...@li...
> > Subject: RE: [GD-General] Key handling revisited
> >
> >
> > I'm also interested in a related issue: if anyone has a
> > sensible input model
> > that can work across computers and consoles, i'd love to hear
> > it :) at the
> > moment the plan is to reimplement the control interface on
> > each platform
> > (it'll need tweaking for each platform anyway), but i don't
> > want to have to
> > do more work than is necessary on a problem that _surely_
> > must have been
> > solved? :)
> >
> > Jamie
> >
> >
> > -----Original Message-----
> > From: gam...@li...
> > [mailto:gam...@li...]On Behalf =
Of
> > Brian Hook
> > Sent: 10 February 2002 02:39
> > To: gam...@li...
> > Subject: [GD-General] Key handling revisited
> >
> >
> > After thinking about my key handling situation for a day, I
> > think I finally
> > stumbled upon the obvious solution.
> >
> > Fundamentally I wasn't differentiating between ASCII
> > characters and raw key
> > codes, so I ended up just having a jumble of logic both on
> > the key reading
> > side (my platform driver) and on the application side.  My
> > HEvent structure
> > only had a keyCode member, which mapped to my system virtual
> > key constants
> > (directly taken from the VK_ constants in WINUSER.H so that
> > there was a
> > one-to-one mapping).
> >
> > To simplify my life, I just added another field, evChar,
> > which is the ASCII
> > representation of the virtual key code.  So I can
> > differentiate between top
> > row "0", keypad "0", or just read an ASCII "0" depending on
> > the needs of
> > the calling routine.
> >
> > Yeah, kinda duh, but for some reason I was just focused on
> > having a single
> > key code and doing the appropriate thing with it at all times.
> >
> > Of course, this doesn't address the issue of international
> > keyboards.  I
> > have no idea what to do about that, other than just hope and
> > pray it's not
> > a problem.  And if it is, I guess I'll deal with it then.
> >
> > Brian
> >
> >
> >
> > _______________________________________________
> > Gamedevlists-general mailing list
> > Gam...@li...
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> > Archives:
> > http://sourceforge.net/mailarchive/forum.php?forum_id=3D557
> >
> >
> > _______________________________________________
> > Gamedevlists-general mailing list
> > Gam...@li...
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> > Archives:
> > http://sourceforge.net/mailarchive/forum.php?forum_id=3D557
> >
>
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=3D557


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

RE: [GD-General] Key handling revisited

[Jamie F. <ja...@qu...>]

that's exactly the system i've set up. what i'm currently not too happy with
is the state / event split. obviously you can generate events from states
and vice versa, just seems a bit yucky....

presumably the processing of the physical button also has to be platform
dependent, as the buttons vary.

Not had to handle text input yet, may not have to (fingers crossed :)

Jamie


-----Original Message-----
From: Matt Davies [mailto:ma...@co...]
Sent: 12 February 2002 09:57
To: Brian Sharon; Tom Forsyth; Jamie Fowlston;
gam...@li...
Subject: RE: [GD-General] Key handling revisited


Hi,

Most keyboards rely on single key presses or multiple keys being pressed at
the same time (e.g. Ctrl-F).  However, on some keyboards (like the German
ones) there are multiple key presses that are not done at the same time.  So
if you're allowing entering of text, be wary of that.

The best way of dealing with it is to treat as you would, say, your
renderer.  Figure out the use cases and design a high-level interface to
keyboard input.  Provide drivers under that layer which specialise in PC and
Macs and so forth.

For Galleon, we provide three mappings.

First, we map 'physical' buttons to 'virtual' buttons.  These removes the
platform dependency.  The virtual buttons are the keys used on our imaginary
keyboard.  Next we map 'virtual' to 'command' buttons.  This is called the
user map and is what the player creates by redefining the controls.
Finally, we map those keys to commands via a one-to-many mapping.  The game
reacts to the commands.

But the important thing to point out is that most of our input code is
platform independent except the code that provides the 'physical' button
information.

If you require text input, such a system would not be efficient.  Provide a
load of accessor functions, such as GetChar(), GetWideChar(),
IsControlPressed(), IsShiftPressed(), IsKeyUp(), IsKeyDown().  These
functions could be part of a class called CKeyboardEvent (or whatever) whose
sole purpose is to hold information of a single (or multiple in the case of
German keyboards) key press.  Provide CKeyboardDevice to provide the
platform dependecies and CKeyboardManager to use that and spit out
CKeyboardEvent classes.


Take care and good luck,



Matt Davies
Programmer, Confounding Factor
ma...@co...
www.confounding-factor.com



> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Brian Sharon
> Sent: 11 February 2002 16:08
> To: Tom Forsyth; Jamie Fowlston;
> gam...@li...
> Subject: RE: [GD-General] Key handling revisited
>
>
> > -----Original Message-----
> > From: Tom Forsyth [mailto:to...@mu...]
> > Sent: Monday, February 11, 2002 3:08 AM
> > To: Jamie Fowlston; gam...@li...
> > Subject: RE: [GD-General] Key handling revisited
> >
> > I think there are two separate issues, which Brian sort-of talked
> about.
> >
> > -Text input. Need to handle international chars,
> shift-alt-meta-squiggle
> > wierdness and all that. As much as possible, try to get the OS to do
> all
> > the
> > hard work. Usually queue-driven, so you won't miss keypresses. I don't
> > know
> > anything about macs, but on Windows you just use the WM_CHAR messages.
> > They
> > will tell you what is printed on top of the key that the user pressed,
> and
> > handle virtual keyboards and macros and so on. Probably exposed as a
> > stream
> > of ASCII-like things, except probably 16-bits wide. Could possibly use
> > UNICODE?
>
> Ahh, memories.
>
> Just remember that "there is not necessarily a one-to-one correspondence
> between keys pressed and character messages generated", as the
> documentation for WM_CHAR points out.  It may take a number of key downs
> to make that shift-alt-meta-squiggle (Meta?  this better not turn into
> another damn Emacs thread!).  Also look into WM_IME_CHAR if you want to
> handle double-byte characters in a non-Unicode window.  Otherwise, you
> can get two WM_CHAR messages for a single double-byte character.
>
> And of course, you'll get different actual values in your events
> depending on whether you're a Unicode window or not.  And Unicode
> windows aren't supported directly on Win9x.  Ugh.  Java, anyone? :)
>
> Macs - under the Classic event manager - deal with 8-bit keys and send
> the scan code along with the translated char.  I don't know how this has
> changed under Cocoa or Carbon.  It would be like a WM_CHARDOWN/WM_CHARUP
> combo if such a thing existed.  It's also 8-bit only so if you want to
> do Unicode translation you have to buffer up data until you get a valid
> conversion result into the current system script - at least, I'm pretty
> sure we handled it.
>
> So our x-plat layer used those events above and followed this model:
>
> * send keydown/keyup messages with our own virtual key constants, for
> dealing with gameplay presses - sending kLeftArrowKey, etc.
> * send Unicode char messages when x number of key presses generated a
> valid char, according to the OS
>
> But it would probably be better to poll for the first class of events
> and only send the second as actual events, which is the approach Tom
> outlines.  Either one is possible.
>
> So happy to not be dealing with this anymore,
>
> --brian
>
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_idU7

RE: [GD-General] Key handling revisited

[Matt D. <ma...@co...>]

Hi,

Most keyboards rely on single key presses or multiple keys being pressed at
the same time (e.g. Ctrl-F).  However, on some keyboards (like the German
ones) there are multiple key presses that are not done at the same time.  So
if you're allowing entering of text, be wary of that.

The best way of dealing with it is to treat as you would, say, your
renderer.  Figure out the use cases and design a high-level interface to
keyboard input.  Provide drivers under that layer which specialise in PC and
Macs and so forth.

For Galleon, we provide three mappings.

First, we map 'physical' buttons to 'virtual' buttons.  These removes the
platform dependency.  The virtual buttons are the keys used on our imaginary
keyboard.  Next we map 'virtual' to 'command' buttons.  This is called the
user map and is what the player creates by redefining the controls.
Finally, we map those keys to commands via a one-to-many mapping.  The game
reacts to the commands.

But the important thing to point out is that most of our input code is
platform independent except the code that provides the 'physical' button
information.

If you require text input, such a system would not be efficient.  Provide a
load of accessor functions, such as GetChar(), GetWideChar(),
IsControlPressed(), IsShiftPressed(), IsKeyUp(), IsKeyDown().  These
functions could be part of a class called CKeyboardEvent (or whatever) whose
sole purpose is to hold information of a single (or multiple in the case of
German keyboards) key press.  Provide CKeyboardDevice to provide the
platform dependecies and CKeyboardManager to use that and spit out
CKeyboardEvent classes.


Take care and good luck,



Matt Davies
Programmer, Confounding Factor
ma...@co...
www.confounding-factor.com



> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Brian Sharon
> Sent: 11 February 2002 16:08
> To: Tom Forsyth; Jamie Fowlston;
> gam...@li...
> Subject: RE: [GD-General] Key handling revisited
>
>
> > -----Original Message-----
> > From: Tom Forsyth [mailto:to...@mu...]
> > Sent: Monday, February 11, 2002 3:08 AM
> > To: Jamie Fowlston; gam...@li...
> > Subject: RE: [GD-General] Key handling revisited
> >
> > I think there are two separate issues, which Brian sort-of talked
> about.
> >
> > -Text input. Need to handle international chars,
> shift-alt-meta-squiggle
> > wierdness and all that. As much as possible, try to get the OS to do
> all
> > the
> > hard work. Usually queue-driven, so you won't miss keypresses. I don't
> > know
> > anything about macs, but on Windows you just use the WM_CHAR messages.
> > They
> > will tell you what is printed on top of the key that the user pressed,
> and
> > handle virtual keyboards and macros and so on. Probably exposed as a
> > stream
> > of ASCII-like things, except probably 16-bits wide. Could possibly use
> > UNICODE?
>
> Ahh, memories.
>
> Just remember that "there is not necessarily a one-to-one correspondence
> between keys pressed and character messages generated", as the
> documentation for WM_CHAR points out.  It may take a number of key downs
> to make that shift-alt-meta-squiggle (Meta?  this better not turn into
> another damn Emacs thread!).  Also look into WM_IME_CHAR if you want to
> handle double-byte characters in a non-Unicode window.  Otherwise, you
> can get two WM_CHAR messages for a single double-byte character.
>
> And of course, you'll get different actual values in your events
> depending on whether you're a Unicode window or not.  And Unicode
> windows aren't supported directly on Win9x.  Ugh.  Java, anyone? :)
>
> Macs - under the Classic event manager - deal with 8-bit keys and send
> the scan code along with the translated char.  I don't know how this has
> changed under Cocoa or Carbon.  It would be like a WM_CHARDOWN/WM_CHARUP
> combo if such a thing existed.  It's also 8-bit only so if you want to
> do Unicode translation you have to buffer up data until you get a valid
> conversion result into the current system script - at least, I'm pretty
> sure we handled it.
>
> So our x-plat layer used those events above and followed this model:
>
> * send keydown/keyup messages with our own virtual key constants, for
> dealing with gameplay presses - sending kLeftArrowKey, etc.
> * send Unicode char messages when x number of key presses generated a
> valid char, according to the OS
>
> But it would probably be better to poll for the first class of events
> and only send the second as actual events, which is the approach Tom
> outlines.  Either one is possible.
>
> So happy to not be dealing with this anymore,
>
> --brian
>
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_idU7

Re: [GD-General] Key handling revisited

[Erwin de V. <er...@vo...>]

> The only crossover between the two is when the user is defining their
keys.
> Then you want to find what is printed on the top of the key that the
> "gamepad" has pressed down. Fortunately you can assume that when they are
> being defined, the user will be pressing exactly one key at a time, so
just
> watch both systems to see which WM_CHAR-like message corresponds to which
> keypad keydown.

You can also get the name of the button through Directinput. We used that in
our game for key defining (dont use it for text input!!), but we've seen
some really strange names on some systems. All caps, different naming styles
for the arrow keys, and more of that nonsens. Though i havent looked into it
deeply it appears to depend on a lot of things. Hope it helps.

Erwin

RE: [GD-General] Key handling revisited

[Grills, J. <jg...@so...>]

We have a totally separate system for text input and game control input as
Tom suggests.  The text input system is reasonably straight forward, but the
game control system is pretty interesting, so it's all I'll describe here.

We have a class in the engine called InputMap which converts raw user input
into a series of game events, which is all the game ever sees.  The raw user
input is taken as a stream of events, where an event contains the device id
and the change that happened to it.  All we need to do in code is read the
hardware and send the events to the InputMap.  Then, in data, we create a
new InputMap mapping from the hardware (keyboard keys, joystick buttons,
mouse buttons, or any and all of them) to the game event identifiers.  Each
game event has both a type (move forward, turn, shoot, etc) and a float
value.  We treat digital buttons (keys, many game pad buttons) different
from anything with variable input (joystick axis, pressure sensitive game
pad buttons, POV hats).  

Digital buttons can have several messages associated with them sent at
different times.  There's a message when the buttons is pressed, one when
it's still down (repeated), one when it is released, and one if the
application loses focus (used only by PC platforms).  If you want a button
to issue a single event, you likely only assign it a pressed message.  If
you want it to react whenever it is down, you could assign it the same
pressed and repeat message.  If you want something like a Decent plasma gun,
the press message could send a "start charging" message, the repeat message
could send a "continue charging" message, and the release could send a
"fire" message.  If the user task-switched while charging, the lost focus
message could be "abort firing".  Buttons can also have the same message but
different values associated with them.  Strafe left and strafe right can be
implemented with two buttons but one game message with different values
(-1.0 and 1.0).  You could also have walk, walk fast, and walk slow be three
buttons sending "walk" with different values. 

Some buttons can be designated as shifting keys.  Shifting keys add or
remove bits from a shift state bit mask.  The current shift state bit mask
determines which button map will be used for the messages.  One of the most
tricky problems to solve was what to do when a user presses a key, then
presses a shift key, then releases the key before releasing the shift key.
We decided to bind all the messages a key will ever send at the time that it
is pressed.  This seems to have the least amount of user surprise, and is
relatively simple to implement (just copy the data on press).

Joystick axis and POV hats are handled differently.  They always send down
their message per frame, but the value is taken from a mapping of the
position of the stick or the hat.  Pressure sensitive buttons could be
handled the same way.  Any change to the shifting state instantly changes
the messages that variable input device sends.

In your code that processes the game events, you may need to be careful to
make sure that users can't gain an advantage by mapping multiple keys to the
same event and have the sum of those events exceed some allowable game play
threshold.

Hope this helps,

Jeff Grills
Technical Director, Austin Studio
Sony Online Entertainment

-----Original Message-----
From: Jamie Fowlston [mailto:ja...@qu...]
Sent: Monday, February 11, 2002 5:18 AM
To: gam...@li...
Subject: RE: [GD-General] Key handling revisited


that's really my problem :) for any given system, there's an obvious
approach to use. just trying to unite the ps2 and pc principles is hard, let
alone going further afield than that. the pc is event driven, whereas the
ps2 is state driven. you can translate between the two, but it's a bit
whiffy.

jamie


-----Original Message-----
From: Tom Forsyth [mailto:to...@mu...]
Sent: 11 February 2002 11:08
To: Jamie Fowlston; gam...@li...
Subject: RE: [GD-General] Key handling revisited


I think there are two separate issues, which Brian sort-of talked about.

-Text input. Need to handle international chars, shift-alt-meta-squiggle
wierdness and all that. As much as possible, try to get the OS to do all the
hard work. Usually queue-driven, so you won't miss keypresses. I don't know
anything about macs, but on Windows you just use the WM_CHAR messages. They
will tell you what is printed on top of the key that the user pressed, and
handle virtual keyboards and macros and so on. Probably exposed as a stream
of ASCII-like things, except probably 16-bits wide. Could possibly use
UNICODE?

-Game control input. You just want the keyboard to be returned as a big
keypad with 100+ keys, and tell you which keys are pressed at any one time.
This is what DirectInput exposes. Usually polled, not queue-driven, it's
just a big array of key states (up/down).


The only crossover between the two is when the user is defining their keys.
Then you want to find what is printed on the top of the key that the
"gamepad" has pressed down. Fortunately you can assume that when they are
being defined, the user will be pressing exactly one key at a time, so just
watch both systems to see which WM_CHAR-like message corresponds to which
keypad keydown.


For Windows+DirectX, you're pretty sorted - WM_CHAR for the first,
DirectInput for the second. I don't know much about other platforms.


Tom Forsyth - Muckyfoot bloke.

What's he up to now (and can I have a go)?
http://www.eidosinteractive.com/downloads/search.html?gmid=86

> -----Original Message-----
> From: Jamie Fowlston [mailto:ja...@qu...]
> Sent: 11 February 2002 10:36
> To: gam...@li...
> Subject: RE: [GD-General] Key handling revisited
>
>
> I'm also interested in a related issue: if anyone has a
> sensible input model
> that can work across computers and consoles, i'd love to hear
> it :) at the
> moment the plan is to reimplement the control interface on
> each platform
> (it'll need tweaking for each platform anyway), but i don't
> want to have to
> do more work than is necessary on a problem that _surely_
> must have been
> solved? :)
>
> Jamie

RE: [GD-General] Key handling revisited

[Brian S. <bs...@mi...>]

> -----Original Message-----
> From: Tom Forsyth [mailto:to...@mu...]
> Sent: Monday, February 11, 2002 3:08 AM
> To: Jamie Fowlston; gam...@li...
> Subject: RE: [GD-General] Key handling revisited
>=20
> I think there are two separate issues, which Brian sort-of talked
about.
>=20
> -Text input. Need to handle international chars,
shift-alt-meta-squiggle
> wierdness and all that. As much as possible, try to get the OS to do
all
> the
> hard work. Usually queue-driven, so you won't miss keypresses. I don't
> know
> anything about macs, but on Windows you just use the WM_CHAR messages.
> They
> will tell you what is printed on top of the key that the user pressed,
and
> handle virtual keyboards and macros and so on. Probably exposed as a
> stream
> of ASCII-like things, except probably 16-bits wide. Could possibly use
> UNICODE?

Ahh, memories.

Just remember that "there is not necessarily a one-to-one correspondence
between keys pressed and character messages generated", as the
documentation for WM_CHAR points out.  It may take a number of key downs
to make that shift-alt-meta-squiggle (Meta?  this better not turn into
another damn Emacs thread!).  Also look into WM_IME_CHAR if you want to
handle double-byte characters in a non-Unicode window.  Otherwise, you
can get two WM_CHAR messages for a single double-byte character.

And of course, you'll get different actual values in your events
depending on whether you're a Unicode window or not.  And Unicode
windows aren't supported directly on Win9x.  Ugh.  Java, anyone? :)

Macs - under the Classic event manager - deal with 8-bit keys and send
the scan code along with the translated char.  I don't know how this has
changed under Cocoa or Carbon.  It would be like a WM_CHARDOWN/WM_CHARUP
combo if such a thing existed.  It's also 8-bit only so if you want to
do Unicode translation you have to buffer up data until you get a valid
conversion result into the current system script - at least, I'm pretty
sure we handled it.

So our x-plat layer used those events above and followed this model:

* send keydown/keyup messages with our own virtual key constants, for
dealing with gameplay presses - sending kLeftArrowKey, etc.
* send Unicode char messages when x number of key presses generated a
valid char, according to the OS

But it would probably be better to poll for the first class of events
and only send the second as actual events, which is the approach Tom
outlines.  Either one is possible.

So happy to not be dealing with this anymore,
=20
--brian

RE: [GD-General] Key handling revisited

[Jamie F. <ja...@qu...>]

that's really my problem :) for any given system, there's an obvious
approach to use. just trying to unite the ps2 and pc principles is hard, let
alone going further afield than that. the pc is event driven, whereas the
ps2 is state driven. you can translate between the two, but it's a bit
whiffy.

jamie


-----Original Message-----
From: Tom Forsyth [mailto:to...@mu...]
Sent: 11 February 2002 11:08
To: Jamie Fowlston; gam...@li...
Subject: RE: [GD-General] Key handling revisited


I think there are two separate issues, which Brian sort-of talked about.

-Text input. Need to handle international chars, shift-alt-meta-squiggle
wierdness and all that. As much as possible, try to get the OS to do all the
hard work. Usually queue-driven, so you won't miss keypresses. I don't know
anything about macs, but on Windows you just use the WM_CHAR messages. They
will tell you what is printed on top of the key that the user pressed, and
handle virtual keyboards and macros and so on. Probably exposed as a stream
of ASCII-like things, except probably 16-bits wide. Could possibly use
UNICODE?

-Game control input. You just want the keyboard to be returned as a big
keypad with 100+ keys, and tell you which keys are pressed at any one time.
This is what DirectInput exposes. Usually polled, not queue-driven, it's
just a big array of key states (up/down).


The only crossover between the two is when the user is defining their keys.
Then you want to find what is printed on the top of the key that the
"gamepad" has pressed down. Fortunately you can assume that when they are
being defined, the user will be pressing exactly one key at a time, so just
watch both systems to see which WM_CHAR-like message corresponds to which
keypad keydown.


For Windows+DirectX, you're pretty sorted - WM_CHAR for the first,
DirectInput for the second. I don't know much about other platforms.


Tom Forsyth - Muckyfoot bloke.

What's he up to now (and can I have a go)?
http://www.eidosinteractive.com/downloads/search.html?gmid=86

> -----Original Message-----
> From: Jamie Fowlston [mailto:ja...@qu...]
> Sent: 11 February 2002 10:36
> To: gam...@li...
> Subject: RE: [GD-General] Key handling revisited
>
>
> I'm also interested in a related issue: if anyone has a
> sensible input model
> that can work across computers and consoles, i'd love to hear
> it :) at the
> moment the plan is to reimplement the control interface on
> each platform
> (it'll need tweaking for each platform anyway), but i don't
> want to have to
> do more work than is necessary on a problem that _surely_
> must have been
> solved? :)
>
> Jamie
>
>
> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Brian Hook
> Sent: 10 February 2002 02:39
> To: gam...@li...
> Subject: [GD-General] Key handling revisited
>
>
> After thinking about my key handling situation for a day, I
> think I finally
> stumbled upon the obvious solution.
>
> Fundamentally I wasn't differentiating between ASCII
> characters and raw key
> codes, so I ended up just having a jumble of logic both on
> the key reading
> side (my platform driver) and on the application side.  My
> HEvent structure
> only had a keyCode member, which mapped to my system virtual
> key constants
> (directly taken from the VK_ constants in WINUSER.H so that
> there was a
> one-to-one mapping).
>
> To simplify my life, I just added another field, evChar,
> which is the ASCII
> representation of the virtual key code.  So I can
> differentiate between top
> row "0", keypad "0", or just read an ASCII "0" depending on
> the needs of
> the calling routine.
>
> Yeah, kinda duh, but for some reason I was just focused on
> having a single
> key code and doing the appropriate thing with it at all times.
>
> Of course, this doesn't address the issue of international
> keyboards.  I
> have no idea what to do about that, other than just hope and
> pray it's not
> a problem.  And if it is, I guess I'll deal with it then.
>
> Brian
>
>
>
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
>
>
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
>

RE: [GD-General] Key handling revisited

[Tom F. <to...@mu...>]

I think there are two separate issues, which Brian sort-of talked about.

-Text input. Need to handle international chars, shift-alt-meta-squiggle
wierdness and all that. As much as possible, try to get the OS to do all the
hard work. Usually queue-driven, so you won't miss keypresses. I don't know
anything about macs, but on Windows you just use the WM_CHAR messages. They
will tell you what is printed on top of the key that the user pressed, and
handle virtual keyboards and macros and so on. Probably exposed as a stream
of ASCII-like things, except probably 16-bits wide. Could possibly use
UNICODE?

-Game control input. You just want the keyboard to be returned as a big
keypad with 100+ keys, and tell you which keys are pressed at any one time.
This is what DirectInput exposes. Usually polled, not queue-driven, it's
just a big array of key states (up/down).


The only crossover between the two is when the user is defining their keys.
Then you want to find what is printed on the top of the key that the
"gamepad" has pressed down. Fortunately you can assume that when they are
being defined, the user will be pressing exactly one key at a time, so just
watch both systems to see which WM_CHAR-like message corresponds to which
keypad keydown.


For Windows+DirectX, you're pretty sorted - WM_CHAR for the first,
DirectInput for the second. I don't know much about other platforms.


Tom Forsyth - Muckyfoot bloke.

What's he up to now (and can I have a go)?
http://www.eidosinteractive.com/downloads/search.html?gmid=86

> -----Original Message-----
> From: Jamie Fowlston [mailto:ja...@qu...]
> Sent: 11 February 2002 10:36
> To: gam...@li...
> Subject: RE: [GD-General] Key handling revisited
> 
> 
> I'm also interested in a related issue: if anyone has a 
> sensible input model
> that can work across computers and consoles, i'd love to hear 
> it :) at the
> moment the plan is to reimplement the control interface on 
> each platform
> (it'll need tweaking for each platform anyway), but i don't 
> want to have to
> do more work than is necessary on a problem that _surely_ 
> must have been
> solved? :)
> 
> Jamie
> 
> 
> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Brian Hook
> Sent: 10 February 2002 02:39
> To: gam...@li...
> Subject: [GD-General] Key handling revisited
> 
> 
> After thinking about my key handling situation for a day, I 
> think I finally
> stumbled upon the obvious solution.
> 
> Fundamentally I wasn't differentiating between ASCII 
> characters and raw key
> codes, so I ended up just having a jumble of logic both on 
> the key reading
> side (my platform driver) and on the application side.  My 
> HEvent structure
> only had a keyCode member, which mapped to my system virtual 
> key constants
> (directly taken from the VK_ constants in WINUSER.H so that 
> there was a
> one-to-one mapping).
> 
> To simplify my life, I just added another field, evChar, 
> which is the ASCII
> representation of the virtual key code.  So I can 
> differentiate between top
> row "0", keypad "0", or just read an ASCII "0" depending on 
> the needs of
> the calling routine.
> 
> Yeah, kinda duh, but for some reason I was just focused on 
> having a single
> key code and doing the appropriate thing with it at all times.
> 
> Of course, this doesn't address the issue of international 
> keyboards.  I
> have no idea what to do about that, other than just hope and 
> pray it's not
> a problem.  And if it is, I guess I'll deal with it then.
> 
> Brian
> 
> 
> 
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
> 
> 
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
> 

RE: [GD-General] Key handling revisited

[Jamie F. <ja...@qu...>]

I'm also interested in a related issue: if anyone has a sensible input model
that can work across computers and consoles, i'd love to hear it :) at the
moment the plan is to reimplement the control interface on each platform
(it'll need tweaking for each platform anyway), but i don't want to have to
do more work than is necessary on a problem that _surely_ must have been
solved? :)

Jamie


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Brian Hook
Sent: 10 February 2002 02:39
To: gam...@li...
Subject: [GD-General] Key handling revisited


After thinking about my key handling situation for a day, I think I finally
stumbled upon the obvious solution.

Fundamentally I wasn't differentiating between ASCII characters and raw key
codes, so I ended up just having a jumble of logic both on the key reading
side (my platform driver) and on the application side.  My HEvent structure
only had a keyCode member, which mapped to my system virtual key constants
(directly taken from the VK_ constants in WINUSER.H so that there was a
one-to-one mapping).

To simplify my life, I just added another field, evChar, which is the ASCII
representation of the virtual key code.  So I can differentiate between top
row "0", keypad "0", or just read an ASCII "0" depending on the needs of
the calling routine.

Yeah, kinda duh, but for some reason I was just focused on having a single
key code and doing the appropriate thing with it at all times.

Of course, this doesn't address the issue of international keyboards.  I
have no idea what to do about that, other than just hope and pray it's not
a problem.  And if it is, I guess I'll deal with it then.

Brian



_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=557

[GD-General] Key handling revisited

[Brian H. <bri...@py...>]

After thinking about my key handling situation for a day, I think I finally 
stumbled upon the obvious solution.

Fundamentally I wasn't differentiating between ASCII characters and raw key 
codes, so I ended up just having a jumble of logic both on the key reading 
side (my platform driver) and on the application side.  My HEvent structure 
only had a keyCode member, which mapped to my system virtual key constants 
(directly taken from the VK_ constants in WINUSER.H so that there was a 
one-to-one mapping).

To simplify my life, I just added another field, evChar, which is the ASCII 
representation of the virtual key code.  So I can differentiate between top 
row "0", keypad "0", or just read an ASCII "0" depending on the needs of 
the calling routine.

Yeah, kinda duh, but for some reason I was just focused on having a single 
key code and doing the appropriate thing with it at all times.

Of course, this doesn't address the issue of international keyboards.  I 
have no idea what to do about that, other than just hope and pray it's not 
a problem.  And if it is, I guess I'll deal with it then.

Brian

Re: [GD-General] FPS style input Control

[Brian H. <bri...@py...>]

I'm really not trying to be flippant, but why not just clamp?

if ( pitch += pitchAdjust > 90 ) pitch = 90;
etc.

At 10:00 PM 2/8/2002 -0600, Idahosa Edokpayi wrote:
>Given control input with X and Y axes how do I use the axes to do FPS style
>of control. I know about pitch and yaw but I would like to not have the
>discontinuity at the poles, i.e. you can't look straight up or down.
>
>Idahosa Edokpayi
>
>
>
>_______________________________________________
>Gamedevlists-general mailing list
>Gam...@li...
>https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
>Archives:
>http://sourceforge.net/mailarchive/forum.php?forum_id=557

[GD-General] FPS style input Control

[Idahosa E. <ida...@sw...>]

Given control input with X and Y axes how do I use the axes to do FPS style
of control. I know about pitch and yaw but I would like to not have the
discontinuity at the poles, i.e. you can't look straight up or down.

Idahosa Edokpayi

[GD-General] Cross-platform key handling

[Brian H. <bri...@py...>]

This is something that's been bugging me for a while.  Right now my 
multi-platform key handling is a bit of a mess, and I'm probably going to 
end up rewriting it.

The problem is that each platform has a different idea of how much 
information to export to you about keys being pressed.  On Windows it's 
pretty simple -- you trap WM_KEYDOWN which are system codes that you can 
translate to ASCII using MapVirtualKey().  On the Mac it's a little uglier 
because you don't get individual scan code presses that you then translate, 
instead you get cooked key codes.  For example, ctrl-f is, literally, 
ctrl-f, not a 'f' with the control modifier pressed.

Now, on Windows it's possible to get both cooked and uncooked data by 
trapping WM_CHAR and WM_KEYDOWN (and WM_SYSKEYDOWN).  On the Mac you have 
to deconstruct it into constituent pieces.

On top of that, different platforms have different keys.  The iMac, for 
example, doesn't have function keys or a key pad.

So there are two issues: how to write a generic event handling mechanism 
that's transparent to the application, and how to deal with keys that may 
disappear on different systems.

For the former, I'm currently forcing the app to handle key code -> 
character mapping.  This means that on the Mac, I have to deconstruct 
characters into appropriate key code/modifier key combinations.  There's 
also a bit of ugliness reconciling the fact that different platforms may 
not distinguish (or export) certain key presses (e.g. keypad arrow vs. 
inverted-t arrow keys, numpad / vs. keyboard /, etc.).

For handling non-existent keys, I'm basically just avoiding those keys.  My 
apps don't use F-keys and don't distinguish between top row numbers and 
keypad numbers, which is somewhat limiting.

Is there a cleaner way to handle all this?

Brian

[GD-General] Code Review Anyone?

[Chris B. <Chr...@ma...>]

I've been working on my engine for almost a year now, learning and implementing as I go. My goal has always been to write clear, well designed code that is modular and platform independent.

I've recently produced my first public release, and I'm looking to consolidate my code a bit before launching forward and adding the next wave of features. 

So, in the interests of this goal I was curious as to wether anyone was interested in having a look over my code and making any comments. I'm interested in everything anyone has to say, wether it by style, code of general Zen. I'm sure I'll learn buckets for any comments you make. 

My source code is here http://fourth.flipcode.com/Game.zip (923kb). It contains all libraries needed for compilation, though currently it is setup for compiling in the .NET (nothing special Visual Studio 7, c++).

Many Thanks

Chris Brodie


NOTICE
This e-mail and any attachments are confidential and may contain copyright material of Macquarie Bank or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Bank does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Bank. 

Re: [GD-General] Any suggestion on aircraft geometry modeling?

[Zhou H. <ha...@ep...>]

Thank you Tom and Jamie.

Jamie wrote:
> The standard way, to the best of my knowledge, is to split
> the object into its movable pieces, and LOD (however you wish)
> them independently.

Yes, that's what I'm doing right now.

Tom wrote:
> I'm pretty sure there was a discussion a while back about this sort of thing

Ok, I'll go check archives.

Zhou Haidong

RE: [GD-General] CodeWarrior

[Leath M. <Lea...@en...>]

Bah, you just hate everything... ;)

Leathal.

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Brian Hook
> Sent: Wednesday, 16 January 2002 11:15 AM
> To: gam...@li...
> Subject: [GD-General] CodeWarrior
> =

> =

> It sucks.
> =

> Sorry, had to vent.
> =

> Brian
> =

> =

> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> 

[GD-General] CodeWarrior

[Brian H. <bri...@py...>]

It sucks.

Sorry, had to vent.

Brian

Re: [GD-General] Practical Game Structure.

[Erwin de V. <er...@vo...>]

No, you're right about this. I've had the same problem before. Very annoying
indeed. I just wanted to fix this asap, because it was taking a lot of time
to display those damn warnings.

It could be useful to merge several libraries into a single library though.
Imagine a single shipping product for developers to use. Now YOU may want to
split them in several pieces for convenience, but the end user doesnt want
to know that! They dont like linking with 20 libraries at all! =)

It should be an option though. (Like a lot of things!)

Erwin

----- Original Message -----
From: "Stefan Boberg" <sbo...@te...>
To: <gam...@li...>
Sent: Tuesday, January 15, 2002 18:00
Subject: RE: [GD-General] Practical Game Structure.


> >   Let me guess... you have included the Common static lib as a
> > dependency in your other static lib projects?? Don't :)
>
>   Sorry, that got sent before I was finished!! Let me elaborate: in
> Visual Studio, for some obscure reason it appears as though the
> librarian/linker/whatever actually pulls in all object files from static
> libraries that are in your dependency list for the Visual Studio project
> and bundles them into your freshly created static library. God knows
> why... I really can't see any scenario where that would be useful.
>
>   Or perhaps I am just operating the machinery wrong?
>
> Cheers,
> Stef! :)
> --
> Stefan Boberg - R&D Manager, Team17 Software Ltd.
> bo...@te...
>
>
>
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
>
>

RE: [GD-General] Assertions, pre/post-conditions and call tracing

[Jesse J. <jes...@mi...>]

At 2:25 PM -0800 1/15/02, Brian Hook wrote:
>  > Are you sure this is true? It doesn't make sense to me: if a method
>>  is unable to complete and has to throw an exception the
>>  post-condition need not hold (eg an AddObject() method may not
>>  actually add the object if it runs out of memory).
>
>Sorry, I meant "no matter how it is exited, barring exceptions" =)

Ahh, that would be nice. Another tough thing to do in C++ though.

>  > Invariants aren't too bad. The hard things revolve around pre and
>>  post-conditions. The hardest is that derived classes are allowed to
>>  weaken pre-conditions and strengthen post-conditions (ie they may
>>  accept a wider range of input and more tightly specify what they
>>  return).
>
>Under Eiffel this isn't the case (at least, I don't think it is) -- you
>can only strength both pre and post-conditions.

Nope, just looked it up. Derived classes *can* strengthen 
post-conditions. What this means is that the derived class promises 
to do a bit more than the base class. In other words after the method 
call the possible derived object states are a subset of the base 
object states. But this is still OK because client code has to work 
with the original post-condition.

>  > The other problem is that objects can temporarily fall into a bad
>>  state as their methods execute. This can cause problems if a public
>>  method winds up being called. The fix is to only call the invariant
>>  method when a public method is first entered and exited. This does
>>  turn out to be a problem in my experience.
>
>Yes, that's true, but my guess is that this is more of a case of
>defining the proper invariants, otherwise you would be in hell with
>either a lot of in-line code, or a bunch of helper functions that were
>reporting erroneous conditions.

I'm not quite sure what you're saying here. The problem I'm talking 
about has nothing to do with "proper invariants". In fact, the 
stricter the invariant the more of a problem you have. You can 
eliminate the problem by adopting a convention of having public 
methods call private helper methods instead of the public methods, 
but this is a lot to ask of clients.

   -- Jesse

RE: [GD-General] Assertions, pre/post-conditions and call tracing

[Brian H. <bri...@py...>]

> Are you sure this is true? It doesn't make sense to me: if a method 
> is unable to complete and has to throw an exception the 
> post-condition need not hold (eg an AddObject() method may not 
> actually add the object if it runs out of memory).

Sorry, I meant "no matter how it is exited, barring exceptions" =)

> Invariants aren't too bad. The hard things revolve around pre and 
> post-conditions. The hardest is that derived classes are allowed to 
> weaken pre-conditions and strengthen post-conditions (ie they may 
> accept a wider range of input and more tightly specify what they 
> return).

Under Eiffel this isn't the case (at least, I don't think it is) -- you
can only strength both pre and post-conditions.

> The other problem is that objects can temporarily fall into a bad 
> state as their methods execute. This can cause problems if a public 
> method winds up being called. The fix is to only call the invariant 
> method when a public method is first entered and exited. This does 
> turn out to be a problem in my experience.

Yes, that's true, but my guess is that this is more of a case of
defining the proper invariants, otherwise you would be in hell with
either a lot of in-line code, or a bunch of helper functions that were
reporting erroneous conditions.

> Note that invariants are called explicitly via a macro.  I used to 
> call these from the PRECONDITION macro, but that's annoying because 
> most classes don't have invariants and PRECONDITION and POSTCONDITION 
> are useful pretty much everywhere (if nothing else as a documentation 
> aid).

Right, which is a cornerstone of Eiffel's DbC.
 
Thanks for the code, it may take me a while to sift through all of it.

Brian

Re: [GD-General] Assertions, pre/post-conditions and call tracing

[Jesse J. <jes...@mi...>]

At 8:19 AM -0800 1/15/02, Brian Hook wrote:
>I've gotten into the habit of making tons of function pre-conditions 
>and post-conditions that can optionally be compiled away.  This is a 
>Eiffel habit picked up second-hand from a former coworker of mine.
>
>In Eiffel, you can set up a bunch of safeguards to do basic sanity 
>checking.  The safeguards are pre-conditions (validate state and 
>parameters before a method/"feature" is executed); post-conditions 
>(validate state and parameters after a "feature" is executed); and 
>class-invariants (check the integrity of the object after ANY 
>"feature" is executed).
>
>Eiffel does this with "require" and "ensure" clauses that are 
>analogous to assert() expressions in C++, but are a bit more 
>readable.  In addition, the "ensure" clause is guaranteed to be 
>evaluated no matter how the function is exited (so you don't have to 
>do a "goto ensure" all over your code to make sure you exit out the 
>same place).

Are you sure this is true? It doesn't make sense to me: if a method 
is unable to complete and has to throw an exception the 
post-condition need not hold (eg an AddObject() method may not 
actually add the object if it runs out of memory).

>I don't believe there's any clean way to do a class-invariant in 
>C++, but I may be wrong on that count.  The closest thing I can 
>think of is making each class declare an InvarianceChecker class 
>that is instanced at the beginning of each method and whose 
>constructor/destructor pair do verification.

Invariants aren't too bad. The hard things revolve around pre and 
post-conditions. The hardest is that derived classes are allowed to 
weaken pre-conditions and strengthen post-conditions (ie they may 
accept a wider range of input and more tightly specify what they 
return). I don't think there is a good way to handle this in C++ 
barring a custom preprocessor. However, personally, I haven't missed 
it much.

The other problem is that objects can temporarily fall into a bad 
state as their methods execute. This can cause problems if a public 
method winds up being called. The fix is to only call the invariant 
method when a public method is first entered and exited. This does 
turn out to be a problem in my experience.

I used to handle handle the nesting issues via a mixin class, but 
it's a bit ugly to muck with inheritance for something like this. 
What I do now is use a static map that maps this pointers to nesting 
counts.

FWIW here's the code I use:

#if DEBUG
     void AssertFailed(const char* expr, const char* file, int line);

     #define ASSERT(p)                   (!(p) ? AssertFailed(#p, 
__FILE__, __LINE__) : (void) 0)
     #define PRECONDITION(p)             ASSERT(p)
     #define POSTCONDITION(p)            ASSERT(p)
     #define OBSERVE(type, name, var)    type name(var)
#else   
     inline void DUMMY_TRACE(...)        {}

     #if ASSERTS_THROW
         void AssertFailed(const char*, const char*, int);
        
         #define ASSERT(p)                 (!(p) ? AssertFailed(#p, 
__FILE__, __LINE__) : (void) 0)       
         #define PRECONDITION(p)           ASSERT(p)
         #define POSTCONDITION(p)          ASSERT(p)
         #define OBSERVE(type, name, var)  type name(var)
     #else
         #define ASSERT(p)                 ((void) 0)
         #define PRECONDITION(p)           ((void) 0)
         #define POSTCONDITION(p)          ((void) 0)
         #define OBSERVE(type, name, var)  ((void) 0)
     #endif
#endif

AssertFailed either breaks into the debugger or throws an exception. 
Here's an example of how the macros are used:

void Names::AddName(const std::string& name)
{
     PRECONDITION(!name.empty());
     PRECONDITION(!this->HasName(name));
     OBSERVE(uint32, oldCount, mNames.size());
     CHECK_INVARIANT;
    
     (void) mNames.insert(name);

     POSTCONDITION(oldCount+1 == mNames.size());
     POSTCONDITION(this->HasName(name));
}

Note that invariants are called explicitly via a macro.  I used to 
call these from the PRECONDITION macro, but that's annoying because 
most classes don't have invariants and PRECONDITION and POSTCONDITION 
are useful pretty much everywhere (if nothing else as a documentation 
aid).

Here's the (core) code I use for invariants. The CHECK_INVARIANT 
creates a stack based class that calls the invariant method when it's 
constructed and when it's destroyed:

#if DEBUG
#if __GNUC__    // $$ gcc 2.95 crashes when this is a member function...
     template <class T>
     void InvokeInvariant(const void* object)
     {void (T::*method)() const = &T::Invariant; (static_cast<const 
T*>(object)->*method)();}
#endif

class CheckInvariant {

public:
                     ~CheckInvariant()                                   
                     {LeavingObject(mObject); if (mInvoker) mInvoker(mObject);}

                     template <class T>
                     CheckInvariant(const T* object) : mObject(object)   
                     {mInvoker = NULL; if (EnteringObject(mObject)) 
{mInvoker = &InvokeInvariant<T>; mInvoker(mObject);}}

public:
     static    bool  EnteringObject(const void* object);
     static    void  LeavingObject(const void* object);

private:                   
#if !__GNUC__
                     template <class T>
     static    void  InvokeInvariant(const void* object)   
                     {void (T::*method)() const = &T::Invariant; 
(static_cast<const T*>(object)->*method)();}
#endif

private:                   
     void (*mInvoker)(const void*);
     const void*     mObject;
};
#endif

#if DEBUG
      #define CHECK_INVARIANT      CheckInvariant _checker(this)
     #define CALL_INVARIANT        this->Invariant()

#else   
     #define CHECK_INVARIANT       ((void) 0)
     #define CALL_INVARIANT        ((void) 0)
#endif   

static std::map<const void*, int32> sNesting;
#if THREADED
     static boost::mutex             sMutex;
#endif


bool CheckInvariant::EnteringObject(const void* thisPtr)
{
     ValidatePtr(thisPtr);   
    
#if THREADED
     boost::mutex::scoped_lock lock(sMutex);
#endif

     int32& count = sNesting[thisPtr];    // default construction of a 
POD type zero-initializes (see section 8.5 of the standard)
     bool entered = ++count == 1;
        
     return entered;
}


void CheckInvariant::LeavingObject(const void* thisPtr)
{
     ValidatePtr(thisPtr);   
    
#if THREADED
     boost::mutex::scoped_lock lock(sMutex);
#endif
    
     std::map<const void*, int32>::iterator iter = sNesting.find(thisPtr);
     ASSERT(iter != sNesting.end());
     ASSERT(iter->second > 0);
    
     if (--(iter->second) == 0)
         sNesting.erase(iter);
}

Here's an example of an Invariant:

void PerspectiveCamera::Invariant() const
{
     ASSERT(mHither > 0.0);
     ASSERT(mHither < mYon);
    
     ASSERT(IsUnitVector(mUpVector));
     ASSERT(IsUnitVector(mViewVector));
     ASSERT(AreOrthognal(mUpVector, mViewVector));
    
     ASSERT(mFieldOfView > 0.0);
     ASSERT(mFieldOfView <= 180.0);
     ASSERT(mAspectRatio > 0.0);
}

I've seen some published DbC code that had the Invariant return a 
bool that was then asserted on, but IMO this is completely 
wrong-headed: it makes it way too hard to figure out exactly what 
failed.

   -- Jesse

Re: [GD-General] Assertions, pre/post-conditions and call tracing

[Brooks B. <br...@on...>]

>Anyway, I'm interested to hear what other types of infrastructure people 
>have devised for this type of stuff.

Check out the latest Dr. Dobbs magazine for an article by the author of 
the D programming language.  I only breezed through it but plan to return 
to the examples.  D is, as you would expect, a follow up to C/C++ that 
abandons backward compatiblity in an effort to improve the language while 
retaining familiar syntax.  It includes support for design by contract 
concepts.

Brooks

RE: [GD-General] Practical Game Structure.

[Stefan B. <sbo...@te...>]

>   Let me guess... you have included the Common static lib as a
> dependency in your other static lib projects?? Don't :)

  Sorry, that got sent before I was finished!! Let me elaborate: in
Visual Studio, for some obscure reason it appears as though the
librarian/linker/whatever actually pulls in all object files from static
libraries that are in your dependency list for the Visual Studio project
and bundles them into your freshly created static library. God knows
why... I really can't see any scenario where that would be useful.

  Or perhaps I am just operating the machinery wrong?

Cheers,
Stef! :)
--
Stefan Boberg - R&D Manager, Team17 Software Ltd.
bo...@te...

RE: [GD-General] Practical Game Structure.

[Stefan B. <sbo...@te...>]

> >From this you can assume that just about everything uses common. The
> problem is that since common is included and included again and again
I
> seem to be getting linker warnings about multiply defined symbols.
I've
> been looking for an answer to this for months, not because I get a few
> warnings and it looks messy, rather I get 4000 warnings and it takes a
-
> long- time for them to be displayed, long enough that it's probably
> doubling my build time.

  Let me guess... you have included the Common static lib as a
dependency in your other static lib projects?? Don't :)

Cheers,
Stef
--
Stefan Boberg - R&D Manager, Team17 Software Ltd.
bo...@te...