A fix for Wrong Srpites being drawn.......

[JayJayHux]

I tested it on cartridge, played on my Analogue NT Mini Noir. It was a CHR tile switch glitch, no sprites glitched out, just tiles.

Ok so just animated BG tile glitch or just BG tile glitch unrelated to anim Tiles??
And im guessing you cant see the PPU viewer on the hardware??
Also ill just mention when I first added the fix it immediately made a massive improvement but it wasnt until I removed all other minor fixes that it became 2,000+ screens and counting with zero issues.

 

[tbizzle]

@JayJayHux It was definitely to do with anim. tiles (doLoadScreen16 - script). They were cycling like crazy, lol.

 

[JayJayHux]

@JayJayHux It was definitely to do with anim. tiles (doLoadScreen16 - script). They were cycling like crazy, lol.

Damn....
Please keep me updated with any glitches you see.
I was mainly focused on fixing wrong sprites as that was the more constant but i still havnt seen any other glitches at all yet so on my end things are still 100 percent clean but obviously theres still a bug to be fixed regardless.
I hope we can fix this for real and i at least hope you dont see any sprite issues.

 

[JayJayHux]

@tbizzle Can I just confirm with you that we experience the exact same issue/bug/glitch...
For me my sprite sheet and bg tile sheet always load the correct graphics, the only issue for me is on a glitch screen the rows are in wrong position and always in rows of 4. So for example I might get the hud in the bottom 4 rows as expected but i can also get them in the top 4 rows aswell. Same issue for sprite sheet, can be any variation of this issue but always the same issue.
So if my anim tiles are every glitchy its only becasue the duplicated 4 rows lands on my anim metatile row.

Im asking because the issue was 100 percent gone for me as i said over 2,000 screen loads on 4 different emulators, zero issues.
But then I improved the object system and the fade system and it has produced the glitch again.

So yer since its the only glitch I experience im wondering if yours is the same and if not what exactly is your issue??

These images are examples of the issue, first is on the bg sheet, second is on the sprite sheet.

 

[JayJayHux]

The reason I ask is because I have a new better fix!
I just wanted to test it 2,000 times again over the 4 emulators I have and success, ZERO glitches.
Its basically the same fix as before but more targeted to the issue itself, atleast thats what I think.
After changing alot of things with the nesmaker object system and the fade system I started getting the glitch alot again.
Like every 20 frames again.
So going from that to ZERO over 2,000 attempts to find it is pretty telling.

Anyway the fix is again at the bottom of doLoadChrRam.asm and roughly the same idea as before.

The loader occasionally continued
using stale internal progression state.

So this new code is resetting progression state
between strip loads.



Bottom of doLoadChrRam.asm:

;;; now a full tile has been loaded.
DEC arg3_hold
BEQ doneLoadingTiles
;;;;;;;;;;;;;;;;;;;;;;;;;;STREAM STATE RESET TEST START JJH

LDA #$00
STA temp1

;;;;;;;;;;;;;;;;;;;;;;;;;;STREAM STATE RESET TEST END JJH
INC temp16+1
JMP LoadTilesOuterLoop
keepLoading:
DEC arg3_hold
BNE LoadTilesLoop
doneLoadingTiles:

LDA #$00;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;bug test start
STA temp1
STA arg3_hold
STA temp16
STA temp16+1;;;;;;;;;;;;;;;;;;;;;;;;;bug test end

ReturnBank
RTS

 

[tbizzle]

It's still happening in my game. I've yet to open up the Mesen tools to take a peak since lately I've been playing on OG hardware. I'll have to play it on Mesen and take a look this weekend. It is still happening in my game. 6 times in a 7 hour playthrough the last time.

 

[JayJayHux]

It's still happening in my game. I've yet to open up the Mesen tools to take a peak since lately I've been playing on OG hardware. I'll have to play it on Mesen and take a look this weekend. It is still happening in my game. 6 times in a 7 hour playthrough the last time.

