Language…
17 users online: Akaginite, aroohwahoou, Bullymario,  Burning Loaf, El Cuh Fermin, gibbl, Kosinus69, lyndis, MORC, Neuromancer, Nitrogen, Overcrow03, PerpetualG00se, Scags, Shuttles, TheJavabrew,  Thomas - Guests: 118 - Bots: 174
Users: 55,671 (2,401 active)
Latest user: Alelima0202

Custom sprites problems with BSNES' latest version



Those in the screenshot are five identical Boomerang Bros, but only one of them loads correctly (it isn't a graphical glitch, they don't work at all). This bug also happens with every other custom sprite, but only in BSNES v078. The hack is pretty old, but I managed to fix every other incompatibility issue, could it be an emulation problem?
Working on Quest on Full Moon Island 2.
Update: May 5, 2016
Originally posted by Storm Kyleis
could it be an emulation problem?

If bsnes does one thing and all other emulators does another thing, the other emulators are wrong. It is likely an emulation problem (also known as "inaccuracy"), but the problem is not in bsnes.
Either way, this patch should fix it.

Edit: That patch doesn't clear all the RAM, use this instead.
Originally posted by fixed patch
header
lorom

!Freespace = $1FFFF7;Edit this if you don't want your ROM to crash

org $00800A
JML Main

org !Freespace
db "STAR"
dw Ratstagsdoesnothingexceptwasteromspace-Somestupidlabel-$01
dw Ratstagsdoesnothingexceptwasteromspace-Somestupidlabel-$01^$FFFF
Somestupidlabel:

Main:
STZ $2140
STZ $2141
STZ $2142
STZ $2143
CLC
XCE
SEP #$FF
LDA #$80
STA $2100
REP #$28

LDA.w #$0001
STA $2181
LDY.b #$7E
STY $2183
LDA.w #$8008
STA $4300
LDA.w #NullByte
STA $4302
LDY.b #NullByte/65536
STY $4304
LDA.w #$FFFF
STA $4305
LDY #$01
STY $420B

LDA.w #$0001
STA $2181
LDY.b #$7F
STY $2183
LDA.w #$8008
STA $4300
LDA.w #NullByte
STA $4302
LDY.b #NullByte/65536
STY $4304
LDA.w #$FFFF
STA $4305
LDY #$01
STY $420B

SEP #$20
LDA #$00
STA $7E0000
STA $7F0000
JML $008010

NullByte:
db $00

Ratstagsdoesnothingexceptwasteromspace:

Edit 3: Fixed. This one clears 100% of the WRAM.
<blm> zsnes users are the flatearthers of emulation
I don't understand why clearing ram is necessary. If a sprite or spritetool it's self is using uninitialized ram for some reason, then it's a bug in the sprite or spritetool, and even if you do this it's likely that ram will be overwritten with something anyway.

Mind explaining what the problem actually is and how this fixes it?
Your layout has been removed.
Originally posted by KilloZapit
Mind explaining what the problem actually is and how this fixes it?

The problem is, with 99% confidence, uninitialized RAM. bsnes 077 and lower, and all non-bsnes emulators, initializes RAM to 55 55 55 55, but bsnes 078 initializes it to random values, which is more similar to how real hardware does it.
This patch makes sure RAM is no longer random (even when using bsnes 078), which should fix that problem.

Quote
If a sprite or spritetool it's self is using uninitialized ram for some reason, then it's a bug in the sprite or spritetool

There's plenty of buggy software where nobody knows of the bugs and/or the bugs went unnoticed for years (example: addmusic). When the bugs are found, the authors are likely gone and/or no longer interested in maintaining their software.

Quote
and even if you do this it's likely that ram will be overwritten with something anyway

RAM isn't overwritten unless something overwrites it, and to my knowledge, this something does not exist in the clean ROM. Therefore, a patch is needed.
<blm> zsnes users are the flatearthers of emulation
Thanks, now it works.
Working on Quest on Full Moon Island 2.
Update: May 5, 2016
Originally posted by Alcaro
There's plenty of buggy software where nobody knows of the bugs and/or the bugs went unnoticed for years (example: addmusic). When the bugs are found, the authors are likely gone and/or no longer interested in maintaining their software.


That's what source code and new utils are for. In this case I am willing to bet the problem is in the sprite, unless the problem pops up more often.

