nmstl for fastrom

This is a replacement patch for NMSTL aimed at FastROM users. It offers the same benefits as NMSTL while running in the same complexity as the vanilla routine.



But if you call RIGHT NOW, I will also throw in dynamic allocation for cluster sprites and a few OAM bug fixes.
No longer will Mario be decapitated while carrying a MechaKoopa.
Nor will poor Yoshi be assigned an equally cruel fate when he steps into Lakitu's cloud for a ride.

Read the readme. Most notably, you will need to provide the OAM size of your custom sprites to the patch for it to work with custom sprites. Which is kind of a hassle, but probably worth the performance gains.

With the advent of MaxTile (and the fact that SA-1 is fast enough to run the slow NMSTL code anyway), this is probably not too useful for SA-1 hacks.

Click here to be rickroll.. err I mean click here to view the patch

CALLING IT
I'm actually surprised that fixes for those aren't available (afaik). I recently found the cause of the mechakoopa bug and it seems not so hard to fix (just a matter of finding room in OAM which to be fair can be a little annoying in SMW).

NMSTL has always been known for being slow so hooray for speed!!!! Question though, any reason this is particularly aimed for FastROM users? Does this not work well outside of FastROM?

Very nice ragey, i don't use lorom/fastrom a lot, usually i use sa1, but i am pretty sure that this will be useful for a lot of people.

This has priority system like sa1 system?

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

Youtube
Twitter
SMWControlLibX GitHub
My Discord Server
Snestorage where you can download my resources

I do wonder. Every custom sprite that I have inserted in my hack, I would need to do the OAM stuff? If so, well, that's a shame, but hey, for people who love the vanilla sprites, it will be great. Also, Fastrom gang RISE UP!

---

rises

Hey, this is a cool replacement patch. Now I no longer get to experience slowdown with a certain number of sprites in my upcoming hack!! I actually don't mind if I have to provide the OAM size of my custom sprites, so long as the performance is significantly improved.
By the way, does it break with any version of NMSTL previously installed?

---

Você sempre alegre e eu sem razão
Estou dividido entre o amor e a paixão

You can try it and it will probably work, but I would recommend against hacking like that. Best to uninstall NMSTL first.


This works everywhere, but SA1 is fast enough to run NMSTL anyway and I don't know why you'd ever use SlowROM over FastROM.


Yes. But it doesn't involve writing asm, just providing the size of sprites to the patch.


No priority system. I do have a private build that does that, but I don't know if I want to release and (more importantly) support that one. It's a bit more complicated to set up and use. I want this patch to be almost as simple as NMSTL.

It's always cool to see an index based OAM system just so you can replace current NMSTL with its "search through every OAM slot until you find a free one" system. It would be cool to have a more automated system, though (after all, almost every sprite uses FinishOAMDraw).

Being able to use the full range of OAM would be even cooler but that one requires a rewrite of every graphics routine including of every vanilla sprite.

finnaly nmstl gets some sort of upgrade. ありがとう ragey

I was half-expecting this answer. Hard agree
A shame many people don't know about FastROM. It should be an immediate mention in our earliest tutorials, or just be enabled in Lunar Magic by default.

This is gonna be so incredibly helpful for people working on non-sa1 roms
NMSTL allowed to have more sprite tiles but at the cost of more processing power causing lag in certain situations but this nukes that problem altogether, super cool

Nice. I was just thinking about sprite memory and how the one problem with the regular NMSTL patch is how slow it is. Will you submit it to the section?

Also, something that might be useful to add is the ability to make a sprite change how many tiles it uses if a certain flag is set (such as bit 5 of the second extra property byte, or if the acts-like setting is 85). If that is true, then it uses an additional RAM table (such as $7FAB7C,x or something) to indicate the OAM size. It would mainly be useful for sprites where there is a significant difference in how many tiles they draw depending on their settings, such as the YI Ball 'n' Chain (which can either draw 12 or 24 tiles) and certain "combined" sprites (for instance, if I make all of my projectiles one sprite, and most of them are a single tile but one of them draws 6). I could add it to my own copy easily enough, though, if nobody else would need it that badly.

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

I'm working on a hack! Check it out here. Progress: 64/95 levels.

This sounds very promising, as normal NMSTL is very prone to causing slowdown when there's a fair number of sprites spawned. I will probably try to use it instead of the other one for my own things, and having to insert the OAM size for custom sprites isn't a big deal anyway (just a minor annoyance). As MFG mentioned, this could be maybe automated by hijacking the FinishOAM routine, although some sprites may not use it (or, for example, the routine that draws wings has its own "finish OAM" code, which I guess could be hijacked as well). Another thing to keep in mind is that PIXi now includes its own optimized version of FinishOAM, so that would need to be updated as well.

Found a small issue: when pressing a P-Switch, one of its halves may disappear. This is because the switch uses 2 tiles instead of 1 when in the pressed state. Changing $04 to $08 for entry $3E in the .StandardSpriteTileCount table fixes it.
Also I have a question: if this is specifically made with FastROM in mind, why is !long = $000000? Wouldn't $800000 make more sense?

I like this idea, it might be worth further exploration.


This is out of scope for this patch.


Probably not. It's easier for me to maintain via Github.


It's probably easier to have sprites with such a large difference between its oam sizes manaully increase the oam allocator. The base patch already does this for Lakitu's fishing line, if you need an example.


Good eye, I'll fix it some day.
And about the second point, you're probably right in that I should add rom type detection to the patches.

Thanks for the comments, by the way.