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