Page 11 of 20
Re: Tänzer, a "ninja" game (Dev Diary thread)
Posted: Fri Jun 15, 2018 4:26 pm
by mix256
This is a part of the log of when it fails (took a while for me to get the issue in the emulator). I have other runs where everything is ok even when "VRAM_alloc(256) fail" (yes, I know, it's a big explosion
) is made. But this time an sprite allocation failed and returned NULL.
Code: Select all
Message : VRAM_free(1047) --> remaining = 515
Message : SPR_allocateSprite(): success - allocating sprite at pos 118
Message : VDP_allocateSprites(16) success: 29 - remaining = 43
Message : VRAM_alloc(256) failed: cannot find a big enough VRAM tile block (largest free block = 249 - free = 515)
Message : VDP_releaseSprites(29, 16) --> remaining = 59
Message : SPR_releaseSprite: success - released sprite at pos 118
Message : sprite == null ############################################ SPR_addSpriteX
Message : VRAM_alloc(9) success: 956 - remaining = 571
Message : VRAM_alloc(30) success: 965 - remaining = 541
Message : VRAM_alloc(24) success: 995 - remaining = 517
Message : VRAM_alloc(1) success: 1019 - remaining = 516
Message : VRAM_alloc(1) success: 1020 - remaining = 515
Message : VRAM_alloc(256) success: 1021 - remaining = 259
Message : SPR_allocateSprite(): success - allocating sprite at pos 118
Message : VDP_allocateSprites(16) success: 45 - remaining = 43
Message : VRAM_alloc(256) success: 1277 - remaining = 3
Message : DMA_queueDma(..) warning: transfer size is above 7500 bytes.
Message : DMA_queueDma(..) warning: transfer size is above 7500 bytes.
Message : DMA_queueDma(..) warning: transfer size is above 7500 bytes.
Message : DMA_queueDma(..) warning: transfer size is above 7500 bytes.
Message : SPR_releaseSprite: success - released sprite at pos 110
Message : VDP_releaseSprites(21, 4) --> remaining = 47
Message : VRAM_free(965) --> remaining = 33
This is the code that handles the sprite add.
Code: Select all
Sprite* SPR_addSpriteX(const SpriteDefinition *spriteDef, s16 x, s16 y, u16 attribut){
Sprite* sprite = SPR_addSprite(spriteDef, x, y, attribut);
if(!sprite) {
KLog("sprite == null ############################################ SPR_addSpriteX");
VDP_setPaletteColor(0, OUT_OF_SPR_COLOR);
SPR_defragVRAM();
sprite = SPR_addSprite(spriteDef, x, y, attribut);
}
return sprite;
}
Any suggestions?
Re: Tänzer, a "ninja" game (Dev Diary thread)
Posted: Sat Jun 16, 2018 9:48 am
by Stef
Oh got it ! I can see that SPR_defragVram() is allocating the last sprite which couldn't be allocated ! Let me fix that :p
Re: Tänzer, a "ninja" game (Dev Diary thread)
Posted: Sat Jun 16, 2018 10:20 am
by Stef
Ok, i just pushed a new spr_eng.c file on github repository, can you test with it to see if it fix these issues ? Thanks
(and yeah, 256 tiles is *a lot*, basically it's more that what you can send to VDP in a single VBlank !)
Re: Tänzer, a "ninja" game (Dev Diary thread)
Posted: Sat Jun 16, 2018 1:48 pm
by mix256
Stef wrote: ↑Sat Jun 16, 2018 10:20 am
Ok, i just pushed a new spr_eng.c file on github repository, can you test with it to see if it fix these issues ? Thanks
(and yeah, 256 tiles is *a lot*, basically it's more that what you can send to VDP in a single VBlank !)
It works! It manages to recover now. I get the yellow border but everything continues as it should. Super thanks!
Yeah, this mostly happened when the level-boss explosions started so it's not like I have animated 256 tile objects that often.
Again, super thanks Stef!
Re: Tänzer, a "ninja" game (Dev Diary thread)
Posted: Sat Jun 16, 2018 5:41 pm
by Stef
Glad to hear it fixed your issue
It's good to have feedback from real user / game developer (as i don't really do it myself
) so i can fix that kind of bug not always easy to track
Re: Tänzer, a "ninja" game (Dev Diary thread)
Posted: Sat Jun 16, 2018 7:41 pm
by Chilly Willy
I try to help track down issues and add support where I can, but I still haven't gotten my sega set back up after the move. I have located the book it's in.
Re: Tänzer, a "ninja" game (Dev Diary thread)
Posted: Sun Jun 17, 2018 7:27 am
by mix256
Stef wrote: ↑Sat Jun 16, 2018 5:41 pm
Glad to hear it fixed your issue
It's good to have feedback from real user / game developer (as i don't really do it myself
) so i can fix that kind of bug not always easy to track
Your support makes me want to find issues, as well.
I have one more, related to sound that I've been meaning to ask about. Sometimes when stopping the music, XGM_stopPlay(), the sound goes crazy (like it's playing the music REALLY fast) for about a second before stopping. Heard anything like that before?
Chilly Willy wrote: ↑Sat Jun 16, 2018 7:41 pm
I try to help track down issues and add support where I can, but I still haven't gotten my sega set back up after the move. I have located the book it's in.
You've moved to something bigger? In that case I'm envious.
I'm looking for a small place to house my pinball machine (and upcoming arcade/pinball machines) here but it's really hard finding something. Will need that place when Tänzer gets into shipping mode as well so I better hurry up finding it.
I got a Fei Hao HD Retro Game in the mail this friday. I think it's a freakin' awesome machine.
The mini that sega is about to endorse should have been made by them.
In relation to that, it's running 60hz output so I'm hoping to use it for testing slowdowns on NTSC. But it kind of hit me that the machine internals (cpu/dma) could be running faster, couldn't it? So a slowdown test might not be accurate, right?
Thinking of making a small test-app for this, or what do you guys think on the matter?
Re: Tänzer, a "ninja" game (Dev Diary thread)
Posted: Sun Jun 17, 2018 3:54 pm
by Chilly Willy
Actually moved to someplace smaller. We had two houses on almost 4 acres that was just too big for me and my brothers. So we moved across the US to be closer to (remaining) family and got a much smaller place. However, the move also gave me an ulcer. So I've spent the last four months feeling like I was about to die (it's ridiculous how bad ulcers can make your entire body feel), and I'm only just recently feeling well enough to start actually unpacking.
Re: Tänzer, a "ninja" game (Dev Diary thread)
Posted: Sun Jun 17, 2018 5:45 pm
by mix256
Chilly Willy wrote: ↑Sun Jun 17, 2018 3:54 pm
However, the move also gave me an ulcer.
Man, I'm glad you're getting better!
Re: Tänzer, a "ninja" game (Dev Diary thread)
Posted: Sun Jun 17, 2018 8:21 pm
by Stef
mix256 wrote: ↑Sun Jun 17, 2018 7:27 am
Your support makes me want to find issues, as well.
I have one more, related to sound that I've been meaning to ask about. Sometimes when stopping the music, XGM_stopPlay(), the sound goes crazy (like it's playing the music REALLY fast) for about a second before stopping. Heard anything like that before?
No i never heard about that one ^^ really weird indeed. I though the XGM player was a use case strong enough for the XGM driver. It looks like i was wrong
does it happen a lot ? anything specific when this situation arrive ?
@Chilly> Hope you will recover and get comfortably installed soon =)
Re: Tänzer, a "ninja" game (Dev Diary thread)
Posted: Mon Jun 18, 2018 12:40 pm
by Chilly Willy
Thanks, everyone. I'm feeling well enough that I'm programming again (I help out on hyper3DGE, among other projects), and I'm working on getting my Genny set up as well. Still need to locate my Dreamcast... too many damn boxes!
Just updated to Xubuntu 18.04, so at least that's done for another two years. I'll rebuild my toolchains through the week, then make sure things like SGDK are up to date in my projects drawer.
Anywho, back on topic - I noticed from a kickstarter notice that soundtrack CDs would be available. Backing this project looks cooler all the time!
Re: Tänzer, a "ninja" game (Dev Diary thread)
Posted: Tue Jun 19, 2018 4:02 pm
by mix256
Chilly Willy wrote: ↑Mon Jun 18, 2018 12:40 pm
I noticed from a kickstarter notice that soundtrack CDs would be available.
Yes, Johan wanted to do a CD and producing those was much cheaper then I thought.
Stef wrote: ↑Sun Jun 17, 2018 8:21 pm
...does it happen a lot ? anything specific when this situation arrive ?
I've been trying to figure out when it happens, but it seems really random.
Are there any rules to when you can stop it? During vblank or the like? I've been trying all sorts of things like that but it still happens.
It happens at least once per (longer) session I have with the game.
Re: Tänzer, a "ninja" game (Dev Diary thread)
Posted: Tue Jun 19, 2018 9:08 pm
by Stef
At least in my case i often do it in the vint callback but that should not really make any difference. I think that sometime you fall in some race condition which make that weird behavior to happen. You said that when it happen, the music don't stop immediately and play very fast for a short amount of time right ? do it happen only on stop operation ?
Re: Tänzer, a "ninja" game (Dev Diary thread)
Posted: Wed Jun 20, 2018 4:03 am
by mix256
Stef wrote: ↑Tue Jun 19, 2018 9:08 pm
do it happen only on stop operation ?
Yes.
Been playing for a few hours now and it hasn't happened at all during this time, just because I was trying to get it probably...
Or it has magically gone away.
Edit:
Unrelated, but I got an address error now.
Code: Select all
0000869c <sortSprite.lto_priv.139>:
869c: 48e7 0038 moveml %a2-%a4,%sp@-
86a0: 226f 0010 moveal %sp@(16),%a1
86a4: 2469 002c moveal %a1@(44),%a2
86a8: 2669 0030 moveal %a1@(48),%a3
86ac: 3229 001c movew %a1@(28),%d1
86b0: b6fc 0000 cmpaw #0,%a3
86b4: 677e beqs 8734 <sortSprite.lto_priv.139+0x98>
86b6: b26b 001c cmpw %a3@(28),%d1
86ba: 6f78 bles 8734 <sortSprite.lto_priv.139+0x98>
86bc: 204b moveal %a3,%a0
86be: 2068 0030 moveal %a0@(48),%a0
86c2: b0fc 0000 cmpaw #0,%a0
86c6: 6700 00de beqw 87a6 <sortSprite.lto_priv.139+0x10a>
86ca: b268 001c cmpw %a0@(28),%d1
86ce: 6eee bgts 86be <sortSprite.lto_priv.139+0x22>
86d0: b1cb cmpal %a3,%a0
86d2: 6760 beqs 8734 <sortSprite.lto_priv.139+0x98>
86d4: 2068 002c moveal %a0@(44),%a0
86d8: b5c8 cmpal %a0,%a2
86da: 6750 beqs 872c <sortSprite.lto_priv.139+0x90>
86dc: b4fc 0000 cmpaw #0,%a2
86e0: 6700 00ce beqw 87b0 <sortSprite.lto_priv.139+0x114>
86e4: 254b 0030 movel %a3,%a2@(48)
86e8: 274a 002c movel %a2,%a3@(44)
86ec: 286a 0024 moveal %a2@(36),%a4
86f0: 196b 0021 0003 moveb %a3@(33),%a4@(3)
86f6: b0fc 0000 cmpaw #0,%a0
86fa: 6774 beqs 8770 <sortSprite.lto_priv.139+0xd4>
86fc: 2668 0030 moveal %a0@(48),%a3
8700: 234b 0030 movel %a3,%a1@(48)
8704: 2348 002c movel %a0,%a1@(44)
8708: b6fc 0000 cmpaw #0,%a3
870c: 6700 00bc beqw 87ca <sortSprite.lto_priv.139+0x12e>
8710: 2749 002c movel %a1,%a3@(44)
8714: 2149 0030 movel %a1,%a0@(48)
8718: 2068 0024 moveal %a0@(36),%a0
871c: 2669 0024 moveal %a1@(36),%a3
8720: 1768 0003 0003 moveb %a0@(3),%a3@(3)
8726: 1169 0021 0003 moveb %a1@(33),%a0@(3)
872c: 200a movel %a2,%d0
872e: 4cdf 1c00 moveml %sp@+,%a2-%a4
8732: 4e75 rts
8734: b4fc 0000 cmpaw #0,%a2
8738: 67f2 beqs 872c <sortSprite.lto_priv.139+0x90>
873a: 204a moveal %a2,%a0
873c: b26a 001c cmpw %a2@(28),%d1
8740: 6cea bges 872c <sortSprite.lto_priv.139+0x90>
8742: 2068 002c moveal %a0@(44),%a0
8746: b0fc 0000 cmpaw #0,%a0
874a: 670a beqs 8756 <sortSprite.lto_priv.139+0xba>
>> 874c: b268 001c cmpw %a0@(28),%d1
8750: 6df0 blts 8742 <sortSprite.lto_priv.139+0xa6>
8752: b1ca cmpal %a2,%a0
At 874c, a0 is odd. During the sorting of sprites, it seems. Any clue to why with the above code?
Re: Tänzer, a "ninja" game (Dev Diary thread)
Posted: Wed Jun 20, 2018 10:15 am
by Stef
Ok, the bug seems to come from an incorrect 'prev' field in one of the Sprite structure from the sort routine :
Code: Select all
// find position forward first
s = next;
while(s && (s->depth < sdepth)) s = s->next;
...
else
{
// try to find position backward then
s = prev;
while(s && (s->depth > sdepth)) s = s->prev;
}
I'm investigating and trying to sort that out.
Are you using SPR_xx method just in the main loop (never from VInt call back) ?