 |
|
 |
|
| Custom sprites problems with BSNES' latest version |
|
Forum Index - SMW Hacking - General SMW Hacking Help - ASM & Related Topics - Custom sprites problems with BSNES' latest version |
|
Pages:  1  |
|
|
|
| Posted on 2011-05-05 09:44:52 AM |
Link | Quote |
|
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?
|
|
| Posted on 2011-05-05 09:47:03 AM |
Link | Quote |
|
Originally posted by Storm Kyleiscould 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 patchheader
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.
|
| Last edited on 2011-05-05 10:03:09 AM by Alcaro. |
|
| Posted on 2011-05-05 10:36:35 AM |
Link | Quote |
|
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?
|
| Last edited on 2011-05-05 10:38:07 AM by KilloZapit. |
|
| Posted on 2011-05-05 11:18:30 AM |
Link | Quote |
|
Originally posted by KilloZapitMind 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.
QuoteIf 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.
Quoteand 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.
|
|
| Posted on 2011-05-05 12:12:23 PM |
Link | Quote |
|
|
Thanks, now it works.
|
|
| Posted on 2011-05-05 03:48:54 PM |
Link | Quote |
|
Originally posted by AlcaroThere'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 AlcaroRAM 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.
|
| Last edited on 2011-05-05 03:58:26 PM by KilloZapit. |
|
| Posted on 2011-05-05 05:18:28 PM |
Link | Quote |
|
Totally offtopic, but...
Originally posted by Alcarodb "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...
|
| Last edited on 2011-05-05 05:31:08 PM by Kaijyuu. |
|
| Posted on 2011-05-05 07:15:34 PM |
Link | Quote |
|
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 #$??.
|
| Last edited on 2011-05-05 07:24:18 PM by KilloZapit. |
|
| Posted on 2011-05-05 08:21:18 PM |
Link | Quote |
|
|
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.
|
|
| Posted on 2011-05-05 09:52:29 PM |
Link | Quote |
|
Originally posted by KaijyuuWhat 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.
|
|
| Posted on 2011-05-12 03:19:36 PM |
Link | Quote |
|
Originally posted by AlcaroEdit 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.
|
|
| Posted on 2011-05-12 04:29:38 PM |
Link | Quote |
|
|
I think it'd be better to fix the root of the problem, rather than have everyone use a workaround.
|
|
| Posted on 2011-05-12 04:55:53 PM |
Link | Quote |
|
|
What exactly is the root of the problem? What should be initialized that isn't?
|
|
|
| Pages: 1 |
|
|
|
|
Forum Index - SMW Hacking - General SMW Hacking Help - ASM & Related Topics - Custom sprites problems with BSNES' latest version |
|
|
 |
|
 |
The purpose of this site is not to distribute copyrighted material, but to honor one of our favourite games.
Copyright © 2005 - 2013 - SMW Central
Legal Information - Link To UsTotal queries: 29
|
|
|
|
.png)
