Optimizing GAPI

[bdillon]

   Hi.  The name's Brandon Dillon, and I'd like to say "hi" to everyone.  I guess I already did that, but anyway, I've been working on developing a game for the PocketPC for a few weeks now, (It's an RPG, but we're just laying down the fundamental code right now) and while I've really enjoyed the development platform, (I was recently developing some Game Boy Advance code, but doing that freelance can be quite a challenge) I do have some questions that I'd like to ask.<br><br>    First, let me say a bit about the project.  It's a isometric tile-based RPG with turn-based combat.  All of the code written so far is completely hand-written.  (I avoided EasyCE and others because I wanted to understand the inner workings of the program)  I'm using GAPI and currently have graphics and input working quite well.  I've abstracted everything away from windows and have my own input handlers, image surface systems, and so on and so forth.  Right now, the only thing the application really does is scroll a map around, but I feel that I've got the capability to do quite a bit with the code.<br><br>    The nature of my questions are not how to acheive some particular task or anything like that; it's more a question of optimization.  My program runs quite well in the emulator (50 fps) and never experiences a slowdown from that benchmark.  Of course, this is not the case on my actual device. (iPaq 36xx)  I get roughly 8 frames per second, which isn't adequate for my needs.  Considering that it appears that I can run Quake on my iPaq at a faster framerate than that, I don't think I can blame it on hardware.  I've tried to search the boards and find a topic on optimization, but I couldn't seem to find any, so I decided to post a fresh topic.<br><br>    One of the concerns I have is that I'm blitting this map full-screen without any kind of virtual keypad or anything like that, and I'm updating the state as fast as the system will let me.  I'm moving my pre-loaded map buffer over to the back buffer, which is in turn moved over to the actual video memory at update-time.  Is there any way to avoid this overhead?  Also, my input system seems to lag the system heavily, but I can't seem to track down any specific conflicts within the system that would account for the slow-down.  Another concern is my image blitting code itself.  I am working on some optimizations for this myself, but if anyone has any insight, I'd love some advice.<br><br>    I, of course, would appreciate any tips on optimizing for the PocketPC in general that can only be acquired through experience.<br><br>    Let me say thank you in advance to anyone who helps out.  I came to this forum because it seems to be heavily trafficked by prominent and intelligent coders, and if you don't mind, I'd like to leech off of some of your experiences.<br><br>   Oh, and happy new years!<br><br>-Brandon DillonLast modification: bdillon - 01/01/02 at 00:12:24

[Digby]

First thing you need to do is find the bottleneck in the code you are executing each frame.  Unfortunately, there isn't a profiler available with eVC, but you should be able to narrow things down by bracketing sections of your code with calls to GetTickCount() or QueryPerformanceCounter().  You can also comment out the code that performs the back buffer to video memory copy then see how fast your code runs.  If it speeds up a lot then you know the bottleneck is this copy routine.  Just keep eliminating things until your performance jumps up.<br><br>The secret to fast blt performance on the iPaq devices is to create a back buffer that is oriented the same as the iPaq's display memory (landscape).  This makes the copy operation very simple as it a single call to memcpy.  The same thing goes with whatever you're blitting to the back buffer.  Make it so that you won't have to perform a rotation when you blit.<br><br>Of course if you're using palettes, colorkeys, or alpha blending during your blits, then those things will take more time as they aren't a simple memcpy, but we've discussed those things to death here and how to optimize them.  Search the archives or look at some of Jacco's tutorials for details.<br><br>Welcome to the fray.  I hope you'll find something useful here that will help you with your upcoming game.  Let us know how it goes and don't hesitate to ask for help or suggestions.<br><br>

[Dan East]

Try taking a look at the Easy CE and Pocket Quake sources (vid_ppc.c and sys_win.c) . Neither is derived from the other, so they provide different solutions to the same problems.<br><br>It is difficult for us to provide generalized solutions to your specific problems without seeing the source. Perhaps you could post excerpts of the critical loops. I'm sure you're aware you shouldn't be Sleeping anywhere in your message loop unless your app has lost activation, etc.<br><br>Dan East

[bdillon]

[bdillon]

[Dan East]

[MirekCz]

[bdillon]

[Digby]

[MirekCz]

[Phantom]

[MirekCz]

[Digby]

[MirekCz]

[bdillon]