PocketMatrix

Does anyone have any suggestions on the best way to write to the iPaq's video memory?  I am blitting bmps to a back buffer and then writing the back buffer to video memory.  Currently my back buffer is a linear array of memory (240X320) and I am doing a pixel by pixel blit to video memory to get the correct conversion for the iPaq display.  This seems to slow though.  I am thinking about doing the conversion at the back buffer level, so that my blits to the back buffer would do the conversion.  This way I could just memcpy the back buffer to video memory.  I think this would be slower, however, since this would require the conversion for every sprite instead of just the conversion of the back buffer.  Another option I am trying is to do the conversion at the bitmap level so that I only need to memcpy the bitmap to the back buffer and then memcpy the back buffer to video memory.  I can't seem to figure this out though.  It would seem that the bitmap memory would need to expand to handle this.  Does anyone have experience doing this?  Any suggestions?  Thanks in advance.<br><br>Tom

For the iPaq, I rotate all of my artwork when it is loaded from disk (RAM).  My back buffer is oriented as 320x240 so that I can use a custom block copy using ARM assembly, but you could use memcpy just as easily.  Images are copied to the back buffer a line at a time using this same routine.  You have to adjust the x and y values after the image conversion to convert portrait to landscape like so:<br><br>x' = 320 - (y + sprite.height);<br>y' = x;<br><br>There's another thread going on in Phantom's forum about this.  Jacco and Mirek actually do the rotation on the iPaq when blitting the back buffer to display memory.  You might want to check it out or perhaps they'll chime in here.<br><br><br>

Thanks!  I can't wait to give it a try.  I think I have everything correct except for converting the bmp to landscape.

Yeah we where indeed discussing this. EasyCE does the rotation for you, but this takes some time indeed. Advantage is that your app works the same on all devices, you just have to supply a function for the device that you want to support. On the Casio's, this means a direct memcpy, on the iPaq it's the rotate. We where discussing ways to speed up the rotate by fetching two pixels at once and writing 32bits to the hardware framebuffer. I haven't tried this though.

Another disadvantage to pre-rotating the various elements is if your program will allow toggling landscape / portrait on the fly, like PQ and most emulators. You would have to reload and redraw all those elements. Either way, pre-rotating is a far more complex way to go coding-wise.<br><br>Dan East

Well you either rotate all the artwork once, or you rotate the back buffer every frame in your blit code.  I prefer to pay the penalty once.  Something else to note is that with some devices (Casio) they don't give you a pointer to actual display memory.  They give you a pointer to an intermediate back buffer in DRAM (see GXIsDisplayDRAMBuffer) and then copy its contents to display memory when you call GXEndDraw.  If this is the case, you should not have a back buffer in your app, and rely on the intermediate buffer instead, otherwise you're going to pay the penalty of copying a 240x320 WORD buffer twice each frame.  But now you must have your own back buffer because you are going to rotate it as you copy to GAPI's back buffer.  With the method I propose, I copy the pre-rotated sprites to the DRAM back buffer and there's only one copy (when I call GXEndDraw). <br><br>Here's the way I look at it.  I don't think the person who bought your game really cares about how complex the loading code is (as long as it doesn't take a year and a day to load).  They do care about how fast it runs while they are playing it.  If it takes and extra half-second to load the artwork when someone changes from portrait to landscape that shouldn't be a big deal as they usually only do that once before playing the game, or am I missing something and people do this on-the-fly while playing the game?<br><br>The person who plays the game doesn't care how the game does it, they care what the game does.  If my game is running less than say, 30 fps, then it's my job to jump through as many hoops as possible to get the frame rate up.  If the frame rate is already satifactory, then I'm not going to spin my cycles trying to get 5 more fps out of it and complicate the code.  I should be spending my time adding some other feature to make it a better game.<br><br>