The Overworld Design Contest ends in
Views: 904,623,786
24 users online: AmazingChest, AyGaAlPa, Cal-of-Gearva, chickaDEE Magazine, fztotheggg,  GlitchCat7, gui, JokerGamerOk,  K.T.B., KatMakes, Kinkerton, le4che, LordDarkScythe, Murphmario, NGB, Nouie, Nowieso, Retro Master HD,  Sayuri, sipoliv, StackDino, Taker259, TruffledToad, wulv257 - Guests: 36 - Bots: 79 Users: 50,717 (2,109 active)
Latest: Lebokadneza
Tip: Make sure your overworld's aesthetic, and the levels within, are coherent.
Not logged in.
No More Sprite Tile Limits
Forum Index - SMW Hacking - SMW Hacking Help - ASM & Related Topics - No More Sprite Tile Limits
Pages: « 1 2 3 4 » Link - Thread Closed
After much trial and error, I have managed to re-program SMW's sprite tile allotter, and basically eliminated sprite tile limits (per sprite) and the need for "special allowances" defined in the sprite header setting. Instead of allotting a certain number of tiles to each sprite, each sprite's tile index in the OAM starts right after the end of the last sprite tiles in the OAM.

Since for some reason yoshi doesn't work right otherwise, he will always get the first two slots. This also fixes the annoying priority glitch when yoshi goes behind sprites and mario goes in front, such as with the arrow lift or other ridable sprites.

This will also allow more tiles for custom sprites, so custom sprites with more than 6 tiles will be possible without special allowances. Special allowances for certain sprites defined in the sprite header also limit the number of sprites of that type that can be on the screen at one time usually to 2 or 1.

I probably won't make this always in effect in the ROM, rather there will be code inserted with an xkas patch (same type of patch as the dynamic sprite patch), and then a generator that sets a flag that activates this.

Also, the blowhard and goonie now work without header setting 0E

Here are some examples of a few things that will glitch without this patch:

There is, however, a small chance that this will cause a major glitch somewhere else and can't be used at all, and can't be released, but it's most likely that it will be released within the next few weeks, while I test many different sprites with this, and make sure there aren't any noticeable glitches.

EDIT: and those screenshots were taken with normal sprite header setting 00

EDIT2: just so you know, this does not have anything to do with the number of enemies on-screen at one time, but rather the main purpose is to allow "bigger" custom sprites (LM) and provide a more efficient method of handling sprite (hardware) tiles.

known glitches:
- slightly slows down game if there are too many sprites
- doesn't load very first frame, this can be fixed by making the routine check the first block at the top left of the screen instead of a generator. I don't mean custom blocks, I mean copies of the block (usually #025) that would originally be there would have their map16 numbers entered into the patch when it's patched. The issue with generators setting a flag is that they seem to be processed after sprites are processed.
- dynamic sprites seem to glitch (probably because of the address I used for the flag)

EDIT4: I'm just going to make it use the (almost) unused sprite header setting 10, which appears to be an exact clone of 00, used only in bowser battles. The bowser battles seem to work perfectly fine with sprite header setting 00, though.

EDIT5: I have the patch ready for public test! Download see next post edit
It overrides sprite header setting 10, a clone of 00 only used in bowser battles for some reason, so you must change the bowser battle sprite header setting to 00.

EDIT6: Here's the final patch code as of now: Link to post
Interesting. Most interesting.
smwedit, your a wonderful smw hacker.
And I think more people could learn from this work and stuff.
Truly an inspiration to learn how assembly works and the snes' programming format.
Miyamoto would be impressed by something like this :)

I hope you will be able to fix the glitches because this can open up many possibilities in sprite-making.

Your layout has been removed.
Wow, dude... Your ASM skills cure cancer. :D

This is the BOMB... I can't tell you how aggravating the Sprite Memory limitations are at times, especially when I'm trying to work with those Turnstyle platforms... Simply amazing. I don't know what else to say. :)

How did you figure this out, though? I can't imagine how difficult a puzzle like that would be... You just familiar with the SMW engine is all?

It's me!!

High on life is the best high.
I want that! @[email protected]
Sprite Memory being a thing of the past is my everlasting dream...

It's not even close to Halloween, and already Christmas Sales are starting early!
Originally posted by Amanda
I want that! @[email protected]
Sprite Memory being a thing of the past is my everlasting dream...

I never had problems with sprite memory before, but I want to make a barrage of enemies in my dance club level >=D
Whoops, said too much.

Your layout has been removed.
Wow, smwedit, this is incredible!

...and it would be even more incredible if it could work with absolutely any regular or custom sprite, I once attempted to use 2 of the non line-guided platforms that move forever right when you jump on them (unsuccessfully though, w/o this new concept, only one is usable at a time AFAIK) on a level, but here's hope this works out well.

'crosses fingers'
Now, all we need is dynamic sprite sets.

...for those who don't know what that is:
The last three sprite files start out empty. When a sprite enters the screen, it reserves X tiles (16x16?) in the sprite set (where X is the amount of tiles it will use). The sprite then loads the necessary graphics into that space. Whenever the sprite leaves the screen, its reserved graphics space is marked as free. This removes the problem of sprites from different sprite sets being incompatible due to tile collision and stuff.

