Any writes to $2006 seem to botch my CHR-Ram graphics load. However, things still got weird when I tried to fix the scroll.
#Fceux palette swap code#
looks like it's not necessarily the method implementation that's the problem, but something that is countering it somewhere in code (my guess, just a single frame where sprite zero is being *cleared* in my object drawing loop, and drawn off screen). It's possible that a sprite-clear function in my current version of the code at time of screen load is causing the main issue.though I thought I disabled that. After a lot of trial and error, I found that putting in some flags to make sure that the nametable AND zero sprite are drawn prior to checking for the hit got me past the *freezing* in that version. So.I've gone back to a much earlier (read: simple) version of the code. All with the same result.Ĭurrently, i am drawing sprite zero at #$d0 if it helps (and it is definitely colliding with background). I tried different versions of the sprite zero check discussed here.
But with the sprite 0 hit and trying to separate the screen, the color does not change, I get *animated junk* at the top, scroll value was pshed off, and it seems that in some spots it is drawing the right value (f5, which should be a blank tile) but from the wrong pattern table. If I skip the sprite 0 loop and just do the single color swap, no problem. so something with the sprite zero check is the problem?
this works with no issue if I don't do the sprite zero check  should change a color in the last sub palette.
some arbitrary numbers in a dummy loop here to try to get to the end of the scanline checks game state.if not a screen where sprite 0 is drawn, skip this code
0 kommentar(er)
