Could this technique be used for a horizontal scroll?
The horizontal scroll, only with V9958, works by combining the R#26 registers from 8 to 8 pixels, with the R#27 which is the fine one that goes from 1 to 1 pixel.
It is convenient to mask the jump of 8 pixels, which loses 8 pixels of width of the screen.
Hi albs_br
Why don't you use screen 12?
I've tried it and it works perfectly.
Being YJK, you can get the full image with BMP2G9B.
I guess the main reason is having 16 RGB based colors for sprites…
Indeed. We define sprites with their palette.
https://www.youtube.com/watch?v=fugnGL1LiVs
not public sorry.
This one I think so.
https://studio.youtube.com/video/mUgsNs8ixX0/edit
correct link https://www.youtube.com/watch?v=mUgsNs8ixX0
Thanks syn
Hi albs_br
Why don't you use screen 12?
I've tried it and it works perfectly.
Being YJK, you can get the full image with BMP2G9B.
It's important for me to have the capacity of drawing software sprites on background. In future I may need it, as the hardware sprites are very limited (for an ambitious project like this). I plan to use one (or more) sprite splits, but currently I have no experirence with this techinique so it's safer to have the two possibilities opened.
Also, the quality improvement of having 19000 color instead of 12000 doesn't seem to be very meaningful.
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 important for me to have the capacity of drawing software sprites on background.
this is not an *easy* task to do in V9958 screen modes as it is in screen 5 to 8 modes, due to pixel encoding.
those modes are best suited for statics images, not for animations.