by Dan East » Jun 17, 2001 @ 10:02pm
Well, PQ's display routines are dynamic enough to run on any RGB 555 / 565 device, regardless of where the display origin is. The fact that the @migo's screen orientation matches the iPaq is certainly responsible for a very high game compatibility, as there are probably a good number of games out there with hard-coded display routines that assume that all ARM Pocket PCs are iPaqs.<br><br>Technically speaking there is no good reason why a device should run faster in a landscape orientation than portrait, or vice-versa. A program is given a buffer (a chunk of memory) which it fills with data. The display drivers / hardware takes that data once every screen cycle and displays it. The method in which I fill that buffer with data has nothing to do with the hardware / driver side of it. I could write every other pixel then go back and write the rest, or start on the right and write to the left. It doesn't matter. The only real issue is that a pixel on any current color Pocket PC device is represented by a short, which is 2 bytes, or 16 bits. Since these devices all have 32 bit architecture, it is ineffecient to write only 16 bits at a time. Thus if the programmer were to fill the buffer in such a way that 2 pixels were copied at a time, then native 32 bit operations could be used which are much faster. Again, this still has nothing to do with the orientation of the display. I write shorts with PQ because I have to look up each pixel's palette value. Also, the blitting of the display accounts for something like .5% of the work to render a frame, so any optimization would result in something like .01 FPS increase, which is not worth the effort.<br><br>So in other words, I do not know why some programs perform better in landscape, even if the display is technically a "landscape" display. My hunch is that some sort of ineffecient sizing is done to squeeze the image to a portrait display which slows it down.<br><br>Dan East
Overclocking
<br><br>Dan East
