0 Members and 7 Guests are viewing this topic.
Quote from: DJ Omnimaga on October 10, 2010, 01:04:15 pmI unfortunately cannot help due to lack of ASM knowledge but one thing to be careful with when using direct input is to make sure to either add a delay between key detections or get rid of key repeat by checking if the user has released the key you pressed before continuing further in the program. Also make sure there's a small delay before checking if people released the key, so it gets detected at all. Not sure how long the delay would be in ASM, though. Otherwise, what happens is that in your game menus, options will be chosen way too fast and it will be impossible to accurately navigate through menus due to key detection being too sensitive. In-game it can also pose problem if your game has everything moving tile-by-tile. An example of this problem would be the first version of Splut, which was submitted to the contest.I had that problem before already, but luckely Quigibo had a perfect solution for that:http://ourl.ca/6459/105146So direct input would defenitely be an option.
I unfortunately cannot help due to lack of ASM knowledge but one thing to be careful with when using direct input is to make sure to either add a delay between key detections or get rid of key repeat by checking if the user has released the key you pressed before continuing further in the program. Also make sure there's a small delay before checking if people released the key, so it gets detected at all. Not sure how long the delay would be in ASM, though. Otherwise, what happens is that in your game menus, options will be chosen way too fast and it will be impossible to accurately navigate through menus due to key detection being too sensitive. In-game it can also pose problem if your game has everything moving tile-by-tile. An example of this problem would be the first version of Splut, which was submitted to the contest.
Perhaps you could post the source, that way we could see what is really happening.
I'll look through it. Basically what I would do is run it in wabbitemu and place a breakpoint at $0038. $0038 is where the calculator goes when an interrupt happens, so if you follow the interrupt through, it will point you back to the location of the hidden EI.
(...) b_call _GetCSC CP skKey JP Z, LabelAfterLabel: di ld a, %00001010 out (03), a (...)Label: (...) JR AfterLabel
If you are still using getCSC then yes, it will be less responsive because the interrupts aren't turned on for most of the time. Which would make the getCSC only check for keypresses once per loop. If you are using direct key presses, then it wouldn't have any affect, unless you didn't make the checking routine very well.
in a,($04) bit 3,a jp z,Quit
Author
Topic: Disabeling the "ON" button during an App? (Read 11099 times)