Ok no worries, let me know how the new code goes in emulator and hardware if you get a chance.
Ill be figuring out a way to start testing on hardware now too.
I cant use my NES cause no room and it will get damaged.

 

[tbizzle]

Ok no worries, let me know how the new code goes in emulator and hardware if you get a chance.
Ill be figuring out a way to start testing on hardware now too.
I cant use my NES cause no room and it will get damaged.

I will definitely give the code a go tomorrow. I have time to do a full 7 hour complete run of the game!

 

[tbizzle]

@JayJayHux I was playing on OG hardware (Analogue NT Mini Noir), 4 hours in and got the glitch once. It was a main tileset that was animated tile swapping with a path tileset.

 

[JayJayHux]

@JayJayHux I was playing on OG hardware (Analogue NT Mini Noir), 4 hours in and got the glitch once. It was a main tileset that was animated tile swapping with a path tileset.

Thanks for the update, all info helps especially since our setups are slightly different.
My setup is I only have 2 frame animation and I only use MM and MSSS.
The 2 most recent fixes ive added are not 100 percent fixes but each time for me it has helped so much. Would you think it has helped decrease the likelihood of your glitch?
Im also working on another thing to lock the doLoadChrRam script once it has loaded and the sections (Main, Main(or SSS), Hud, Sprite00, Sprite01) so it cant load an extra time with incorrect info. It works really well but it doesnt include anim tiles yet so thats what im working on now.

 

[tbizzle]

Thanks for the update, all info helps especially since our setups are slightly different.
My setup is I only have 2 frame animation and I only use MM and MSSS.
The 2 most recent fixes ive added are not 100 percent fixes but each time for me it has helped so much. Would you think it has helped decrease the likelihood of your glitch?
Im also working on another thing to lock the doLoadChrRam script once it has loaded and the sections (Main, Main(or SSS), Hud, Sprite00, Sprite01) so it cant load an extra time with incorrect info. It works really well but it doesnt include anim tiles yet so thats what im working on now.

I think it has. Usually I get about 3 to 4 occurences in that amount of time. But the glitch is a bastard, just when you think it is tamed it rears its ugly head. I'll finish the playthrough tonight and get back to you on what else happens.

 

[JayJayHux]

I think it has. Usually I get about 3 to 4 occurences in that amount of time. But the glitch is a bastard, just when you think it is tamed it rears its ugly head. I'll finish the playthrough tonight and get back to you on what else happens.

Exactly and everytime it comes back Im even more determined to find it for real. If I can get the anim tiles loaded aswell with my new fix then in theory it should be solved. But ive thought that many times before so well see.

 

[tbizzle]

@JayJayHux I got through another two hours of that playthrough and it did not happen again! I set one of my warps wrong and had to abandon the run, so I am going to restart from the beginning tomorrow. 1 occurence in 6 hours of play is very promising!

 

[JayJayHux]

@JayJayHux I got through another two hours of that playthrough and it did not happen again! I set one of my warps wrong and had to abandon the run, so I am going to restart from the beginning tomorrow. 1 occurence in 6 hours of play is very promising!

Thats awesome! Im really happy to hear that. For both of our sakes.
Please keep me updated and btw ive now got the doLoadChrRam block working with animated tiles and no glitch so far after roughly 500 screen transitions. Still early days yet but it atleast doesnt hurt anything and might be a real fix.
If you keep experiencing bigs even super rarely this might be the next move. I just wanna keep testing it first then ill post it hear if I get no glitches.

 

[tbizzle]

@JayJayHux So I just completed a 7ish hour complete playthrough and It happened a total of four times. Twice it was sprites that cycled with another sprite set, and one of those times it was all the HUD sprites and all the monster sprites, then theo other it was just two sprites on the HUD, really was pretty incignificant. Then the other two times a path tile set animated with a another path tile set. So kinda like 3 and a half times, lol. It wasn't a fail by any means, you can chalk that up as a 50% reduction. Before it was happening on average 8 times a playthrough. Thank you, for at least that! 4 times waaaay better than 8!

 

[JayJayHux]

