How to get rotation working


The compression is not visible (unless you create a picture where every pixel has a different color - but then again, that doesn't make sense).

There are basically two problems:

Speed and software code.

About speed:

When using the framebuffer, the data is written directly into the graphics RAM (basically directly into the system). This is the fastest thing you can do.

To rotate the image, you'd need to setup a temporary buffer where the image is stored normally (1280x720 pixels) and then transfer that RAM into the graphics RAM. The transfer is slow. AFAIR, when notaz made some tests, we found out the performance hit was huge (about 10% of original speed left).

When I ran Gambatte in a rotated X window, I had about 10 - 15 fps or something like that.

I'm pretty sure that when using the Vivante, we would still need to use that temporary buffer and would have the bottleneck of the RAM transfer.

About software:

Physically, the display appears to Linux as a 720x1280 screen.

So everything in Linux is setup to use it as a portrait screen: The normal terminal, etc.

X can be setup to use a rotated screen, yes. But that still makes things a bit slower.

However, if you want games without the performance hit from the rotation, you would need to basically code them in 720x1280 resolution.

Which means: You couldn't code in 1280x720 and then rotate it (that would slow things down again), you would need to use rotated sprites, etc. and code them in 720x1280.

Needless to say, this would be horrible for ports.

I'm also not sure if it would be easy implementing a low-level rotation function. It would need to be hacked into the kernel, otherwise you couldn't easily run a standard Linux distribution on the Pyra. You'd always need to include the hacked up SDL, etc. versions that include rotation (and still slow things down).

So whatever we are trying to do here, it would be some horrible hackup with slowdowns.

Unless we have a hardware that makes the LCD appear as 1280x720 to Linux.
 
The compression is not visible (unless you create a picture where every pixel has a different color - but then again, that doesn't make sense).

There are basically two problems:

Speed and software code.

About speed:

When using the framebuffer, the data is written directly into the graphics RAM (basically directly into the system). This is the fastest thing you can do.

To rotate the image, you'd need to setup a temporary buffer where the image is stored normally (1280x720 pixels) and then transfer that RAM into the graphics RAM. The transfer is slow. AFAIR, when notaz made some tests, we found out the performance hit was huge (about 10% of original speed left).

When I ran Gambatte in a rotated X window, I had about 10 - 15 fps or something like that.

I'm pretty sure that when using the Vivante, we would still need to use that temporary buffer and would have the bottleneck of the RAM transfer.

About software:

Physically, the display appears to Linux as a 720x1280 screen.

So everything in Linux is setup to use it as a portrait screen: The normal terminal, etc.

X can be setup to use a rotated screen, yes. But that still makes things a bit slower.

However, if you want games without the performance hit from the rotation, you would need to basically code them in 720x1280 resolution.

Which means: You couldn't code in 1280x720 and then rotate it (that would slow things down again), you would need to use rotated sprites, etc. and code them in 720x1280.

Needless to say, this would be horrible for ports.

I'm also not sure if it would be easy implementing a low-level rotation function. It would need to be hacked into the kernel, otherwise you couldn't easily run a standard Linux distribution on the Pyra. You'd always need to include the hacked up SDL, etc. versions that include rotation (and still slow things down).
Indeed sounds like a complex problem. Interesting that basicly all mobile devices deal with that without any issues (as long as they only use one OS).
Unless we have a hardware that makes the LCD appear as 1280x720 to Linux.
Here you are talking about the Rotator Chip then, right? :D
 
Last edited by a moderator:
Indeed sounds like a complex problem. Interesting that basicly all mobile devices deal with that without any issues (as long as they only use one OS).
Sure, we can force everyone to use OpenGLES for their programs as well, then rotation won't be an issue.

But you wouldn't have X (unless we switch to Wayland) or most other normal Linux games.

Unless we have a hardware that makes the LCD appear as 1280x720 to Linux.
Here you are talking about the Rotator Chip then, right? :D
Yes, that's exactly what it does.
 
I seem to recall that the rotator chip can be disabled and the LCD driven directly, and that it did not cost very much (like $5? I can't find a source on this so might be misremembering) so if a "better" solution presents itself there isn't really a major loss to having it.
Can someone please confirm whether it's true that the rotator chip can be disabled or bypassed somehow?

Since rotation really isn't an issue when using fullscreen OpenGL I would much rather take the improved image quality. Also given that Desktop Linux will hopefully soon get a full 3D compositor by default.

I looked at the sample images and I think the compression is quite bad, especially for pixel art or anything really that isn't photo or video (which suffers from compression artifacts by default).

Sorry if this comes off as pedantic, I just make small pixel art games from time to time and am used to looking at pixels.
 
I looked at the sample images and I think the compression is quite bad, especially for pixel art or anything really that isn't photo or video (which suffers from compression artifacts by default).

Sorry if this comes off as pedantic, I just make small pixel art games from time to time and am used to looking at pixels.
Have you zoomed into the image or checked it with the correct size (5" diagonal).

Because I doubt you'll be able to see it with that small pixels.

I couldn't even find anything on CaveStory (or any other pixel games - unless you use thousands of pixels with different graphics and not just tiles, etc.)
 
I looked at the sample images and I think the compression is quite bad, especially for pixel art or anything really that isn't photo or video (which suffers from compression artifacts by default).
Then you are literally the only one. No one else considered the artifacts to be bad, and barely anyone could even recognize them the first time around. Are you absolutely certain you aren't just suffering confirmation bias? Seems more likely than you being the only person able to consistently identify bad artifacts. We could set up a scientific test for it, if you wanted.
 
I looked at the sample images and I think the compression is quite bad, especially for pixel art or anything really that isn't photo or video (which suffers from compression artifacts by default).
Then you are literally the only one. No one else considered the artifacts to be bad, and barely anyone could even recognize them the first time around. Are you absolutely certain you aren't just suffering confirmation bias? Seems more likely than you being the only person able to consistently identify bad artifacts. We could set up a scientific test for it, if you wanted.
Sorry but where are the images? did i miss something? 
 
Sorry if this comes off as pedantic, I just make small pixel art games from time to time and am used to looking at pixels.
Do you make pixel art in 1280x720? Most pixel art stuff I've seen, would use way lower resolutions and scale it up with nearest neighbor to get the desired blockiness.

I don't really see the point of pixel art at 1280x720 on a 5" display. That's as if someone in ancient Rome would be spending dozens of years to make elaborate mosaic tilings, which are to be viewed only from a satellite in outer space.
 
About speed:

When using the framebuffer, the data is written directly into the graphics RAM (basically directly into the system). This is the fastest thing you can do.

To rotate the image, you'd need to setup a temporary buffer where the image is stored normally (1280x720 pixels) and then transfer that RAM into the graphics RAM. The transfer is slow. AFAIR, when notaz made some tests, we found out the performance hit was huge (about 10% of original speed left).

When I ran Gambatte in a rotated X window, I had about 10 - 15 fps or something like that.

I'm pretty sure that when using the Vivante, we would still need to use that temporary buffer and would have the bottleneck of the RAM transfer.
You shouldn't assume that because this particular software implementation was very slow it means rotation using the GC320 will be anywhere close to as bad. Unless the implementation is extremely poor I can't see it being anywhere within this order of magnitude of poor performance.

The specs say 700-1000 Mpixels/s depending on the clock speed (or two pixels per clock), and benchmarks performed on OMAP5 show at least 850 Mpixel/s for some 1:1 operations on 32-bit pixels. 1280x720 is about 1Mpixels, so 60Mpixel/s should probably not be a problem here. Unless it handles rotation very, very poorly (like with no blocking whatsoever)
 
Last edited by a moderator:
Well, if you want to try the rotation with the Vivante and check if we could use that as fixed rotation without a performance hit, you're welcome to do so.

I'd be happy to have a working solution, with or without the SSD.
 
Most pixel art stuff I've seen,
That's not pixel art, that's people faking  old looking games by making sprites look ugly on purpose on high resolution screens.

Pixel art back in the 80s and 90s was about doing the best with the resolution you had available, not misusing the resolution to make it look old school. 
 
Most pixel art stuff I've seen,
That's not pixel art, that's people faking  old looking games by making sprites look ugly on purpose on high resolution screens.

Pixel art back in the 80s and 90s was about doing the best with the resolution you had available, not misusing the resolution to make it look old school. 
Sure. And pixel art in that sense has become outdated, because resolution and color palette are essentially unlimited now.
 
Well, if you want to try the rotation with the Vivante and check if we could use that as fixed rotation without a performance hit, you're welcome to do so.

I'd be happy to have a working solution, with or without the SSD.
It'd be good to get someone to start doing GC320 demos anyway because even if it's not used for rotation there's a very good chance it'll be useful for other things. But this is not something I am going to get an OMAP5 dev board for.

Is this something any of the EVM users here think they can take a stab at?
 
Well, if you're interested, I could set up a remote connection for you incl. Webcam or I could send you an EVM or prototype setup.
 
I am very familiar with pixelart. When 1024x768 where the common resolution, I was doing perfectionism with way more colors than 8bit could handle, with handmade anti aliasing and dithering.

Yes, I can see the artifacts without zooming too, but only on my 24" which has a very good display quality. But there is no way I would see it on the Pyra, I am very sure about it. It is good to know there is a compression used so I wont try anything serious picture-editing related. I just wonder why there is no lossless compression available.
 
Last edited by a moderator:
Back
Top