This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Final Chance, to solve SMBDIS Sprite 0 Removal Problems!

Final Chance, to solve SMBDIS Sprite 0 Removal Problems!
by on (#46920)
There must be a way to permenantly removing sprite 0, no alternitaves

the removal of it without glitches (of which I am strict of) or using up IRQs while using one RAM place ($B8 = 40) is what should be rejected.

I am really serious about removing sprite 0 for freedom of the screen, Replacing the status bar and make my own pause screen with statistics (SMBDX style).

Is it now clear? If so, can anyone Please give me an anwser since Sprite 0 sucks a lot when I remove it my own way. I tried so hard, I can't do it.

I am sorry if I repeated it, The answers I get were not very good. Neither were my posts, I am still working on stuff myself. But this is hopefully the last request anyways

by on (#46921)
I'm sorry if my memory is failing, but if I'm not mistaking, it's at last the 15th time you post something like that, and if that is the case people may get really mad at you.

by on (#46922)
Fine, If it's too complicated, Then everybody, Including me, fails

But that is OK, It's Nintendo's fault of using Sprite 0 like this (Anti-Piracy comes to mind)

Bregalad wrote:
I'm sorry if my memory is failing, but if I'm not mistaking, it's at last the 15th time you post something like that, and if that is the case people may get really mad at you.


Actually, Take away Ten to see the approximate number (5)

by on (#46923)
What's SMB DX style?

by on (#46924)
tomaitheous wrote:
What's SMB DX style?


If you ever played it (It's the Gameboy Color Version). Pausing will scroll up/down instead of freezing on and off, While disabling sprites, then reenabling them)

But my plan will be to not scroll it, But to use four-screen mirroring for switching it from current position to $2800 or $2C00 and back

by on (#46925)
So, you want to remove the status bar up top completely and add a 'status' screen when paused?

by on (#46926)
Either that or use MMC5 for sprites in 8x16 mode while adding graphics and remove leftover sprites and modding it's space usage, making space for status bar

Either way, it's doable

Think of the first one like in Trolls in Crazyland (Doki Doki Yuuenchi or something like that) Only Without Sprites.

by on (#46927)
I've having trouble understanding what your end goal is and why you don't want to use a sprite 0 system. Well, if you wanted to do away with any status bar then I could see why you'd want to remove the sprite 0 system, but you posted otherwise.

by on (#46928)
tomaitheous wrote:
I've having trouble understanding what your end goal is and why you don't want to use a sprite 0 system. Well, if you wanted to do away with any status bar then I could see why you'd want to remove the sprite 0 system, but you posted otherwise.


I do not want sprite 0 and I want to remove it permanently, Simple as that

by on (#46929)
There was a hack/port of SMB1 to the TG16/PCE system (among other games that I'm sure used sprite #0). If they can pull that off, I'm sure it's just as doable on the NES with an IRQ hack. If it's worthwhile, maybe you could disassemble that (I think that .PCE file was called 5-in-1 something). But for all I know that system could also have a sprite #0 detection thing going on, I wouldn't be surprised.

Seems like the quick hack would be to write an IRQ routine, and change the spr#0 polling to poll some RAM that the IRQ routine sets. Then you'd also have to hack in where it initializes the IRQ, and every frame where it sets the scanline for it to happen on (or I guess you could do that in the IRQ routine).

by on (#46930)
Memblers wrote:
There was a hack/port of SMB1 to the TG16/PCE system (among other games that I'm sure used sprite #0). If they can pull that off, I'm sure it's just as doable on the NES with an IRQ hack. If it's worthwhile, maybe you could disassemble that (I think that .PCE file was called 5-in-1 something). But for all I know that system could also have a sprite #0 detection thing going on, I wouldn't be surprised.

Seems like the quick hack would be to write an IRQ routine, and change the spr#0 polling to poll some RAM that the IRQ routine sets. Then you'd also have to hack in where it initializes the IRQ, and every frame where it sets the scanline for it to happen on (or I guess you could do that in the IRQ routine).


See 1st post. Not what I really want at all

Just so you know, Last time when I tried it with MMC5 when modding the proper routines, It never works. MMC5 IRQS sucks

Yes, PCE has Sprite0, I was originally going to Re-do a port of SMB with enhanced graphics, but there is no luck having sprites without a PCE sprite graphics editor for windows. That is my problem with PCE dev.

PCE has 2 graphics formats, BG (Same format as SNES) and SPR (Totally weird and currently unsupported on current editors on windows)

by on (#46931)
Hm, I don't see how IRQ wouldn't work as a replacement. It can take some care to set up, much like writing timed code.

Quote:
I do not want sprite 0 and I want to remove it permanently, Simple as that


Wouldn't one solution then be to make the tile it uses to be all transparent pixels, and replace the sprite #0 polling with NOPs? That would be the easiest way to go I'd think.

by on (#46933)
Memblers wrote:
Wouldn't one solution then be to make the tile it uses to be all transparent pixels, and replace the sprite #0 polling with NOPs? That would be the easiest way to go I'd think.


The Status bar shakes up and down when I do that

Code:
Sprite0Clr:
               nop
               nop
               nop
               nop
               nop
               nop
               nop
               ;lda PPU_STATUS            ;wait for sprite 0 flag to clear, which
               ;and #%01000000           ;will not happen until vblank has
               ;bne Sprite0Clr                ;ended
               lda GamePauseStatus       ;if in pause mode, do not bother
               lsr                                   ;with sprites at all
               bcs Sprite0Hit
               jsr MoveSpritesOffscreen
               jsr SpriteShuffler
Sprite0Hit:   
               nop
               nop
               nop
               nop
               nop
               nop
               nop
               ;lda PPU_STATUS            ;do sprite #0 hit detection
               ;and #%01000000
               ;beq Sprite0Hit
               ldy #$14 ;small delay, to wait until we hit horizontal blank time
HBlankDelay:   
               dey
               bne HBlankDelay
SkipSprite0:   
               lda HorizontalScroll      ;set scroll registers from variables
               sta PPU_SCROLL_REG
               lda VerticalScroll
               sta PPU_SCROLL_REG
               lda Mirror_PPU_CTRL_REG1  ;load saved mirror of $2000
               pha
               sta PPU_CTRL_REG1
               lda GamePauseStatus       ;if in pause mode, do not perform
               lsr                                   ;operation mode stuff
               bcs SkipMainOper
               jsr OperModeExecutionTree ;otherwise do one of many, many possible subroutines
SkipMainOper:  lda PPU_STATUS            ;reset flip-flop
               pla
               ora #%10000000            ;reactivate NMIs
               sta PPU_CTRL_REG1
               rti                       ;we are done until the next frame!

by on (#46935)
Quote:
Quote:
Seems like the quick hack would be to write an IRQ routine, and change the spr#0 polling to poll some RAM that the IRQ routine sets. Then you'd also have to hack in where it initializes the IRQ, and every frame where it sets the scanline for it to happen on (or I guess you could do that in the IRQ routine).


See 1st post. Not what I really want at all


So you don't want sprite #0 method and you don't want a scanline interrupt counter method? There really isn't any other way, if you want to execute a PPU reg change at a specific point during the frame.

I haven't played SMB DX in ages or at all for those other games mentioned. Can you post some pics or at least a crude ascii drawing. If you do want to section off part of the screen for a status (be it in a different place or not), what are the requirements this "window" needs that you can't do currectly?

FYI- PCE doesn't have a sprite #0 system like NES. It has "collision for sprite #0 with another other sprite" system, but it's almost never used. For the Castlevania NES ROM hack I did on PCE; I cached the writes to the PPU X/Y reg and had a system that checked sprite #0's position, if on screen I generated a scanline IRQ relative to its position onscreen, applied the X/Y cache to video processor.

by on (#46937)
Hamtaro126 wrote:
Memblers wrote:
Wouldn't one solution then be to make the tile it uses to be all transparent pixels, and replace the sprite #0 polling with NOPs? That would be the easiest way to go I'd think.


The Status bar shakes up and down when I do that


The relevant part of the code, quoted below relies on the sprite #0 hit happening consistently and waiting for hblank. Since that's ripped out you'll need to move that code so it will run during vblank, before the PPU is active otherwise it will jump around.

Code:
               ldy #$14 ;small delay, to wait until we hit horizontal blank time
HBlankDelay:   
               dey
               bne HBlankDelay
SkipSprite0:   
               lda HorizontalScroll      ;set scroll registers from variables
               sta PPU_SCROLL_REG
               lda VerticalScroll
               sta PPU_SCROLL_REG
               lda Mirror_PPU_CTRL_REG1  ;load saved mirror of $2000
               pha
               sta PPU_CTRL_REG1
               lda GamePauseStatus       ;if in pause mode, do not perform
               lsr                                   ;operation mode stuff
               bcs SkipMainOper
               jsr OperModeExecutionTree ;otherwise do one of many, many possible subroutines
SkipMainOper:  lda PPU_STATUS            ;reset flip-flop
               pla
               ora #%10000000            ;reactivate NMIs
               sta PPU_CTRL_REG1
               rti                       ;we are done until the next frame!

by on (#46938)
THE RAAAAAAAAAAAGE

Quote:
There must be a way to permenantly removing sprite 0, no alternitaves
the removal of it without glitches (of which I am strict of) or using up IRQs while using one RAM place ($B8 = 40) is what should be rejected.


No alternatives? So you want to removes sprite 0 and not replace it with anything? Do you even know how the NES works? GRAH

Quote:
Sprite 0 sucks a lot when I remove it my own way


Maybe it's because you don't know what you're doing.

Quote:
The answers I get were not very good.


Yes they were. You just didn't understand them. Unless by "not very good" you mean "didn't do all of the work for me".

Quote:
But this is hopefully the last request anyways


As much as I want to believe this I find it hard to swallow.

Quote:
Fine, If it's too complicated, Then everybody, Including me, fails


Yes... I fail because you pose a "challenge" to do the impossible. Hey, build me a functioning car made out of nothing but tubes of toothpaste and hairspray. Can't do it? OH NO I GUESS WE ALL FAIL!

Quote:
But that is OK, It's Nintendo's fault of using Sprite 0 like this (Anti-Piracy comes to mind)


Anti-piracy? Haw.

Maybe because it's the only way to do raster effects on the NES without additional hardware or rigid cycle timing? But I suppose if you knew anything about the NES you'd know that.

Quote:
Just so you know, Last time when I tried it with MMC5 when modding the proper routines, It never works. MMC5 IRQS sucks


BWAHAHAHAHAH. MMC5 only has the most sophistocated scanline counter available on the NES. But I guess if you couldn't get it working, it MUST suck. I mean after all... there's NO way you could've been doing it wrong.

grumble grumble grumble

by on (#46939)
Hamtaro126 wrote:
PCE has 2 graphics formats, BG (Same format as SNES) and SPR (Totally weird and currently unsupported on current editors on windows)

Then write a short program for Windows that translates BG into SPR, and have the makefile that builds your ROM hack call this program.

by on (#46940)
Hamtaro126 wrote:
PCE has 2 graphics formats, BG (Same format as SNES) and SPR (Totally weird and currently unsupported on current editors on windows)


TMOD2 works with PCE sprites. Plus the PCEAS assembler from Magic kit can convert PCX files to either PCE tiles or sprites (assemble just a file with an "include" and no header)

by on (#46978)
Disch wrote:
Quote:
There must be a way to permenantly removing sprite 0, no alternitaves
the removal of it without glitches (of which I am strict of) or using up IRQs while using one RAM place ($B8 = 40) is what should be rejected.

No alternatives? So you want to removes sprite 0 and not replace it with anything? Do you even know how the NES works?

Hamtaro may not have as solid a grasp of the NES architecture as we would prefer. But he might be thinking of how Ikari Warriors, M.C. Kids, and Super Mario 64 draw their status bars:

Image

by on (#46980)
tepples wrote:
Disch wrote:
Quote:
There must be a way to permenantly removing sprite 0, no alternitaves
the removal of it without glitches (of which I am strict of) or using up IRQs while using one RAM place ($B8 = 40) is what should be rejected.

No alternatives? So you want to removes sprite 0 and not replace it with anything? Do you even know how the NES works?

Hamtaro may not have as solid a grasp of the NES architecture as we would prefer. But he might be thinking of how Ikari Warriors, M.C. Kids, and Super Mario 64 draw their status bars


Also: Adventure Island, Kid Icarus and Metroid.

by on (#46983)
You want to add your own sprites for the status? I'd say to forget about that, I expect that would involve a lot of rewriting the game's sprite code and fully reverse-engineering it.

The best shortcut I can give you is to do a 2nd sprite DMA based on a seperate page in RAM. But even that's useless, it'll leave a black bar and you can't move the other sprites over it, so it might as well be background..

I know you want to solve this problem, but man, I think it's more work (and harder debugging) than writing a game from scratch.

Your idea of using 4-screen nametables, and using those for status sounds like the best one to me. You could use a separate sprite DMA for that screen and have your own sprites+background. You could even have yours AND the game's sprites+bg on screen at the same time, if you accept the black bar being between them.

by on (#46986)
but good luck splitting the screen (black bar or no) without IRQs or Sprite 0 hit.

by on (#46989)
Code:
               ldy #$14 ;small delay, to wait until we hit horizontal blank time
HBlankDelay:   
               dey
               bne HBlankDelay


is this standard after polling for sprite 0 hit?

by on (#46990)
frantik wrote:
Code:
               ldy #$14 ;small delay, to wait until we hit horizontal blank time
HBlankDelay:   
               dey
               bne HBlankDelay


is this standard after polling for sprite 0 hit?


The timing is dependant on the X position of the sprite, and I'd think also the X position of the collision (give or take a few pixels - a single pixel sprite #0 is known to be unreliable).

by on (#46992)
ah ok.. you need to wait for hblank though before you do the scrolling, right?

by on (#46994)
You don't NEED to, but if you don't you'll have a scanline where the scroll is all skewed.