Severe Screen Tearing In Games.

[DaveC]

Now that there are many new things being released I am noticing a consistant theme through them all, severe screen tearing. Recently openTyrian was released, great port but the tearing is so bad it almost makes the game unplayable. I doubt it is the port that is the problem. The screen slinks and crawls downward as it scrolls. Unfortunatly almost all emus I have tried do this, SNES, Amiga, even C64. It is starting to look like it is a hardware or OS problem or something as all software seems to do it. Is it because devs aren't doing a proper v-sync? Can things be double buffered or something? People complained about the tearing on the Wiz but this seems worse. Is this fixeable? Do the Devs know what the issue is?

 

[Prometheus]

It's come up at least here. The gist of it is that SDL needs optimising. (The linked thread itself is about an LCD timing app that ED later took down when it was noted that the display itself wasn't designed to be pushed like that, but it mentions what needs to be done. )

 

[Exophase]

Yes, devs aren't waiting for vsync or double buffering. For some applications just the former will remove a lot if not all of the tearing. I'm sure not ALL software has this problem - try PicoDrive for instance - but a lot are quick ports.

 

[Prometheus]

I just noticed that a recent official blog-posts mentions this as well;

The community has also started to work on improving the OS. paeryn is currently working on SDL – that would speed up games and eliminate tearing.

 

[zx-81]

Yes, devs aren't waiting for vsync

Is there a simple way to wait for vsync on pandora ?

or double buffering. For some applications just the former will remove a lot if not all of the tearing. I'm sure not ALL software has this problem - try PicoDrive for instance - but a lot are quick ports.

I can try double buffering on opentyrian to see if it's better.

 

[Loon]

Now that there are many new things being released I am noticing a consistant theme through them all, severe screen tearing. Recently openTyrian was released, great port but the tearing is so bad it almost makes the game unplayable. I doubt it is the port that is the problem. The screen slinks and crawls downward as it scrolls. Unfortunatly almost all emus I have tried do this, SNES, Amiga, even C64. It is starting to look like it is a hardware or OS problem or something as all software seems to do it. Is it because devs aren't doing a proper v-sync? Can things be double buffered or something? People complained about the tearing on the Wiz but this seems worse. Is this fixeable? Do the Devs know what the issue is?

Now that's interesting, I've noticed a lot of tearing on SNES & Amiga emulation, quite a bit when watching video but almost none at all when playing Tyrian via the full desktop mode with default clock speed. Only played the 1st level of Tyrian though.

Is it possible that tearing would be worse in minimenu or that tearing could be worse on one Pandora than another? Could it be like the scratchy sound issue where some Pandoras suffered from scratchy sound and others did not despite supposedly identical software & hardware?

 

[notaz]

Yes, devs aren't waiting for vsync

Is there a simple way to wait for vsync on pandora ?

http://pandorawiki.org/Kernel_interface#vertical_sync

I can try double buffering on opentyrian to see if it's better.

If you try doing it over SDL it will currently have no effect, only way to have it currently is using Linux fb interface. There is work being done on having more featured SDL, but it's not clear when it's goint to be finished.

 

[EvilDragon]

paeryn is at it, but hasn't got a unit currently (currently being replaced), so it might take a bit, but he's working on it.

 

[zx-81]

Is there a simple way to wait for vsync on pandora ?

http://pandorawiki.org/Kernel_interface#vertical_sync

Thanks . i will then give it a try in my futur ports.

 

[john4p]

Is this "#define FBIO_WAITFORVSYNC _IOW('F', 0x20, __u32)" also valid for 50Hz-mode?

 

[lulzfish]

Double-buffering?

only way to have it currently is using Linux fb interface.

Does that also apply to v-sync?
I'd rather not stop everything and switch to framebuffer just to have a game not tear.

 

[notaz]

Is this "#define FBIO_WAITFORVSYNC _IOW('F', 0x20, __u32)" also valid for 50Hz-mode?

yes, it doesn't care about the rate.

Double-buffering?

only way to have it currently is using Linux fb interface.

Does that also apply to v-sync?
I'd rather not stop everything and switch to framebuffer just to have a game not tear.

No, you can have vsync as long as display is on, and it should not interfere with SDL. And you can use fb interface while X is running, but you have to ask X to stop updating the screen (op_runfbapp can do it for you).

 

[EvilDragon]

john4p updated UAE4ALL with VSYNC.

The updated version is in the File Archive. It's sooooooooooooo nice

 

[Loon]

john4p updated UAE4ALL with VSYNC.

The updated version is in the File Archive. It's sooooooooooooo nice

Well, that'll make the Pandora all I wanted it to be, an ST and an Amiga in your pocket. Yeah, I was one of those sensible ones with a foot in both camps.

Kudos to john4p.

Goes to get, pinball fantasies here I come.

 

[DaveC]

Yes, devs aren't waiting for vsync or double buffering. For some applications just the former will remove a lot if not all of the tearing. I'm sure not ALL software has this problem - try PicoDrive for instance - but a lot are quick ports.

I should assume that Temper doesn't have screen tearing as that isn't SDL right?

 

[Exophase]

I should assume that Temper doesn't have screen tearing as that isn't SDL right?

Yeah, that's true...

 

[DaveC]

I should assume that Temper doesn't have screen tearing as that isn't SDL right?

Yeah, that's true...

Cool, any estimates as to when we will be able to try it