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.
TO MAKE YOUR OLD ROMI SPRITE WORK WITH PIXI 1.2.10+
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:
For extra defines, something like this:
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:
The code above would read the 12th extra byte for a sprite.
Exemple for shooters:
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.
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.