Sprite sorting

SGDK only sub forum

Moderator: Stef

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Re: Sprite sorting

Post by Stef » Thu Jan 03, 2019 10:33 am

In fact it was easy to add support for it, can you try to update the spr_eng.h / spr_eng.c files directly from github ? i added support to add sprite in first position in the list (just use the SPR_FLAG_INSERT_HEAD flag for that), i didn't tested it but it should be ok (few changes needed).

mix256
Very interested
Posts: 189
Joined: Thu Jan 25, 2018 2:08 pm
Location: Sweden
Contact:

Re: Sprite sorting

Post by mix256 » Thu Jan 03, 2019 11:19 am

Awesome! Super thanks!
Longing home to test it out. :)

Edit:
You have this still there, though. Might clash if one wants to do setDepth, right?

Code: Select all

// sprite is always added at the end of list so we use MAX_DEPTH here
sprite->depth = SPR_MAX_DEPTH

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Re: Sprite sorting

Post by Stef » Thu Jan 03, 2019 2:20 pm

oh thanks ! better to use MIN_DEPTH for head of list element then but as i don't sort it initially (assuming it's already in place) you can change its depth immediately without needed resorting ;)

Edit: fixed.

mix256
Very interested
Posts: 189
Joined: Thu Jan 25, 2018 2:08 pm
Location: Sweden
Contact:

Re: Sprite sorting

Post by mix256 » Thu Jan 03, 2019 4:51 pm

I think that something is not working as intended.
If I only add sprites with the head flag it seems like only the last added sprite is visible. I will investigate some more.

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Re: Sprite sorting

Post by Stef » Fri Jan 04, 2019 8:43 am

and if you add the normal way are they displayed correctly ? I will check that, i probably made a stupid mistake :p

Edit: Indeed some other parts of the code (internal links update) assumed inserting sprite in last pos, it should be fixed now (i hope ^^)

mix256
Very interested
Posts: 189
Joined: Thu Jan 25, 2018 2:08 pm
Location: Sweden
Contact:

Re: Sprite sorting

Post by mix256 » Fri Jan 04, 2019 10:07 am

That's brilliant! Will check as soon as I get back home! :)

mix256
Very interested
Posts: 189
Joined: Thu Jan 25, 2018 2:08 pm
Location: Sweden
Contact:

Re: Sprite sorting

Post by mix256 » Sat Jan 05, 2019 11:28 am

I fell asleep when I got home yesterday. Guess I needed it. :)

Seems to work fine, for the most part! Super awesome!
Got it to hang when using setDepth like this:

Code: Select all

SPR_setDepth(beam0, SPR_MIN_DEPTH + 2)
SPR_setDepth(beam1, SPR_MIN_DEPTH + 2)
SPR_setDepth(beam2, SPR_MIN_DEPTH + 2)
SPR_setDepth(beam3, SPR_MIN_DEPTH + 2)
SPR_setDepth(beam4, SPR_MIN_DEPTH + 2)
Since I won't be doing that again, it doesn't really matter for me. :D
But I guess there is something still that's not working as intended. just so you know.

mix256
Very interested
Posts: 189
Joined: Thu Jan 25, 2018 2:08 pm
Location: Sweden
Contact:

Re: Sprite sorting

Post by mix256 » Sat Jan 05, 2019 4:47 pm

Got an address error in spr_update now, related to this you think? :)

Code: Select all

   3292a:	4879 00ff 33c4 	pea ff33c4 <vdpSpriteCacheQueue>
   32930:	42a7           	clrl %sp@-
   32932:	4eb9 0003 0fba 	jsr 30fba <DMA_queueDma.part.2>
   32938:	4fef 0014      	lea %sp@(20),%sp
   3293c:	2479 00ff 5914 	moveal ff5914 <firstSprite>,%a2
   32942:	b4fc 0000      	cmpaw #0,%a2
   32946:	6752           	beqs 3299a <SPR_update+0xac>
   32948:	47f9 0003 0fba 	lea 30fba <DMA_queueDma.part.2>,%a3
   3294e:	4df9 0004 0b1c 	lea 40b1c <lz4w_unpack>,%fp

   32954:	302a 0016      	movew %a2@(22),%d0

   32958:	670a           	beqs 32964 <SPR_update+0x76>
   3295a:	5340           	subqw #1,%d0
   3295c:	6700 011e      	beqw 32a7c <SPR_update+0x18e>
   32960:	3540 0016      	movew %d0,%a2@(22)
   32964:	3012           	movew %a2@,%d0
   32966:	4a00           	tstb %d0
   32968:	6726           	beqs 32990 <SPR_update+0xa2>
   3296a:	0800 0005      	btst #5,%d0
   3296e:	6600 016e      	bnew 32ade <SPR_update+0x1f0>
   32972:	3400           	movew %d0,%d2
   32974:	0802 0004      	btst #4,%d2
   32978:	665a           	bnes 329d4 <SPR_update+0xe6>
   3297a:	302a 0002      	movew %a2@(2),%d0
   3297e:	6600 02be      	bnew 32c3e <SPR_update+0x350>
   32982:	0802 0002      	btst #2,%d2
   32986:	6600 0086      	bnew 32a0e <SPR_update+0x120>
   3298a:	0242 ffcf      	andiw #-49,%d2
   3298e:	3482           	movew %d2,%a2@
   32990:	246a 0030      	moveal %a2@(48),%a2
   32994:	b4fc 0000      	cmpaw #0,%a2
   32998:	66ba           	bnes 32954 <SPR_update+0x66>
