Zaurus Faster In Portrait Mode Than Landscape?

[flexibyte]

Hi, I just received my C3200 a couple of days ago and have been trying various ROMs. I found pdaxrom to be ideal for me and the new beta4 is fantastic.

I compiled and install the stratagus game engine and upon running it I was disappointed. It is slow and unplayable, sound is very jerky and so is movement. I can also see really bad tear lines.

I then tried running it in portrait mode (480x640) and it ran fantastically! Sound was now perfect, and it seemed to be running the same as on my desktop PC.... but I cant play it sideways .

Could I have done something wrong when compiling stratagus? Do I need to enable some sort of hardware acceleration to allow landscape to match portrait performance?

This is incredibly frustrating me for. This will make lots of games unplayable when they could potentially run great. What about zpsx? How will that combat this issue?

Thanks,
Phill

[Meanie]

Hi, I just received my C3200 a couple of days ago and have been trying various ROMs. I found pdaxrom to be ideal for me and the new beta4 is fantastic.

I compiled and install the stratagus game engine and upon running it I was disappointed. It is slow and unplayable, sound is very jerky and so is movement. I can also see really bad tear lines.

I then tried running it in portrait mode (480x640) and it ran fantastically! Sound was now perfect, and it seemed to be running the same as on my desktop PC.... but I cant play it sideways .

Could I have done something wrong when compiling stratagus? Do I need to enable some sort of hardware acceleration to allow landscape to match portrait performance?

This is incredibly frustrating me for. This will make lots of games unplayable when they could potentially run great. What about zpsx? How will that combat this issue?

