11 users online: Boosius, codfish1002, Hwailaluta, Jukeboxi_, Mapping_bl, Noob, pakkie, pnaha, worldpeace, wye, Zavok - Guests: 62 - Bots: 315
Users: 55,705 (2,320 active)
Latest user: nigelreg

PIXI v1.2: Some Sprite Insertion Tool of Sorts

You could always just make the necessary files (.ssc, .mwt, and .mw2) manually. I've always done it that way.


I'm working on a hack! Check it out here.
Yeah, I think PIXI even supports command line options for appending those to the ones it generates automatically, which would be handy here.
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
Ok that's good news. Thanks for letting me know. I mean could upgrade to 64 bit, I'm not sure if it means reinstalling a ton of crap and slow it will be. It's not something I'm interested in for the moment. I'll hang in and use Sprite tool for now, and if the sprites arnt updated yet this summer I'll consider the 64 bit version of my OS. Thanks for clearing this up for me.

Edit: I can do it manually? Is this hard process? I don't intend on having a ton of custom sprites. I would consider doing this if the process could be explained.
Thanks, that actually seems preety straightforward.
In case anyone else gets in the same boat save yourself time and do manual thing mentioned above. After upgrading to 64 bit Linux installing wine, latest .net and mono, I was still unable to open the CFG editor.
After using PIXI 1.2.1 on a SA-1 ROM any level with more than 84 sprites (which is the limit without SA-1) will crash after that many sprites have been loaded. This doesn't happen if I only use SA-1.

Is this a bug or am I doing something wrong?
Version 1.2.4 Released, courtesy of Tattletale. It got Lunar Magic support and many bug fixes.

Change log:
  • (Tattletale) Recompiled with new g++. Added namespace as a fix for the macro sublabel shenanigan.
  • (Tattletale) Updated Asar dll to 1.61.
  • (Tattletale) SA-1 16bit sprite data pointer support.
  • (Tattletale) FastROM pagination sprite data pointer support.
  • (Tattletale) GetMap16 and ChangeMap16 were replaced by Akaginite's implementation. Added support to new LM.
  • (Tattletale) Sprite 7B is entirely reserved to LM, so nothing inserted in the 7B slot will work as a custom sprite.
  • (Tattletale) SubOffScreen updated to consider new LM settings.
  • (Tattletale) Fixed a bug with SubOffScreen, it would run all checks even when the sprite is on screen.
  • (Tattletale) Aiming routine update to use Akaginite's version.
  • (Tattletale) All routines were updated to use ?+/?- instead of +/- to avoid redefines outside the routine context.

Happy hacking. If you see any new bug on this Sprite Tool, let me know or Tattletale. We will make this Sprite Tool reliable as Romi's used to be.
GitHub - Twitter - YouTube - SnesLab Discord
HUGE updates today!

Thank you for this!
My Youtube channel

Currently working on:
Project C

Finished project:
Well, I was sort of unaware of this thread. I don't really use the forums. But I will try to keep track of pixi stuff. Would appreciate if stuff were posted here, I will read them.

Anyway, new release.

Version 1.2.6.

Change log:
Version 1.2.6 (Dec 30, 2018):
-(Tattletale) Fixed an issue with ChangeMap16 in vertical levels.
-(Tattletale) Fixed an issue with GetMap16 in vertical levels.

Version 1.2.5 (Dec 29, 2018):
-(Tattletale) Fixed an inconsistency I left in main.asm that would cause a half-state of the perlevel feature to be inserted. Without -npl this would cause the first shooter or generator to not spawn properly.
-(Tattletale) Perlevel sprite has been turned off by default.
-(Tattletale) -npl doesn't do anything anymore, but is still around so stuff don't break with it.
-(Tattletale) New flag -pl created so you can still use sprite perlevel feature.
-(Tattletale) Bugfix on the LM version detection code. Rude, rude mistake (didn't affect anyone unless you use lm 193 and 16x), unredeemable.
-(Tattletale) Fixed a bug in error handling for sprite per level below B0 or above BF.
-(Tattletale) CFG Editor now opens either cfg or json without changing file types in the menu (mask is *.json; *.cfg).
-(Tattletale) Fixed thwomp json mappings.
-(Tattletale) Donut Lift's code reverted. Now it should be working normally. I'm sorry I left a piece of test code there.

As you can see 1.2.5 and 1.2.6 are one day apart, so make sure to update your pixi! Got a report from worldpeace about these routines. It's fixed now.
Your layout has been removed.
I didn't post about .7 and .8 but here's .9
Consistency is the key :^)