Happend at the 32954 row and a2 is FF8103.

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Re: Sprite sorting

Post by Stef » Mon Jan 07, 2019 10:54 am

it looks like the firstSprite pointer is corrupted (point on odd address, that should never happen).
I investigated (and made a minor fix and tweak) but i don't think it will change the problem.
Can you try to get the last spr_eng.c file (and recompile the lib) to see if it helps (for both problems) ? Thanks :)
Also are you always using SPR_xxx methods from the main loop ? (don't mixing SPR_xx call from vint and main loop), just to be sure ^^

mix256
Very interested
Posts: 189
Joined: Thu Jan 25, 2018 2:08 pm
Location: Sweden
Contact:

Re: Sprite sorting

Post by mix256 » Mon Jan 07, 2019 12:01 pm

Thanks! Will update as soon as possible.
I myself haven't set up anything to run on vint. But I'm not disabling vint anytime either. Could this be a problem?

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Re: Sprite sorting

Post by Stef » Mon Jan 07, 2019 1:05 pm

No, that shouldn't be a problem, normally the sprite engine is safe and protect itself where it needs to be.
I will continue to investigate, if the problem never happened before then it means the last addition bring a regression.

mix256
Very interested
Posts: 189
Joined: Thu Jan 25, 2018 2:08 pm
Location: Sweden
Contact:

Re: Sprite sorting

Post by mix256 » Mon Jan 07, 2019 7:47 pm

Super thanks! I've just updated let's see if it happens again.

mix256
Very interested
Posts: 189
Joined: Thu Jan 25, 2018 2:08 pm
Location: Sweden
Contact:

Re: Sprite sorting

Post by mix256 » Sun Jan 13, 2019 3:35 pm

Got an address error in allocatesprite now, at 32e66. A1 is 00FF83FF. :)
It looks like it "result->prev = NULL" that gives the address error here?

Code: Select all

00032e28 <allocateSprite.lto_priv.199>:
   32e28:	2f02           	movel %d2,%sp@-
   32e2a:	322f 000a      	movew %sp@(10),%d1
   32e2e:	2039 00ff 591e 	movel ff591e <free.lto_priv.243>,%d0
   32e34:	b0b9 00ff 591a 	cmpl ff591a <allocStack.lto_priv.247>,%d0
   32e3a:	6700 0094      	beqw 32ed0 <allocateSprite.lto_priv.199+0xa8>
   32e3e:	2400           	movel %d0,%d2
   32e40:	5982           	subql #4,%d2
   32e42:	23c2 00ff 591e 	movel %d2,ff591e <free.lto_priv.243>
   32e48:	2040           	moveal %d0,%a0
   32e4a:	2028 fffc      	movel %a0@(-4),%d0
   32e4e:	4a41           	tstw %d1
   32e50:	6732           	beqs 32e84 <allocateSprite.lto_priv.199+0x5c>
   32e52:	2079 00ff 5916 	moveal ff5916 <firstSprite>,%a0
   32e58:	b0fc 0000      	cmpaw #0,%a0
   32e5c:	6704           	beqs 32e62 <allocateSprite.lto_priv.199+0x3a>
   32e5e:	2140 002c      	movel %d0,%a0@(44)
   32e62:	2240           	moveal %d0,%a1
   
   32e64:	42a9 002c      	clrl %a1@(44)
   
   32e68:	2348 0030      	movel %a0,%a1@(48)
   32e6c:	4ab9 00ff 5912 	tstl ff5912 <lastSprite>
Cheers!

EDIT:
Got am address error in spr_releasesprite now as well at 32d68, a2 is 00000005. But this is just a corrupt sprite pointer being sent into the function, right?

Code: Select all

00032d60 <SPR_releaseSprite>:
   32d60:	48e7 3820      	moveml %d2-%d4/%a2,%sp@-
   32d64:	246f 0014      	moveal %sp@(20),%a2
   
   32d68:	4a52           	tstw %a2@
   
   32d6a:	6d06           	blts 32d72 <SPR_releaseSprite+0x12>

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Re: Sprite sorting

Post by Stef » Mon Jan 14, 2019 4:35 pm

Your last bug about the releaseSprite make me think that you are probably sometime having some corrupted Sprite pointers (leading to all that weird errors). Do you check that your sprite are correctly allocated after a SPR_addSprite(..) call (you need to check for NULL return) ?

mix256
Very interested
Posts: 189
Joined: Thu Jan 25, 2018 2:08 pm
Location: Sweden
Contact:

Re: Sprite sorting

Post by mix256 » Mon Jan 14, 2019 6:04 pm

All of the SPR_xxx functions that I use are wrapped with null checks. Both for return values and as parameters.
Since A2 in the last error is 0x05 it either means I have gotten 0x05 back from SPR_addSprite or that it has happened in some other way afterwards. Me thinks. :)

Post Reply