Sprite Problems

[MartinW]

I'm programming in C but I'm hitting the hardware directly so I'll post here...

Are there any "gotchas" related to hardware sprites and different models of Amiga? I have a simple program that sets up a copper list. The copper list defines some bitplanes, colours, screen setup, the usual stuff. I also create a sprite in ChipMem and set the sprite pointers to sprite 0 in the copper list together with the definition for colour 17 (I'm only using 1 colour + transparent).

As far as I know, nothing out of the ordinary at all. But it only works on an emulated A1200 with fast memory. If I try on my real hardware, at best I don't see the sprite, at worst I get some flickering as though I'm changing the sprite pointers outside of VBlank. But any changes are done after a "WaitTOF()". The background displays fine on all tests I've done. The code that runs after WaitTOF amounts to: change the active sprite pointer to point to whichever sprite I want (1 command), update VHPOS and VCTRL (2 commands) and update SPR0PTH / SPR0PTL in the coper list (2 commands), so very, very little going on there.

If I change the emulation to either not have fast memory or be any other model I get similar results to my real hardware. This is all a bit of a mystery since I'm not using fast memory for my sprite.

I can post up some code later or perhaps even share my (currently private) git repository.

Finally, do VSPRITES exist at a hardware level? All the documentation in the manuals seems to be reams and reams of C code. I was only playing with a single hardware sprite to get a feel for how it works!

[a/b]

Hard to tell w/o code or executable.
Hmmm, AGA. Did you set sprite mode bits in $106 (bplcon3), and align sprite data correspondingly?

[ross]

If you set the right FMODE, sprite0 works even with a really big overscan area.

So yes, you need to post up your code...

[MartinW]

Will sort something out tonight.

Could be BPLCON1 though because at the moment I only have BPLCON0_4BPP_LORES. That will be because originally I was just testing the bitplanes and not sprites

I have FMODE set to 0. Don’t recall reading anything about sprite alignment.

[EDIT] And that define is probably not a standard one. Got a feeling it was from an article I was reading so will have to look up the actual value.

[Asman]

@MartinW.
What about Sprite DMA, did you set it ? What about sprite address, is it odd ? Also you should check when you updating sprite pointers, please check this Toni post http://eab.abime.net/showpost.php?p=650741&postcount=15

[MartinW]

@a/b : Sorry, was reading on my phone earlier and I didn't spot that you said BPLCON3, not BPLCON1 (or indeed, BPLCON0! which is what I really meant to say and didn't). I certainly haven't done anything with BPLCON3, but then I'm not specifically targeting AGA.