@JayJayHux So I just completed a 7ish hour complete playthrough and It happened a total of four times. Twice it was sprites that cycled with another sprite set, and one of those times it was all the HUD sprites and all the monster sprites, then theo other it was just two sprites on the HUD, really was pretty incignificant. Then the other two times a path tile set animated with a another path tile set. So kinda like 3 and a half times, lol. It wasn't a fail by any means, you can chalk that up as a 50% reduction. Before it was happening on average 8 times a playthrough. Thank you, for at least that! 4 times waaaay better than 8!

Ok cheers for the detailed update, it helps.
Im glad its helped, it has done the same for me, which is an obvious reduction.
It sounds like your issues are slightly different to mine but we also have slightly different setups. It still seems like the same root cause.
Again, I have a new fix i was mentioning that I havnt yet seen any glitches at all.
This time its not just resetting stale data but locking the doLoadChrRam script as soon as possible after loading all sections for sprite sheet, bg sheet and anim tiles.
I will try to post the fix here tomorrow if I get a chance.

 

[JayJayHux]

WRONG CHR LOADING FIX (Lock doLoadChrRam ASAP After Correct Graphics Loaded)

The Theory:
Rare CHR corruption may be caused by
unexpected or stale CHR loads occurring
after legitimate screen loading is complete.



Step 00: Create Vars
chrLoadLock = 0
chrLoadCounter = 0



Step 01 Add lock check at beginning of doLoadChrRam
doLoadChrRam:

;;;;;;;;;;;;;;;;;;;;;;;;;;CHR LOAD LOCK CHECK START JJH
LDA chrLoadLock
BEQ continueChrLoading

RTS

continueChrLoading:
;;;;;;;;;;;;;;;;;;;;;;;;;;CHR LOAD LOCK CHECK END JJH

If locked:
Exit immediately.

If unlocked:
Continue loading.



Step 02 add Load Counter at end of doLoadChrRam
doneLoadingTiles:

LDA #$00;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;bug test start
STA temp1
STA arg3_hold
STA temp16
STA temp16+1;;;;;;;;;;;;;;;;;;;;;;;;;bug test end

;;;;;;;;;;;;;;;;;;;;;;;;;;CHR LOAD COUNT TEST START JJH
INC chrLoadCounter

LDA chrLoadCounter
CMP #$0F ; TEST VALUE

BCC dontLock

LDA #$01
STA chrLoadLock

dontLock:
;;;;;;;;;;;;;;;;;;;;;;;;;;CHR LOAD COUNT TEST END JJH

ReturnBank
RTS

Count every completed CHR load.

When counter reaches 15:
Enable lock.



Step 03: Reset Vars at very top of doDrawSpriteHud
LDA #$00
STA chrLoadLock
STA chrLoadCounter

Screen loading has completed.

Unlock CHR loading.
Reset load count.
Ready for next screen transition.



Counter Value

#$0F is a test value that works for my project.

You should reduce this value as much as possible while still allowing:
- All screen types to load correctly.
- All animated tiles to function correctly.
- All CHR banks to load correctly.

The goal is to allow the minimum number of legitimate CHR loads according to your project.



Reset Location

The reset does NOT have to occur in doDrawSpriteHud.

It simply needs to occur at a point where:
- The previous screen load has completed.
- The next screen transition has not yet started.

In my project I use top of doDrawSpriteHud.

...........................................
I hope this makes sense and is helpful.
Any questions at all just ask and ill explain or help as best I can.

 

[JayJayHux]

@tbizzle just posted the fix but im short on sleep so it might not be super clear. Hopefully it is.
If i didnt make it clear you likely need to adjust Counter Value to suit your setup. You should just have it the lowest possible value whilst all your screens still animating and behaving correctly.

 

[tbizzle]

@JayJayHux I'll give the code a playthrough tomorrow night!

 

[tbizzle]

I don't where in the code but, this new code disables most of my CHR from displaying when testing. My screens are all black, lol. I'll play with it and see where the changes need to be made. @JayJayHux