Version 1.2.9

Version 1.2.9 (Feb 17, 2019):
- (Tattletale) Fixed a bug with the Star.asm routine (provided by Blinddevil, reported by Darolac).
- (Tattletale) Fixed a bug with ExtendedGetDrawInfo.asm (reported by Darolac, I think it was Sonikku who fixed this (?)).

Version 1.2.8 (Jan 20, 2019):
-(Tattletale) Fixed a bug with sprite data in sa1 not being displaced correctly. This would cause random sprites to spawn when extension byte was used (didn't happen every time). Also added some doc/comments to main.asm while I was at it.

Version 1.2.7 (Jan 13, 2019):
-(Tattletale) Routines ChangeMap16, ExtendedHurt, SubVertPos, SubHorzPos, SpawnSprite, GetMap16 and GetDrawInfo were updated so their top-most labels were removed and only sublabels are used within them to avoid issues with asar. Reported by DigitalSine.

Just another minor update for routines.
Your layout has been removed.

Many thanks, Tattletale. You're a hero to us all!!!

Links β–Ά Twitter ♦ Discord ♦ YouTube ♦ Steam ♦ Twitch

So, I noticed most people have no idea what's going on in these last few updates I made and I think some of those people should know what's going on, so I decided to sum everything up nicely so most of what has been changed and every new feature added to pixi will be listed in this post, plus a couple explanations to some of my decisions here and there.

Be aware that, unless you have TECHNICAL feedback - meaning it has to have programming/project management (as far as programming goes) backing - over the decisions I made, I will 100% ignore your post. I may touch the non-technical argumentation for some of the decisions I made, but mostly to drive my point home, they are not up to discussion, since they are not what I'm going for with all these changes.

Table 1938 has been changed to 7FAF00

This table is responsible for telling the sprite loader that a certain sprite died, has already been loaded or should be loaded by the game.

This change causes incompatibility between Romi and Pixi for slowROM/fastROM solutions (non SA-1 roms), because the new table addressing is now 24bits (long) instead of 16bits (word) and because converters have no idea they should convert this address to the new one. Most old Romi sprites, if converted to Pixi, are affected by this due to the fact that the old table is not initialized anymore and is basically untouched by the game, thus considered free. This happens because most of the old Romi sprites had their routines inlined in all sprites, which includes the routine that writes to said status table to despawn a sprite - the infamous SubOffScreen.
The SA-1 patch works the same way/does the same thing.

Just change whatever mentions to 1938 there are in the sprite to 7FAF00.

It might not work, because 7FAF00 is a long address and the table might be indexed by y instead of x and there's no opcode for long,y read/write. In that case, you will get an error and you should look for help, or fix it yourself if you know what you are doing.
Unfortunately, there's no way to predict how any of the SubOffScreens in those old sprites were coded, so there isn't a sane way of fixing them automatically.
I will probably make a compatibility flag so you can turn this off because a lot of people just can't handle this properly, or read about it to go as far as to figure out the issue is that to begin with, so there's that.
You could also go back to pixi 1.2.9. You will lose a couple new features, but it's not like they are in use.

Conversion tools should be updated to take care of this new address. Maybe I will update them myself later, maybe. Only issue with that is that I think the trashasm converter should't care about all that, so yeah.

Thanks to this change, now along with Pixi, slowROM/fastROM solutions (non SA-1 roms) now properly support 255 sprites per level, just like SA-1 does. So now it's safe to disable LM's warning regarding max sprites per level.

3 Extra bytes for shooters have been added

Pixi should've had this feature from the start, but hey! Now it's here.
Three RAM tables have been reserved for that, then being:
8 bytes each, first 6 digits are for slowROM/fastROM and the second 6 digits are for SA-1, separated by a pipe.

Quality of life defines added
Defines were added so they can be globally used around Pixi in order for Pixi defines to be more similar to the other tools'. Here are them:

And !1938 is now the same as !7FAF00, check out the "Table 1938 has been changed to 7FAF00" topic if you wanna know more about this.

Secret asm/extraDefines and asm/extraHijacks folders

I added two new folders, one so you can define and ship your own defines along your sprites (extraDefines) and another one so you can ship your own hijacks along your sprites (extraHijacks).

Everything inside the extraDefines folder (all .asm files) will be included in every sprite inserted by pixi.

Everything inside the extraHijacks folder (all .asm files) will be inserted after Pixi's main asm files have been inserted. You are responsible for keeping the free areas clean and stuff. This feature works essentially the same way patching something with asar does, so be very very careful about using it. It exists so inserting sprites that require patches is a little bit less annoying.

If you need to import Pixi's defines and whatnot to that extra hijack file, you would be doing something like this:
incsrc "../sa1def.asm"

For extra defines, something like this:
incsrc "../ExtraDefines/yourExtraDefine.asm"

Maybe at some point I automatically add those lines to every hijack file, but for now it has to be done manually.

MeiMei has been added to Pixi!

All in all this title says nothing, but it does a lot. MeiMei is a tool created by Akaginite to fix sprite data for levels after Pixi ran, in fact it is a wrapper for Pixi.

So from now on, Pixi fixes sprite data when you change a sprite's sprite data size configuration when said sprite is already being used inside a level.
Stuff like placing a sprite in a level and then right after inserting that sprite with Pixi, only to realize you borked your level/sprite data because that sprite uses extra byte won't happen anymore, basically. And now you have a certain degree of freedom to edit that configuration.

It should be working fine for both SA-1 and fastROM, but for some weird reason the current asar version used in Pixi (1.61) places Freedata for SA-1 in Freecode instead. It doesn't change anything, all that causes is that LM will move it back to Freedata once you edit a level that had it's sprite data remapped by MeiMei/Pixi.

There are several config flags for MeiMei, which are:
-meimei-off		Shuts down MeiMei completely
-meimei-a Enables always remap sprite data
-meimei-k Enables keep temp patches files
-meimei-d Enables debug for MeiMei patches - I recommend you turn this on if you wanna know what levels were edited and how.

n extra bytes for both shooters and normal sprites (actually 12)

From now on, Pixi supports sprite data size to be n. Sadly Lunar Magic soft locks sprite data to be 12 bytes.

The new extra byte system works differently from the old one, that doesn't cause any kind of incompatibility with sprites that weren't using more than the old extra byte limits (4 for normal sprite, 3 for shooters).

The new system works by using extra_byte_1,2,3 as indirect pointers to the sprite data itself. So for normal sprites from 5 onward extra bytes, the first 3 extra bytes will be used as an indirect pointer to the sprite data, starting at 1. For shooters, from 4 onward, same

Be careful when declaring 10+ extra bytes in the cfg/json format. Cfg format will expect hex numbers, json will expect decimal (when editing manually).

Exemple for sprites:
LDA !extra_byte_1,x
STA $00
LDA !extra_byte_2,x
STA $01
LDA !extra_byte_3,x
STA $02
LDY #$0B
LDA [$00],y

The code above would read the 12th extra byte for a sprite.

Exemple for shooters:
LDA !shooter_extra_byte_1,x
STA $00
LDA !shooter_extra_byte_2,x
STA $01
LDA !shooter_extra_byte_3,x
STA $02
LDY #$07
LDA [$00],y

The code above would read the 8th extra byte for a shooter.

So you could say that in this model, extra_byte_4 for sprites is a free table that won't get cleanups. I didn't add more ram for this feature because sprites already have a whole load of RAM reserved and they are mostly unused all the time.
If you in turn think you need more RAM, just use the extraDefines folder.

It can potentially be harmful for shooters, since shooters do not possess the same amount of free ram tables as sprites do.
But honestly, I think you should consider if it's really an issue (performance-wise), since to begin with shooters don't even have init pointers, they only have mains. If even then you think this model has a performance issue, use the extraDefines/Hijacks folders, add your own reserved RAMs for shooters, add a hijack for cleaning up the tables and be happy.

Removed resources

Now for the more controversial topic. A lot of resources have been removed from Pixi lately, which are:
Sprites, cluster sprites, extended sprites, graphic files, patches, tools (sa1converter and trashkas), the source zip. I will address each and every type of resource I removed as much separately as they can be addressed.

Still, all resources that were removed from Pixi have been submitted to smwcentral. If you can't find them on smwcentral, they are still inside Pixi's github for testing purposes.
Both sa1converter and trashkas are the only exceptions, they both are projects apart from Pixi and have nothing to do with Pixi. So they were removed and are not inside Pixi's github. They are, however, accepted as submitted resources in smwcentral and I hope they each have githubs for themselves, but that's honestly none of my business, so long the tools are available elsewhere.

If you don't care about the technobabble, just jump to the "Non technobabble argument" section. Keep in mind that section is the one that I least care about, so if you wanna discuss any of the matters in there, you are in for that alone.

Sprites/Cluster Sprites/Extended sprites/Graphic files have been removed so they can be updated, rewritten, fixed and otherwise straight up removed from smwcentral according to what people desire. Packing them along with Pixi and evolving them in Pixi's project would warrant a new Pixi release every time each and every sprite would be changed. We do not want that. It makes up for a very poor versioning control.
We already have 2 pretty cool examples of that happening. An old bug has been fixed with the levelender and rotodisc has been updated to include a bunch of cool features.
Most of the graphic files have also been edited for better usage by the staff.

Patches, well patch, the old poison mushroom patch. I see two things good from it being removed from Pixi. First things first, now people know it exists! Isn't that cool? The second one is that it hijacks a pretty cool section of this game and it could be used as study material for a lot of cool stuff. Give it a try yourself!
Basically I like the fact that it's not hidden anymore (also the sprite solution is bad because it doesn't work properly with Yoshi - only if you intend to use them with Yoshi).

