Final Chance, to solve SMBDIS Sprite 0 Removal Problems!

Final Chance, to solve SMBDIS Sprite 0 Removal Problems!
by Hamtaro126 on 2009-05-17 (#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 Bregalad on 2009-05-17 (#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 Hamtaro126 on 2009-05-17 (#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 tomaitheous on 2009-05-17 (#46923)

What's SMB DX style?

by Hamtaro126 on 2009-05-17 (#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 tomaitheous on 2009-05-17 (#46925)

So, you want to remove the status bar up top completely and add a 'status' screen when paused?

by Hamtaro126 on 2009-05-17 (#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 tomaitheous on 2009-05-17 (#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 Hamtaro126 on 2009-05-17 (#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 Memblers on 2009-05-17 (#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 Hamtaro126 on 2009-05-17 (#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 Memblers on 2009-05-17 (#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 Hamtaro126 on 2009-05-17 (#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 tomaitheous on 2009-05-17 (#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 Memblers on 2009-05-17 (#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 Disch on 2009-05-17 (#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 tepples on 2009-05-17 (#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 tomaitheous on 2009-05-17 (#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 tepples on 2009-05-18 (#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:

by Hamtaro126 on 2009-05-18 (#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 Memblers on 2009-05-18 (#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 Disch on 2009-05-18 (#46986)

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

by frantik on 2009-05-18 (#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 Memblers on 2009-05-18 (#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 frantik on 2009-05-18 (#46992)

ah ok.. you need to wait for hblank though before you do the scrolling, right?

by Celius on 2009-05-18 (#46994)

You don't NEED to, but if you don't you'll have a scanline where the scroll is all skewed.