Language…
11 users online: AbuseFreakHacker,  BeeKaay, ben15420, Gorry, Green, Michel2023, OrangeBronzeDaisy, Ray Hamilton, Rykon-V73, ShoopDaWhoop,  YouFailMe - Guests: 259 - Bots: 609
Users: 64,795 (2,369 active)
Latest user: mathew

Sprite Tool Super Delux [Beta] (aka when Jack is bored)

Firs things first, this is NOT Daiyousei!!!
This is something I started back in summer when progress on Daiyousei came to a standstill with nobody even talking in the forum for a long time. Of course, 3 days into the projects and progress on Daiyousei resumed, so I kinda felt cheated here #smw{>_>}.
Anyway, after 1 week, the basic coding was done, with only testing and bugfixing left to do. I then kinda got stuck on sa-1 which was resolved a couple months back. So I figured, might as well finish this up for C3 if nothing else... except I then got stuck on removing sprite_tool code, because that thing is a coded as a fucking mess...

So er... hi there and welcome to my booth... I guess.
This is my quick attempt on a new sprite tool along with some of my trademarked crazy ideas that people may or may not care about. So, here's what's new:

  • Softcoded
    The applied asm file is available for editing. The tool only generates the binary tables that are included by the asm. So you can basically look at the code and edit it (to some extend) as you like.
  • Dynamic SA-1 support
    Kinda goes hand-in-hand with the softcoded part. The tool doesn't really care if the ROM is SA-1 or not. HOWEVER, there is an asm file with all sa-1 defines that will be default included in every sprite, so you don't have to stick that annoying read1() check for sa-1 at the beginning of every sprite. For all sprite relevant addresses, there exists a define. More info to that in the readme
  • GPS Interface
    I basically copied over the interface from p4plus2's GPS for 2 reasons.
    1. It's simple, easy and comfortable to use.
    2. It's a lot more comfortable to work with multiple tools if the all got the same interface to work with.
  • Shared Routines
    Again, kinda goes hand-in-hand with the GPS interface, so why not copy that over as well? I mean that quite literally, that is 99% the code from GPS copied over but as a friend of mine likes to say "Why bother to reinvent the wheel".
  • Asar Only
  • So yeah, this is one thing that's probably gonna be a problem for many people. The tool only allows asar coded sprites... no more TRASM. That is again for 2 simple reasons. 1. TRASM sucks and 2. I'd have had to literally overthrow the way my entire code works to include this shitty assembler, so no thank you.
  • Sprite Tool support
  • The tool basically works the same as sprite tool and can be applied on top of a ROM that used sprite tool before. It will of course remove all the sprites though.
  • Per Level Sprites
    So here it is, the real reason why I even got into this in the first place. My stupid crazy idea. I noticed we have a lot of things that run on a per level basis. With Vitor's uberASM tool now even NMI. So I thought to myself, "Why not sprites?" and with that, the idea was born.
    This tool "sacrifices" 16 global sprite slots and turns them into per level slots. Meaning, you can assign the same sprite number to different sprites depending on the level. Sprite B0 could be a thwomp in level 105 and a hammer bro in level 106 or a reverse boo in level 107.
    The 16 slots from B0-BF can be freely assigned across all $200 levels.
    Likewise, you can also have a shooter, that shoots sprite B0, which will spawn a sprite depending on the level.
    I figured this could be especially neat for collabs and such.
  • Beta
    I didn't get to test the tool up and down and against everything that could go wrong yet... mostly due to the lack of existing sprites for sa-1 and my lack of motivation to convert them all.
    I included trashkas (trasm->xkas converted) and Vitor's sa-1converter in the ASM folder if you wanna try it out.

Pointless Screencap:


So yeah, without knowing when Daiyousei is completed, I don't know when this tool becomes obsolete. Could be next week, or next year, who knows...
Lastly:
See the readme before you ask questions~ #wario{X_X}

[Download]
[GitHub]

Anime statistic on MyAnimeList:
400 animes completed ✓
6000 episodes completed ✓
100 Days completed ✓
... what even am I doing with my life?
This actually sounds really nice seeing as Daiyousei might be a ways off and sprite tool has been needing even a simple upgrade for years
This looks awesome!

Could someone please explain to me the advantages of having these sprites per level concept? I read the description, but don't get it.

Like when I insert a sprite currently, can't I put it in ANY level already? So what's the point. Do we get more sprite slots or does it save space.

Anyway keep this up I would like to see this in the tools section for sure.
This looks really cool, though I'll wait for more compatible sprites to be released before using it.


Originally posted by Final Theory
This looks awesome!

Could someone please explain to me the advantages of having these sprites per level concept? I read the description, but don't get it.

Like when I insert a sprite currently, can't I put it in ANY level already? So what's the point. Do we get more sprite slots or does it save space.

Anyway keep this up I would like to see this in the tools section for sure.


Well basically, they stop rarely used sprites and gimmicks taking up space in the sprites list. For example, in the existing sprite tool, a sprite slot might be used for an enemy or boss only present in a single room in the game. So if you have a lot of levels, this fills up the list really quickly.

In this tool though, you can make it so the same slot works differently based on what the level ID is. So for example, every boss could share the same sprite slot, except with the actual sprite differing based on the ID of the level/room. That way, your global sprites list isn't filled up with custom bosses and projectiles you only need to call once.

Heck, if you need a good example of a game where this mechanic would be really useful, look at this level from Brutal Mario:

https://www.youtube.com/watch?v=NcLJQpLc9og

Every single enemy here is technically the same sprite (kcastle.asm), with the effect being set based on the level ID and screen ID.

With per level sprites, carol could have made each enemy and effect its own seperate sprite, using the same few sprite slots differently per room.

It's also really useful for collab projects like SMWCP2, ASMT, Morton's Empire, VIP 6/7/whatever, etc, since it means levels made by multiple people (like the Bowser's Castle equivalent) can allow them to use their own seperate sprites and gimmicks in their 'rooms' without affecting the rest of the game.

Either way, kudos to JackTheSpades for this tool, it seems really useful and just what people with heavily customised hacks need.
For gaming news and Wario discussions, check out Gaming Reinvented and Wario Forums respectively.

As for Mario's Nightmare Quest? Well, it's currently on Fusion Gameworks, ROM Hacking.net or the GCN at the moment.
this one tool



EDIT: I have an important question though. How are these awesome per-level sprites supposed to work with SpriteTip, or anything that creates in-LM content for them ?
Cool a new sprite tool. Really like the new features

RIP spritetip though
Originally posted by Mathos
image


This pretty much sums up what I thought when I saw this thread.

I still need to try out myself, maybe after C3.
Yoshiatom's Post
I must admit this seems pretty cool considering Daiyousei is nowhere close to release, and that sprite tool hasn't had an update / replacement in years, but there a couple of questions I have about the Per Level Sprites You've been so excited to announce;

Mainly, how does it effect space in the ROM? Like, is having single level sprites space effecient or is there possibility of it using enough space so that normal sprites couldn't be inserted? If so it would make the whole thing kinda moot.

Secondly, how would this work with SpriteTIP or LM's Custom Sprite list? (I know this is in beta, but still...)

And finally (this goes for all the tools features in general), do you plan to get any of these features into Daiyousei? Because if not I fear it will be Sprite Tool VS Tessera all over again.

I'm probally not as excited for this as most ASMer's are about this, but this does seem like a direct improvement and I hope it will... you know... improve stuff... #smw{>_>}

YOSHIATOM DOESN'T KNOW HOW TO END POSTS

Layout by Koopster!

<DeputyBS> I knew it
<DeputyBS> alcarobot is taking over the world through his truck dealership franchise
SOMEMTHING I ALWAYS NEEDED!!! THANK YOU!!! #smw{:D}
what is a lunar magic and can i eat it
Originally posted by yoshiatom
Mainly, how does it effect space in the ROM? Like, is having single level sprites space effecient or is there possibility of it using enough space so that normal sprites couldn't be inserted? If so it would make the whole thing kinda moot.

Dunno if I really understand this question. The tables for the sprite data take up some space but whether or not the sprite takes up space and how much entirely depends on the sprites and how many you insert.
You're gonna get into space issues if you actually use all the now available sprite slots, simple because that would be so many sprites that you probably run out of space for them. Say your ROM has enough space to support 100 sprites, then it doesn't matter if you insert all of them as global sprites or per-level ones.

I guess something I could do is optimize the tool to not generate the tables if they are unneeded, thus saving some space. There is a lot of stuff I could add but for starters, I wanted to see general reception of the tool before I went into full on optimization mode.

Originally posted by yoshiatom
Secondly, how would this work with SpriteTIP or LM's Custom Sprite list? (I know this is in beta, but still...)

Obviously and unfortunately, no.
Since this is kinda a thing I just came up with, LM doesn't support the custom list with name changes depending on the level. Of course, you can still use custom display and add sprite B0 to the custom list, just not with any specific names. Like, "Custom Sprite B0" would work, but if you want the name to be "Thwomp" for one level and "Hammer Bro" for another, that's gonna be a problem.

Originally posted by yoshiatom
And finally (this goes for all the tools features in general), do you plan to get any of these features into Daiyousei? Because if not I fear it will be Sprite Tool VS Tessera all over again.

I'm not really in charge of Daiyousei, STSD is open source so they can always look it up if they want to implement it.
That said, if Daiyousei is ever finished and actually implements all the stuff that is being talked about, without the need to recode every existing sprite, then there will be no need for this tool at all. Daiyousei would be superior, period.
The whole thing with Tesserar vs Sprite Tool, as far as I could tell, was that Tesserar, while enabling new features, had a lot of bugs and also required sprites to be coded differently from sprite tool ones, which in turn caused a lot of people to now want to use it, since there weren't that many sprites available in the first place.
So it's entirely up to Daiyousei if it will fall into the same trap, or if it will let sprites keep the same format for backwards compability.

Really, the main reason I had for creating this was
A) A version of sprite tool that is more comfortable for developers (seriously, the existing one is a bit of a nightmare)
B) Easier to make custom collabs, as you can just use a handful of common global custom sprites and then have level specific ones for the individual levels.

