Tänzer, a "ninja" game (Dev Diary thread)

Announce (tech) demos or games releases

Moderator: Mask of Destiny

Post Reply
notaz
Very interested
Posts: 193
Joined: Mon Feb 04, 2008 11:58 pm
Location: Lithuania

Re: Unnamed "ninja" game (Dev Diary thread)

Post by notaz » Mon Mar 19, 2018 12:47 pm

If your build process keeps the elf file you can do "addr2line -e yourgame.elf 42c0" to find the line of code, or you can look up the address in the map file. Not sure if SGDK produces those, I use custom makefiles for my stuff.

Miquel
Very interested
Posts: 514
Joined: Sat Jul 30, 2016 12:33 am

Re: Unnamed "ninja" game (Dev Diary thread)

Post by Miquel » Mon Mar 19, 2018 3:30 pm

It can also be a jump (pointer function for example) to an erroneous direction, and then just executing random instructions until one crashes. MAYBE.

Or a variable that gets overwritten by mistake, buffer overrun or whatever.
HELP. Spanish TVs are brain washing people to be hostile to me.

Miquel
Very interested
Posts: 514
Joined: Sat Jul 30, 2016 12:33 am

Re: Unnamed "ninja" game (Dev Diary thread)

Post by Miquel » Mon Mar 19, 2018 4:13 pm

Digging a bit deeper:

instruction: 0x3238
in binary by fields: 00 11 001-000 111-000

move.w (xxx).w, d0.w

where:
- "(xxx).w" it's the source, a memory absolute
- d0.w is the destination

So the instruction that crashes is a constant address like:

*((u16*)1) = 0;

CONCLUSION: Not a variable overwrite, not a regular pointer. Perhaps a function pointer, or perhaps a basic misalignment.
HELP. Spanish TVs are brain washing people to be hostile to me.

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

Re: Unnamed "ninja" game (Dev Diary thread)

Post by mix256 » Mon Mar 19, 2018 7:31 pm

Ey, thanks a lot! Although it was 3228, not 3238. :)

So, it's in SPR_update(), then?

Last screenshot:

Code: Select all

    41ba:	51c9 ffe4      	dbf %d1,41a0 <SPR_update+0x256>
    41be:	0242 ff0c      	andiw #-244,%d2
    41c2:	6000 fece      	braw 4092 <SPR_update+0x148>
    41c6:	206a 000c      	moveal %a2@(12),%a0
    41ca:	3228 0012      	movew %a0@(18),%d1
    41ce:	6600 029c      	bnew 446c <SPR_update+0x522>
    41d2:	426a 0016      	clrw %a2@(22)
First screenshot:

Code: Select all

    4170:	0802 0000      	btst #0,%d2
    4174:	6700 ff18      	beqw 408e <SPR_update+0x144>
    4178:	206a 000c      	moveal %a2@(12),%a0
    417c:	326a 001e      	moveaw %a2@(30),%a1
    4180:	3610           	movew %a0@,%d3
    4182:	2868 0002      	moveal %a0@(2),%a4
 
I've done some (a lot, actually), so the addresses have changed a bit.

Don't think it's sgdk that's making this happen, though. It's probably my handling (fail handling and releasing) of sprites after getting the handle.
Although the first of these screenshots were when just leaving it at the start. And nothing sprite-wise was going on except for the main sprite being on screen with the idle animation.
Well, at least I know in what area to concentrate on now.

Thanks for the help guys!

Miquel
Very interested
Posts: 514
Joined: Sat Jul 30, 2016 12:33 am

Re: Unnamed "ninja" game (Dev Diary thread)

Post by Miquel » Tue Mar 20, 2018 12:13 am

mix256 wrote:
Mon Mar 19, 2018 7:31 pm
Ey, thanks a lot! Although it was 3228, not 3238. :)
0x3228: 00 11 001-000 101-000 -> move.w (displacement, A0), D1
0x3610: 00 11 011-000 010-000 -> move.w (A0), D3

Both crash instructions seem to do similar things and the stack is at the same deep level. Seems to be that whatever is A0 (¿a pointer to a struct?) is completely wrong but only crashes when by chance is even. That's my guess ;)

Edit: checking the asm code just you previously released you need to know from where A2 comes.
HELP. Spanish TVs are brain washing people to be hostile to me.

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

Re: Unnamed "ninja" game (Dev Diary thread)

Post by mix256 » Tue Mar 20, 2018 8:44 am

Miquel wrote:
Tue Mar 20, 2018 12:13 am
Edit: checking the asm code just you previously released you need to know from where A2 comes.
Most likely, I've got a hunch that it's trying to get the frame->time of a sprite.
But since that could have been triggered from anywhere in my sprite handling code (like, any of the SPR_setAnim() calls) tracking down the actual issue will take some work.

Edit:
This is it, I am now certain.

Code: Select all

