Opened 22 months ago
Last modified 8 weeks ago
#15395 new defect
TWINE: Shading Palette loss of colours?!
| Reported by: | xesf | Owned by: | |
|---|---|---|---|
| Priority: | normal | Component: | Engine: TwinE |
| Version: | Keywords: | palette, screen, shade-table | |
| Cc: | xesf | Game: | Little Big Adventure |
Description (last modified by )
When looking at Twinsen with Tunic we can clearly see the shading palette in Tunic is not correct and you can see the artifacts in the animation when comparing with the original or TwinEngine.
Added 2 videos for comparison, one from ScummVM another from TwinEngine.
Attachments (2)
Change History (5)
by , 22 months ago
| Attachment: | twin-e.mov added |
|---|
by , 22 months ago
| Attachment: | scummvm-twine.mov added |
|---|
comment:1 by , 22 months ago
| Description: | modified (diff) |
|---|
comment:2 by , 22 months ago
| Summary: | Shading Palette loss of colours?! → TWINE: Shading Palette loss of colours?! |
|---|
Note:
See TracTickets
for help on using tickets.
this might have to do with the high and low bit handling of the color/normal combination in the renderer. it looks like the same normal is used for a bigger area as in the original renderer. might also be clamping related. See e.g. Renderer::svgaPolyGouraud() in SVGAPolyGouraudS proc in original sources.
the original uses dh (the high byte of the 16-bit intensity value) as the color index
The color is added to the LOW byte of the intensity word. This means the final 16-bit value stored per vertex is: high byte = intensity, low byte = color + intensity_low_bits
The issue is maybe in preparePolygon() - a mismatch in how the per-vertex intensity (palette index) is computed and used compared to the original. but needs more investigation...