Speed Problem

[seb0uille]

[efortier]

Are you drawing directly on the backbuffer in the ProcessNextFrame() function or have you created another background surface that you blit to the backbuffer?

If you created another surface you might consider drawing directly to the backbuffer provided to you, this will allow you to discard one big blit and should speed things up a bit.

If you are already using just the backbuffer, and filling it with FillRect() and you are only getting 25 FPS in release mode, than you may have a low device. I would suggest loading one of the GapiDraw sample, push the max FPS to 60 and see what you can get. If it remains in the 20-30 range, that may be the limit of your device.

Someone might provide better ideas, since I don't have a jordana to test.

--Eric

[fzammetti]

Just as a reference benchmark, this may help...

My current project involves a 200x200 playfield that is completely redrawn every frame. Basically, there is a 200x200 portion of the screen that is constantly changing, the rest of the screen is static, or at least changes far less frequently.

The way I accomplish this is that I have a 400x400 temporary surface, and I draw to that all the elements of the game field. What I do is I draw to a 200x200 region that is centered on that 400x400 surface (i.e., there is 100 pixels on all sides of the part I draw on). Then, every frame, I do a FillRect on that portion of the surface, redraw all the sprites and other components of the game, and blit that portion of the surface to the real backbuffer.

This allows me to not bother with clipping at all. If a 50x50 sprite is positioned at 180,160 on my temporary surface for example, it will of course get drawn, since it doesn't break a surface boundary. Then when I blit the 200x200 portion of the temporary surface, part of it is of course outside of the source rect, so it's effectively clipped without any calculations whatsoever.

This may sound suboptimal, and I'm not about to argue that it is! But it does make the code rather more simple and removes any clipping concerns I would otherwise have to deal with.

My point to all this though is with regard to speed... On my stock Casio E-125 (MIPS 150MHz for those that don't know), I get 40FPS solid at all times (the game is set to run at that speed). I know that the Casio does it's own double-buffering, so that would logically add to the potential speed difficulties. However, there doesn't appear to be any difficulty at all! I haven't tried to unbound it to see what the maximum frame rate would be (EDIT: I just did... hangs between 50-60 the whole time, depending on what's actually going on at the time) but it's reasonable to guess it would be higher, since it's solid at 40.

There could conceivably be devices out there with specific issues that will cause speed problems later on, but if it runs that well on my Casio, it's a fairly safe bet all "modern" devices will have no trouble whatsoever keeping up.

If I can get these results with what most would view as an inefficient way of doing things, I would say there is something very odd going on for you.

[fzammetti]

Geez, I didn't read the original post very completely... An SH3. There's your problem. Your actually lucky to even get 25FPS!

I'm not even kidding. SH3's are notoriously slow as compared to virtually anything else. I wouldn't be surprised if there is some video-related bottlenecks too, but just CPU speed alone is enough to kill your frame rate.

I'd say you will have to code things exceptionally efficient to get a frame rate much above what your getting now. You say you have a bunch of surfaces for the bubbles... I'm not sure if you mean just images loaded into surfaces or you have a bunch of temporary surfaces. If it's the former, there's not much you can do. It it's the later, you may want to rethink how your doing things.

But in any case, any SH3 device is going to be dog-slow no matter what you try and do with it, this is why virtually no one supports those devices any longer. You just either can't get the performance a decent game requires, or you will go nuts trying to get it there.

[DillRye]

Yeh, Sh3's are slow. What was really funny was when I sent SBL a version of a game I was making(puyo puyo clone). Later I found out that on an ARM processor the game would go soo fast that the screen would fill up instantly(forgot to put frame rate limiting). I said something to SBL about this and he said that he wondered why it filled up so fast :).

Basically, if you can wade through my rambelings, I just wanted to point out that an 206 ARM proc runs about 10 times faster than a 133mhz sh3. Or should I say a sh3 runs 10 times slower......

[seb0uille]

Thanks for your replies.
Well I'm quite disappointed... I'm not planning to purchase a new PDA so I wonder if I will keep on coding games for my device

Strangely I had a not so bad framerate with my previous game (http://sebastien.rousiere.free.fr/speedball/). In that one I had only one sprite and lots of line drawing.

[Hosed]

[Sm!rk]

[fzammetti]

[ppcStudios]

As everyone has already stated, SH3 is all but dead, with MIPS not far behind. While we offer MIPS versions of our products, and will likely offer a MIPS release of Warlords as well, it is out of respect for those who still rely on the devices, not for the added sales - which are negligable.

But, if all you have is an SH3 device, don't let that deter you from developing ppc applications. You will still develop on the desktop and only periodically test directly on the device.