static u16 updateFrame(Sprite *sprite)
{
#ifdef SPR_PROFIL
    s32 prof = getSubTick();
#endif // SPR_PROFIL

#ifdef SPR_DEBUG
    KLog_U1("  updateFrame: sprite #", getSpriteIndex(sprite));
#endif // SPR_DEBUG

    // init timer for this frame (+1 as we update animation before sending to VDP)
    if ((sprite->timer = sprite->frame->timer))
        sprite->timer++;
The sprite->frame pointer seems to be invalid.
And I'm guessing the problem is with my HUD code.

Good day, today. Sunny outside and progress on the bugs.

If only the artist I've commissioned to do the cover gets in contact with me soon, the day would be perfect. :D

Miquel
Very interested
Posts: 514
Joined: Sat Jul 30, 2016 12:33 am

Re: Unnamed "ninja" game (Dev Diary thread)

Post by Miquel » Tue Mar 20, 2018 1:59 pm

Is that code yours or belongs to SGDK?

Then what is wrong is "Sprite *sprite", the stack parameter... which gets overwritten somehow... estrange that the stack gets mess up...
HELP. Spanish TVs are brain washing people to be hostile to me.

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

Re: Unnamed "ninja" game (Dev Diary thread)

Post by mix256 » Tue Mar 20, 2018 2:15 pm

Miquel wrote:
Tue Mar 20, 2018 1:59 pm
Is that code yours or belongs to SGDK?

Then what is wrong is "Sprite *sprite", the stack parameter... which gets overwritten somehow... estrange that the stack gets mess up...
It's SGDK, and I don't think there's something wrong with the stack. It's the spirte->frame that is messed up. Because of an animation frame not being properly set, somehow/somewhere. Most likely in my HUD code.

In fact, there is no stack involved when calling the updateFrame(), it just seem to branch over there:

Code: Select all

    40ec:    0800 0006      	btst #6,%d0
    40f0:    6600 01f8      	bnew 42ea <SPR_update+0x27c>
    	...
    	...
    42ea:    206a 000c      	moveal %a2@(12),%a0
    42ee:    3228 0012      	movew %a0@(18),%d1
    42f2:    6600 029c      	bnew 4590 <SPR_update+0x522>
That btst #6 is coming from SPR_update():

Code: Select all

            if (status & NEED_FRAME_UPDATE)
                status |= updateFrame(sprite);

Miquel
Very interested
Posts: 514
Joined: Sat Jul 30, 2016 12:33 am

Re: Unnamed "ninja" game (Dev Diary thread)

Post by Miquel » Tue Mar 20, 2018 2:40 pm

mix256 wrote:
Tue Mar 20, 2018 8:44 am

Code: Select all

static u16 updateFrame(Sprite *sprite)
Unless it's inlined by the compiler, all parameters are stored on the stack by gcc. No way around. a7 is the stack pointer but could get copied to another address/pointer register. There is no "bnew" instruction, perhaps is a psedo-code for gcc itself?

But if you are sure that the problem resides on "spirte->frame" it really doesn't matter.
HELP. Spanish TVs are brain washing people to be hostile to me.

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

Re: Unnamed "ninja" game (Dev Diary thread)

Post by mix256 » Tue Mar 20, 2018 2:49 pm

You're pulling my leg, of course BNE exists and for word. :)

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

Re: Unnamed "ninja" game (Dev Diary thread)

Post by Stef » Tue Mar 20, 2018 3:30 pm

There was a bug in the previous SGDK version where timer wasn't correctly reset, so you can end with incorrect animation timing but as far i know i never meet issue with the frame pointer itself. Are you sometime calling setFrame by yourself ?

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

Re: Unnamed "ninja" game (Dev Diary thread)

Post by mix256 » Tue Mar 20, 2018 4:12 pm

Stef wrote:
Tue Mar 20, 2018 3:30 pm
There was a bug in the previous SGDK version where timer wasn't correctly reset, so you can end with incorrect animation timing but as far i know i never meet issue with the frame pointer itself. Are you sometime calling setFrame by yourself ?
No, I don't but doing a SPR_setAnim() with an invlid anim could render this issue, right? I guess, this could create an invalid frame pointer in SPR_setAnim() ?

Code: Select all

sprite->frame = animation->frames[frameInd];

Miquel
Very interested
Posts: 514
Joined: Sat Jul 30, 2016 12:33 am

Re: Unnamed "ninja" game (Dev Diary thread)

Post by Miquel » Tue Mar 20, 2018 4:37 pm

mix256 wrote:
Tue Mar 20, 2018 2:49 pm
You're pulling my leg, of course BNE exists and for word. :)
Yes, "bne" exists! and perhaps new versions of gcc are passing arguments throw d0/d1/a0/a1. My bad.
HELP. Spanish TVs are brain washing people to be hostile to me.

Sik
Very interested
Posts: 939
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: Unnamed "ninja" game (Dev Diary thread)

Post by Sik » Tue Mar 20, 2018 5:12 pm

Note that most compilers will not bother with a call to subroutine when the function would immediately return once the subroutine is done, they'll just jump straight to it since the result will be the same (this is a common optimization when programming in asm, too).
Sik is pronounced as "seek", not as "sick".

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

Re: Unnamed "ninja" game (Dev Diary thread)

Post by Stef » Tue Mar 20, 2018 5:19 pm

mix256 wrote:
Tue Mar 20, 2018 4:12 pm
Stef wrote:
Tue Mar 20, 2018 3:30 pm
There was a bug in the previous SGDK version where timer wasn't correctly reset, so you can end with incorrect animation timing but as far i know i never meet issue with the frame pointer itself. Are you sometime calling setFrame by yourself ?
No, I don't but doing a SPR_setAnim() with an invlid anim could render this issue, right? I guess, this could create an invalid frame pointer in SPR_setAnim() ?

Code: Select all

sprite->frame = animation->frames[frameInd];
For sure it could lead to incorrect frame pointer if you use setAnim (or setFrameAndAnim / setFrame) with incorrect index :p i'm not doing any bounds verification (for performance reason obviously).

Post Reply