Graphic sprite and tile bug NESmaker 4.5.9 Adventure (SOLVED)

I don't know what happen, I spotted strange sprite bugs in Underworld. I use Mesen, and open CHR viewer. Start with location X=0 Y=0. Head right to X=1 Y=0 and I noticed weird sprite glitch appear on $4B in CHR Viewer. Then keep heading right to X=2 Y=0 and I noticed weird sprite glitch appear on $0B in CHR Viewer. I don't know it just me or it happen any of you.
 

Attachments

  • NESMakerBugs1.png
    NESMakerBugs1.png
    15.9 KB · Views: 33
  • NESMakerBugs2.png
    NESMakerBugs2.png
    16.1 KB · Views: 32

baardbi

Well-known member
I think the Underworld is cursed. Especially in the platform / metrovania modules. A lot of strange things happen when I use the underworld in those modules. I haven't seen this particular bug though.
 
I know this is an old topic. I spend a lot of time digging to understand the coding. I was looking in https://www.nesdev.org/wiki/Init_code and noticed it is not the same script compared to Nesmaker's Reset.asm. I modify the way Nesdev put it down. I start Nesmaker in adventure mode, I have not seen rare sprite and tile glitches for a long period of time. Try this code if you have similar small sprite and tile glitches like this.

RESET:
SEI ; ignore IRQs
CLD ; disable decimal mode
LDX #$40
STX $4017 ; disable APU frame IRQ
LDX #$FF
TXS ; Set up stack
INX ; now X = 0
STX $2000 ; disable NMI
STX $2001 ; disable rendering
STX $4010 ; disable DMC IRQs
STX $4015 ; disables APU sound

; Optional (omitted):
; Set up mapper and jmp to further init code here.

; The vblank flag is in an unknown state after reset,
; so it is cleared here to make sure that @vblankwait1
; does not exit immediately.
bit $2002

; First of two waits for vertical blank to make sure that the
; PPU has stabilized
vBlankWait1:
bit $2002
BPL vBlankWait1

; We now have about 30,000 cycles to burn before the PPU stabilizes.
; One thing we can do with this time is put RAM in a known state.
; Here we fill it with $00, which matches what (say) a C compiler
; expects for BSS. Conveniently, X is still 0.
TXA
clrMemLoop:
STA $0000,x ;Zero RAM addresses from $0000 to $00FF
STA $0100,x ;Zero RAM addresses from $0100 to $01FF
STA $0200,x ;Zero RAM addresses from $0200 to $02FF
STA $0300,x ;Zero RAM addresses from $0300 to $03FF
STA $0400,x ;Zero RAM addresses from $0400 to $04FF
STA $0500,x ;Zero RAM addresses from $0500 to $05FF
STA $0600,x ;Zero RAM addresses from $0600 to $06FF
STA $0700,x ;Zero RAM addresses from $0700 to $07FF
INX ; X++
BNE clrMemLoop ;loops until X reaches zero again (after roll-off).

; Other things you can do between vblank waits are set up audio
; or set up other mapper registers.

vBlankWait2:
bit $2002
BPL vBlankWait2

;8 Enable NMI
LDA #%10010000 ; turn on NMI, set sprites $0000, bkg to $1000
STA $2000
LDA #%00011110
STA $2001
STA soft2001

LDA #$00
STA $2005
;;DON'T TURN ON RENDERING UNTIL FIRST GRAPHICS ARE DRAWN.
 

Attachments

  • game_001.png
    game_001.png
    28.4 KB · Views: 6
  • NESMakerBugs1.png
    NESMakerBugs1.png
    31 KB · Views: 7
I know this is an old topic. I spend a lot of time digging to understand the coding. I was looking in https://www.nesdev.org/wiki/Init_code and noticed it is not the same script compared to Nesmaker's Reset.asm. I modify the way Nesdev put it down. I start Nesmaker in adventure mode, I have not seen rare sprite and tile glitches for a long period of time. Try this code if you have similar small sprite and tile glitches like this.

RESET:
SEI ; ignore IRQs
CLD ; disable decimal mode
LDX #$40
STX $4017 ; disable APU frame IRQ
LDX #$FF
TXS ; Set up stack
INX ; now X = 0
STX $2000 ; disable NMI
STX $2001 ; disable rendering
STX $4010 ; disable DMC IRQs
STX $4015 ; disables APU sound

; Optional (omitted):
; Set up mapper and jmp to further init code here.

; The vblank flag is in an unknown state after reset,
; so it is cleared here to make sure that @vblankwait1
; does not exit immediately.
bit $2002

; First of two waits for vertical blank to make sure that the
; PPU has stabilized
vBlankWait1:
bit $2002
BPL vBlankWait1

; We now have about 30,000 cycles to burn before the PPU stabilizes.
; One thing we can do with this time is put RAM in a known state.
; Here we fill it with $00, which matches what (say) a C compiler
; expects for BSS. Conveniently, X is still 0.
TXA
clrMemLoop:
STA $0000,x ;Zero RAM addresses from $0000 to $00FF
STA $0100,x ;Zero RAM addresses from $0100 to $01FF
STA $0200,x ;Zero RAM addresses from $0200 to $02FF
STA $0300,x ;Zero RAM addresses from $0300 to $03FF
STA $0400,x ;Zero RAM addresses from $0400 to $04FF
STA $0500,x ;Zero RAM addresses from $0500 to $05FF
STA $0600,x ;Zero RAM addresses from $0600 to $06FF
STA $0700,x ;Zero RAM addresses from $0700 to $07FF
INX ; X++
BNE clrMemLoop ;loops until X reaches zero again (after roll-off).

; Other things you can do between vblank waits are set up audio
; or set up other mapper registers.

vBlankWait2:
bit $2002
BPL vBlankWait2

;8 Enable NMI
LDA #%10010000 ; turn on NMI, set sprites $0000, bkg to $1000
STA $2000
LDA #%00011110
STA $2001
STA soft2001

LDA #$00
STA $2005
;;DON'T TURN ON RENDERING UNTIL FIRST GRAPHICS ARE DRAWN.

I still get similar tile graphic bugs in similar spots even after trying this alternative RESET script. Just wondering if you have any other ideas or have had any other discoveries regarding this issue. For what it's worth, I only started noticing the tile bugs after implementing music, and they do not occur when music is off, so I think it is related to the extra cycles caused by updating music, but it's just a theory.
 
Top Bottom