Stars scroller with sprites flickering issue

[jotd]

I'm doing a sprite scrolling background


Sprite 7 is enabled once in a line or not (random) with a varying color. I also copy the copperlist instructions to create a scroll.


It works not so bad, but it tends to flicker. Is that because it's too slow copying the stuff and conflicting with beam?


Zoned archive (stars_scroller.zip) with exe + source. The routine is "scroll_stars", called once each vblank interrupt.

[paraj]

I don't know what's wrong, but I don't think it's because you scroll routine is too slow.
Exectuable doesn't work with A500 quickstart, but issue is seen with A1200 QS as well and there I can see that scroll_sprites starts completes in due time (putting breakpoint on the call and stepping over with "z" it goes from V=304 to V=9).

Copying copperlist from glitchy frame and displaying it staticly seems to work, so probably some concurrency issue, but I don't know where.

The order of your writes to the sprite registers seem suspicious (don't seem to follow the recommendations from http://amigadev.elowar.com/read/ADCD.../node00C7.html), but maybe that's for a reason.

Maybe someone else can spot the issue, otherwise delete as much of the other unnecessary code and I'll have another look

[jotd]

thanks, that's probably the problem. I can't test right now but your help is (as always) much appreciated!

[DanScott]

One of the first things I did when I was learning to code in 1990... updating sprite positions, racing the beam, but from the vblank, you should have updated all before the first sprite is even fetched

[Photon]

IDK if it's what Dan means but you can certainly race the Copper as you can race the beam. (As in, you can start writing sprite positions into the currently displayed Copper when Vblank hits. Likely the CPU will be faster, so when the Copper word to change the position is reached, the CPU will have written more than 1 such position to the Copper = race won.)

A normal starfield is just a static sprite as high as the screen and a Copper with two (or one, it happened... :P ) SPRxPOS words per line.

Without checking the source I can only offer 1) no CWAIT before initializing relevant other registers in Copper list, or 2) writing sprite DMA bit while sprite DMA or bitplane DMA is on. I don't see much else that could cause flicker.

[jotd]

what do you mean by "no cwait" ?

[Photon]

I'm sorry, it was very late and I wanted to offer general advice and go to bed.

No CWAIT = No Copperwait before writing registers that affect sprite or bitplane DMA. If these are poked into the Copper list in the VBI, they may be written just as the Copper reads them, so that it will be hit-or-miss which happens first. Also applies to switching the entire Copper. The fix is easy, put a wait for VPOS $1a or higher before the first such CMOVE (Copper move) in all Copper lists you create.

Though a good practice, this is not the case here, because the glitches happen about 60% down the screen. And dumping the entire project doesn't help us find it. I'll be honest and say that I don't fancy spending the time pinpointing it. I can't assemble it, and the Copper is declared with non-standard macros.

See if you can do the same. One easy way is to put BG color changes before and after calls in the frame loop. One will likely coincide with the glitch position, and probably it's writing into the Copper rows being displayed by the Copper at the same time. If it's double-buffered, typically this means you got the buffering phase wrong (not writing to a back buffer).

Once you find the code you suspect, if you can't find the error post the snippet here. A screenshot with a mark where the glitch is would save lots of time and give you more potential answers/idea, I think

Now food, hope you get it sorted.

[jotd]

I understand. Now I have added "pause" in my game, and when paused, the copper trashes the second half of the stars.

I'm suspecting a control word issue.


it's 100% for half of the screen, but second half is sometimes glitchy.

The control word/pos I'm using takes X and Y into account, and I noticed that Y doesn't matter. Or does it?

YES it does. It worked somehow with my previous attempt but I have to specify Y=256 else control word is wrong, and fun fact sometimes it work sometimes it doesn't...

	add.w	#6*8,d0	| add 48 offset because of screen centering
	move.w	#256,d1	| max Y, else glitchy stars
	bsr		store_sprite_pos_16  ; X,Y => sprite control / pos longword

Mystery solved, thanks

But now DMA sprite is conflicting with that system. If I turn off sprite DMA, I get perfect star scroll, but when using sprites "classically" I get the glitch...

Can't I use "classical" dma controlled sprites with copper-controlled sprites like this? Of course this multiplexed sprite in the copper is using sprite 7 and other sprites are 0,1,2,3,4,5 only.

At the start of my copperlist, I'm setting a blank sprite in all sprites. As long as I don't display any of the sprites using a valid control word, the star scroller is OK.

but as soon as I enable, say sprite 0 by writing a valid position/control words, then the stars begin to glitch (WinUAE, didn't test on real hardware but I'm pretty confident that it will be the same on real hardware, I still have to test on it)

[jotd]

finally fixed it by setting a blank sprite at startup for all sprites. Not a piece of cake but working!

this is great!

[jotd]

Well, actually it works unless DMA sprite is on...

If sprite DMA is off, it works perfect, but if it's on then it fails. DMA seems to update SPRDAT even if I set it to a blank sprite, which is expected, as I'm constantly changing control word/pos to set my stars, maybe it's not possible to do that that way. Here's one line where sprite is set

 00000728: 0178 1c76            ;  SPR7POS := 0x1c76
 0000072c: 017a 2407            ;  SPR7CTL := 0x2407
 00000730: 017e 0000            ;  SPR7DATB := 0x0000
 00000734: 017c 8000            ;  SPR7DATA := 0x8000
 00000738: 2501 fffe            ;  Wait for vpos >= 0x25 and hpos >= 0x00
                                ;  VP 25, VE 7f; HP 00, HE fe; BFD 1
 0000073c: 017e 0000            ;  SPR7DATB := 0x0000
 00000740: 017c 0000            ;  SPR7DATA := 0x00001

I found out that sprite 7 (the one which is multiplexed) gets updated by sprite DMA. How can I block that? I could write to sprpt+28 (sprpointer 7) at each line to reset it? I was initializing it with a buffer with a bunch of zeroes at start but it doesn't help.

[paraj]

" but if sprite 0 is displayed, then it fails. " - You mean if sprite DMA is enabled? Not just that sprite 0 is displayed (using non-DMA method), right?

I don't remember all the rules for sprites, but some things to test/make sure:
- Sprite 7 pointer properly initialized in copper list to a null sprite (NOT PT=$0, but something pointing at dc.w $0,$0)
- When writing spr7ctl/pos with copper, set ystart/yheight to 0 (think the sprite should still display, but it won't try to use DMA later on)

[jotd]

YES! thanks (again) paraj. Zero height did it! (and zero Y)

So great to have proper stars! I was desperate.