English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 27 June 2019, 15:18   #1
MartinW
Registered User

 
Join Date: Mar 2017
Location: Minehead / UK
Posts: 527
Question Sprite Problems

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!
MartinW is offline  
Old 27 June 2019, 16:22   #2
a/b
Registered User

 
Join Date: Jun 2016
Location: europe
Posts: 124
Hard to tell w/o code or executable.
Hmmm, AGA. Did you set sprite mode bits in $106 (bplcon3), and align sprite data correspondingly?
a/b is offline  
Old 27 June 2019, 16:25   #3
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 2,163
If you set the right FMODE, sprite0 works even with a really big overscan area.

So yes, you need to post up your code...
ross is online now  
Old 27 June 2019, 16:29   #4
MartinW
Registered User

 
Join Date: Mar 2017
Location: Minehead / UK
Posts: 527
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.
MartinW is offline  
Old 27 June 2019, 16:54   #5
Asman
68k

Asman's Avatar
 
Join Date: Sep 2005
Location: Somewhere
Posts: 695
@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
Asman is offline  
Old 27 June 2019, 18:58   #6
MartinW
Registered User

 
Join Date: Mar 2017
Location: Minehead / UK
Posts: 527
@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.
MartinW is offline  
Old 27 June 2019, 19:43   #7
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,595
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.
meynaf is offline  
Old 27 June 2019, 20:31   #8
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 2,163
Code:
 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..
ross is online now  
Old 27 June 2019, 21:56   #9
Asman
68k

Asman's Avatar
 
Join Date: Sep 2005
Location: Somewhere
Posts: 695
Code:
	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
Asman is offline  
Old 27 June 2019, 21:57   #10
MartinW
Registered User

 
Join Date: Mar 2017
Location: Minehead / UK
Posts: 527
Quote:
Originally Posted by ross View Post
Code:
 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):

Code:
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 is offline  
Old 27 June 2019, 22:01   #11
MartinW
Registered User

 
Join Date: Mar 2017
Location: Minehead / UK
Posts: 527
Quote:
Originally Posted by Asman View Post
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.
MartinW is offline  
Old 27 June 2019, 22:13   #12
Asman
68k

Asman's Avatar
 
Join Date: Sep 2005
Location: Somewhere
Posts: 695
Quote:
Originally Posted by MartinW View Post
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
Asman is offline  
Old 27 June 2019, 22:37   #13
MartinW
Registered User

 
Join Date: Mar 2017
Location: Minehead / UK
Posts: 527
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)
Attached Files
File Type: lha amipac.lha (2.7 KB, 14 views)
MartinW is offline  
Old 27 June 2019, 22:42   #14
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 2,163
Quote:
Originally Posted by MartinW View Post
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).
Code:
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.

Quote:
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.
ross is online now  
Old 27 June 2019, 22:53   #15
MartinW
Registered User

 
Join Date: Mar 2017
Location: Minehead / UK
Posts: 527
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.
MartinW is offline  
 


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

Similar Threads
Thread Thread Starter Forum Replies Last Post
Sprite issues attle Coders. C/C++ 7 23 February 2016 15:26
Resetting sprite problems Knocker Coders. Asm / Hardware 11 29 January 2016 01:30
Sprite collision help Shatterhand Coders. Blitz Basic 8 13 December 2015 00:02
Mani Pulite sprite problems (A500 mode) andreas support.WinUAE 17 22 January 2015 15:41
sprite overscan jamiejamie Coders. General 11 02 February 2011 17:59

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 13:26.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.08465 seconds with 16 queries