2 registered members (AndrewAMD, 7th_zorro),
1,285
guests, and 4
spiders. |
Key:
Admin,
Global Mod,
Mod
|
|
|
Re: Pointer To A Pointer Problem
[Re: i_program_games]
#162993
10/24/07 22:28
10/24/07 22:28
|
Joined: Nov 2005
Posts: 94 Texas
3Dski
OP
Junior Member
|
OP
Junior Member
Joined: Nov 2005
Posts: 94
Texas
|
MISTAKE:
void* key_map[88 void* key_map_cache[88]
Should be... void* key_map[MAX_KEY_POS]; void* key_map_cache[MAX_KEY_POS];
DON'T KNOW THAT GOT MESSED UP : (
The purpose of "void *" is the general specification for a function pointer, which the handlers are. All the def_* methods are default handlers defined in defaults.c, which is the reason for the "#ifdef default_c" (which gets defined if included). Haven't dug deep enough to know why def_video() and def_def_debug() crash when invoked in this code, as opposed to the setting them to their respective "nn_*" EVENT objects.
One odd thing is, Lite-C doesn't like locally defined function pointers, so you have to define one globally for use in functions... I hate this, but I guess this rule might relate of the "clean-up" methodology they built into the engine.
The use of a struct might be good to hold at least the key's literal name its corresponding handler's pointer. You wouldn't need to cache the key's name, so I would probably leave the caching array as is, but store the structs into the key_map[]. The key's name would only really be useful when providing an interface to see and change their key mapping, which is a good feature.
I'll keep playing and testing. I really need to learn how to effectly use debugging, which isn't as clean as I'm used to (Eclipse IDE, with JAVA).
Last edited by 3Dski; 10/25/07 00:17.
|
|
|
Re: Pointer To A Pointer Problem
[Re: 3Dski]
#162994
10/25/07 03:09
10/25/07 03:09
|
Joined: Oct 2006
Posts: 106
i_program_games
Member
|
Member
Joined: Oct 2006
Posts: 106
|
With debugging I create temporary global variable with debug in the name and set them to the value I want to see. For example debugStartPoint=startPoint; I haven't found a way for the debugger to allow local variables to be seen so this is my reason for it. I'm hacking the struct now and will post shortly.
Chaos is a paradox consistently inconsistent.
|
|
|
Re: Pointer To A Pointer Problem
[Re: i_program_games]
#162996
10/25/07 04:02
10/25/07 04:02
|
Joined: Oct 2006
Posts: 106
i_program_games
Member
|
Member
Joined: Oct 2006
Posts: 106
|
Ok, I've hacked together a general on_anykey function which captures the scancode and resolves them via the key_mapping array. Anyway, here is what you were probably already thinking. As such I see no need for a struct at this time.
P.S. You have KB_C defined twice, once for the c key and once for the comma key. I changed it to KB_COMMA.
Implementation:
//Test Functions: function BeepOnce() { beep(); }
function BeepTwice() { beep(); beep(); } //End Test Functions
void gpFunction();//global function pointer
//function to handle input function processInput(scancode) { gpFunction=key_map[scancode]; gpFunction(); }
function main() { map_key(KB_B, BeepOnce); map_key(KB_C, BeepTwice); on_anykey = processInput; }
Chaos is a paradox consistently inconsistent.
|
|
|
Re: Pointer To A Pointer Problem
[Re: 3Dski]
#162998
10/25/07 07:06
10/25/07 07:06
|
Joined: Oct 2006
Posts: 106
i_program_games
Member
|
Member
Joined: Oct 2006
Posts: 106
|
Yes, disable_onkey_defaults() should only be called once. I also believe I see the value of this architecture. I think that we need an array of arrays allowing for several different key mapping "sets". For example:
//Pseudocode
#define MAIN_MENU, 0 #define OPTIONS_MENU,1
//individual key sets var arKeySetMainMenu[88]; var arKeySetOptionsMenu[88];
//all key sets var arKeySets[2][88];
arKeySets[MAIN_MENU][KB_A]=arKeySetMainMenu[KB_A]; arKeySets[MAIN_MENU][KB_B]=arKeySetMainMenu[KB_B];
arKeySets[OPTIONS_MENU][KB_A]=arKeySetOptionsMenu[KB_A]; arKeySets[OPTIONS_MENU][KB_B]=arKeySetOptionsMenu[KB_B];
Of course we'd write a function to assign the arrays to this multidimensional array. Or we could simply forgo extra arrays and shove stuff directly into the multidimensional array.
Chaos is a paradox consistently inconsistent.
|
|
|
Re: Pointer To A Pointer Problem
[Re: i_program_games]
#162999
10/28/07 20:06
10/28/07 20:06
|
Joined: Nov 2005
Posts: 94 Texas
3Dski
OP
Junior Member
|
OP
Junior Member
Joined: Nov 2005
Posts: 94
Texas
|
I thought a bit about the possibility you speak of... multiple key mapping sets.
I had out-of-town guests and wasn't able to post another correction. I found another problem with the size specified for the arrays, which ripple down to the conditions tested. I noticed that your code is using the incorrect 88, which wouldn't include the mouse and joystick scancodes. The size of the arrays should be 116 as opposed to the earlier correction I made of 115. I noticed that your code is using the incorrect 88, which wouldn't include the mouse and joystick scancodes. If one did want to just include the keyboard, the 88 would have to be upped to 89 and the loop conditions would have to test for "< 89".
Here's the corrections I made to account for all scancodes:
EDITED: BETTER NAME FOR THE FOLLOWING WOULD BE KEY_MAP_SIZE... #define MAX_KEY_POS 116
...
void init_key_map() { ... for( i = 0;i < MAX_KEY_POS; i++) ... }
void cache_key_map() { ... for( i = 0; i < MAX_KEY_POS;i++) ... }
void restore_key_map() { ... for( i = 0; i < MAX_KEY_POS; i++) ... }
void map_key(var scode, void* funct) { if (scode > 0 && scode < MAX_KEY_POS ) ... }
I think this covers the array dimensioning problems. Recognized this problem when my code was crashing, in an attempt to work on navigation control. Saw the dimensioning problem and fixed it thinking it would correct my crash. Didn't correct the crash, but at least the subtle dimension problem is fix fixed.
Last edited by 3Dski; 10/28/07 20:32.
|
|
|
|