Screen Tearing Issue Fix?

[Spykez]

Well I guess it's not really a fix but I hear people complaining (not meant as a derogatory statement of what people do) about this most annoying screen tearing issue and I notice it a lot of side scrolling games, at least I used to. As far as I know right now the NES and GBA emulators both contain an anti-tear/v-sync mode that, from what I can tell, eliminates any screen tearing issues. I was doing castlevania on GBA and the tearing was horrible, put it into anti-tear mode, didn't see one bit of tearing, same thing with the NES, turn on perfect v-sync and no tearing.

So it's obvious getting rid of the tearing issue is possible, so why not code in the option for settings or something to enable a v-sync like feature?

 

[Exophase]

It has nothing to do with vsync. The only way to get around the tearing is to use portrait mode, which involves either rotating the display after it's rendered or fundamentally changing the way in which it's rendered, which can be non-trivial to achieve. The GBA emulator can basically do it for free because it's scaling the display anyway, and folding rotation into that doesn't cost anything extra.

The other issue is that it requires firmware 1.0.1, as far as I'm aware. Doing the ioctl to put the Wiz in portrait mode doesn't seem to work on 1.0.0.

 

[notaz]

The other issue is that it requires firmware 1.0.1, as far as I'm aware. Doing the ioctl to put the Wiz in portrait mode doesn't seem to work on 1.0.0.

Hm, works fine for me on 1.0.0. Maybe your kernel wasn't flashed properly and you're still running pre-release one?

 

[Exophase]

The other issue is that it requires firmware 1.0.1, as far as I'm aware. Doing the ioctl to put the Wiz in portrait mode doesn't seem to work on 1.0.0.

Hm, works fine for me on 1.0.0. Maybe your kernel wasn't flashed properly and you're still running pre-release one?

Nah, the pre-release one was actually running in portrait by default. The one flashed is definitely different.

Maybe I was doing something wrong when I tried it.

 

[sbock]

I tried both gpSP and MAME on 1.0.0 and the portrait mode work fine.

 

[Alex.]

Exophase is right, switching to portrait mode from landscape can be non-trivial. For programs that consist of sprites and backgrounds this is simple, but for things that take advantage of the portrait mode pixel order this change can ruin everything. Honestly I hope that GPH can force SDL apps to adopt portrait mode through the 3D hardware at a firmware level for little cost, so that we can keep on using the intuitive landscape orientation.

On the plus side, forcing people to use 240*320 could push on new GP32 ports

 

[vsviridov]

After enabling no-tear mode on gpsp some games just started to crash the emu and return back to the wiz menu. So I switched it off for now.
Is there any way to obtain a crash dump? So i could send it to the developer maybe?

 

[Franxis]

It has nothing to do with vsync. The only way to get around the tearing is to use portrait mode, which involves either rotating the display after it's rendered or fundamentally changing the way in which it's rendered, which can be non-trivial to achieve. The GBA emulator can basically do it for free because it's scaling the display anyway, and folding rotation into that doesn't cost anything extra.

The other issue is that it requires firmware 1.0.1, as far as I'm aware. Doing the ioctl to put the Wiz in portrait mode doesn't seem to work on 1.0.0.

I assume the screen can be rotated and scaled using OpenGL without cost... if GPH provides the library or the sample code in the future...

 

[Squidge]

Maybe I was doing something wrong when I tried it.

Here's what I use (you might not need everything. On my dev Wiz nothing was visible unless you enabled the layer(s) yourself, not even the menu! :

static FB_RGBSET rgbset;
static unsigned int DevEnable[3];

CODE
DevEnable[0] = 0; // layer
DevEnable[1] = 1; // on
DevEnable[2] = 1; // mlc_dev
ioctl(dev_fb_0, FBIO_DEVICE_ENABLE, DevEnable);

rgbset.Layer = 0;
rgbset.Addrs = 0;
rgbset.Left = 0;
rgbset.Top = 0;
rgbset.Right = 240;
rgbset.Bottom = 320;
rgbset.HStride = 2;
rgbset.VStride = 4096;
rgbset.enable3D = 0;
rgbset.Bakcol = 0x0;
rgbset.Mlc_dev = 1;
ioctl(dev_fb_0, FBIO_RGB_CONTROL, &rgbset);

// Off = 240*320
send[0] = LCD_DIRECTION_OFF_CMD;
ioctl(dev_fb_0, FBIO_LCD_CHANGE_CONTROL, send);


and then for the other direction:

CODE
rgbset.Right = 320;
rgbset.Bottom = 240;
ioctl(dev_fb_0, FBIO_RGB_CONTROL, &rgbset);
send[0] = LCD_DIRECTION_ON_CMD;
ioctl(dev_fb_0, FBIO_LCD_CHANGE_CONTROL, send);

 

[notaz]

After enabling no-tear mode on gpsp some games just started to crash the emu and return back to the wiz menu. So I switched it off for now.

What games? Any easy way to reproduce?

Is there any way to obtain a crash dump? So i could send it to the developer maybe?

It wouldn't help much because the binary is stripped.

 

[EvilDragon]

It has nothing to do with vsync. The only way to get around the tearing is to use portrait mode, which involves either rotating the display after it's rendered or fundamentally changing the way in which it's rendered, which can be non-trivial to achieve. The GBA emulator can basically do it for free because it's scaling the display anyway, and folding rotation into that doesn't cost anything extra.

The other issue is that it requires firmware 1.0.1, as far as I'm aware. Doing the ioctl to put the Wiz in portrait mode doesn't seem to work on 1.0.0.

I assume the screen can be rotated and scaled using OpenGL without cost... if GPH provides the library or the sample code in the future...

AFAIK GPH plans on doing that

 

[notaz]

AFAIK GPH plans on doing that

They really need to end planning and actually do it.

 

[rx_shorty]

AFAIK GPH plans on doing that :"]

They really need to end planning and actually do it.[/quote]Yup they do, but they are still working on the manual from what I have understand of it...

 

[Duddyroar]

Forgive me if this has already been asked elsewhere Notaz, but are you able to solve the tearing issue in PicoDrive? I'm running 1.35 and the tearing is terrible...is this the latest Wiz-compatible version?

 

[sbock]

Forgive me if this has already been asked elsewhere Notaz, but are you able to solve the tearing issue in PicoDrive? I'm running 1.35 and the tearing is terrible...is this the latest Wiz-compatible version?

http://www.gp32x.de/board/index.php?/topic/48602-picodrive-tearing-reduction-not-working/

 

[wizzy]

Is this problem present in all Wiz units? I don't see this problem in my new Wiz...

 

[sbock]

Is this problem present in all Wiz units? I don't see this problem in my new Wiz...

Yes, but some people don't seem to notice the problem that much. There're also a few workarounds available. The Wiz menu, music and videoplayer are not affeccted since the firmware update 1.0.1.

 

[torpor]

Its very annoying, in my opinion. I see these screen tearing artifacts as being a real downer .. hope a standard fix is possible, soon ..

 

[Duddyroar]

Forgive me if this has already been asked elsewhere Notaz, but are you able to solve the tearing issue in PicoDrive? I'm running 1.35 and the tearing is terrible...is this the latest Wiz-compatible version?

http://www.gp32x.de/board/index.php?/topic/48602-picodrive-tearing-reduction-not-working/

Thanks