For tools, I removed them all from Pixi (CFGEditor is still there but not for long) because I think each one of them needs development and submissions/versioning for each of them has nothing to do with Pixi. They can be updated to comply to a change I made on Pixi, but that's not all there can potentially be to updates on those tools.
For the SA-1 and trashkas I doubt there will be any changes to them, unless I myself update them due to Pixi changes, but there could be changes so they are less abrasive to use. Pixi also doesn't depend on them existing to work, so they both are not developed along and there isn't a strong cohesive reason for them to be packed along.

Now for the most controversial one, the CFGEditor. It was born along with Pixi and it even uses one of Pixi's compiled files as a model for itself, which creates a strong cohesive dependency from CFGEditor to Pixi. That said, that piece could've been extracted from Pixi to being with, but honestly considering the simplicity of it, it can very well be replicated among both projects with little to no harm. I doubt it will ever change as well.
Pixi doesn't use the CFGEditor for anything and updating/changing the CFGEditor for whatever purpose we might have warrants a new Pixi release, which doesn't make sense and makes up for a very poor version control, if done recurringly. Pixi has an internal version number that has to be updated along with said updates, or else we end up with weird situations like Pixi telling you your current version is 1.2.1 but the CFGEditor is from 1.2.2. And at this juncture, I really feel like the CFGEditor needs quality of life changes, like loading the sprite list maybe, and stuff like that.
Lastly, I think the CFGEditor could evolve to better support different sprite tools and detach itself from Pixi (still keeping Pixi compatibility, if possible). Faerie could've been the CFGEditor instead if it wasn't inside the Pixi project. Doubt that would happen, but it could.

