SpritesMind.Net

Chilly Willy wrote: ↑

Sat Jan 15, 2022 11:31 pm

It's no wonder it has problems... you aren't saving r0 or r2.

Close. It is saving the R0 register in 'main_irq'. However, I completely missed R2. Fixed. Thanks!

Chilly Willy wrote: ↑

Sat Jan 15, 2022 11:31 pm

Static is only for LOCAL variables. This MUST be a global variable.
"volatile unsigned int variable_name;" and this must not be inside a function, but in the main body of the code. I.e., a global variable.

That makes so much more sense now. I'm exclusively a Java developer in my profession, and in Java, part of the way in which a variable becomes "global" (actually class scope, but it's close) is by marking it "public static". I'm actually pretty rusty with C and C++ as I haven't actively used in in many years now. So I was *really* confused about why you insisted it wasn't global. But having thought on it some, I'm now on the same page. Another easy fix.

And so with the two aforementioned fixed, it looks like the FPS counter is working now ...
Although it's oddly only settling on values like 15.0, 20.0, 30.0, etc. Maybe that's just a problem with my math/logic. I'll have to review that again. But I'm certain it's correctly updating the vblankCount value (middle one in the screen shot), and that's what I care about most at this point in time.

Thanks for your patience and help. And now I'm back to making the greatest thing since sliced bread (if sliced bread was for the 32X).

That makes sense if you're rusty on C/C++. Static in C/C++ makes a local variable hold its value between calls to the function. So it's a like a global in that it always exists and holds its value, but it's still local to the function where it's defined.

My standard method of doing FPS is to increment a global each time the event occurs (a frame is drawn, for example). Then in the main timing code (maybe the vert blank int), I check if a second has gone by, and if so, copy the global to another variable that represents the displayed FPS, and then clear the event global count. That makes the FPS update once per second with the FPS for the previous second. It's really simple and fast.

saxman wrote: ↑

Sun Jan 16, 2022 5:00 am

Although it's oddly only settling on values like 15.0, 20.0, 30.0, etc.

If your frame lasts than 1 vbl, you program is going to run at 60fps on NTSC. At 2 vbls, you get 60/2 = 30fps. At 3 - 60/3 = 20FPS, at 4 - 60/4 = 15FPS. Unless you're averaging your tic values like Chilly has suggested, you're only going to get 60/X on your FPS meter.

One of the more recent discoveries that I've made is that aligning the mov instructions on longword boundary does make a measurable impact on performance. Especially in the tight drawing loops.