ASM: VERTB int and 16 colored sprites.

[Asman]

Hello,

I need some explanation about VERTB int + 16 colored sprites. I uploaded into zone two examples ( four files: 2 source + 2 binary ). the main difference between sources is hidden in two lines inside the VERTB routine.

		bsr	fill_sprites
		bsr	sprites_on

and

		bsr	sprites_on
		bsr	fill_sprites

But only second one works, mean there are four moving and blinking sprites on screen. I can't explain why when I launch vertb-spr16-bad then there is no sprites on screen. Any ideas are welcome ?

I tested on my A1200 blizzIV 030/50 32mb fast and on WinUae ( beta 20 or something ) I choosen a1200 configuration + cycle exact option.

edit:
vertb-spr16-bad.asm ( binary:vertb-spr16-bad ) - there is no sprites on screen
vertb-spr16-ok.asm ( binary: vertb-spr16-ok )- blinking and moving sprites on screen


Regards

[pmc]

Asman - I only quickly scanned the souce code but didn't run the .exe's

You have a vblank interrupt to keep things sync'd with the display but you are also waiting for vb in your main loop - I don't think you need to do both - in fact, I'm fairly sure when I've messed around with doing this in the past that it caused display problems...

Edit: Also - it looks like each interrupt you write the pointers to the sprite data into the copper list. Is this needed? If your sprites are animated then most likely yes but if not and you just want to move the sprites you shouldn't need to rewrite the sprite pointers into the copper list each frame. Obviously this won't cause any harm though...

[Asman]

Originally Posted by pmc

Asman - I only quickly scanned the souce code but didn't run the .exe's

thank you.

You have a vblank interrupt to keep things sync'd with the display but you are also waiting for vb in your main loop - I don't think you need to do both - in fact, I'm fairly sure when I've messed around with doing this in the past that it caused display problems...

Yes I don't need to do both ( vertb + wait for vb in main loop ). But in other hand I do nothing special in main loop ( only wait for lmb ).

Edit: Also - it looks like each interrupt you write the pointers to the sprite data into the copper list. Is this needed? If your sprites are animated then most likely yes but if not and you just want to move the sprites you shouldn't need to rewrite the sprite pointers into the copper list each frame. Obviously this won't cause any harm though...

Yes it's necessary to write the pointers to the sprite data into the copper list( animation ). As you know I'm working on psycheual and there I found that
problem. I just simplify to minimum the problem.

cheers.

[pmc]

Originally Posted by Asmna

Yes it's necessary to write the pointers to the sprite data into the copper list( animation ). As you know I'm working on psycheual and there I found that
problem. I just simplify to minimum the problem.

Ah, OK - animation. Yes, you will still need to write those pointers then.

Originally Posted by Asman

Yes I don't need to do both ( vertb + wait for vb in main loop ). But in other hand I do nothing special in main loop ( only wait for lmb ).

Have you tried running with no main loop wait vb...?

Anyways, I'll shut up now - I don't think I've been too much help to you. No surprise really - you know what you're doing better than I do!

[Toni Wilen]

Working case runs sprite_on early enough, before copper has processed sprite pointer update moves, bad case updates them too late -> previous frame's sprite data is shown on screen (which is always sprite_off sprite data because sprite_off always runs early enough)

[Asman]

@Toni Wilen - now its so obvious. many thanks.