Tearing Phenomenon


dogeymon

Still Fresh
Joined
Aug 7, 2009
Messages
82
Location
Chico, CA
Website
www.facebook.com
I have been overjoyed ever since the Picodrive update fixed that unsightly tearing problem. All the games run perfectly.

But the tearing problem still exists with the AlexKidd, NES, PocketSNES, TG16, and such emulators. Can't they do the same treatment to those that they did to the Picodrive??
 
dogeymon said:
I have been overjoyed ever since the Picodrive update fixed that unsightly tearing problem. All the games run perfectly.

But the tearing problem still exists with the AlexKidd, NES, PocketSNES, TG16, and such emulators. Can't they do the same treatment to those that they did to the Picodrive??

It is not simply a matter of Fixing a tearing issue. It is a matter of reprogramming your graphics engine for the emulator you use. GPH in all their excellence have created a good handheld but yet again have screwed up by rotating the screen the wrong way. As I understand it the screen originally is actually a portrait mode screen that has been fitted to function in the Wiz as a landscape oriented screen. So the updates of the screen are performed in a different way. Like the scanlines in old CRT TVs.
This causes problems as almost all the emulators out there are optimized for a landscape oriented screen and framebuffer. The software of the Wiz solves that by doing the rotate but this causes tearing, because of the way the screen is set up.
So in order to make things work without tearing on the Wiz you need to rotate the emulators screen output in a smart way....

Options:
- Rewrite your emulator's tile engine so that it accommodates the portrait framebuffer so there's no tearing whatsoever
- Plot the screen using the emulator's standard code but add a software rotate before plotting the screen in native portrait mode
- let the device handle the rotation in OpenGL

Option 1 is a huge task in most cases....
Option 2 is used but slows down the emulator and diminishes framerates as CPU power is needed to convert each frame before plotting it.
Option 3 could be really fast but no -one has used it yet (I think.... )

Your use of 'they...' implies a uniform group of people responsible for the graphics on the Wiz - well in case of the mentioned emulators in your post this is not a uniform group but individual programmers. 'They' may opt to fix it or 'they' may not. ;-)


Cheers, from a rudimentary programmer from the Netherlands....
 
Last edited by a moderator:
Unless the pixel buffer implementation on OpenGL ES 1.1 for Pollux is really good the chances are option 3 won't be any faster than option 2, and more likely a lot slower. Someone can go ahead and try this, but if it's slow then nothing can be done to improve it since the drivers aren't open. It would probably be better to circumvent then and access the 3D hardware directly; of course someone with Pollux documentation has to do this.
 
Mark1970 said:
dogeymon said:
I have been overjoyed ever since the Picodrive update fixed that unsightly tearing problem. All the games run perfectly.

But the tearing problem still exists with the AlexKidd, NES, PocketSNES, TG16, and such emulators. Can't they do the same treatment to those that they did to the Picodrive??

It is not simply a matter of Fixing a tearing issue. It is a matter of reprogramming your graphics engine for the emulator you use. GPH in all their excellence have created a good handheld but yet again have screwed up by rotating the screen the wrong way. As I understand it the screen originally is actually a portrait mode screen that has been fitted to function in the Wiz as a landscape oriented screen. So the updates of the screen are performed in a different way. Like the scanlines in old CRT TVs.
This causes problems as almost all the emulators out there are optimized for a landscape oriented screen and framebuffer. The software of the Wiz solves that by doing the rotate but this causes tearing, because of the way the screen is set up.
So in order to make things work without tearing on the Wiz you need to rotate the emulators screen output in a smart way....

Options:
- Rewrite your emulator's tile engine so that it accommodates the portrait framebuffer so there's no tearing whatsoever
- Plot the screen using the emulator's standard code but add a software rotate before plotting the screen in native portrait mode
- let the device handle the rotation in OpenGL

Option 1 is a huge task in most cases....
Option 2 is used but slows down the emulator and diminishes framerates as CPU power is needed to convert each frame before plotting it.
Option 3 could be really fast but no -one has used it yet (I think.... )

Your use of 'they...' implies a uniform group of people responsible for the graphics on the Wiz - well in case of the mentioned emulators in your post this is not a uniform group but individual programmers. 'They' may opt to fix it or 'they' may not. ;-)


Cheers, from a rudimentary programmer from the Netherlands....


Oh yeah, I know that different individuals make different emulators. I sorta meant "they" referring to all the different creators with their emulators.

Wiz makers put the screen in wrong??? WOW. That's interesting. I think I get it. You are really knowledgeable about this. Were you implying that I can fix this myself without the emulators' creator's help???
 
Last edited by a moderator:
dogeymon said:
Wiz makers put the screen in wrong??? WOW. That's interesting. I think I get it. You are really knowledgeable about this. Were you implying that I can fix this myself without the emulators' creator's help???

No, they didn't put it in wrong - the screen is meant to be portrait mode. Think of your TV - it scans from top to bottom as it builds a picture. The Wiz screen does something similar, but right-to-left (or left-to-right, whichever). Because most emulators emulate a landscape screen they tend to build their frames from top to bottom - the conflict of directions results in a diagonal tear.

GPH didn't put it in wrong, as I said - either the cost of a landscape 320x240 OLED screen was prohibitive, or they simply don't exist. I'd imagine a little of both, as they're intended to go into mobile phones, not handheld gaming devices.

D.
 
Last edited by a moderator:
Back
Top