CFGEditor will be under dtothefourth's wings because I also have no will to update it at all. Working with C# is puke for me tbf, I hate it. Keep in mind this reasoning here has nothing to do with the reasoning behind me removing the CFGEditor from Pixi, read the above lines again if you think that's the reason.
Also, dtothefourth was against removing it from Pixi, so don't go around putting blame on anyone but me.

Non technobabble argument

Sprites/Cluster Sprites/Extended sprites/Graphic files now have a change to be updated to include new features and fixes. Even if you dislike the fact that they are not packed inside Pixi, you likely already have them inside your Pixi folder, so it's not an issue. It's not like updating your Pixi folder will delete anything from there, plus we got a file telling you where to get them.

For the patch, the old poison mushroom patch. Well, the issue with that one will likely be same. No one will look for it where it is (patches) and where it was in Pixi (asm). It's just out of place in both cases, visibility for it is bad in general, only the way it is currently is none of my business and can potentially evolve to be much better than anything I could do to bring it forth.

Now for the tools. They simply don't belong inside Pixi's project. If that's an issue for you, you either already have it downloaded and should put it elsewhere that's not inside Pixi's folder so you don't accidentally delete it (dunno why you would delete your Pixi folder if you intend to update/use it, but here's my piece of advice) and it will work out just the same.
If the issue is that you can't find them anymore because I removed them from the packing, check the removedResources.txt file. Everything should be properly linked there.

Now for the soon to be removed tool, the CFGEditor. The same reasoning above applies. Just move it out of your Pixi folder if you intend to ever delete your Pixi folder, if not, just keep it there and nothing changes.
Updating Pixi won't delete anything inside your folder, so nothing changes.
Now if you are unable to find it when I happen to remove it from Pixi, it will be in smwcentral for sure and linked inside the removedResources.txt folder. It's not like downloading one more tool will be harmful for anyone. Also not everyone inserting sprites is editing sprites, so there's that too.
I'm sure everyone will properly instruct newbies to look for stuff in the right places, just like we all usually do, sadly I can't broadcast all this post to everyone and force feed them with the knowledge put in here, so there will be also old info regarding the tool, but it's not like solving this problem is any hard, you will just likely search for the tool in the tool section and find it.


Basically I don't consider any of that a big deal at all, enough to warrant both a poor versioning control and a possibility that the CFGEditor won't get quality of life updates ever/or any sort of friction for it to happen. All the other resources were removed for similar reasons.
There are a lot of cases in which that's not even a real issue also, so that's it for the non-technobabble argument and a bit of the technobabble too. I can't really expose my reasoning for doing this without touching the technobabble topic.

Again, don't blame dtothefourth or any of the staff on this, they have nothing to do with my decision here. I do expect them to understand why I'm going that direction though, even if they do not agree with it wholly.
Your layout has been removed.
So, as some of you might know already, I'm working on a pretty big update to Pixi, which will bring many QoL features as well as a bunch of cool new things.

For example, you'll finally be able to specify exactly what code to run during your sprite's carriable state using a simple
print "CARRIABLE", pc

and the same goes for every state between 07 and 0C.

I also fixed a couple of bugs related to cape interaction with extended sprites and added a bunch of useful shared routines that weren't present.

For more details I highly encourage you to read my pull request where I'm making the changes.

However, this change conflicts a bit with the "per-level" sprite feature that's present in Pixi.

Why does the update conflict with the per-level feature? [Warning: technical explanation ahead]
For the new feature, you need 5 pointers PER SPRITE stored somewhere in the ROM, each pointer consists of 3 bytes of data.
Since you can have a total of 16*512 + 176 sprites in total with the feature active, you're gonna need (16*512 + 240)*3*5 = 126480 bytes which is A LOT.
I also noticed that not many people use, let alone need, the per-level sprite feature and I consider my update to be slightly more useful.
Therefore I'm leaving here a poll, to decide on what to do to resolve the conflict between my feature and per-level sprites.
There are 3 (but actually 2) options currently:
- Throw away your feature, keep per-level sprites
- Throw away per level sprites, keep your feature
- Rework per-level sprites to make it work with your feature (note: while this is possible, I lack technical knowledge for this, therefore, if this option wins, I'm gonna put on ice the update until I find someone willing to help me fix the issue or provide the code to do so, so please, only choose this option if you know what you're doing.)

The last option isn't in the actual poll, to choose it you're gonna have to post in this thread with your proposal for the solution or the fix. If you actually have an idea on how to fix it, please contact me on Discord (Atari2.0#1706)
I choose option 4: throw away both, make the usage of extra property byte 2 bits 6 and 7 more explicit as mentioned, have a wrapper for the original status routine that can be called with a JSL (so that sprites using bit 7 can run default code for just some of statuses), and make it possible to insert a unique sprite for every combination of sprite number and extra bit setting (including sprites E0-FF, extra bit 1, extra bit 0 for the unused sprites, etc.)

Also, would anything from here be worth adding to the subroutines? And would it be silly to make $14C8,x values 0D and above valid but usable for custom code by the user (probably just acting like main, but maybe with an option to add default code for some of them)?


I'm working on a hack! Check it out here.
Originally posted by imamelia
I choose option 4: throw away both, make the usage of extra property byte 2 bits 6 and 7 more explicit as mentioned, have a wrapper for the original status routine that can be called with a JSL (so that sprites using bit 7 can run default code for just some of statuses), and make it possible to insert a unique sprite for every combination of sprite number and extra bit setting (including sprites E0-FF, extra bit 1, extra bit 0 for the unused sprites, etc.)

This feels more like a complete rewrite than a feature addition.
If you want such a thing, you'll have more luck writing a sprite tool from scratch and just using that one instead of relying on Pixi. It's not a thing I'm looking to implement.

Originally posted by imamelia
Also, would anything from here be worth adding to the subroutines?

Will take a look.

Originally posted by imamelia
And would it be silly to make $14C8,x values 0D and above valid but usable for custom code by the user (probably just acting like main, but maybe with an option to add default code for some of them)?

Pretty sure this would require some kind of big rewrite of Pixi's main asm code. This is also not something I want to do.
Could you please make $7E18C5-$7E18CC a misc Shooter sprite table?

You're free to assign it that usage yourself. I don't think Pixi is going to reserve any RAM tables on its own unless it's strictly necessary for the tool's features to function, particularly since that may break immediate compatability with other patches if they assumed $18C5 was safe to use.

If this is for a custom sprite you're submitting to the site, just make sure to provide a define for modifying it if necessary.

Professional frame-by-frame time wizard. YouTube - Twitter - SMW Glitch List - SMW Randomizer