A sprite insertion tool made to allow more dynamic sprite usage, space savings and more SA-1 compatibility when compared to old iterations.
Despite this, it is almost fully compatible with sprites written for older SpriteTools, save for the fact that Asar is now used as the assembler.
Detailed usage instructions, common errors and changes can be found in the included readme.txt file.
For more information, read here.
Source code can be found at GitHub.
Also I forgot to mention, when you’re using any of the provided sprites, you may have to edit it’s code in order to prevent sub label issues with the macro. I’ve mentioned earlier that labels (including the +/- labels) leaks outs (as in, treating labels inside the macro as if they’re outside where it’s called) and cause problems.
Edit: Now, I try this version, and I get a lot of errors:
The sprite was made for trasm, check if it has been remoderated in the sprites section.
If so you're good to go if you download the remoderated sprite.
If not you'll have to try and use trashkas (Included in "asm/Converter Tools" and see if that can convert the sprite correctly.
If that does not work you're probably better of asking for help directly or waiting for it to get remoderated.
As for the mushroom sprite it might be using some stuff that asar doesn't like but xkas allows.
First step applies to this as well but if it hasn't been remoderated you probably don't want to convert it if it doesn't throw errors as that will cause it to definitely break.
Okay, I put it in F:\OLD Drive\pixi v1.1, but do I have to move the original sprites from the old folder to the new folder?
I tried both versions, but I deleted your version and then uploaded this version. So I need both versions for it to work?
Edit: Okay, after about two or three hours of copying and pasting the files like it said, I think it worked, but I inserted the sprites, and I have the mushroom that gives you more time so when I collect it, the screen just like blinks and turns blank and the music plays in the background. Am I missing something? It worked fine for the SMW2 soldiers that walk and run around in the castles, but I don't know what is wrong w/the mushroom sprite. People were being overcritcal saying that it played the halfway point sound so I don't know if that might have something to do w/it. That wasn't my fault.
That's the freedata align bug, an issue with Asar which causes PIXI to softlock when trying to insert per-level sprites. If you don't need per-level sprites, you can use TheBiob's modified PIXI which doesn't have the crash bug (at the price of not supporting per-level sprites).
Does this not work with addmusick? I've tried it multiple times, and the program executes but freezes right before completion. If its not addmusic, idk what it is. I can apply it to a fresh rom just fine, but applying sprites to my current one just doesnt work.
I'll just leave a warning here. The cluster sprite support that this new version of PIXI comes with is incompatible with the Extended NMSTL patch, and using PIXI will massively break your ROM if you've previously applied the patch.
This is surprisingly easy to fix. I haven't tested it with custom cluster sprites, but it should work. First, comment out lines 123-125 and 265-273 from extendnstl.asm. Go to the end of the file and add a new line which says print "GetExtOAMIndex: $",hex(GetExtOAMIndex). Apply the patch and write down the offset it gives you.
After that, go into PIXI's asm/cluster.asm. If you've previously applied extendnstl.asm, remove the autoclean from line 14. Find line 37 (BEQ .return) and, on a new line after it, put PHA : JSL $xxxxxx : PLA. Replace $xxxxxx with the offset you wrote down earlier. Now PIXI won't break the graphics of cluster sprites or nuke your ROM. You should change the offset in asm/cluster.asm every time you reapply extendnstl.asm to make sure it doesn't change (I could make it read it from the ROM, but I'm too lazy).
uh, I tested by inserting 1 sprite on id=#$00 on donut lift sprite and even weirder stuff happened:
line: 1num: 1, ex: 0, char: F18 Shared routines registered in "routines/"
An error has been detected:
sprites/donut_lift.asm:85: error: Label "SubOffScreen_return" redefined [.return]
routines/SubOffScreen.asm:26 (called from sprites/donut_lift.asm:49): error: Relative branch out of bounds (distance is -147) [BNE .return]
routines/SubOffScreen.asm:49 (called from sprites/donut_lift.asm:49): error: Relative branch out of bounds (distance is -192) [BPL .return]
routines/SubOffScreen.asm:68 (called from sprites/donut_lift.asm:49): error: Relative branch out of bounds (distance is -226) [BNE .return]
routines/SubOffScreen.asm:71 (called from sprites/donut_lift.asm:49): error: Relative branch out of bounds (distance is -231) [BCS .return]
routines/SubOffScreen.asm:100 (called from sprites/donut_lift.asm:49): error: Relative branch out of bounds (distance is -289) [BPL .return]
Yes, thats an asar bug with having a %Macro() in between main label and sublabel(s), but whats with the underline part?
(PS: Really REALLY REALLY hope asar had this macro issue resolved, having sublabels are not only used to prevent redefined errors, but also keeps the code structure (viewed by a programmer) organized). Using + and - doesn't help much on telling a code its purpose.