Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: SirCmpwn on September 19, 2010, 01:20:22 pm
-
Hello,
What is a good Axe routine to wait for all keys to be released?
-
While getKey(0)
End
-
While getKey(0)
End
^++ This.
No better way to my knowledge ;D
-
Ah, I was using While getKey:End
-
You could add a DispGraphr inside that loop, so that if you're using grayscale or something, it'll still be smooth.
-
Right, that much I know. And I usually use 4 level, so DispGraphrr would be more appropriate :)
-
While getKey(0)
End
That doesn't work in Doors CS, though. I believe I had issues with Mirage as well as WabbitEmu. but again maybe Axe Tunnel was using a slightly different code.
-
I have to do this in my code:
while getKey(0)
Pause 50
EndOtherwise it exits the loop randomly :O
-
I have to do this in my code:
while getKey(0)
Pause 50
EndOtherwise it exits the loop randomly :O
Really?
The loop is suppose to exit only when you release the key - are you sure you aren't accidentally letting go of a button?
-
Maybe you're not holding down a button when it starts. Try
:Repeat getKey(0)
:End
:While getKey(0)
:End
and see if it works.
-
I have to do this in my code:
while getKey(0)
Pause 50
EndOtherwise it exits the loop randomly :O
dittoes(i was getting a bit frustrated about it last night)...
-
getKey(0) is just really fast.. so without any pause between checking getKey(0) will mess things up. you should be okay with this:
While getKey(0)
Pause 3
End
-
I generally add a Pause(50) also.
-
If you're in Full mode then the delay in the key routine is too quick to register the key-group switch. Make sure you're in Normal mode when using direct key detection.
-
Oh I see why there are issues now. Key delay was too short. Gonna have to fix Axe Tunnel at one point then...
-
If you're in Full mode then the delay in the key routine is too quick to register the key-group switch. Make sure you're in Normal mode when using direct key detection.
I'm in Normal mode and have to do it.
-
Maybe we could have a getKey(#)r that uses the delay appropriate for 15MHz mode?
And yeah, it is annoying x.x
-
Maybe we could have a getKey(#)r that uses the delay appropriate for 15MHz mode?
And yeah, it is annoying x.x
Yeah, that'd be a great feature to add. I thought Axe'd done it already, though.
-
Shouldn't you just do
Normal
While getkey(0)
Pause 3
End
Full
?
This is what we do with grayscale actually.
-
Huh? I never heard about that. So we absolutely need a pause if we use grayscale?
-
No, he means if you're running a program at 15MHz, you have to similarly precede the DispGraphr(r) with Normal and put Full after it.
-
Oh, got it.
-
Yeah this is what I meant. We have to do the same thing with grayscale.
-
This is hilarious. I posted this hoping for a simple routine, but instead it turns into a two page mini-discussion about the best way to approach this, with 7 or 8 potential routines.
-
2 pages? That's nothing. I've seen a topic asking for simpler routines turn into huge, 7-8 page argument on an almost unrelated subject.
EDIT: Soo, which routine are you going to use?
-
This is hilarious. I posted this hoping for a simple routine, but instead it turns into a two page mini-discussion about the best way to approach this, with 7 or 8 potential routines.
Yeah but no need to be a jerk about it either if that's your intention. People just thought it would be cool if Quigibo implemented a routine making it easier for people to get around the delay issues and discussed potential routines. You have to expect this to happen in help topics. I saw this happen a lot before.
-
This is hilarious. I posted this hoping for a simple routine, but instead it turns into a two page mini-discussion about the best way to approach this, with 7 or 8 potential routines.
wow, the sarcasm is so intense, I can feel it radiating from my screen
-
This is hilarious. I posted this hoping for a simple routine, but instead it turns into a two page mini-discussion about the best way to approach this, with 7 or 8 potential routines.
wow, the sarcasm is so intense, I can feel it radiating from my screen
In that case ... please disregard my last post ;D
-
Err...
This is what I said in a PM with DJ:
I meant it more as praise than anything, that I can post requesting a simple routine, and the community strives to find the best possible way of doing it instead of just a quick reply.
-
That's what I thought.
Soo, which routine are you going to use?
-
lol, :)
-
Soo, which routine are you going to use?
While {Lobesteritus_Ensues}
getKey->{The_Game}
End
-
By the way, adding a pause in a loop with a getkey doesn't actually do anything control-wise other than make the response time a little slower. The pause needs to be internal in the getkey routine itself (which I have fixed now).
-
Do you mean pause and getkey will be merged? I am not too sure what you mean by being internal in the getkey routine :(
-
Quigibo, does that mean something like the getKey(#)r I suggested, or am I misunderstanding?
-
You mean getKey(#) will have the pause built-in from now on, right? So no messing with Pause for keypresses :D
EDIT: Oh, yeah, you're right, Quigibo. Even if we added a pause, it wouldn't affect anything since the getKey routine's already done.
-
Oh I see now what he meant. It would be nice if we could make the pause internal.
-
It has to be, anyway. So what was the problem earlier? Did the getKey(#) routine simply not have a pause, so the key codes could turn out wrong or something?
-
I think it didn't have a long enough pause for 15MHz mode.
-
I think in Wabbitemu, this also happened in 6 Mhz mode. One of player1537 program (his first contest entry I think) had that problem. Wabbitemu migth have handled key detection differently or something.
-
Could Wabbit be running too fast? It seems to be, even for 6 MHz now.
-
Yeah I heard people saying it has been running a bit faster. However, in 6 MHz mode I didn't notice.
-
In 6mhz mode on my calc (an 84+SE letter M) I need to add extra Pauses when doing loops like this:
While getKey(54)
End
(I must do While getKey(54):Pause 40:End. Please note the 40 isn't exact, it's the first number that I tried, and it works, so... :))
-
What happens if you don't? Does it not register the keypresses?
-
I assume so. Isn't a smaller delay enough, though? Personally I would hate if the delay was too long because then the game starts slowing down, which is bad if you are using grayscale.
-
By the way, how does the Pause command work? Does it loop NOPs?
-
What happens if you don't? Does it not register the keypresses?
Yeah, like if I'm holding down 2nd it'll go on sometimes. :(
I assume so. Isn't a smaller delay enough, though? Personally I would hate if the delay was too long because then the game starts slowing down, which is bad if you are using grayscale.
I use loops like this in areas like the main menu of Jump!. Try holding down 2nd on the main menu. :)
-
The "Pause" command is a a loop of "djnz $+0" commands which is equivalent to about 850 nop's per pause number.
The original getkey(#) command waited 8 clock cycles which I think is enough for 6MHz. getkey(0) was a separate routine which only waited 4 clock cycles. I have now merged the 2 into a single command that waits 13 clock cycles which might be enough for 15MHz. As a result, the getkey routine is a little larger, but each call to getkey(0) is 3 bytes less now, so the program size would actually go down if you were using it more than once.
-
What happens if you don't? Does it not register the keypresses?
Yeah, like if I'm holding down 2nd it'll go on sometimes. :(
I see. And I see why adding a pause would work: It wouldn't register the first keypress moment, but after the Pause, it starts registering.
The "Pause" command is a a loop of "djnz $+0" commands which is equivalent to about 850 nop's per pause number.
The original getkey(#) command waited 8 clock cycles which I think is enough for 6MHz. getkey(0) was a separate routine which only waited 4 clock cycles. I have now merged the 2 into a single command that waits 13 clock cycles which might be enough for 15MHz. As a result, the getkey routine is a little larger, but each call to getkey(0) is 3 bytes less now, so the program size would actually go down if you were using it more than once.
Got it, and thanks. When do you think you'll update?
-
Well, 8 clock cycles times 15MHz/6MHz is 20 clock cycles... 13 still might not be enough...
Good luck making it work!
-
I wonder if 20 would start being a bit slow when a game in particular checks for about 20 keys every loop? It might be nice if in 6 MHz the amount of clock cycles was kept lower in 6 MHz mode. You would have to make the parser detect which getkey commands are placed after Full and which ones are placed after Normal or something like that, though. Disregard my comment if the slow down is not noticeable when Getkey() is used in large amounts in one loop, though.
-
Well, the main problem is that you can't tell whether or not you're currently in Full mode, and doing so would take more than 8 (and possibly 20) clock cycles. Maybe a getKey(#)r like I suggested could alleviate that by at least giving programmers the option?
And it shouldn't be too noticeable unless speed is very important.
-
The speed is negligible. If you checked for 80 key presses, it would be the same as an extra "Pause 1" which means each key would only add about 1/80th of a pause number. The main reason I've been avoiding it is because it makes the code larger and having separate routines makes it even worse. So at this point I think I'll just add an extra byte to give it a total of 20 clock cycles regardless of speed. This should settle the matter.
-
Sounds good; can't wait for a release! :D
-
Oh wow, disregard my comment, then. If the speed is this negligible, 20 clock cycles should be ok. Keep up the good work Quigibo :)