Hi carl & Si,
Nothing is quicker than 0 ;-)
Actually, there are a couple of ways you can have even less pausing. But first some details about pause and why you might not want it to go faster.
Pause works by calculating a future clock value (which is clock i@+the pause value) and then it waits for clock i@ to exceed it. The wait loop is begin dup clock i@ - 0< until
That's why 0 pause will be faster because it will still wait until the clock has incremented. Of course, if your program has done quite a lot of work before you execute 0 pause then perhaps the clock will increment just as you go into the loop and it'll hardly additionally pause at all.
-1 pause won't be faster, because the built-in pause command treats -n pauses as "wait for n frames or until you press a key", so using it will generate erratic pauses. Note: the startup FIGnition logo uses -100 pause so you can cut it short by pressing a key.
One way to generate faster pauses is to use timer1. This runs at 2.5MHz so a pause of 1/100th of a second will be 25000 t1pause. The command to do this would be:
: t1pause tcnt1 i@ + begin dup tcnt1 i@ - 0< until drop ;
I can't remember the address of tcnt1 off-hand but I'll post that in my next message (it's in the atmega168 data sheet from atmel though).
However, will it help? FIGnition's display only updates at 50fps so even if you pause for <20ms you won't see the result properly, instead the user will just miss frame updates or see tearing on the screen if you start generating the second frame while the previous one is showing. Here, it's better to think about moving objects by more than 1 unit per frame and this should also reduce computation too.
Hope this helps.
-cheers julz
--
You received this message because you are subscribed to the Google Groups "FIGnition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fignition+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.