• Advertisement
Sign in to follow this  

Pong Slow? (VS2005 - Pocket PC 2003 Emulator - C#)

This topic is 4240 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Well, I have not really done much with mobile development. But here recently, I wanted to give it a try. All has gone well. And I have started writing a VERY simple Pong clone. LoL. Nothing wrong there. I am writing it using a lot of "g.FillRectangle" (filling the screen to black, filling paddle rectangles, etc.) and then a "g.FillEllipse" for the ball. I only update the paddles when the up/down buttons are pressed, and I continuously update the ball. Even the ball-edge collisions work, but I don't have it colliding with the paddles yet. Well, it's EXTREMELY slow. And it's even slower when I move the user paddle (left paddle). The right paddle is the opponent (non-human; not in use yet). When I move the paddle, the ball slows way down, I'll let go of the up/down key, and it will keep going, because it's way "behind." Is this probably due to the fact that I'm drawing with the "Graphics g;" object? By the way, I'm using off-screen drawing. I got that idea from this MSDN article. Should I just use three simple bitmaps, one for each paddle, and one for the ball? Or should using the standard "Graphics.Fill*" methods be much faster than it is? I'm using VS 2005 Pro, C#, and the VS2005 Pocket PC 2003 SE Emulator. Thanks in advance, Matt U.

Share this post


Link to post
Share on other sites
Advertisement
Big problem number one:
Quote:
I'm using ... the VS2005 Pocket PC 2003 SE Emulator.
Emulators are bad for performance testing. It doesn't matter that you are emulating a 200, 300, or even 600 MHz processor on your 3GHz machine, emulators are still slower and faster at different operations. Always do performance and other tests on the actual hardware.


Big problem number two:
Quote:
I only update the paddles when the up/down buttons are pressed, and I continuously update the ball.
Timers and delays are your friends.

"Continuous" and tight loops are your enemies. On these platforms, don't bother with anything more than 20FPS (roughly 50 ms per frame) because there isn't any significant gain.


Big problem number three:
You never measured. Make friends with a profiler, or even put your own timing code around blocks of code and have it send out debugger messages and/or log entries. Also emit those messages on function calls that you suspect might be an issue. If you discover you are redrawing the ball 200 times each second but only updating its position 20 times per second, you can easily observe that you wasted about 180 drawing calls.


Good luck.

Share this post


Link to post
Share on other sites
The emulator is very slow indeed. But still it might be worth testing your app on it. For instance my older acer device didn't support GDI raw framebuffer access, but the emulator did so I could develop/test it. Also WM5 emu supports DirectDraw, which may be handy if you need to test some DD code without a proper device.

I've seen some C# games for PocketPC, and I had the impression that there were flickers and the Gfx wasn't very fast.

by the way here you may find sources/bins of my version of the good old Pong game, which I finished recently. I think the speed is acceptable, even with 5 balls... :-)

Share this post


Link to post
Share on other sites
Well, thank you both. I will look into it some more, and I'll try some of the suggestions. But I don't have the hardware to test it on, and I can't really afford one right now. =P

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement