Sprite sorting

[mix256]

Played all night yesterday with out any issues.
How should the sound be different?
I think I might hear a difference in the sfx playback, but I'm not sure. I guess that's a good thing?

[Stef]

Played on real hardware without any issue using the flag ? Did you used the release build (and not the debug one) ?
Did you try to just remove the flag and recompile to see if that really makes the difference here (bug without the flag, no bug with the flag) ?
If that is the case then it means that you probably got some RAM corruptions (68K side) when Z80 is trying to access 68K bus during a DMA... I'm really surprised that it happens, normally you can eventually got Z80 read corruption but 68K RAM corruption seems a bit extreme.
I still waiting for your confirmation that is source of the problem before continuing investigation

[mix256]

It was a release build with the flag on.
I will play some more tonight, using this build, to make sure that the issue doesn't arise. Then I will turn the flag off again and do the same test.
Thanks!

[Stef]

Thanks to you for taking the time to test !

[mix256]

Played for a few hours yesterday without any issues. Also, the game has an attract mode that plays parts of a few stages mixed with showing the title screen. So after I played yesterday I left the machine running all night. No issues has appeared in the morning.

I've now set the halt flag to 0 and I have the attract mode playing at home. Will see what has happened when I get back home again.

[mix256]

Was just about to write that there didn't seem to be an issue with the flag off either, when this happened.


Lasted for well over 10 hours, though.

What I've done as well is to remove most of the compression on the sprites (using NONE in rescomp files). Maybe that is why it lasted quite long now?

[Stef]

Sprite compression should only make processing a bit more intensive (and do probably display more slowdowns) but except that... more than 10 hours is a long run before showing the problem Normally the XGM driver try to avoid to access 68K BUS during VBlank, and so during DMA.. but at some point that can happen anyway (because DMA stay longer than expected or just because the XGM driver itself is under load). In fact the current XGM driver implementation cannot guarantee it will never use the 68K BUS during VBlank so that definitely happen from time to time. And on 68K side, it's also very difficult to guarantee that DMA will stay only in VBlank period, if you have many GFX to upload on a specific frame then your DMA may end in active display, or you have to limit DMA capacity (DMA queue from SGDK support this feature but the sprite engine does not for now so it would display garbage when DMA queue is full :p)
You said you couldn't hear much difference in sound with the flag was enabled, You have to know that only the PCM playback is affected by it, it's also very depend from the DMA load (long Z80 halt because of long DMA transfer will affect it more obviously). If the sound difference is really minimal then i guess you can go with enabling this flag for safety (if that really does a difference of course).

[mix256]

Thanks!
I'll turn the flag on again and see. Maybe I was just lucky to not get the issue with the flag on? Will let you know of the outcome.

[Stef]

Yeah, if you had to wait more than 10 hours to get the crash it means it arrives very rarely. Maybe it happens less when you left the "demo" mode of your game ?

[mix256]

Yes, it's probably different behaviour between the demo and playing myself.
What I do is that I play through the game (~50 minutes) then I leave it on running the attract sequence.

I've now turned on he flag, and had the attract sequence running the whole night now without any issue. I played it through this morning and has left it running again until I get back back home. Going to play it through again when I get back home and if it hasn't crashed then (~24 hours running) I'm going to stop hunting this issue down.

[Stef]

If the problem doesn't show with the flag turned ON, then it definitely mean it has something to do with Z80 accessing 68K bus during DMA operation.
If the impact on turning this flag ON isn't that hurting, than that is the easy solution

[mix256]

It's still running without issues, closing in on 24 hours now and I've been playing about 3 hours of them myself.

Haven't look at what the flag does, but would it be possible to have this like a setting programmatically at run-time?
I already have a "performance" options so it could be presented there for the user, I thought?

[mix256]

48 hours in soon, where I've played about 5 of them myself and still no issues.
I think we can safely say that the flag is fixing the issue.

[Stef]

Ok definitely. Right now there is no way to enable it on run-time, that's definitely something i could add though (this will have probably a minor penalty on performance though). Still if you don't heard difference in sound, then i think you should keep it enable to preserve a good game experience for users (bugs, even when they are rare, are definitely something you want to avoid..)