-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TLUT InternalPalette unexpected results #30
Comments
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. |
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. 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). |
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. |
Yep what ARM9 & fraser125 have stated is true =D |
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. |
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. |
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. ) |
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)?
The text was updated successfully, but these errors were encountered: