To use bitmap sprites, successive copies are required, after covering the previous image with the background.
I have tried this, on screen 11, and if position X is not a multiple of 4, the image is damaged.
I don't understand how you want to do it.
this is due to pixel encoding. From a blitter perspective those modes are more like screen 8 modes while on screen things are different
this is due to pixel encoding. From a blitter perspective those modes are more like screen 8 modes while on screen things are different
Yes, correct I understand.
albs_br,
For this, hardware sprites must be used, maximizing the OR function to the maximum, to obtain the maximum colors, with the minimum number of sprites. https://www.msx.org/wiki/The_OR_Color
To use bitmap sprites, successive copies are required, after covering the previous image with the background. I have tried this, on screen 11, and if position X is not a multiple of 4, the image is damaged. I don't understand how you want to do it.
It’s fine for static enemies, right? They just need to stay in place and cycle through animation frames. Like ground turrets, etc.
albs_br wrote:
Also, the quality improvement of having 19000 color instead of 12000 doesn't seem to be very meaningful.
The numbers 19000 vs 12000 are slightly misleading because those colour counts are arrived at by including all the YJK colours that get clipped on the “edge” of the RGB colour sprectrum.
Not counting the clipped colours, I like to think about it like this:
Screen 12 (YJK) has a range of 16384 colours, with 5 bits for red and green, and 4 bits for blue.
Screen 11 (YJK+YAE) has a range of 8192 colours, with 5 bits for red and green, and 3 bits for blue.
It doesn’t work exactly like that due to the YJK encoding, but by putting it in terms of RGB bit-depth, this gives me a good intuition.
