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!