Annoying 256 chunk loading/drawing bug

I've had this problem for a while, but for the last few months I thought I fixed it. Obviously, I was wrong, so here it is because I don't have any other idea on the matter:





No, not the red arrow, the two 'empty' blue tiles. <_<


For some reasons, two tiles won't load. It happens in my additional GH level (it has water) and sometimes in Labyrinth as well (act 2 I think).


It won't happen if I launch the level from a level select screen. It's either those two tiles or two tiles in one of the foreground blocks (always the same ones).


Since those BG chunks in GH won't reload in game, the glitch is visible during the entire level, but when it's on a foreground chunk, once reloaded while playing (moving further and coming back), they will be displayed properly.


Ideas and suggestions are welcome (solution as well haha).

 

Do they go away if you move off screen and then return? I had a simular problem before.

 

If the chunk is reloaded, they do (though that particular background chunk is never "away" from the plane, so it is never reloaded and in this case, it doesn't disappear).

 

I'm not too familiar as to why this happens either, of course what I DO understand is that it is related to the calling of "LoadTilesFromStart", now I know for a fact that this routine functions properly, so it's definately not something within that function, but it is based around it.


I would like you to try disabling the blanking interrupts and then enabling them after the function is called, something on the lines of:



loc_3946:
moveq #3,d0


bsr.w PalLoad1 ; load Sonic's pallet line


move #$2700,sr ; Disable the blanking interrupts


bsr.w LevelSizeLoad


bsr.w DeformBgLayer


bset #2,($FFFFF754).w


bsr.w MainLoadBlockLoad ; load block mappings and pallets


bsr.w LoadTilesFromStart


jsr FloorLog_Unk


bsr.w ColIndexLoad


bsr.w LZWaterEffects


move #$2300,sr ; Enable the blanking interrupts


move.b #1,($FFFFD000).w ; load Sonic object


tst.w ($FFFFFFF0).w


bmi.s Level_ChkDebug


move.b #$21,($FFFFD040).w ; load HUD object


Level_ChkDebug:



This isn't a guarantee by the way, we're just experimenting here, my hunch here is that it is a strong posibility the "LoadTilesFromStart" routine is being interrupted and that the data it is currently processing isn't restored correctly for some reason, or that maybe the "LoadTilesAsYouMove" routine that runs in V-blank may be assuming that a level has already been loaded and a new position has been set (when it hasn't), and as a result writes new tile data over the sections that "LoadTilesFromStart" had already drawn.


Take note that by disabling the blanking interrupts, this means V-blank is no longer called, and hence the 68k sound drive MAY remain hulted in the period of the interrupts being disabled, I haven't checked this myself, but it would depend on how fast the routines inbetween are.


If this DOES in fact fix the problem, then we know that it's something in one of the blanking interval routines that is triggering it, and we can replace the disabling/enabling of the interrupts with a single flag that when set, stops running whatever it is in the blanking interval routines that is responsible for throwing off the drawing, whilst continuing everything else that we want running in the blank routines (like the sound driver and DMA transfers for example).


OR, you could try calling "LoadTilesFromStart" again just before the screen fades in at:



Level_DelayLoop:
move.b #8,($FFFFF62A).w


bsr.w DelayProgram


dbf d1,Level_DelayLoop


; <- here


move.w #$202F,($FFFFF626).w


bsr.w Pal_FadeTo2



A bit hackish I know, and it won't explain why the bug happens, but it might fix your bug.

 

Looks like it's working. Thanks


Though it's the 4th or 5th time I think I get rid of it, so I'll test this more tomorrow. <_<


I'm using the z80 sound driver by the way, so no problem there.


I enable the interrupts right after DeformBGLayer and it seems to be enough. There was a visual glitch otherwise, half of the screen was visible for 1 frame with the under water palette when everything else was still black (excepted for the 1st palette line of course).


From what I've seen thanks to several tests I did some times ago and that change above (the first one), the background deformation is too slow when there's an h-int, I don't know why though, neither do I know why it affects the tiles being loaded.

 

Well, at least we have some theory and resource into the possible reason, we'll have to research this sometime and create a guide or something to fix it =P

 

It's still there <_<


The missing blocks were hiding a little further in the foreground.


But, the good news are, if I disable/enable the interrupts only before and after loadtilesfromstart, it loads properly as you expected. The problem in that case being that underwater flash on half of the screen.

 

That is interesting. I experimented something like this in two occassions, but my missing tiles was in the level blocks instead on the bg. It happened firstly in Scrap Brain Act 3 (Labyrinth Zone Act 4) and then, in Labyrinth Zone Act 1. I "fixed" it changing the layout. I never understood where it came from because I had that layout since too many time and it was always ok, but someday, it starts to appear :S


Good to see where the problem is. Thanks!

 

I still don't know exactly what's happening, but I disabled the animated art reloading for that level until the level timer is launched, and it looks like the glitch is gone again. That's without disabling the interrupts (so no water flash).


Forget that, it's still there <_<


Edit: So, for now, only Mr Jester's solution 2 seems to really work without any glitch (and not any visible slowdown).


Edit2: I really think it's a problem with the routine being interrupted too early or improperly. I placed a delayprogram of 2 frames (or maybe it's really 1, since 1 crashes the game) before the 'bsr.w mainloadblockload", and it seems the glitch isn't visible in that case either.