TLUT InternalPalette unexpected results

[Zapeth]

This is not necessarily an issue with the according test rom, assuming the screenshot was taken from real hardware, but since the results are somewhat unexpected I'd like to at least open up a discussion about it.

To be specific, running the test rom on an emulator (CEN64 and mupen64plus/angrylion-rdp) yields results that one would expect when comparing the displayed colors with the raw tlut color values of the rom (interpreted as 16bpp).
However the colors in the screenshot don't match, for starters none of the tiles should have blue values > 0 and the alpha values are also distributed somewhat different (though I'm not sure yet how they are processed in the emulator either).

I wonder if this is a quirk of the hardware or some incorrect implementation of the emulation software? Though if its the latter, how should the color values be interpreted instead (assuming its a color encoding issue)?

[ARM9]

This may be unrelated but worth noting, I've ran into problems before with screenshots taken on Windows not displaying the correct colors. I tried taking a system screenshot of bsnes+ and pasting it into mspaint.

The safest way to get the 'right' colors is probably dumping the raw framebuffer in the emulator to an image.

[Zapeth]

Just in case it wasn't clear, the colors that are displayed in the emulators actually do look correct, at least when comparing them with the raw color values from the assembly.
Its only when comparing with the included screenshot where the results don't match, you can easily check it yourself by loading the rom e.g. in CEN64 (no rom byte-swapping required).

I guess it would be interesting to know how the included screenshot was created, though I'm assuming it was somehow captured from the console (at least the picture quality is an indication).

Of course its always nice if someone could double-check the results on real hardware, unfortunately I don't have the necessary equipment myself (though I would like to test a ton of other stuff).

[fraser125]

I believe PeterLemon has stated that most/all screenshots from hardware were taken using video capture card, so very difficult to guarantee color accuracy.

There has been another technique that has been used to capture screenshots but it requires additional code and hardware (64Drive) both of which would affect the compatibility of the same test rom to run on console and in emulators unless 64Drive features are implemented in the emulator as well.

[PeterLemon]

Yep what ARM9 & fraser125 have stated is true =D
most of my early screenshots were just copy/pasted from cen64/MAME emulators, someone else then started taking screenshots from real HW, saving out the actual VI framebuffer bytes & converting that to a .png for me, by modifying my demos, not all screenshots have been done this way though.
Sorry for the confusion ;)

[Zapeth]

That answer still confuses me though :P

If the actual VI framebuffer bytes were used to generate that image, then there definitely shouldn't be a color difference when compared to an emulator.
Unless the png conversion process wasn't done properly or the modified demos used different color values, or is that what you were referring to?

[PeterLemon]

Only a few screenshots have VI bytes saved from HW, mainly for CPU tests, most of my RDP test screenshots have been saved from emus.

[bryanperris]

In this test's source code, the framebuffer mode should be set to 8-bit mode (1), and not Color Index mode which equals to 2.

I was able to get the right colors to output, and maybe fixed a bit with the alpha masking involved. The colors seem fine from the screenshot, the only thing missing is the anti-aliasing. Also my framebuffer scaler is stretching out the texture rectangles too much height wise.

The RCP has a built-in 8-bit palette that only gets used in the 8-bit framebuffer mode.

What seems to happen in the hardware is that the user TLUT 16-bit value is OR'd with the computed color from the internal 8-bit TLUT. Like if you read 0xFF00 from TLUT using the color index 0xFF, then the 8-bit palette returns also 0xFF, there for the final 16-bit color result is 0xFFFF which gets you white. So all of the colors you find in Peter's TLUT source are simply repeated for both hi and lo bytes of the final 16-color.

If the 16-bit colors seem a bit off its either a poor conversion from RGBA5551 to whatever target color format was chosen or it could be result of in the lack of VI filtering. Also 16-bit graphics involve more dithering. I noticed that some 16-bit grays should be appear much darker than what I produce in my framebuffer, no doubt this is the work of the VI itself.

( Btw, ignore the fact it says PAL I have a bug in region detection. )