Whilst I'm only really coding for my own amusement and therefore don't really have any desire to worry about supporting KS1.3 (which I've never used), I don't have anything against any particular model of Amiga. I personally have AGA KS3.1.4 with 2MB Chip and 24MB Fast and also a machine that has ECS+, KS3.1 (+3.9 set patch), 2MB Chip and over 128MB of fast ram.

I'd like it to work on those two machines but point really is that as far as I am aware I'm not using any fast memory so I don't see why it wouldn't work on a machine without such as a basic A600 for example?

I should probably mention that I am using as much vertical overscan as I could get to work (from memory 284 lines?) but I did try disabling the overscan and it didn't magically sort things out. I can of course revisit that.

I will look into some of the things that have been mentioned this evening. In the meantime I've made my repository public:

https://code.guddler.uk/mart/AmiPac

Most of what is of interest is in:
https://code.guddler.uk/mart/AmiPac/...c/src/amipac.c

And:
https://code.guddler.uk/mart/AmiPac/.../inc/display.h

Obviously that's C code, not assembler but it's just manipulating the hardware directly and should be trivial for anyone here to understand.

[meynaf]

So you alter your copperlist after WaitTOF(), right ?
If so, you get a race condition between the cpu and the copper.
When you do your changes, the coplist is already running. It's possible that without fastmem the code runs too slow and fails.

[ross]

 copListPAL[SPR_OFFSET] = ((ULONG)activePac) & 0xffff0000;
 copListPAL[SPR_OFFSET + 2] = ((ULONG)activePac) & 0xffff;

Where is >>16?

And as meynaf suggested a CWAIT at top of your copper list is useful in your case..

[Asman]

	pacSprite[0]->vhpos = (playerY << 8) + playerX;
	pacSprite[0]->vctrl = (playerY + 16) << 8;

Above is also not correct. Please check http://amigadev.elowar.com/read/ADCD.../node00CC.html

[MartinW]

Originally Posted by ross

 copListPAL[SPR_OFFSET] = ((ULONG)activePac) & 0xffff0000;
 copListPAL[SPR_OFFSET + 2] = ((ULONG)activePac) & 0xffff;

Where is >>16?

And as meynaf suggested a CWAIT at top of your copper list is useful in your case..

OK, I don't really understand, I thought the bitwise & was doing the same thing but I've changed it to the following and I now get my sprite regardless of fast memory or not so good call (will test on real hardware shortly):

copListPAL[SPR_OFFSET] = ((ULONG)activePac) >> 16;
copListPAL[SPR_OFFSET + 2] = ((ULONG)activePac);

But I'm seeing the odd bit of corruption suggesting the race condition is indeed happening.

I've added a wait for line 24 - is that what you guys meant? So I (in theory) have enough time to change the sprite reference before DMA accesses it?

I'm not really sure how else I would do this beyond waiting on TOF? Or is this a result of me not using assembler?

Apologies if I'm asking dumb questions but I'm quite pleased with where I've got so far!

[MartinW]

Originally Posted by Asman

Above is also not correct. Please check http://amigadev.elowar.com/read/ADCD.../node00CC.html

Are you referring to the fact that I'm not assigning the vertical position in CTRL correctly? If so, I know, I haven't got to that yet so I know I can only go part way down the screen until I handle bits 1 & 2 properly.

[Asman]

Originally Posted by MartinW

Are you referring to the fact that I'm not assigning the vertical position in CTRL correctly? If so, I know, I haven't got to that yet so I know I can only go part way down the screen until I handle bits 1 & 2 properly.

yeah I referred about that, but If you know, thats ok. I just analyzing source to find out possible bugs

[MartinW]

No worries I hope my code isn't too embarrassing. Been a few years since I worked professionally with C so I'm a bit on the ropey side to put it mildly and have never really worked in ASM. Well, barely anyway.

Happy to report that I see my sprite on all the real hardware that I have access to now. I just need to work out how to make sure I don't write to the sprite control registers when I shouldn't so that I don't get the glitching.

I understand the why, just not the what to do about it and I'm probably in the wrong section of the forum for that

If anyone feels like they want to marvel at a sprite moving across the screen and tell me that it doesn't work for them then feel free...

(and yeah, I know the maze is more rounded than it should be - it's on the fix list)

[ross]

Originally Posted by MartinW

OK, I don't really understand, I thought the bitwise & was doing the same thing but I've changed it to the following and I now get my sprite ...

ahem.. the bitwise AND simply 'extract' some bits from the source longword, certainly it does not move it into the right position (to be written in a word sized variable).

static UWORD __chip copListPAL[]

is defined as an array of UWORD.
You have to divide the ptr in high and low parts and insert in copper list to be CMOVEd to proper registers (SPR0PTH/SPR0PTL), like you did after.

On A1200 worked only by chance, probably because you zeroed the high ptr word and sprite data was placed in some low memory position.

I've added a wait for line 24 - is that what you guys meant? So I (in theory) have enough time to change the sprite reference before DMA accesses it?

Yes, this in theory. But the race condition can be more subtle.
Think about a situation where you update only partially the ptr. Both CPU and Copper cannot do atomic updates on SPRxPTx pointers...

However I don't think that the corruptions that you say you see are due to this, you would have in most cases only a delay of one frame.

[MartinW]

Thanks for the explanation. I'm going to go away and do some quick tests to visualise the shift vs. &. Bitwise maths has never been my strong point, as has maths in general!

I will plough on for now. Ultimately I can't use hardware sprites because they don't give me enough colours. I could compromise, and might for the moment but ideally I need 5 sprites of 3 colours, but 5 different sets of colours which is not possible. Hence the talk of VSPRITES. Or maybe I need to look at bobs. I'm just trying to get my head around things first and see some progress.