anyone know the granularity of color/pattern address when the vdp is working in mixed mode?
screen1 -> 2048 bytes of granularity
screen2 -> 8192 bytes of granularity
mixed mode ? -> ?
thx
Aangemeld of registreer om reacties te plaatsen
anyone know the granularity of color/pattern address when the vdp is working in mixed mode?
screen1 -> 2048 bytes of granularity
screen2 -> 8192 bytes of granularity
mixed mode ? -> ?
thx
There is no real mixed mode, so the granularity would be that of screen 2.
There is no real mixed mode, so the granularity would be that of screen 2.
Ah, dvik, you gave me bad news.....
Anyway thx
@dvik:I would go to screen 1.
Using 4 separate ptn buffers that i can swap on the fly should be possible i guess.
if at each frame, one swap the active ptn address, and do some blitting on the other inactive ptn tables (even in active retrace area), even a omni directional scroll routine could be doable as you have already done.
In screen 1 you can have in vram up to 8 sets of patterns (actually 6, if you want a pnt and sprites)
with 2 pixel steps, 4 sets could be used to store pre-rotated tiles for horizontal scrolling
Otherwise, two alternate sets can be used as double buffer: show the first while updating the other by ram->vram transfer (you can do any kind of scroll/animation in this case)
Sad that the color resolution in screen 1 is so low...
I've been using screen 1 more and more, its really underused and not appreciated for its nice properties
Sad that the color resolution in screen 1 is so low...
Yeah, it would have been so nice to have one color entry per character instead of one color entry per 8 characters.
You did a great work on the title screen of Intruder4k
It seems incredible but it is PURE SCREEN1

BTW
About impossible "what if", I would have been happy with a mode with a single tile set with screen 2 color resolution BUT relocatable at 2K steps (i.e. with up to 8 positions for shapes and with up to 8 positions for colors).
Such a mode would have allowed in 16K A LOT of things....
Damn crap of a VDP...
@ARTRAG, Dvik: the limited color table arrangement is, for me a real mistery. Maybe because the vdp was designed to work with only 4KB of VRAM?
But this could be turned into an advantage.
I remember a game, called if i'm not wrong 'centipede' or 'scentipede', that uses screen 1 and updating the color table (not only the color table, to be honest), create the image of a charater with 3 color. Background, border, and internal.
Even without re-basing the address of the color table, writing only 32 bytes is doable on vblank without optimizations.
do you know how to do that effect?
it is sill now a mystery for me
please tell us!
What i'm thinking is a screen converter (max 256 tiles of course), that choose patterns based on the similarity of the combinations of BG/FG colors, in order to gain the maximum number of possibilities (32), but of course a screen could not be converted, not only because one can run out of tiles , but also because of color combinations.
But maybe most screens could even be converted, if:
n. of different patterns <= 256
n. of different color combinations <=32
one does not run out of 32 bytes in colortable, even if there are only two or three different color combinations on the original screen.
Don't you have an account yet? Become an MSX-friend and register an account!
