Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: Happybobjr on September 14, 2010, 07:18:23 am
-
Is there any way to limit a programs frame rate/speed?
-
Use the Pause(EXP) command every now and again. But, I don't think you can do it accurately...
-
u could use an interrupt to update the screen, and do a 'Stop' every time you updated the buffer.
Stop:Stops execution until the next interrupt occurs. Interrupts must be enabled or else the calculator will freeze.
-
Yeah, that too.
-
Another solution if you aren't using interrupts is to make sure DispGraph is only ran like every 2 or 3 loop. If slowed down too much it can make the game a bit too fast, though, so you may have to add a Pause command or stuff more features there.
-
DO NOT USE STOP WITHIN AN INTERRUPT!
This would be bad. Interrupt code turns OFF interrupts upon executing.
-
What kind of stuff can happen if you do so?
-
The calc would hang and you would have to pull a battery.
-
FnOff
Stopor, in ASM
di
haltShortest way to freeze a z80 processor AFAIK ;D
-
The calc would hang and you would have to pull a battery.
Ah ok I was worried worse stuff migth happen or something x.x
-
so nothing will make it even?
so i have a consistent speed of a ship or something in real time?
-
Back to your original problem, interrupts would probably be the way to go.
An example:
0->C->X
ClrHome
fnInt(T,0
Repeat getKey(0)
!If C
Disp X+1->X>Dec
50->C
End
End
Return
Lbl T
C-1->C(Untested, should work)
Edit: Oops, wrote getKey instead of getKey(0). Fixed.
Edit 2: Bad typo. Fixed
-
Ah ok I was worried worse stuff migth happen or something x.x
It would also clear RAM.
-
Back to your original problem, interrupts would probably be the way to go.
An example:
0->C->X
ClrHome
fnInt(T,0
Repeat getKey(0)
!If C
Disp X+1->X>Dec
50->C
End
End
Return
Lbl T
C-1->C(Untested, should work)
Edit: Oops, wrote getKey instead of getKey(0). Fixed.
Edit 2: Bad typo. Fixed
ok thanks
-
And it crashes horribly... You get the idea, though.
-
And it crashes horribly... You get the idea, though.
As far as I'm aware, it's not much of a spectacular crash. It just stops working. Not nearly as spectacular as the Omnicalc/2.53 MP/Entries menu crash.
-
I had the Omnicalc entry menu crash in other OSes too. I forgot what could crash it, though. x.x (I think it had to do with long entries)
-
Ah, I found it!
-
I probably just should have said "it crashes" :P
I've never actually used Axe interrupts, though, so someone should rewrite my code so that it works :)
-
Weird it seems different than the entry menu bug I got. If I recall, I had to store massive entries or something and it started wrapping around and glitching. Scrolling down too far would crash the calc.
-
Wow, I was thinking of updating the OS, but I think I won't know. Maybe I should just get a 34 multiview
-
So what exactly is the status on finding an solution? Go with interrupts?
Ah, I found it!
I feel like thats bad...someone should fix that :P
-
lol Sir, that's bad. It needs to be fixed... :P
-
did you use Omnicalc 2.53MP patch btw? I remember the old Omnicalc had problems on 2.53MP then Dr'Dnar made a patch that worked on it.
-
lol Sir, that's bad. It needs to be fixed... :P
i will just rewrite code and make it proportinatly slower
-
*BUMP*
For future reference, maybe someone could write the interrupt code? (Not me, as I seem to be confused by Axe interrupts :P)
-
Like
:.axample
:FnInt(A,6)
:lbl A
:Pause X (1-20 for how much slower you want it)
:return
:...rest of program...
:LnReg
-
0->C->X
ClrHome
fnInt(T,0
Repeat getKey(0)
!If C
Disp X+1->X>Dec,i
50->C
End
FnOn
End
LnReg
Return
Lbl T
C-1->CNever mind, I figured out why my code wasn't working... (and something I can bug quigibo about...)
Edit: Indented for readability.
-
What is wrong with the code?
-
The code I just posted is fine and tested to work.
The problems that I solved were 1) I had forgotten LnReg (that's why it crashed before) and 2) For some mysterious reason, Disp, Disp >Dec, and possibly other OS routines disable interrupts, which means I had to insert an FnOn into the loop (it also could have been put in the If instead of the Repeat)
Number 2 is the one I'm going to bother Quigibo with.
-
Ah ok, what is it for? Is it the code to slow down the game to a specific framerate when fewer stuff is drawn?
-
What it does is perform an action at a certain rate.
Lemme explain it for you :) (Note that it is only an example ;D)
.Initialize variables for the program
0->C->X
.Just to make it look nice
ClrHome
.Set up the timer interrupt
fnInt(T,0
.Main program loop
Repeat getKey(0)
.If the counter is zero
!If C
.Display and increment X and put a new line
Disp X+1->X>Dec,i
.Reset the counter to 50 again
50->C
End
.Because Disp is silly
FnOn
End
.Clean up and return
LnReg
Return
.The timer
Lbl T
.Just decrement C
C-1->CIn short, it's an example program that counts up at regular intervals. Note that the only weakness to this method is, if you don't reset the counter when it reaches 0, it will have to count down all the way from 65535 to 0 again. (This normally should not be a problem)
-
Ah ok. I assume this is less accurate if many actions are performed at once, though?
-
No, it should as accurate as the interrupts are as timers, providing that you don't miss when the timer is 0. ;D
-
Ah ok, I was worried about when you had like 100 sprites to draw and another set of frames you had 1-2 :P
-
Actually, something I missed: if the counter will hit 0 n times per second, then taking over an nth of a second will cause it to skip a cycle. (Very similar to interrupt routines, in fact)
But, again, unless you do a lot of stuff, this shouldn't be a problem :)