was8bit 2018-11-18 06:12 (Edited)
(NX core 0.11)
Line up letters to match target word... a timer tracks the time it takes to complete all 3 levels.
Timo 2018-11-18 11:06
One minor critic: These 60 FPS time counters make me nervous ;) Would be nicer using seconds.
was8bit 2018-11-18 11:43
As in it is a hardship on the system ? Or it's just perhaps annoying?
I thought about a proper time representation (seconds, minutes, hours) but was following my new guidelines of keeping it simple and quick.... now that it seems to be working OK, I could polish that on :)
Timo 2018-11-18 11:54
Just divide by 60 and done, no need for minutes/hours :)
was8bit 2018-11-18 11:55
It's actually not counting FPS as I am using WAIT VBL and not VBS...
my shown time is based on TIMER, but I'm having difficulties.... i have tested it and it seems to be doing over 3,000 ticks per minute... I would have assumed 6,000 ticks per minute... 3,000 Ticks per minute means it's doing 50 ticks per second...
We don't have any access to actual TIME, do we....??
was8bit 2018-11-18 12:05
I just now did a test using WAIT 1 and made sure I read the count better and got 3575... if it was 60X60 it should have read 3600...
Maybe you could test the minute count on your end, maybe my iPad mini is abit sluggish...
Is there a way to have an accurate accounting of time that would show proper amount of game time, I know you don't want time and date and such as this stuff wasn't available for the gaming systems you are emulating, but maybe behind the scenes TIMER could be kept accurate to the passing seconds by calibrating itself against actual time... that way the calculated passing minutes won't off....
was8bit 2018-11-18 12:06
The difference is very small, so perhaps not worth worrying about... for most all games what you have works just fine :)
was8bit 2018-11-18 12:42
I just did a 5 minute test, and it's only off by 2 seconds :)
Timo 2018-11-18 12:49
"WAIT VBS" doesn't exist...
WAIT VBL waits until the next frame, running at 60 FPS (usually). Should be 3600 ticks per minute. TIMER just counts frames, not real time.
WAIT 1 is like two times WAIT VBL. The idea is "wait n/60 seconds and then for the next frame". I will create a new topic in the forum to explain and discuss this, it's a bit strange.
In any case, all timing of a game should use frames instead of real time. It makes animations smooth and simplifies cases of unstable frame rates. Programming with dynamic framerates using real time can be really complicated.
was8bit 2018-11-18 16:13
Odd that your comment about dividing byn60 didn't show up until now...
Thanks for the tech info :) one last tech question... when timing PLAY,
Are these two times identical, my assumption would be yes, but according to the help file they play time is 1/60 a second ( or 1 frame)and you said WAIT 1 is really 2 frames... so for proper timing here I should ACTUALLY be using...
Timo 2018-11-18 16:51
Yes, the second example is correct. Or if you play a sequence of several notes, just set the play time to 0 (unlimited), use WAIT and in the end STOP.
Hm, there are maybe too many options and not enough explanations or examples. I may have to improve it.
was8bit 2018-11-18 17:00
Thanks for verifying :)