Originally posted by Alcaro
RAM isn't overwritten unless something overwrites it, and to my knowledge, this something does not exist in the clean ROM. Therefore, a patch is needed.


I mean that if this sprite reads uninitialized ram, and never sets it, why is it using that ram address at all? If it does read it, and does set it, then the ram will no longer be the same and the next sprite of that type in that slot will fail. Unless it specifically checks to see if a ram is uninitialized to set some constant, in which case I don't see why you wouldn't use a rom constant, I have no idea why a sprite would work for non-random uninitialized ram and not for random uninitialized ram. The fact that uninitialized ram is used at all is a problem, regardless if you know the value or not.
Your layout has been removed.
Totally offtopic, but...
Originally posted by Alcaro
db "STAR"
dw Ratstagsdoesnothingexceptwasteromspace-Somestupidlabel-$01
dw Ratstagsdoesnothingexceptwasteromspace-Somestupidlabel-$01^$FFFF
Somestupidlabel:

..

Ratstagsdoesnothingexceptwasteromspace:

What really wastes rom space are the tools that don't overwrite data not enclosed in rats tags. I know there's plenty in my rom: residue of old patches, and some stuff I removed manually (like BTSD's offset table).

The most space rats tags could possible waste would be a thousand or so bytes (and that'd require a buttload of sprites/blocks/patches/etc). On the other hand, not overwriting unused data could easily waste far, far more.




Ontopic:

Troublesome. Anyone happen to know exactly where spritetool does this? (which hijack specifically, and I can trace it from there) I think I can make a patch to fix it, though of course it'd have to be applied every time spritetool is run.

I don't want to use alcaro's fix, since initializing every ram address is incredibly hackish and would make the game take a fraction of a second longer to load up.

Guess I'll have to switch to a 100% patch version sooner than I thought...
I think in that case, the asm block is in the original rom or the very end of the expanded rom, so the rats tag doesn't matter. I doubt Alcaro would argue that rats tags in general do nothing. Because anyone who uses any kind of basic utility can easy prove that wrong.

Also, as I said, I expect it's the sprite it's self and not the tool, otherwise we would see this happen a lot more. For the record though, I agree it's an incredibly hackish and silly solution to make a patch that clears ram like that rather then, say, debugging the OAM writes the sprite makes to fix what is probably one LDA $?? that should have been LDA #$??.
Your layout has been removed.
Well, Storm Kyleis said that all custom sprites they were using were messing up, not just the boomerang bro. Barring some extremely unfortunate luck, I doubt ALL of them have the same bad coding. Seems far more likely to me that sprite tool doesn't initialize something (perhaps sprite states?) and instead just checks if they're out of the normal bounds.
Originally posted by Kaijyuu
What really wastes rom space are the tools that don't overwrite data not enclosed in rats tags. I know there's plenty in my rom: residue of old patches, and some stuff I removed manually (like BTSD's offset table).


My tools used to do this a while back but people were still using patches that didn't use RATS tags and just depended on their bytes being non-zero to be counted as 'reserved space'. This caused a huge mess that was annoying for people to track down so it was reverted, even though it is objectively worse to do it tha way =/. Maybe now the situation is better and tools can start doing it the Right Way!

RATS tags definitely matter yes. It's easy to come up with simple patches that would have important parts overwritten without them. Ignore anything that tells you otherwise..

Ontopic:

if it's exclusively sprites at fault then yeah, don't initialise the entire RAM. Just fix the SpriteTool hack. If this is the only issue that came about from randomness then that's not too bad actually.
Originally posted by Alcaro
Edit 3: Fixed. This one clears 100% of the WRAM.

Seeing as how this is more or less necessary for a majority of hacks to work on the SNES, shouldn't your update of that patch be uploaded to the patches section, starred for importance, and added to the Fixing Your Hack To Work On The SNES Thread?

I mean, this patch sounds virtually mandatory. In fact, it would be nice to see it included as part of Lunar Magic.

[?] Miscellaneous Helpful Hints
If I moderated your hack, there was apparently a 90 percent chance it was rejected.
I think it'd be better to fix the root of the problem, rather than have everyone use a workaround.
What exactly is the root of the problem? What should be initialized that isn't?

----------------

I'm working on a hack! Check it out here.