Axelay graphic problems

[ToniBC]

In the game Axelay presents a small graphic error in the upper part that could be present in other games. Above the photo you can see a gradient of the sky and then you see the background of the phase, but it is incorrect, it is missing as a white fade between the two as if Bsnes v107 and other versions.

Incorrect image, white gradient is missing and cut as objects.

In Bsnes 107 or earlier, the image looks correct.

[bearoso]

Looks like at line 32, it starts a gradient using the subscreen background color, but for some reason or another it's just not doing it. I don't know if this simply isn't implemented or is implemented wrong, but it's in the tile renderer, so ugh.

[bearoso]

Ok, I know what we're doing wrong. Subscreen backdrop blending is supposed to occur no matter if subscreen is enabled or not, but we're not doing that.

[bearoso]

It's a little simpler than that, but it might be complicated to fix. We're not applying master brightness properly to the subscreen backdrop and it's blending too bright.

[ToniBC]

Bsnes v107 created a new core for that version or a modification of the one that was oriented to speed. Maybe some idea comes out looking at the code, but of course, I'm not a programmer. It is appreciated that they are investigated to improve the emulator that I like a lot.

[bearoso]

Looks like master brightness in combination with subscreen addition is utterly broken. I'll have to figure out a way to get this fixed.

[bearoso]

I've fixed this, but it's probably a slow way to do it. @OV2, any ideas how to make this faster?

[OV2]

I'll have to find some time to understand what's going on first. It's only fixed atm if GFX_MULTI_FORMAT is undefined, right?

[bearoso]

Basically, we cap the color of the main screen and subscreen to maximum brightness before rendering them in tables, so when we get to the combine step, each component is already darkened appropriately, but if we add them they can exceed the brightness cap.

I thought about keeping the components at full brightness until the end, but that would add a guaranteed table check for brightness for every pixel, rather than just subscreen addition, and make things even slower than how I have it. I think it's sufficiently fast how I have it in the commit I'm working on now, because we lose the 64k GFX.X2 table, which is likely a big cache-eater, and the tiny 32 entry table nets us no branches.

At the moment, the code is RGB565/RGB555 only. I'm thinking about just getting rid of GFX_MULTI_FORMAT. Nothing is really using it to change depths on-the-fly except directdraw, and that can be worked around. Would it be OK with you if I just stripped it all out except the two RGB formats and made everything work with fixed formats?

[OV2]

I'm not sure if any ports were relying on this feature. But I'm fine with removing it.

[bladeoner]

@OV2 @bearoso I've added the commits for removing GFX_MULTI_FORMAT to both Snes9x GX and Snes9x EX+ ports, both are working fine.

[bearoso]

It shouldn't cause any problems. The only use case was switching between 555 and 565 formats at runtime if 565 wasn't supported. In practice, every OpenGL ES 1.0 device supports 565 through an extension, so we don't need to worry about SoCs. DirectDraw 15 bit doesn't exist on Windows XP or greater, so we don't need to worry about that use case either. If by chance an X11 user was running at 15-bit, there might be problems, but the chances of that are slim.

[bearoso]

I'm going to mark this fixed in git.

I'm still not happy that we perform the subscreen math with less precision on lower master brightness. And as can be seen in the sky gradient on the top screenshot, applying master brightness even at full 16-bit precision is wrong because on the hardware it was performed by the DAC and could display colors that couldn't be represented in that format.