OESF Portal | OESF Forum | OESF Wiki | LinuxPDA | ELSI (coming soon) | Ibiblio

IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
> Zaurus Faster In Portrait Mode Than Landscape?, Games unplayable unless in portrait mode
flexibyte
post May 17 2006, 05:15 PM
Post #1





Group: Members
Posts: 26
Joined: 5-May 06
From: UK
Member No.: 9,784



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 smile.gif.

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
Go to the top of the page
 
+Quote Post
Meanie
post May 17 2006, 06:54 PM
Post #2





Group: Members
Posts: 2,803
Joined: 21-March 05
From: Sydney, Australia
Member No.: 6,686



QUOTE(flexibyte @ May 18 2006, 11:15 AM)
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 smile.gif.

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
*


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.
Go to the top of the page
 
+Quote Post
flexibyte
post May 18 2006, 05:22 AM
Post #3





Group: Members
Posts: 26
Joined: 5-May 06
From: UK
Member No.: 9,784



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.
Go to the top of the page
 
+Quote Post
flexibyte
post May 18 2006, 03:18 PM
Post #4





Group: Members
Posts: 26
Joined: 5-May 06
From: UK
Member No.: 9,784



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
Go to the top of the page
 
+Quote Post
adf
post May 18 2006, 03:34 PM
Post #5





Group: Members
Posts: 2,808
Joined: 13-September 04
From: Wasilla Ak.
Member No.: 4,572



QUOTE(flexibyte @ May 18 2006, 11:18 PM)
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
*

That's odd. I seem to remember pocketworkstation data from the PW page saying things were faster in landscape
Go to the top of the page
 
+Quote Post
flexibyte
post May 18 2006, 04:29 PM
Post #6





Group: Members
Posts: 26
Joined: 5-May 06
From: UK
Member No.: 9,784



QUOTE(adf @ May 19 2006, 12:34 AM)
That's odd.  I seem to remember pocketworkstation data from the PW page saying things were faster in landscape
*


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.
Go to the top of the page
 
+Quote Post
lardman
post May 19 2006, 01:31 AM
Post #7





Group: Members
Posts: 4,512
Joined: 25-October 03
From: Bath, UK
Member No.: 464



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
Go to the top of the page
 
+Quote Post
flexibyte
post May 19 2006, 02:32 AM
Post #8





Group: Members
Posts: 26
Joined: 5-May 06
From: UK
Member No.: 9,784



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?
Go to the top of the page
 
+Quote Post
emip
post May 22 2006, 01:29 AM
Post #9





Group: Members
Posts: 29
Joined: 26-April 06
Member No.: 9,707



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? wink.gif
Go to the top of the page
 
+Quote Post
Dima202
post May 22 2006, 01:36 AM
Post #10





Group: Members
Posts: 68
Joined: 6-November 05
Member No.: 8,479



"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 smile.gif
--Also video playback? wink.gif))))
Go to the top of the page
 
+Quote Post
sashz
post May 22 2006, 02:01 AM
Post #11





Group: Members
Posts: 388
Joined: 7-December 03
Member No.: 1,058



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.
Go to the top of the page
 
+Quote Post
flexibyte
post May 22 2006, 06:04 AM
Post #12





Group: Members
Posts: 26
Joined: 5-May 06
From: UK
Member No.: 9,784



QUOTE(sashz @ May 22 2006, 11:01 AM)
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.
*



Sounds interesting. I'll be looking forward to the samples.
Go to the top of the page
 
+Quote Post
zodttd
post May 22 2006, 07:48 AM
Post #13





Group: Members
Posts: 188
Joined: 14-January 06
Member No.: 8,925



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

ZodTTD
Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 11th December 2017 - 03:37 AM