by Digby » Sep 21, 2001 @ 1:49pm
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>