Open ped7g opened 4 years ago
The setup was way from core2.0.x times, not doing anything explicit about new regs like $68, $6B, $70, ... But even after modifying the setup to be more explicit the visual results are still same.
With further research the pink is coming from "fallback colour" $4A register.
My current hypothesis is that core3.1.5 has bug. The blending mode is described as: "(U|T)S(T|U)(B+L)" which in my understanding means this:
Now the transparency rules should be like this ... long pause, looking for official docs... didn't find any, so this is unofficial info I got probably directly from Allen long ago:
There were recent changes adding the "front" non-blend layer (first "(U|T)") which I did not test yet and the failure in Lmix_LxU is happening between the LoRes vs Layer2 blending.
Needs further explanation/confirmation from Allen, if this is happening or I messed it up somewhere... :)
Allen confirms this is by-design change, i.e. "UP + LT" case should really result in transparent pixel with 3.1.1+ cores.
We are still discussing it, if this is going to stay like this, but seems likely to stay, so the test needs to be fixed then.
Test updated to core3.1.5 blending rules, photos updated, description fixed.
Open: extend the test or create new test to exercise all the new core3.1.5 combinations, with ULA vs Tilemap capable to be displayed separately.
the core 3.1.10 (since 3.1.3? But test-confirmed on N-Go with 3.1.10 core) "(U|T)S(T|U)(B+L)" meaning:
Open: extend the test or create new test to exercise all the new core3.1.5 combinations, with ULA vs Tilemap capable to be displayed separately.
Areas which should be transparent and display white background there is the $E3 pink colour instead.
It's not clear whether the blending-mode changes from core3.1.5 make the original setup of test invalid and this is correct result, or the original test should have displayed the screen as before and this is new core bug.
Investigate: