Looks like you're making exciting progress, congratulations!
Please don't hesitate to ask if you have any questions.
Oh well, we need a mess vs. bsnes snap comparison before continuing talking all the day about it ;P
Yes, discussed on my forum. Minor regression caused while moving some things for save state support:
src/ppu/ppu-inline.hpp:77:
status.hcounter = 0;
//was status.hcounter = 186;
//which was mis-aligning OAM address reset and such
http://img13.imageshack.us/img13/2981/71901316.pngIn the middle of adding a GUI-based debugger, so no new build just yet.
Color shifting is the first thing that MESS does what other snes emus don't afaik. Ideally if you should do a color conversion to a framebuffer and you can't completely fill that framebuffer, you should fill the remaining data with the most significant bytes of the color offsets.
If you're meaning SNES RGB555->RGB888 bit-extending (10111->10111101 instead of 10111000), I already do that. If you're meaning direct-color mode RGB443->RGB555, then you are incorrect. The low bits are always zero on the real thing.
//palette data = 00000bgr
//tilemap data = BBGGGRRR
//result = 0BBb00GGGg0RRRr0
Verify yourself by placing an all-white sprite on top of the BG layer.
If your goal is to make the output prettier than the real thing, it's a good strategy. I'd also recommend rasterizing mode 7 at 512x448 in that case
Now then, if you really want to be the first to do something ... $2100 INIDISP controls the screen brightness. But it is not a linear drop as you go down. In fact, with a brightness of zero the screen is still visible. Max out your TV brightness control and you will see it. The effect can't be simulated in RGB555 colorspace. The actual color adjust occurs on the luma channel upon TV output in YUV format. The exact algorithm is unknown, as it's very hard to measure.
