Language…
5 users online: Alex No, Hammerer, Rudi_Schrausch,  Tahixham, Torchkas - Guests: 279 - Bots: 330
Users: 64,795 (2,377 active)
Latest user: mathew

I feel like SMW hacking is bogging SNES homebrew down

Link Thread Closed
  1. The game actually reserved each sprite some OAM tiles, for special sprites like Banzai Bills and Big Boos even more.
  2. NMSTL actually checks through every single sprite slot and search so long until it hits a used sprite slot. The optimised version is, of course, using an OAM tile index (and some people did, albeit not released to the patches section).
  3. It also sets the sprite tile size and removes the OAM tile when it's too far offscreen. Of course, it is unoptimised, but it's used to save ROM space since Nintendo had the idea that every sprite can be put into one bank... (They don't.)
Does NMSTL work like this:

Say X are sprites that are already being used, and Z are sprites that belong to a big sprite like a Banzai Bill. The OAM table looks like this:

XX----XXXX---XXXX--------------------X--XXX---X-X-X---XXXX-----X

Because the Banzai Bill uses 16 sprites, the 16 sprites go here:

XX----XXXX---XXXXZZZZZZZZZZZZZZZZ----X--XXX---X-X-X---XXXX-----X

Is this how it works?
I realised my post wasn't really completed...

Anyway, NMSTL is simply "Search so long through the OAM tiles until one is used. Previous index is unused."
In other words, if we used C, we would have had (roughly) this code:
Code
for(int i = ; i < tiles; i=i-4)
{
	if(OAMYPos[i-4] != 0xF0) return i;
}

Where tiles is in this case (double, for NMSTL and without Yoshi) 0xD8, how many tiles are checked times four.

It's more like this:
Without Banzai Bill:
------------------XXXXXXX--XXX
With Banzai Bill:
--ZZZZZZZZZZZZZZZZXXXXXXX--XXX
Originally posted by MarioFanGamer
I realised my post wasn't really completed...

Anyway, NMSTL is simply "Search so long through the OAM tiles until one is used. Previous index is unused."
In other words, if we used C, we would have had (roughly) this code:
Code
for(int i = ; i < tiles; i=i-4)
{
	if(OAMYPos[i-4] != 0xF0) return i;
}

Where tiles is in this case (double, for NMSTL and without Yoshi) 0xD8, how many tiles are checked times four.

It's more like this:
Without Banzai Bill:
------------------XXXXXXX--XXX
With Banzai Bill:
--ZZZZZZZZZZZZZZZZXXXXXXX--XXX


Don't you mean "i=i+4"?
Graph suggests OAM is used backwards, so it should indeed be i-=4.

But then it should be i>0, not i<tiles, so who knows. There is indeed at least one mistake somewhere.
<blm> zsnes users are the flatearthers of emulation
What's up with the gaps between sprites?
My guess: The graph is inaccurate, just like the code.

Unfortunately, I don't remember how things actually work. Go rip apart the NMSTL patch if you care.

(The clean ROM reserves five OAM slots for each actor, with a few actor types (for example Banzai Bill) being special cased to get more. It's fast, but pretty limited.)
<blm> zsnes users are the flatearthers of emulation
Does the person who wrote NMSTL still post on here? It's a pain in the butt trying to dig up other people's source codes and stuff.
Originally posted by Drex
Does the person who wrote NMSTL still post on here? It's a pain in the butt trying to dig up other people's source codes and stuff.

edit's Discord seems to be listed on his profile but I don't know if he'll just reply to ya out of the blue

Ask around the oldbies (Ersanio and such), maybe they can help you reach him

Maybe.
He could have gone the way of Roy and carol and become practically unreachable for all I know lol
HackPortsASM"Uploader"

i'd e-mail him, that's probably your best bet. he pops in every now and then but only like a few times this year
ask me if i give a f*ck...
I almost forgot about this:

https://www.smwcentral.net/?p=viewthread&t=79098&page=1

Whatever happened to the Supreme OAM handler?
Once upon a time I made my own OAM rewrite as well, but I never got around to fixing the original game's bosses and a handful of sprites I didn't personally use, so I never released it. It dynamically allocated spots so that priority could be more easily assigned and every slot could be used efficiently, with the downside of being a bit slow.

There's a lot of inertia with how the original game and custom sprites are written. Every sprite in the game hardcodes whether it will be writing to the upper or lower half of the OAM, and fixing that require editing every single graphics routine. The commonly used NMSTL patch just cleans things up for sprites that use the upper half (ie, most enemies), but doesn't do anything for the lower half. So we have inefficiencies like the block of 0x20 tiles being reserved for so-called cluster sprites when they were used in something like 3 levels in the original game, and mistakes like the spinjump hitspark's lower right tile often being overwritten, all preserved even in modern hacks.
Does an OAM map exist?
Originally posted by Drex
Does an OAM map exist?

Here you go.
Doesn't look finished. What goes into the "extended sprites" and "undocumented sprites" places?
"extended sprites" are things like enemy fireballs, hammers, and other projectiles, along with iirc things like smoke puffs and stars when an enemy is spinjump'd. A lot of things.

The "undocumented sprites" at the very bottom of the list is the area that enemies use for their main graphics. Koopas, goombas, platforms, etc. I don't remember what the other two blocks of undocumented are.
@Old Topic/Thread title:
SMW Hacking is doing nothing to the Homebrew scene, and it's probably helping it too.

@Current Topic:
Basically what Kaijyuu said.
Hi, I'm a signature!
Hack Thread
Hack Testing Status: Available.
Layout by Koopster.
A fast way of organizing sprite priorities is by putting sprites on a linked list, and using a routine to arrange them in the correct order. I don't know how much work that would take getting it to work on SMW because different objects have different drawing routines.

Is there any common sprite drawing routines in SMW, or is every single object different?
Some of the enemy sprites share drawing routines (the single and double tile ones), but the rest are all hardcoded based on the needs of the object.

There are some shared subroutines (again, mostly for enemies) like the one that determines if the object is too far offscreen to draw in the first place, and the one that provides an OAM index to write directly to the OAM mirror (index is 8 bit, and determined by a simple algorithm that depends on the level header).
A linked list proper is right out because SMW stores sprites interleaved in memory. You can extend the concept, with a few wrinkles, to an array of sprite indices or something though.

A bigger issue is that a number of things depend on sprite processing order in a weird way, like the behavior of enemies killed by shells. So you can't just totally willy-nilly change the processing order. But I'm not sure how big of a deal this is to non-speedrunners.

Additionally, sprites can just kill themselves and others without telling anybody and they don't really have to call a routine for it or anything, so you might end up with some kinks regarding sprite spawning/despawning. In particular a sprite that kills itself and the next sprite on the priority list on the same frame should probably work.

Most sprites have separate drawing routines but in practice they mostly just plop a bunch of tiles into the OAM in a nice contiguous block (with a few exceptions that a priority thing would probably want to change anyway). So even though you can't nicely extract a graphics routine from most of them it's not really a huge impediment.

I don't know exactly what you'd want this for in SMW though. Better climbing net sprites? There aren't many priority tricks to be had in SMW and most of the good ones you can do by having one sprite draw its own tiles in priority order. It's not like it's top-down.
Link Thread Closed