A while ago I got a tip from Sonic to use 2 sprite attribute tables.
Back then I wasnt ready for such magic.
Now its entering my thoughts again, and I was thinking about this:

some enemies are 16x32 pixels, but are actually 2 (16x16) enemies which function as one.
The movement of this 16x32 enemy is handled in 2 parts.
first the top sprite is moved, then the bottom one.
The sprite attribute table is copied to VRAM at VBLANK.
now when the VBLANK int. occurs right inbetween setting the x+y attributes of those 2 sprites,
then the movement of them doesnt look smooth.
In other words:
It would be handy if I could first update all enemies, and THEN write the attribute table to VRAM.

What could I do best, and what is your experience with this?

Should I:
Have 2 attribute tables in RAM, or 2 in VRAM ?
And what about the color table. or sprite character table ?
Some enemies need to change their color at VBLANK.

??

Quote:

A while ago I got a tip from Sonic to use 2 sprite attribute tables. Back then I wasnt ready for such magic. Now its entering my thoughts again, and I was thinking about this: some enemies are 16x32 pixels, but are actually 2 (16x16) enemies which function as one. The movement of this 16x32 enemy is handled in 2 parts. first the top sprite is moved, then the bottom one. The sprite attribute table is copied to VRAM at VBLANK. now when the VBLANK int. occurs right inbetween setting the x+y attributes of those 2 sprites, then the movement of them doesnt look smooth. In other words: It would be handy if I could first update all enemies, and THEN write the attribute table to VRAM. What could I do best, and what is your experience with this? Should I: Have 2 attribute tables in RAM, or 2 in VRAM ? And what about the color table. or sprite character table ? Some enemies need to change their color at VBLANK. ??

If you have place, take a your own copy of sat on RAM then copy at vblank on VRAM. This is for speed reasons.

While VRAM Access is relatively fast copying continuos blocks it's extremely slow for random access. So, for example, in ram it's easy to update the y pos of sat for the 4 and 8 sprite. Assuming hl pointing to the beginning of ram sat:

ld hl,sattable
ld de,4
add hl,de
add hl,de
ld (hl),a
add hl,de
add hl,de
ld (hl),a

if you work directly in VRAM you need two slow VRAM access.


ld hl,sattable
ld de,4
add hl,de
add hl,de
call setvrwrt
out (0x98),a
add hl,de
add hl,de
call setvrwrt
out (0x98),a

..... not a good thing. Taking the sat in RAM also allow you to structure sat as you need. So for example:


first byte : y
second byte: x
third byte: patterno
fourth byte: blink flag (immaginary)
fifth byte: altenate patterno to use for animate it (immaginary)

... so on
you can also add a flag used to display it, ... and other useful infos.

Quote:

The sprite attribute table is copied to VRAM at VBLANK. now when the VBLANK int. occurs right inbetween setting the x+y attributes of those 2 sprites, then the movement of them doesnt look smooth.

It seems to me that you're trying to fix the wrong problem. From your statement I conclude that the code that processes your sprites is not synced to the interrupt routine that displays them. If you want to get rid of stutters, then you should sync this code so you can be sure that the processing is done before displaying.

Quote:

Quote: The sprite attribute table is copied to VRAM at VBLANK. now when the VBLANK int. occurs right inbetween setting the x+y attributes of those 2 sprites, then the movement of them doesnt look smooth. It seems to me that you're trying to fix the wrong problem. From your statement I conclude that the code that processes your sprites is not synced to the interrupt routine that displays them. If you want to get rid of stutters, then you should sync this code so you can be sure that the processing is done before displaying.

Like ONLY write the SPAT to VRAM after all the enemies have been moved ?

More the other way around. Make sure enemies have moved before the spat is moved to vram.

hey another silly question just pops my mind:
is there a simple OUT instruction for turning on/off the CAPS lamp signal ??
cool for some slickering effect (like when the endboss enters)

Check the docs on port $AA.

cool !~!
and what about the FDD BUSY lamp and the POWER lamp ??

Don't push it

ow, damn,
those leds cannot be handled manually ?

Don't push what? The power switch?

All leds, save for the power led, (including CAPS, KANA, R800, FDD, etc) are manually controllable. But I'm afraid that programming the FDD led would involve some FDC knowledge. Maybe Prodatron can help you out on that

I suggest, that you don't mess with FDD led. On some machines it can be changed without turning motor on, but usually it is linked to FDC motor signal. Way of turning the led on/off is depends of MSX model and disk controller. Here ís information about MSX tR LEDs:

http://www.msx.org/forumtopic1566p18.html

Quote:

A while ago I got a tip from Sonic to use 2 sprite attribute tables. Back then I wasnt ready for such magic. Now its entering my thoughts again, and I was thinking about this: some enemies are 16x32 pixels, but are actually 2 (16x16) enemies which function as one. The movement of this 16x32 enemy is handled in 2 parts. first the top sprite is moved, then the bottom one. The sprite attribute table is copied to VRAM at VBLANK. now when the VBLANK int. occurs right inbetween setting the x+y attributes of those 2 sprites, then the movement of them doesnt look smooth. In other words: It would be handy if I could first update all enemies, and THEN write the attribute table to VRAM. What could I do best, and what is your experience with this? Should I: Have 2 attribute tables in RAM, or 2 in VRAM ? And what about the color table. or sprite character table ? Some enemies need to change their color at VBLANK. ??

Personally I'd keep two tables in VRAM. You update these tables when you're good and ready to do so (so not during VBLANK like some suggested here), and on VBLANK you change the pointer to the table instead of OUTing the data. This leaves you with much more time so actually write the sprite data (so you won't have trouble when moving a great deal of sprites around), plus it means only a couple of OUTs during VBLANK, allowing you to do other time-critical stuff that needs to be done during VBLANK. It's prolly best to prepare all data in RAM, and then OUT the whole bunch to vram. If you do a lot of big copies, it might be a good idea to send the data while the VDP is executing one of those copies. I've heard this may slow down the command slightly, but it might still be a good idea to take advantage of this parallelism. Natually, you may need to update the color and patterntables likewise, depending on what you're doing. Most of the time just updating the attribute table will be enough though.

thanks
ill work on it