Wiz Ram Size

[quote]

OK, does anyone have a video of what exactly screen tearing looks like?
Doesn't have to be on the Wiz, I guess.
I just hear a lot of people complaining about it and havn't seen the problem in action yet .

 

[sbock]

In this video you can see the effect a few times after 1.47:

http://www.youtube.com/watch?v=5szdNBXOFUQ


Regards,
Stephan

 

[quote]

Oh my...

Cheers.

 

[WarmFluffyUK]

My Wiz is on my desk at work at the moment, but I will video the planet explode sequence from Myriad tomorrow which shows the tearing problem up a little better. Originally I thought it might have been a problem with the Fenix runtime which is why I didn't report it as this was heavily in development, but now unfortunately it's destined to stay, at least in this version of the Wiz.

 

[arrrgh]

I could see that getting pretty bad on a sidescroller like Mario or Sonic.

 

[WarmFluffyUK]

I could see that getting pretty bad on a sidescroller like Mario or Sonic.

To be honest I agree, but GPH have released workarounds so don't be too disheartened!

With all the games and emu's I am playing on my Wiz at the moment, I hardly ever am annoyed with the tearing problem. I still whole heartily approve of the Wiz, it's a really nice machine, not perfect but nice. EVERY console has it's quirks, even the Pandora will, it's just the Pandora isn't out there yet for us to report back. And sorry I am not trying to break my own rule of comparing the two, I am just making an analogy of two consoles that haven't yet been released and how one is getting criticized to death because some of us actually have them. Gimme a Pandora and I will criticize that just the same and honestly report what I find.

 

[arrrgh]

I could see that getting pretty bad on a sidescroller like Mario or Sonic.

To be honest I agree, but GPH have released workarounds so don't be too disheartened!

I believe the "workarounds" consist of using a 240x320 video mode.

 

[WarmFluffyUK]

QUOTE

I believe the workarounds consist of using a 240x320 video mode.


Yep you're correct, not tried it myself yet as will not be a problem with my current project.

 

[Prophet]

WarmFluffy,

What is the detriment of using 240x320 for rendering landscape? I'm guessing a speed hit?

There's no way at all GPH will address the issue? Is it just laziness, or something in the hardware that can't be fixed at this point in development?

 

[sam fisher]

WarmFluffy,

What is the detriment of using 240x320 for rendering landscape? I'm guessing a speed hit?

There's no way at all GPH will address the issue? Is it just laziness, or something in the hardware that can't be fixed at this point in development?

*sigh*

 

[Exophase]

WarmFluffy,

What is the detriment of using 240x320 for rendering landscape? I'm guessing a speed hit?

There's no way at all GPH will address the issue? Is it just laziness, or something in the hardware that can't be fixed at this point in development?

*sigh*


I know you've said before that it's strictly a hardware bug that can't be fixed. But this is only GPH's official stance on it (of course they're going to say it's not something they can fix) - until we know why this problem occurs then we can't say what it is one way or another.

There's no direct consequence for using 240x320 mode as portrait, but it's naturally not landscape and most things on Wiz will be (especially emulators), so it can be difficult to coax them into the right format.

Doing so directly will possibly still be faster than using the 3D accelerator to do it for you though. Even though that can be done concurrently while you do other things it'll still eat memory bandwidth in the background.

 

[Orkie]

You can also set the Pollux side of things to read the horizontal pixels in the framebuffer in reverse, to flip it (that will probably make it a bit faster with maybe one calculation fewer to do per pixel ).

 

[quasist]

I see no problem for using 240x320 via OpenGl ES. Just rotate on PI/2 radians and set different projection aspect.

 

[Exophase]

You can also set the Pollux side of things to read the horizontal pixels in the framebuffer in reverse, to flip it (that will probably make it a bit faster with maybe one calculation fewer to do per pixel ).

That wouldn't help at all.

 

[Orkie]

Well it did the way I was doing it, clearly you know a better way.

 

[sam fisher]

Well it did the way I was doing it, clearly you know a better way.

Is that British sarcasm? If so that may not work well on the internet .

 

[Exophase]

Well it did the way I was doing it, clearly you know a better way.

Step through source along the x axis, step through dest along the y axis. Increment to next horizontal line for source, increment to next vertical line for dest. Stepping through the x axis backwards isn't going to save you any time. Which leads me to wonder exactly what you were doing such that you had "operations" per pixel...

 

[Orkie]

Remember, (0, 0) is in the upper right of the screen. But yes, I guess if you use variables to keep track of where you are drawing instead of doing a calculation it wouldn't be useful.

 

[Orange Pumpkin]

Remember, (0, 0) is in the upper right of the screen.

Am I wrong or the PC has 0,0 at the left upper corner of the screen ??

Why isn't it the same ??

 

[quasist]

Remember, (0, 0) is in the upper right of the screen.

Am I wrong or the PC has 0,0 at the left upper corner of the screen ??

Why isn't it the same ??

OpenGL have (0,0) in the left bottom corner...