Issues warping from Title to Main Game, no buffer screen helps me!

[abenjack]

Hi guys,
I've been stuck for a few days on a known bug that apparently has a workaround. It’s about graphical glitches that occur when transitioning from an 8x8 start screen to "normal" 16x16 screens. If the starting point is directly on the gameplay level, everything works fine. But if the game starts with a title screen and then, after pressing the start button, transitions to the main game using the warp screen macro, glitches randomly appear, and often at least one of the HUD elements (standard, not sprite-based) disappears.

I’ve searched quite a bit on the forum and saw that many of you managed to solve it using a temporary (timed or not) 16x16 buffer screen. However, in my case, that doesn't seem to fix the issue.
Also, I noticed that this buffer screen workaround is often used with the Metroidvania mod, while I’m using the Maze mod — so this behavior seems odd to me.

The strange thing is that even when I use a "classic" 16x16 start screen, glitches still appear when warping to the main game, and not all HUD elements show up (if I force an update with the UpdateHudElement macro, the element being updated appears, but another one disappears).

Any suggestions? This bug is driving me crazy
Thanks in advance for any advice!

 

[dale_coop]

Try adding that code in your press start input script:

      LDA #00
      STA screenLoadTemps

 

[abenjack]

Nice Dale_Coop, it works! (and I'm not using a buffer screen). You're a 8 bit hero!!!
Really, thanks for your precious support

 

[dale_coop]

Nice Dale_Coop, it works! (and I'm not using a buffer screen). You're a 8 bit hero!!!
Really, thanks for your precious support

You're welcome.

I also wrote a tutorial for the fix, for new members that will have the same issue :

[4.5.9] Fix for the glitch tiles after a warp from an 8x8 screen

Here’s another way to fix that infamous glitch that happens when you warp from a screen using 8x8 pixel tiles to a regular 16x16 pixel screen, like this: The fix consists of adding the following lines of code:LDA #00 STA screenLoadTempsIn every script you use to warp out of an 8x8 screen...

nesmakers.com

 

[abenjack]

Hi Dale, I tested better my game and looks like the fix won't works correctly. I noticed that if I press start quickly there is no problem, but if I wait some seconds before I press start button the issue is still present (my player start glitching). This is the code called by the start button:

LDA gameHandler ORA #%10000000 STA gameHandler ;; this will set the next game loop to update the screen. LDA #00 STA screenLoadTemps WarpToScreen #$00, #$FE, #$00 RTS

I also gave an eye to your tutorial and put the fix in the TimerEndScript.asm script and the macro for warp but nothing. Any idea?
Thanks in advance!

 

[dale_coop]

Hi Dale, I tested better my game and looks like the fix won't works correctly. I noticed that if I press start quickly there is no problem, but if I wait some seconds before I press start button the issue is still present (my player start glitching). This is the code called by the start button:

LDA gameHandler ORA #%10000000 STA gameHandler ;; this will set the next game loop to update the screen. LDA #00 STA screenLoadTemps WarpToScreen #$00, #$FE, #$00 RTS

I also gave an eye to your tutorial and put the fix in the TimerEndScript.asm script and the macro for warp but nothing. Any idea?
Thanks in advance!

Can you share a video or gif ? (maybe it's not the same glitch anymore (the small squared tiles)

 

[abenjack]

I used a workaround for the issue. I noticed that the warp was causing a glitch only on the player if I waited a few seconds before pressing the start button. On the 8x8 title screen, sprites were hidden (including the player), while on the main game screen, sprites were visible. I found that if I keep the sprites visible even on the title screen, the problem doesn’t occur.


So, I set a black palette for the player on the title screen, making them invisible by blending into the black background. I know it’s not a clean solution, but it works
Maybe once I improve my skills with NESMaker, I’ll clean up the code and fix this properly (but if you understand the issue and have a better solution, it’s more than welcome )

 

[dale_coop]

I used a workaround for the issue. I noticed that the warp was causing a glitch only on the player if I waited a few seconds before pressing the start button. On the 8x8 title screen, sprites were hidden (including the player), while on the main game screen, sprites were visible. I found that if I keep the sprites visible even on the title screen, the problem doesn’t occur.


So, I set a black palette for the player on the title screen, making them invisible by blending into the black background. I know it’s not a clean solution, but it works
Maybe once I improve my skills with NESMaker, I’ll clean up the code and fix this properly (but if you understand the issue and have a better solution, it’s more than welcome )

I meant... if the glitch you have now is NOT the background tile (small quares) glitch (like the gif on my topic) it's a different glitch.
Each glitch has it's own fix.

For your player sprite glitch, you could try to add in your press start input script (to initialize the sprite animation):

ChangeActionStep player1_object, #00

 

[abenjack]

Great! It works!
Thanks again

 

[slaxx]

I am trying to follow the solution described here, but I am still encountering a glitch when starting the game.
However, the glitch seems to not occur as frequently as before.
The green arrow causes the error when switching from 8x8 to 16x16. But the glitch can also be on other parts of the screen.
The player sprite seems to be fixed (I hope).

 

[slaxx]

This glitch also appears in the middle of the game. What could be the reason for this?

 

[dale_coop]

This glitch also appears in the middle of the game. What could be the reason for this?
View attachment 9194

That glitch is not caused by the warp or by going from an 8x8-based screen to a 16x16-based screen.

The one you’re encountering is caused by the NMI. Some people reduced it by removing the paths (there are some topics about that on the forum). Other people, myself included, reduced it by commenting out several JSR doWaitFrame calls in the do Load Screen script.