PocketMatrix

This is a known problem with MediaQ based devices.

The final blit (memory -> framebuffer) is what is slowing the whole process down ( 20 ms as opposed to a standard 5 ms on non mediaq based devices)
There is not much you can do short of limiting number of bytes being blitted to the framebuffer.

Ah crap, I was afraid it was going to be something like that.

Does you warmi, or anyone else, know where I can obtain a list of devices using the MediaQ chip? Because I'm going to have to list them as not supported for my game since the speed makes it not play very well.

I suppose I could implement a frame skip feature, but that's not the way to go.

That is seriously messed up. I bet the game runs full-speed on an old SH3 device, but now a brand-spanking new device. Can we say BIG F'ING MISTAKE?!?

Yeah. It sucks.

As far as I know, Toshibas e3xx and Axims are the most popular devices using MediaQ chip.

Obviously is the frame rate drop is too severe there is not much you can do but if it is manageable ( and 20 fps should be perfectly fine for great majority of games) then you can redesign your game to use floating point position/movement variables and then simply adjust values depending on the current frame rate.
Basically make your game frame rate independent.

PS.
When I say floats I mean fixed point ...

Well, as the game is designed today, it's playable, but noticeably degraded. I wouldn't feel right selling it the way it performs on my Axim, even though it works and is playable.

However, the FMV's that are to be added later MUST run at 30FPS solidly to work right (for voiceover syncing and such), so that's kind of a deal-breaker anyway. I had been assuming, incorrectly it turns out, that if it runs fine on my E-125 I should be fine on any "modern" device. It seemed like a safe assumption at the time

Redesigning it as you suggested, at this point, isn't really an option I suspect. I'm too far into it now to do that. I have to admit I don't understand how you desribed implementing it anyway, and I want to, even though I'm not going to do it.

I mean, the way I do it today is that each object on the screen that moves has a "speed" value associated with it. This is just the interval in frames between movements (i.e., a speed value of 3 means it moves every 3rd frame). Some objects will also move more than 1 pixel per interval, but most move one pixel in some direction. This is of course dependant on frame rate in the sense that if the frame rate slows down, so does the movement obviously, but I don't know how to do it otherwise.

I would absolutely appreciate a short "tutorial" on how to not do this very much

It is actually quite simple.

For example you assign a given speed value to an object , say 1.0 at 40 fps which will be your target or default movement rate for this object.
During runtime you measure FPS and multiply your movement value by (targetFPS / currentFPS).

So for example if your frame rate drops to 30 and your object is supposed to be moving at 1.0 at 40 FPS ( your perfect rate) you would do :

1.0 * 40/30 which would result in your object "speeding up" to 1.3 per frame as opposed to 1.0 per single game update.
This way your objects will move at the same speed regardless of the current frame rate.

Of course, if your frame rate drops to 5 fps, this algorithm will result in your object moving at 8 pixels per one game update which will look rather crappy but still, the game itself will still run at the same speed.

Maybe I'm missing something, but isn't it better to base movement and other animations on time rather than frames? I use GetTickCount() and compare the speed value to how many ticks have lapsed. Animation is smoother on faster devices because more frames can be shown to cover the same "distance"

Pam

Ah! I see! Your right, it is quite simple.

I was about to ask how I move 1.3 pixels per frame, but then it dawned on me that you just add it to your X coordinate and round that to an integer value to plot it. Since in your example 1.0 * 40 = 40, and 1.3 * 30 = 39.9, when you round off the vales you have still moved the same 40 pixels per second in either case.

You know, I should be able to pretty easily retrofit my code to implement this. In fact, it'll arguably have other benefits besides keeping the game running at a roughly constant speed because I don't really have to do checks each frame to see if it's time to move a given object. Now I just do the calculation and move it, and I can of course set values < 1.0 to skip some frames.

Thank you for that wonderful explanation. Others have tried to explain it, but none did it as well as you just did (part of it was undoubtedly me being thick-headed though).

Pam:
It is the same concept.

Pam, are you saying that if I'm targeting 40 FPS as ideal and I have a device that can actually render 80 FPS that half of your frames are essentially unchanged? I.e., your first rendered frame is the same as your second, then you change things on your third, then render the same for the fourth, and so on?

If so, I can see how that would be better for faster devices, but I don't understand how it helps if the frame rate can't meet the minimum 40.

Warmi, one other question on your approach... Is there some variance between ideal and actual frame rate where the approach yields poor results? You mentioned that 5 FPS yields 8 pixels moved per frame, and that is obviously bad. But it seems like 1.3 pixels per frame if we drop to 30 FPS is reasonable. My question is, what's the lowest FPS, in your opinion, that you can hit and still have decent-looking results?