Also, if you, for some reason, want to make a sprite with a shitload of different frames, you don't have to fill the entire graphics space with different graphics. All you have to do is reserve room enough for a single frame, then, each frame, upload the necessary tiles for that frame. (If that causes slowdown, one could also reserve enough room for, say, four frames and load the graphics only once every four frames.)
The wheels of progress continue to turn. Obstacles that once seemed absolute now waver and fade.

In other words, great work! I can't believe my eyes!
Yay! I never thought that something as important as this would come so soon... :o

This could be veeeeeeery useful. Furthermore, if someone makes Smallhacker's idea, then we could basically use any sprite anywhere! :O

Your layout has been removed.
That is awesome - good luck with the ongoing testing. I hope this proves to work out well. I think the xkas patch + generator is probably the way to go, at least for the time being.


[?] Miscellaneous Helpful Hints
If I moderated your hack, there was apparently a 90 percent chance it was rejected.
Great! If you're successful with this, I might start working on custom sprites again.

I already have one idea up my sleeve:

@ Smallhacker: Your idea seems very reasonable, as Mario and the animated tiles already work similar to that.


Wow, amazing!
I can't wait to have 5 Banzai Bills on screen at once!

This is so helpful that I can't even find words to describe it. :o
Neat. This gives me an idea or two for a new sprite which would have been stopped by the sprite per tile limit. I'm still wondering why the original chose to do it such a way (there must be a reason) since the way you seem to be doing it now is the simplest and doesn't put strict limitations.

Smallhacker: Dynamic sprite sets sounds difficult to implement in standard sprites, unless a common routine they all always access has a hack to account for it. I can see the FinishOAMWriteRt having some sort of hack that checks if a sprite is standard and if a GFX set is not yet loaded, it is loaded into vram according to a predefined table. For custom sprites you can just pass the routine a poitner to a table with whatever details are needed for the allocation / upload. There's still the matter of compression (does LM compress GFX sets?) and the bottleneck of vram uploads. 2kb was the absolute max I could push with dynamic sprites, so there needs to be code to handle cases where more than half an exgfx file needs to be moved.

You describe the way current dynamic sprites function in the second paragraph, where a 4x4 tile slot in SP4 is reserved each frame by a dynamic sprite routine. With the upload routine I had a ROM -> RAM DMA per sprite into some unused RAM, then at vbl I had a 2kb transfer straight to vram since the code between transfers made the code break into active display (crash and burn).
Man, smkdan... I managed to read your entire paragraph, and then I felt my brain go numb. XD

I wish I understood this stuff like you guys do... You make me feel so insignificant. All three of you. *points to smkdan, smwedit and Smallhacker* XD

It's me!!

High on life is the best high.
That sounds indeed incredible. Since it seems to be possible now, I also wonder why Nintendo choosed to put up quite a few different settings for different sprites, if you just could have one setting which works for all sprites.
Anyway, that's damn nice. I never really had problems with using Banzai Bill and Big Boo so far, but I always had trouble with using the platforms Schwa was mentioning and the bubble in the ghost houses. I think in their current state they are very hard to implement if you want something interesting out of it (that counts especially for the bubbles, I think), but with the Limit gone, that could change a great deal.!


Originally posted by smkdan
Smallhacker: Dynamic sprite sets sounds difficult to implement in standard sprites


There's still the matter of compression (does LM compress GFX sets?) and the bottleneck of vram uploads.

Yes, it would be extremely painful to implement for standard sprites. I doubt that there's a relevant and common enough routine to use... ...or one could simply make a hack only containing custom sprites.

As for the compression... Well, one could simply store the enemy graphics uncompressed. It would waste tons of space, but would speed up things. As for the VRAM uploads... Hm... I wonder how they did it in, for instance, Donkey Kong Country (which uses dynamic sprite sets). ...maybe that's worth looking into.

Also, one could also make the most common sprites (possibly the standard sprites) "static". If one makes the two first sprite files static and the two last files dynamic, it would speed up things in more than one way... Less loading necessary and less data to upload to VRAM.
Nice. Very nice.

the good thing is this is a huge advancement and solves a major glitch.

the bad thing is you guys are gonna face some bad-ass levels in the last world of my hack.

Congrats, smwedit!

also, what's the glitch, what does it do..?

<TLMB> I use YY-CHR to edit DNA
I have the generator and patch almost ready, but I need some beta-testers. You must know how to use xkas and sprite tool. PM me if you would like to beta-test. I will start sending it out some time tomorrow.

Main glitch: it slows down the game if there are a lot of sprites on the screen at one time, especially if they are cpu-intensive like the wild piranha plant and blowhard because they are dynamic sprites and they also have to do lots of math.
Pages: « 1 2 3 4 » Link - Thread Closed
Forum Index - SMW Hacking - SMW Hacking Help - ASM & Related Topics - No More Sprite Tile Limits

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


Follow Us On

  • YouTube
  • Twitch
  • Twitter


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