Banner
Views: 932,821,194
Time:
11 users online: Dippy, Donb_Rgas, FrozenQuills, Fry, JupiHornet, KaidenThelens, Lespna1, morisot, PastaNoSauce, RollingRigatonis, ZMann - Guests: 104 - Bots: 254 Users: 52,067 (2,105 active)
Latest: Graul
Tip: Check this thread to find extremely useful diagrams and data.
Not logged in.
nmstl for fastrom
Forum Index - Sunken Ghost Ship - C3 Museum - Summer 2021 - nmstl for fastrom
Tags:
Pages: « 1 » Link
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
Originally posted by Ragey
But if you call RIGHT NOW, I will also throw in dynamic allocation for cluster sprites and a few OAM bug fixes.

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?

--------------------
Avatar by Magi!
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
I literally just used the old NMSTL patch in a hack.

If I changed it to FastROM and patched this to it, would it break? Or do I have to start fresh?
- Signed, LuigiTime
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! #smrpg{:O}
Originally posted by Anorakun
Also, Fastrom gang RISE UP! #smrpg{:O}

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?
Originally posted by Katerpie
By the way, does it break with any version of NMSTL previously installed?

Originally posted by LuigiTime
If I changed it to FastROM and patched this to it, would it break? Or do I have to start fresh?

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

Originally posted by Koopster
Question though, any reason this is particularly aimed for FastROM users? Does this not work well outside of FastROM?

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.

Originally posted by Anorakun
Every custom sprite that I have inserted in my hack, I would need to do the OAM stuff?

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

Originally posted by anonimzwx
This has priority system like sa1 system?

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.
Originally posted by Anorakun
Fastrom gang RISE UP! #smrpg{:O}

#smrpg{:O}


finnaly nmstl gets some sort of upgrade. ありがとう ragey
Originally posted by Ragey
I don't know why you'd ever use SlowROM over FastROM.

I was half-expecting this answer. Hard agree :P
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.

--------------------
Avatar by Magi!
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.
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?
Originally posted by MarioFanGamer
It would be cool to have a more automated system, though (after all, almost every sprite uses FinishOAMDraw)

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

Originally posted by MarioFanGamer
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.

This is out of scope for this patch.

Originally posted by imamelia
Will you submit it to the section?

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

Originally posted by imamelia
(suggestion on extra feature)

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.

Originally posted by KevinM
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?

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.
Pages: « 1 » Link
Forum Index - Sunken Ghost Ship - C3 Museum - Summer 2021 - nmstl for fastrom

The purpose of this site is not to distribute copyrighted material, but to honor one of our favourite games.

Copyright © 2005 - 2021 - SMW Central
Legal Information - Privacy Policy - Link To Us


Menu

Follow Us On

  • YouTube
  • Twitch
  • Twitter

Affiliates

  • Super Mario Bros. X Community
  • ROMhacking.net
  • Mario Fan Games Galaxy
  • sm64romhacks