Starting a fade in/out sometimes crashes on hardware

[Grind]

I had an issue in my project for a while where the game would hang between room transitions (fading). It would only happen on hardware, not emulators (except BlastEm) which reported

Code: Select all

Read from VDP data port while writes are configured, CPU is now frozen. VDP Address: 2, CD: 5

it looks like the problem is that sometimes a vertical interrupt occurs during a call to VDP_getPaletteColors (which is in turn called by VDP_fadeTo). VDP_getPaletteColors should probably disable interrupts write before setting up reads on the VDP and then turn them back on after it's done reading the current palette. That said, you can probably fix this by doing a VDP_waitVSync before calling VDP_fadeTo.

I've only seen it happen before on async fade so I just disable interrupts before calling, but that wouldn't make sense for a blocking one. Calling VDP_waitVSync first is rather wonky.

[Stef]

Indeed there is many luck that interrupt occurs during the fading process. Normally later SGDK protect the method against that, but not all methods are protected because it would generate many CPU overhead so it's better to let user/developer to deal with that in a more efficient way.

[cero]

I think I've seen this a few times too. But I use sync fading only.

edit: Perhaps the call should be protected if async is false?

[Sik]

Indeed there is many luck that interrupt occurs during the fading process. Normally later SGDK protect the method against that, but not all methods are protected because it would generate many CPU overhead so it's better to let user/developer to deal with that in a more efficient way.

Yeah, I assume it's safe for all blocking ones though, that's the least performance critical stuff by definition after all =P

I'm guessing this case was an oversight anyway?

[Grind]

I tried putting this into my title screen loop, and it doesn't seem to freeze the game at all (ate controller inputs though).

Code: Select all

SYS_disableInts();
VDP_waitVSync();

VDP_waitVSync seems to re-enable interrupts (or at least just VInt), so maybe it would be just fine to leave it the way it is, and call SYS_disableInts() even before synchronous fades. Guess the answer is subjective at this point.

[Stef]

waitVSync() doesn't re-enable interrupts so in your case you indefinitely disable interrupts which is a big problem :p
you should always use SYS_enableInts() after a SYS_disableInts() call.

Yeah, I assume it's safe for all blocking ones though, that's the least performance critical stuff by definition after all =P

Blocking fading now correctly handle that on SGDK, even non blocking ones for the last version
I added more security here and there (by disabling temporary ints) but of course i tried to do that only on methods that you don't use too much

[Grind]

Oh I see, I misunderstood how VDP_waitVSync works. I thought disabling interrupts might make it loop indefinitely, but the vblank flag it checks seems to be changed regardless.

[Mask of Destiny]

Blocking fading now correctly handle that on SGDK, even non blocking ones for the last version

Still looks broken on Github to me. VDP_fadeTo calls VDP_getPaletteColors without waiting for VSync or disabling interrupts and VDP_getPaletteColors doesn't do that either.

[Stef]

Oh you're right, I completely forget to protect the read palette method (writes are ok)
I will commit change asap !

Edit: Commited !

[cero]

Thanks.