YUV2 Fallback Broken?

If you're having problems with Snes9x, or think you've found a bug, this is the place to be.
Post Reply
cmonkey
Snes9x White Belt
Posts: 5
Joined: Wed Dec 30, 2020 12:42 pm

YUV2 Fallback Broken?

Post by cmonkey »

I am running a cli only linux build of snes9x 1.60 (the unix folder). I have tested on two machines and can provide screenshots if absolutely needed. Without the -xvideo argument everything is fine, with the exception that fullscreen does not scale, but I don't think it ever has. With the -xvideo argument colors are really off. When I built and tested snes9x 1.55 one machine (x11-intel-i915) looked great, but the other (x11-openchrome) looked different, than 1.60, but still bad.

The difference between 1.60 and 1.55 causing 1.55 to work on the i915 machine, is the use of rbg555 for 24 bit linux displays.

The i915 has an okay amount of x11 visuals (pixel formats) to pick from. And it finds one and does not have to fall back on the last resort Yuv2 conversion. The change to rgb565 leaves the i915 without a good match and it then fallsback to yuv2.

The openchrome machine falls back with both versions.

Before I understood the code better, I thought that the issue was the change over to rgb565, but the yuv2 conversion still being setup for rgb555. But I doubt that is the case.

I have some notes, but they may not help.

First, I have found why the broken output between 1.55 and 1.60 did not match. The shift operator for blue is reversed after 1.55.
x11.cpp line 635 -> b = (color & 0x001F) >> 3; <- if you switch it back to left shift, the outputs match again. It is my opinion that it should remain left shift. But perhaps this only looks better because something else is broken, and once fixed maybe the right shift would be correct.

As I said before, I had originally thought the issue was that the Yuv2 conversion was still working with rgb555, even though the rest of the x11 is working with rgb565. But I don't think these really interact with each other. Seems to me that the Yuv2 is isolated to its own conversion. But I did try changing it to rgb565 and the result was better, but still incorrect.
r = (color & 0xF800) >> 7;
g = (color & 0x07E0) >> 3;
b = (color & 0x001F) << 3;

The last thing I noticed, is that moving layers seem to not blend well. Game play is fine. But during intros and the like, a still frame with another frame moving across the other lookes painfully unblended. This goes away if you use the -notransparency argument. The odd thing here is that in the untouched (other than the shift operator) 1.60 code, with no transparency you just get the still layer. With the 1.60 code using the yuv2 rgb565 conversion I modified it with, you then lose the still layer and only have the moving one.

The rom I tested with is Castlevania Dracula X. It is a good one because it starts off with the "Konami" logo, which has a white background. That way you can see if your color is white balanced or not. If you let the game load and do nothing, an intro will play and show the layer issue.

It is kind of a pain to upload images, but it would be my guess that this could be reproduced on any Linux machine, if you modify x11 to force useage of the fallback Yuv2 conversion. But if this is not the case, I can provide screenshots and test patches. The issue could be between snes9x and Slackware 14.2, which is used on both machines.
cmonkey
Snes9x White Belt
Posts: 5
Joined: Wed Dec 30, 2020 12:42 pm

Re: YUV2 Fallback Broken?

Post by cmonkey »

I was wrong. The bit shift, for blue, is okay in 1.60. I was using a recent pull from github, where it has since been reversed for some reason.

My understanding is that red must shift 11 and green 5. Then specific to rgb565 the shift is back red 3, green 2, blue 3. Since blue does not have an initial shift, it must shit the other way. So red >> 7 (11 - 3), green >> 3 (5 - 2), blue << 3 ( - 3).

That is why for rgb555 it is 7, 2, 3; since the 2nd shift for rgb555 is 3, 3, 3.
User avatar
OV2
Official Win32 Porter/Dev
Posts: 679
Joined: Thu Aug 30, 2007 10:15 pm

Re: YUV2 Fallback Broken?

Post by OV2 »

I'm not sure where you are pulling the source from, but in git this is still a left shift https://github.com/snes9xgit/snes9x/blo ... 1.cpp#L636

I don't have any unix environment where I can take a look at the moment. You might be better off opening an issue in the git repository, maybe we can then tag in who originally introduced the xvideo support.
cmonkey
Snes9x White Belt
Posts: 5
Joined: Wed Dec 30, 2020 12:42 pm

Re: YUV2 Fallback Broken?

Post by cmonkey »

I appreciate the reply.

At this point, I have since lost track of the git I had pulled from.

I was also backwards with how things worked, with my different devices (embarrassing).

When using 1.55 the i915 was falling back on YUV and the openchrome was not. Everything looks great on the openchrome device, when I alter the code and force YUV.

So there is an issue when a xvideo rgb565 visual is found. I don't have a, linux ready, device with other chipsets to test this on. This may only be an issue with my via chipset.

This is why the video looked bad with both versions on the openchrome.

However forcing YUV does not fix this when using 1.6 on the openchrome, when it does with 1.55.

So my solution was to just use 1.55 on the openchrome.

The xvideo rgb visual could be an openchrome driver issue. But YUV working with the 1.55 on the openchrome shows there is an issue with 1.6. However it my also only be with the openchrome driver.

So this cannot be tested by just forcing YUV, since it looks fine on the i915.

I am actually surprised xvideo hasn't been dropped in favor of adding resolution switching fullscreen code to the SDL output.

I do appreciate the performance increase gained by using xvideo on the via, since you can actually see it on that poor old device.

I should have replied sooner, when I realized where I was wrong.
cmonkey
Snes9x White Belt
Posts: 5
Joined: Wed Dec 30, 2020 12:42 pm

Re: YUV2 Fallback Broken?

Post by cmonkey »

I suppose YUV isn't driver specific, since it also looks bad with the i915 on version 1.6 (just tested).

It would be nice if someone else with linux could test that, since testing would work forcing YUV.
cmonkey
Snes9x White Belt
Posts: 5
Joined: Wed Dec 30, 2020 12:42 pm

Re: YUV2 Fallback Broken?

Post by cmonkey »

I guess I should be calling it YUY2.
Post Reply