Does It Have Less Blur(or Ghost) Than Other Handheld With This Oled Sc


renejr902

Active Member
Joined
Apr 19, 2008
Messages
767
Age
44
Location
CANADA, Montreal
Website
Visit site
does it have less blur than other handheld with his oled screen. nintendo ds, psp has a lot of blur in sonic games (genesis) even nes roms have a lot of blur when mario run fast all background things are very blur compqred to the real hardware on a crt television. i hope that oled screen could resolve this problem . i know gp2X has less blur than psp, but its far from perfect. so does this oled screen help to remove blur in games. thanks for answer
 
even nes roms have a lot of blur when mario run fast all background things are very blur compqred to the real hardware on a crt television. i hope that oled screen could resolve this problem . i know gp2X has less blur than psp, but its far from perfect. so does this oled screen help to remove blur in games. thanks for answer
Actually, I notice little-to-no blur at all with this screen. Its very nice, besides the screen tearing, but that will be fixed in a later firmware, I'm sure.
 
Last edited by a moderator:
The screen on the Wiz no noticable blurr, OLED technology has a vasty superior refresh rate compared to the TFT that the PSP/DS uses. This is why I am looking forward to OLED being used in televisions, far superior to Plasma or TFT.
 
There is no noticeable motion blur at all. It does not have any trails or smearing. The OLED screen has much better response time then any LCD on anything.

There is also no problem with viewing angle. Rotating the screen (like when playing MAME) has no bad effects to the contrast or color unlike an LCD. If you wanted to play looking at it from the side you can too, although I don't know why anyone would do that.
 
:wiz: im happy to heard that! but i read all the topic about tearing and im not sure what is it. is it some diagonals lines that appear around the textures. i cant see it on you tube. but i think my onestation have this problem. can someone explain that tearing tbing with more details thanks
 
renejr902 posted on May 18 2009 at 11:58 PM said:
:wiz: im happy to heard that! but i read all the topic about tearing and im not sure what is it. is it some diagonals lines that appear around the textures. i cant see it on you tube. but i think my onestation have this problem. can someone explain that tearing tbing with more details thanks
Yeah, actually.

I thought it would've been a big deal as well, but its really not much of anything, other than this noticeable diagonal line across the screen when it flashes. Its hardly even noticeable.
 
Last edited by a moderator:
Normally, if an image on the display was scrolling from left to right, the whole rectangular image would move as one. Imagine a diagonal line drawn corner to corner, so instead of one rectangular screen you have two triangular ones. In this instance, when an image moves from one side to the other, the two triangular screens appear to be moving slightly out of sync. This is diagonal screen tearing.

I do not have a Wiz to test, but apparently it is only noticeable during fast motion.
 
I just got my Wiz today and it's very noticeable in Sonic. When you are running you can nearly see it all the time. But I can still play perfectly, it's not as bad as blur would be.
 
Arrgghh.. this diagonal is killing me! everytimes I looking at it! can't wait till new firmware!
 
iprice posted on May 19 2009 at 11:44 AM said:
Didn't GPH say they fixed the screen tearing? Sounds like someone was telling porkies...
They claim to have a software workaround, but programmers will have to use it for it to work. Don't forget that the devs have all been working with older firmware up to now. It's going to take a while to add the workaround into all the games and emulators that need it.
 
Last edited by a moderator:
iprice posted on May 19 2009 at 04:44 PM said:
Didn't GPH say they fixed the screen tearing? Sounds like someone was telling porkies...
They changed SDL so that it was fixed (supposedly) but it made everything that used SDL run at 25% the former framerate.

Now they are working on some OpenGL es code to avoid it by using the 3D hardware or something.
 
Last edited by a moderator:
Lets clear this up, yes there is a hardware screen tearing issue, but GPH have solved this if devs use their SDL. Currently older projects do not, and it may take time for developers to adapt.

How devs chose to code is up to them, but if they follow the rules then all will be fine.
 
WarmFluffyUK posted on May 19 2009 at 08:43 PM said:
Lets clear this up, yes there is a hardware screen tearing issue, but GPH have solved this if devs use their SDL. Currently older projects do not, and it may take time for developers to adapt.

How devs chose to code is up to them, but if they follow the rules then all will be fine.
Devs? Following rules?

Enjoy your screen tearing. :lol:
 
Last edited by a moderator:
WarmFluffyUK posted on May 19 2009 at 10:43 PM said:
Lets clear this up, yes there is a hardware screen tearing issue, but GPH have solved this if devs use their SDL. Currently older projects do not, and it may take time for developers to adapt.
You mean they're done, and if I link to SDL currently in Wiz I will have no tearing?
 
Last edited by a moderator:
WarmFluffyUK posted on May 19 2009 at 07:43 PM said:
Lets clear this up, yes there is a hardware screen tearing issue, but GPH have solved this if devs use their SDL. Currently older projects do not, and it may take time for developers to adapt.

How devs chose to code is up to them, but if they follow the rules then all will be fine.
I've heard reports that if you use the fix via SDL you get a tremendous speed hit that'd ruin just about anything. Sounds to me like they're either still using a very poorly written software version or they're using an OpenGL ES 1.1 solution that imposes a major penalty. The latter wouldn't surprise me at all, if they're binding textures every frame then a big speed hit happens on other platforms too.

I wouldn't want to use their SDL solution anyway. You probably wouldn't get scaling, definitely not to your customization. I don't think they've fixed their SDL yet so that it actually works at a 44KHz audio, and I wouldn't want to use Linux audio with SDL video. And if SDL input is like it was on GP2X then it's unusable as well, although I keep forgetting why - all I can say is that every time I forget the problem I try again and realize it again. I think release events may not be triggering for the dpad.

I don't think an OpenGL ES solution is as obvious as everyone thinks. Okay, think about it this way.. your program uses normal system memory and chances are your texture would use it too. To get to a place where the 3D core can see it it has to be in physical memory because it has to be a contiguous block. As far as I'm aware, textures also have to be block swizzled - the memory controller has an interface to do this for you, but again this is something that the texture binding has to follow. Maybe at best you would have a software copy from virtual memory to physical memory, which would completely defeat the purpose since a copy + rotation takes the same amount of work.

No, what you want is a virtual framebuffer that resides in physical memory. Actually, you want two of them that are double buffered so you can start writing to the next one while the old one is being blitted to the screen by the 3D hardware. You also want to mmuhack this memory region so you get write buffering on or it'll be slow to write to. I don't know if it's possible to do this using OpenGL ES, but you really wouldn't want to have to carry around its entire weight just so you can get this functionality.

Unfortunately, driving the 3D core isn't the most obvious thing in the world and GPH's documentation doesn't exactly make it a walk in the park. There are a lot of higher level abstractions/interfaces set up for dealing with real 3D scenarios - vector transformation, display lists, triangle setup, etc. You really want to skip all of this if possible, and I think it is, by setting up a set of primitive command registers directly. Then there's the memory map of the 3D core which has a lot of sub-blocking and corresponding terminology. I think it should be pretty doable for one of us to drive this operation and ensure that it comes at a low cost, but it's probably going to take some playing around before we can get it working. Then again, I have no experience with driving 3D hardware directly so someone else might feel more comfortable doing this or helping me with it.
 
Last edited by a moderator:
Back
Top