Case in point, you can completely ignore the whole deal with the level specific sprites and just use slots 00-AF as you always have. That's still 176 slots that can be used just like the old sprite tool (minus TRASM)
Anime statistic on MyAnimeList:
400 animes completed ✓
6000 episodes completed ✓
100 Days completed ✓
... what even am I doing with my life?
Fanatical like a Demon
Dude this is incredible... o_o

I just hope I can get my already custom sprites transported/converted over with the same sprite IDs I already have them in. This is really incredible and hopefully it won't be a hassle taking them to sa-1 as well. Props man!
Major thanks to Suika Ibuki for layout!
I'm open for music requests, just DM me on discord and we can further discuss there.
SMAS Soundtrack Status: 100% finished
YI Soundtrack Status: 100%
YI Unsampled Soundtrack Status: 100%
NSMB Soundtrack Status: 7.89%
Killer Instinct Soundtrack Status: 14.63%
SPC Thread
From our family to you, keep your pants dry, your dreams wet, and remember, hugs not drugs.
This is like the best thing ever. I know the main feature is supposed to be the per level sprites but honestly what puts this on the radar for me is the editable .asm files, complete with defines and everything! That's about as convenient as it gets to be honest.

Edit: shared routines function doesn't seem to actually work. The tool wants me to put the "routines" folder in the same folder as the tool but also in the "asm" folder(?) what am I supposed to do? Are you required to specify all the paths?

Edit2: shared routines seem to work when you specify the path, but only if that path is "asm\routines". You should make it work by defautl though. Still, sublabels don't work for some reason?

This throws an error, saying that the .NoContact label doesn't exist. That's just one example, I tried inserting a sprite and it gave like 7 or 8 errors like this. It's a sprite I've inserted with asar previously with no problem so I don't get why it doesn't work now.
Code
		LDA $7497
		ORA $787A
		BNE .NoContact
		JSL $00F5B7

		.NoContact


Edit3: When you use the tool for the first time it creates a file called shared.asm, containing a bunch of macros for calling shared routines. It creates it in the same folder as the tool but complains about not finding it in the "asm" folder. Are you supposed to have to copy it there yourself?

Edit4: It seems calling a shared routine interrupts sublabels by placing a new main label. That's... quite frustrating.

Edit5: Finally got it to insert a sprite but it broke the ROM. My ROM is pretty heavily altered from vanilla smw, admittedly. Overall I think(?) this is a pretty good tool, especially if you update it.

allow shy guy emojis in post footers you cowards!
Native SA-1 sprite support is probably what I'm most excited for here, converting everything for every single sprite every time got kind of annoying.
Are you going to submit this to the section when it's been tested more? Even just replacing the old one seems like it's long overdue at this point.
Your layout has been removed.
seems to work fine after moving some files around, but it keeps causing nested RATs 🤔
Other than that cool beans I don't really need to modify the SpriteTool asm but it may come in handy sometime.

e: I had to port but it works now so 👌👌
but please replace GetDrawInfo and SubOffScreen
I don't seem able to compile the source code with make.bat, it throws this message:

sprite.cpp: In function 'int main(int, char**)':
sprite.cpp:675:52: warning: comparison of constant ''\"'' with boolean expression is always false [-Wbool-compare]
if((ROM_name[0] == '"' && ROM_name[length - 1]) == '"' ||

It generates an .exe, but I'm afraid of using it.

All I want to do is to move the asm/ directory to sprite_tool/.

I tried with the original sprite.cpp file just in case I messed something up with my sprite.cpp, but that still happens.

Any help would be appreciated.
Hey, I think that this is a great (although somewhat confusing) tool which will certainly help people out. I'm trying to use it in my ROM, but I had some difficulties with it, like whenever I try to insert the sprites in my list.txt file, it just hangs at the /routines section and doesn't do anything.
I'm unsure if I'm doing something wrong since I'm just typing "stsd.exe rom.smc" and I have my list text file properly set up.
Mind helping me out with this?
I have a DeviantArt, if you do want to see my art on there. I don't really visit it much now, though.