Thanks,
Phill
[div align=\"right\"][a href=\"index.php?act=findpost&pid=127509\"][{POST_SNAPBACK}][/a][/div]

are you sure its running in 480x640 and not 240x320?
most games run fine in 320x240 mode, but 640x480 requires some overclocking for high frame rate games.

[flexibyte]

hmm... it could be that it was running at: 480x480 because the 2 sides were not visisble (the game was running 640x480 windowed mode while the desktop was running at 480x640)... but I have heard that the screen has to be rotated in software from the native 480x640 res, so it makes sense that it runs slow.

Also, i can only get mplayer working smoothly in portrait.. and its unwatchable in normal clamshell mode. Infact the different with mplayer is huge when i rotate the screen.

I will do a test with my SDL games and report back soon. Ill try running it in true 480x640 fullscreen and then in 640x480.

[flexibyte]

Ok, I just compiled one of my home made SDL demos in 320x240 resolution. Running it fullscreen seemed to keep the desktop at 640x480 and just run my demo in the middle of a black screen. Doing xrandr -s 0 before running it made it seg fault, so for this test I just left it at 640x480 (if anyone knows why it seg faults and how to run it in true 320x240 res, please let me know).

Running in landscape - the demo ran fairly jerky - and it shouldnt because its very simple.
Running in portait - the demo ran perfectly with a doubtless speed increase.

Once again, I ask why this is? I could write my games and demos sideways, but that would make porting them hard and kind of silly.

Thanks,
Phill

[adf]

Ok, I just compiled one of my home made SDL demos in 320x240 resolution. Running it fullscreen seemed to keep the desktop at 640x480 and just run my demo in the middle of a black screen. Doing xrandr -s 0 before running it made it seg fault, so for this test I just left it at 640x480 (if anyone knows why it seg faults and how to run it in true 320x240 res, please let me know).

Running in landscape - the demo ran fairly jerky - and it shouldnt because its very simple.
Running in portait - the demo ran perfectly with a doubtless speed increase.

Once again, I ask why this is? I could write my games and demos sideways, but that would make porting them hard and kind of silly.

Thanks,
Phill
[div align=\"right\"][a href=\"index.php?act=findpost&pid=127672\"][{POST_SNAPBACK}][/a][/div]

That's odd.  I seem to remember pocketworkstation data from the PW page saying things were faster in landscape

[flexibyte]

That's odd.  I seem to remember pocketworkstation data from the PW page saying things were faster in landscape
[div align=\"right\"][a href=\"index.php?act=findpost&pid=127674\"][{POST_SNAPBACK}][/a][/div]

Oh? When I used to use OpenBSD, that had this problem too. Everything ran smoother in portrait mode. I spoke to the developers about this and they said its because the screen has to be rotated in software. They also said that in other roms this was done with hardware acceleration, so it was much less noticable and sometimes not noticable at all.

Does the same happen in beta3 with the 2,4 kernel? Ive not tried that yet - maybe the rotation of the screen in 2.6 kernel is not working as well as in 2.4. I may look at this myself soon, as I want to reinstall beta4 anyway.

I also tried ZPSX running final fantasy 7. At first glance it seemed to be running faster in portrait mode too. Later I will do some tests with a stop watch and give my results. Perhaps if this is never fixed ZPSX could be rewritten sideways, like my earlier comment and run in portait mode, but be oriented in landscape mode - but that might be a lot of work and once again just silly.

[lardman]

It's probably because the natural orientation of the screen (framebuffer) is portrait and therefore things have to be rotated before being displayed when in landscape mode.

On the c7x0 this is done in hardware (so there should be no difference in speed), but the cxx00 machines have to use iwmmt I think, which performs this (quickly I admit) in software, therefore there may be a difference for these machines.

That's my vague rememberance anyway (there were lots of posts about speeds in different orientations when the machines first came out a long time ago btw)

If anyone can confirm/deny this authoritatively, then please do so.

Si

[flexibyte]

Hmmm yeah... great... so the Zaurus is using some of its power just to rotate its screen to its default clamshell orientation.

Whenever I saw iwmmt i always thought that was hardware acceleration for the older devices for some reason. How can I enable iwmmt support in my SDL apps for example?

And would you think it would be wise to go ahead and design my games sideways?

[emip]

Take a look at the Intel PXA27x users manual, it documents the LCD controller built into our Z's processor. IIRC it does have hardware accelerated rotation built into it, but the pxafb framebuffer driver in the current 2.6 kernel does not use this feature. (It doesn't use the PXA's internal video SRAM either, IIRC).
Kernel hacking, anyone?

[Dima202]

"pxafb framebuffer driver in the current 2.6 kernel does not use this feature. (It doesn't use the PXA's internal video SRAM either, IIRC)."
Yeah, this will probably really improve some games on our Zaurses
--Also video playback? ))))

[sashz]

No hardware rotation in PXA27x, only software.
Default LCD orientation 480x640 - portrait. For landscape that uses software rotation, its why landscape mode slower.

For PXA27x acceleration:
modprobe pxafb_overlay

that will create 3 devices:
/dev/fb1 - Overlay1 - RGB modes only
/dev/fb2 - Overlay2 - RGB and YUV modes
/dev/fb3 - Hardware cursor (128x128 max)

for initialize overlay, you need write info about resolution and mode with ioctl FBIOBUT_VSCREENINFO to one of this overlay devices, like as for normal framebuffer. Than get info for device as for normal framebuffer and use it.
I will post sample sources later.

[flexibyte]

No hardware rotation in PXA27x, only software.
Default LCD orientation 480x640 - portrait. For landscape that uses software rotation, its why landscape mode slower.

For PXA27x acceleration:
modprobe pxafb_overlay

that will create 3 devices:
/dev/fb1 - Overlay1 - RGB modes only
/dev/fb2 - Overlay2 - RGB and YUV modes
/dev/fb3 - Hardware cursor (128x128 max)

for initialize overlay, you need write info about resolution and mode with ioctl FBIOBUT_VSCREENINFO to one of this overlay devices, like as for normal framebuffer. Than get info for device as for normal framebuffer and use it.
I will post sample sources later.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=128036\"][{POST_SNAPBACK}][/a][/div]

Sounds interesting. I'll be looking forward to the samples.

[zodttd]

Thanks sashz for the pxafb_overlay info!
I was just going to ask about that...

ZodTTD