How to set steady frame rate?

[Galandros]

As the title says: How to set steady frame rate?
I don't know the right procedure to set that.

And what if calculations (like physics) avoid from reaching the frames per second? Or that is not a problem because it is supposed to not happen any time?

I have other problem but they are hard to write or say... As you explain I will ask other things.

And if you give an general idea and related problems say them.

[WikiGuru]

Interrupts. They happen at a steady time, and can be used to update counters/do stuff.

[Galandros]

[darkstone knight]

well...

suppose you have an interupt that does this:

LD HL,timer
inc (HL)
RET

and in your mainloop, you have this:

someroutine:
LD HL,timer
LD A,HL
CP 3
jr NC,$-2
xor a
LD (HL),A
RET

the loop would pause untill interupts triggered
to avoid the loop slowing down whit alot of items of the screen, consirder doing this:

someroutine:
LD HL,timer
LD A,HL
CP 3
jr NC,$+2+5
call fastcopy
jr $-3-2-3
xor a
LD (HL),A
RET

that way, the screen is only updated (updating the screen takes aprox 50% of the time in games) if the game completed the mainloop in 4/110 seconds or less (highly unlikely)

[cjgone]

The Way I keep frame rate stable is using interrupts. Have a counter in your interrupt and a check at the end of your program code in main loop. check the value in the counter into it has reached a specific number and just loop forever into the counter is equal to the desired value, and reset the counter. Interrupts run at a constant rate ( 1\60 seconds is normal time).

Obviously the delay will be longer then what the code needs to even out the field. Extremely taxing calculations that happen here and there can be considered anomalies and will probably drop the frame rate at intervals that are really rare and shouldn't be worried about.

To give an idea, my smooth scrolling game thingy i'm working on runs at about 2\60 seconds to complete at a good frame rate. So thats when the counter = 2at 1\60 second intervals. and thats like 30fps drawing and all teh stuff. When there's a lot of crap sometimes it might exceed 2\60 seconds for a code loop and there will be a noticable drop in frame rate, but it shouldn't be a big deal if it doesn't happen to often.. If it does, you just to increase your counter value, at the cost of slowing everything down to that slower speed.

Pretty much play around with the timer crystal to find a good interupt speed that gives your game or w\e the speed you like.

[calc84maniac]

[darkstone knight]

uhm.. yea

by the way, dont use:

LD A,(myvar)
inc a
LD (myvar),A

use:

ld HL,myvar
inc (HL)

saves 3 bytes

[Galandros]

[Iambian]

[TKD_01]

[Galandros]

[cjgone]

When you disable interrupts your timer will stop incrementing and your program will freeze up in an infinite loop when it reaches a timer check.

I'm pretty sure that the TI-OS uses im 1 and not im 2 so the Ti-OS is disabled when you run your custom interrupt in mode 2. That's why you must change it back to mode 1 before you end your program, or the calculator will crash.


And yea, Iambian's way is definitely the best, but harder to implement. An overall counter for the whole program is pretty simple--his idea is slightly harder. Both work tho.



P.s you could also calculate other stuff instead of wasting loops, ehh. ;o

[darkstone knight]

well, iambians routine wont work for my game, the psychics (run once in 8 frames) take a RIDICULOUS amount of time te complete

when i add 4 halts (on non-psysic frames, duh), the game runs fairly consistant :biggrin: (about 1/30 sec......)

ima post the code soon, its only 10 lines... (a 58*22 arrays)

[Galandros]

[FloppusMaximus]

As long as the calculator is turned on, the interrupt timer runs continuously, firing three times every 1/118th of a second. An interrupt will be generated if the appropriate bit of port 3 is set at the time the timer fires. At that time, the hardware sets the Z80's /INT line low, and it will remain low until the CPU resets that bit of port 3.

Now as to how the CPU reacts: It will only acknowledge an interrupt after it has completed a full instruction, and only if IFF1 (the primary interrupt flip-flop) is set. So if you execute a DI and then do some work, and the timer fires during that time, the /INT line remains low until you execute an EI, and only then will the CPU jump to 0038 or the IM 2 handler or whatever. (In fact, the CPU also won't acknowledge an interrupt immediately after an EI - it waits until the next instruction finishes. That's why it's safe to end an ISR with "ei \ reti" or "ei \ ret".)

It's worth noting that timer interrupts don't get queued up. If you have interrupts disabled for more than 1/118th of a second (for example, if you're copying a full screen image to the LCD) then the timer will fire more than once, but you'll only ever see one interrupt. So if you want to use interrupts for precise timing, be sure that you actually enable interrupts periodically. For the same reason, you want to keep your ISR itself as short as possible. (Hint: if you're going to do a non-trivial amount of work in the ISR, then reset and set bit 1 of port 3 before you do that work. If a second interrupt occurs, it will be acknowledged immediately after your ISR finishes, taking advantage of the behavior of EI noted above.)