Hardware Sprite Glitch

Old_Bob · 05 April 2018, 14:39

I've noticed an odd bit of weirdness with one of the sprites in my Bomb Jack game...

There are two halves, more or less, of different sets of sprite data visible, as well as some rogue pixels. Strangely, it only occurs at a certain, narrow band of scanlines in the frame and displays correctly above and below. The problem also seems to be absent when emulating AGA.

Looking in the debugger, the sprite pointer registers appear to be correct and the data looks right in Chip RAM. I can't test it on real hardware so I don't know if it's a problem with my program or, possibly, a bug in WinUAE?

B

Toni Wilen · 05 April 2018, 15:50

If it only happens in OCS: most likely Agnus bug where bitplane DMA also eats second word of previous sprite. (http://eab.abime.net/showpost.php?p=1196166&postcount=4)

Old_Bob · 05 April 2018, 17:53

Thanks, dude.

After some testing using the quickstart configs, it's both OCS and ECS that exhibit the behaviour. It seems to manifest itself slightly differently, though, when emulating a 500, 500+ or 600. The A3000 quickstart option doesn't seem to be working for me here, using 3.6.1.

All the other hardware sprites on screen are fine. Only the B coin, which uses sprites 4 and 5 in attached mode is affected.

B

Toni Wilen · 05 April 2018, 19:32

Include statefile that shows the problem, preferably something that shows the glitch longer than few frames

Old_Bob · 05 April 2018, 23:53

No need, dude.

It turns out that the routine that updates that sprite was occasionally being called at just the time the data was getting read during the frame.

Moving a single JSR cured it.

Thanks, again.

B

05 April 2018, 14:39	#1
Old_Bob BiO-sanitation Battalion Join Date: Jun 2017 Location: Scotland Posts: 151	Hardware Sprite Glitch I've noticed an odd bit of weirdness with one of the sprites in my Bomb Jack game... There are two halves, more or less, of different sets of sprite data visible, as well as some rogue pixels. Strangely, it only occurs at a certain, narrow band of scanlines in the frame and displays correctly above and below. The problem also seems to be absent when emulating AGA. Looking in the debugger, the sprite pointer registers appear to be correct and the data looks right in Chip RAM. I can't test it on real hardware so I don't know if it's a problem with my program or, possibly, a bug in WinUAE? B Last edited by Old_Bob; 05 April 2018 at 16:59.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Graphical glitch	SLC	support.WinUAE	7	29 January 2018 23:55
glitch with interlace	meynaf	support.WinUAE	9	04 August 2017 12:01
Using hardware sprite images more than once per lin	jimmy2x2x	Coders. General	5	20 November 2014 11:30
Gfx glitch	bodhi	support.WinUAE	3	07 December 2012 17:47
It Came from the Desert; Glitch graphics	jamespstevenson	support.Games	7	08 April 2010 12:42

05 April 2018, 15:50	#2
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,516	If it only happens in OCS: most likely Agnus bug where bitplane DMA also eats second word of previous sprite. (http://eab.abime.net/showpost.php?p=1196166&postcount=4)

05 April 2018, 17:53	#3
Old_Bob BiO-sanitation Battalion Join Date: Jun 2017 Location: Scotland Posts: 151	Thanks, dude. After some testing using the quickstart configs, it's both OCS and ECS that exhibit the behaviour. It seems to manifest itself slightly differently, though, when emulating a 500, 500+ or 600. The A3000 quickstart option doesn't seem to be working for me here, using 3.6.1. All the other hardware sprites on screen are fine. Only the B coin, which uses sprites 4 and 5 in attached mode is affected. B

05 April 2018, 19:32	#4
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,516	Include statefile that shows the problem, preferably something that shows the glitch longer than few frames

05 April 2018, 23:53	#5
Old_Bob BiO-sanitation Battalion Join Date: Jun 2017 Location: Scotland Posts: 151	No need, dude. It turns out that the routine that updates that sprite was occasionally being called at just the time the data was getting read during the frame. Moving a single JSR cured it. Thanks, again. B

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)