A sprite insertion tool made to allow more dynamic sprite usage, space savings and more SA-1 compatibility.
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. There also the new sprite status table that has been moved from 1938 to 7FAF00, used by SubOffScreen routines since version 1.2.10.
Detailed usage instructions, common errors and changes compared to older sprite tools can be found in the included README.html file. Version history can be found in CHANGELOG.html.
List of known bugs/issues
Any weird issues you may encounter, please submit an issue on github at the link above, if you're not sure how to proceed, feel free to contact me on discord (atari2.0) or on the site Atari2.0.
Sometimes sprites will not insert correctly on SA-1 Roms that are 6MB or 8MB, certain sprite slots will be corrupted and it is always random, so be careful when using SA-1.
Did this issue happen in Pixi 1.40 or is exclusive to this version?
I'm honestly not so sure, been a while since I used 1.40, I just know that 1.42 doesn't seem to like SA-1 too much when you get to slot 90 and above. Some sprites will not insert at all or have their data overwritten by other data like GPS, depending on how you build your rom, the slots will remain consistent. Likewise RATS errors can occur.
An adendum, not 100% tested, but AMK/PIXI/GPS combination does not play too nice with 6-8MB Roms (for good reason, they're not extensively tested). My recommendation is to grab the beta of AMK11 that is compatible with 6-8MB roms, use GPS+PIXI first on the rom while it is 4MB and then use AMK after expanding to 6. It appears to fix my issues.
Fernap Oh. so its doing in 16-bit to mitigate the error then. Simple javascript code (you can enter into your devtools) that tests the modulo bias:
Code
function TestModuloBiasRNG(max, SourceRNGMax) {
//Input:
// max = reduced RNG maximum
// SourceRNGMax = the original RNG max value, plus 1 (256 for 8-bit, 65536 for 16-bit)
//
//Output: An array, each element index corresponds to each consecutive integers of the target range,
// whose values they contain represents how many source RNG values would result a given number in the output.
//
//Example: convert 0-65535 to 0-2 means TestModuloBiasRNG(2, 65536), would output [21846, 21845, 21845], that means:
//The chance of getting a 0 is 21846/65536
//The chance of getting a 1 is 21845/65536
//The chance of getting a 2 is 21845/65536
let ListOfOdds = new Array(max+1).fill(0)
for (i = 0;i<SourceRNGMax;i++) {
ListOfOdds[i % (max+1)]++
}
return ListOfOdds
}
function GetPercentage(value, max) {
return value*100/max //Why multiply first instead of divide? See this: https://en.wikipedia.org/wiki/Talk:Rounding#any_mentions_that_best_only_round_at_the_final_step_when_possible?
}
When comparing with akaginite's range RNG, (RangedRNG = floor(rand*(max+1)/256)) or RangedRNG = floor(rand*(max+1)/65536))), especially with larger ranges, Akaginite's have values that are more likely are spread out across the target range (test this), while the modulo one have values that are more likely are at the lower values, consecutively, in the range.
That still looks like it is performing Ranged_RNG = rand % Max+1, that's having modulo bias. You submitted the wrong file? Here's a better RNG patch, which included a better RNG range routine (calculated as RangedRNG = floor(rand*(max+1)/256)). Slight uneven distribution are up to 1/256 chance difference.
How it works? We treat this as cross-multiply: rand/256 = value/max+1 and round down. It is the equivalent of doing the same in javascript. A random number is 0 <= rand < 1 (0 included, 1 excluded), which is equivalent to rand/256 (but we don't divide yet to reduce rounding errors), when then take that number and multiply by max+1. This will scale the RNG with approximately equal distribution to a different-size range. Only difference is that in JS, because it supports floating points, you can scale to a larger range, where as integers, you cannot (without having some values in the enlarged range not possible).
I think it should simply say "less" instead of "without". There's still some modulo bias, but the division is performed on a 16-bit random number now instead of an 8-bit one. The previous version could exhibit fairly extreme bias for certain maxima, while the newer one is much more reasonable.
After weeks testing sprite after sprite, I went into testing the misc sprites as well, among some of the new features and the normal stability test. Resuming everything, I did not find enough issues for a rejection, for everything I tested worked fine.
That being said, my only suggestion was to improve the readme, which is already being done for the next versions. This is minor, though, and won't sway my final decision, which is to accept this update.
It's not a bug but a consequence of Lunar Magic 3's custom goal tapes for secret exits 2 and 3. It should probably be mentioned in the readme or something though...
Because I'm currently the only active tool moderator and I can't moderate this resource because I'm the current maintainer.
Sorry to hear! Is the site accepting volunteers? I would need to be more active on the forums and qualify myself first, but I've been in this community for eight years on and off.
This is not how it works. You don't *push* directly to the original repository. You make your changes on your own fork and then open a pull request, here are the japanese docs from github on how to do that: https://docs.github.com/ja/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests
Feel free to open an issue/pull request here https://github.com/JackTheSpades/SpriteToolSuperDelux with whatever you want to be added and I'll review it and decide if it's worth adding..
Can I have these routines attached to PIXI? (Just the ones that are acceptable)
Also, why does the custom extended sprite increase YSpeed by 3 when gravity is applied? Normally it should increase by 2.
And do you know about this patch?
Yeah, I also find Sonikku’s hammer’s gravity a bit too much. But I’m using your patch with PIXI 1.40 and it works just fine from my testing. I even used the patch with Atari’s test suite version from a year ago and it worked just fine. All thanks to my rigorous testing!
Can I have these routines attached to PIXI? (Just the ones that are acceptable)
Also, why does the custom extended sprite increase YSpeed by 3 when gravity is applied? Normally it should increase by 2.
And do you know about this patch?
Feel free to open an issue/pull request here https://github.com/JackTheSpades/SpriteToolSuperDelux with whatever you want to be added and I'll review it and decide if it's worth adding..
When using this tool, I recommend not have any other programs such as LM have the ROM opened, I've experioenced crashes. Kinda strange on why this occurs. It happened to me when first insertion on the ROM the first time.
Does anyone know the solution to this problem I'm having? I'm not even able to attempt to insert a sprite cuz every time I give pixi my rom I get "You haven't installed the VRAM optimization patch in Lunar Magic, this will cause many features of Pixi to work incorrectly, insertion was aborted..."
Does anyone know what this means/how to fix it? Idk what this patch its referring to is, and I cant find any info online
The patch is contained within Lunar Magic. It is applied as soon as you modify any levels of your ROM with it.
If you encounter an issue with Pixi saying that it's not able to open a file and you have ANY special characters in your path, such as àèéìòù or others, please download it from here and that should work.
Since it's not specifically mentioned in the readme.txt, I figured out that the character to start comments in your list.txt (as of v1.32) is a semi-colon (;).
On any line (blank lines or on a sprite definition row) anything after a (;) will be considered a comment and be ignored while PIXI runs. This makes it easy to add notes, for example which ExGFX goes with which custom sprite.
I don't know where to insert the -pl flag for sprites per levels, because pixi.bat file is not available. Could you help me out with this? I'm using version 1.2.10
I downloaded this new version of pixi and it said that it would not work on windows so i downloaded a previous version of pixi but it also would not work on windows. Could you help me out? its been working before i downloaded this new version. Thanks!
Currently there's a bug with pixi in which it's not really displacing sprite data correctly, causing sprites not to spawn or spawn bugged up sprites. The reason this never happens is because LM3 has a proper cache for that. Some times the cache fails and pixi has to take over the cache, in those cases, sprites are not spawning properly (mostly for super tall levels, don't know the specifics).
This will be fixed within this week.
I don't get the trashkas removal. Have I missed something? I have an old sprite that I can't insert because I need to convert it, but I have no way of doing it.
I don't get the trashkas removal. Have I missed something? I have an old sprite that I can't insert because I need to convert it, but I have no way of doing it.
I inserted a custom sprite into my smw rom but the game is no longer running on the emulator (neither znes nor snes9x) what do I do?
how do i remove the rom sprite?
file path name is not in English that error happened.
Yeah it's made in C/C++ (mostly C), it is not accounting for encoding whatsoever.
I will register that as a bug in the github, but do not expect that to be fixed lol.
I have an error when I try to insert sprites. After I type my ROM's name and press enter, it said:
Quote
An error has been detected: spr_temp.asm:2: error: (E5016): File 'C:/Users/…(my directory)…/pixi_v1.2.10/asm/sa1def .asm' wasn't found. [incsrc "C:/Users/…(my directory)…/pixi_v1.2.10/asm/sa1def .asm"]
The same happened to _header.asm and asm files of sprites I try to insert, though these file exist in a correct folder. I read readme and then think that this error is relevant to incsrc/incbin, but I don't know what this is and what I shoud do.
You fucked up your folder, they are all inside the zip file.
I didn't, but problem was resolved. It is because file path name is not alphabet that error happened.
I have an error when I try to insert sprites. After I type my ROM's name and press enter, it said:
Quote
An error has been detected: spr_temp.asm:2: error: (E5016): File 'C:/Users/…(my directory)…/pixi_v1.2.10/asm/sa1def .asm' wasn't found. [incsrc "C:/Users/…(my directory)…/pixi_v1.2.10/asm/sa1def .asm"]
The same happened to _header.asm and asm files of sprites I try to insert, though these file exist in a correct folder. I read readme and then think that this error is relevant to incsrc/incbin, but I don't know what this is and what I shoud do.
You fucked up your folder, they are all inside the zip file.
I have an error when I try to insert sprites. After I type my ROM's name and press enter, it said:
Quote
An error has been detected: spr_temp.asm:2: error: (E5016): File 'C:/Users/…(my directory)…/pixi_v1.2.10/asm/sa1def .asm' wasn't found. [incsrc "C:/Users/…(my directory)…/pixi_v1.2.10/asm/sa1def .asm"]
The same happened to _header.asm and asm files of sprites I try to insert, though these file exist in a correct folder. I read readme and then think that this error is relevant to incsrc/incbin, but I don't know what this is and what I shoud do.
For some reason this causes any gfx/exgfx in Lunar to be resetted to 0
No. Pixi doesn't touch anywhere near there.
Your rom is corrupted.
The only way to corrupt your rom with pixi is if you run pixi without any normal sprites in its list and then run it again, blowing up your rom. The issue is listed in the known issues link and this would cause your rom to crash before entering the showoff level, right after the nintendo presents screen.
If that's not the case, you will have to check on your own what corrupted your rom.
Free speech and a not-so-free rate systems are a pretty cool combination, aren't them?
I don't care about pixi's ratings. What is he gonna do? Use another tool? Be my guest lmao.
SubOffScreen might be bugged. The Baron Von Zeppelin sprite crashes the game if it's allowed to spawn above the vertical boundary or to the left of the horizontal boundary. Some other sprites may do the same thing.
Routine Star.asm is bugged as well. Reported by Darolac. This issue was actually reported to me by Blinddevil and fixed to me by him himself like more than one year ago, but I forgot about that.
Code
;Routine that star-kills the sprite and gives Mario points.
;Doesn't check whether Mario actually has a star.
PHB
PHK
PLB
JSL $01AB6F|!BankB
LDA #$02 ; \ sprite status = 2 (being killed by star)
STA !14C8,x ; /
LDA #$D0 ; \ set y speed
STA !AA,x ; /
JSR .SubHorzPos
LDA .speed,y ; \ set x speed based on sprite direction
STA !B6,x ; /
INC $18D2|!Base2 ; increment number consecutive enemies killed
LDA $18D2|!Base2 ; \
CMP #$08 ; | if consecutive enemies stomped >= 8, reset to 8
BCC ?+ ; |
LDA #$08 ; |
STA $18D2|!Base2 ; /
?+ JSL $02ACE5|!BankB ; give mario points
LDY $18D2|!Base2 ; \
CPY #$08 ; | if consecutive enemies stomped < 8 ...
BCC ?+ ; |
LDY #$08
?+ LDA .sound,y ; | ... play sound effect
STA $1DF9|!Base2 ; /
PLB ;
RTL ; final return
.speed db $F0,$10
.sound db $00,$13,$14,$15,$16,$17,$18,$19,$03
.SubHorzPos
LDY #$00
LDA $94
SEC
SBC !E4,x
STA $0E
LDA $95
SBC !14E0,x
STA $0F
BPL ?+
INY
?+ RTS
Here's the fixed version.
I will update pixi with these two fixes (this and the other one I posted here) this weekend.
A minor update, but works as intended and it is still stable. Since I tend to use the newest versions when moderating sprites, the tests made give me enough input to accept this.
Just a routine update. Since it does not break the routines that were updated by this version, and it works as usual, I've come to terms to accept the tool.
There's an issue with this release I caused. I set the perlevel flag in asm/main.asm as default 0. This apparently causes issues with inserting / spawning shooters.
I will make a new pixi release (1.2.5) and I will turn off the perlevel feature by default (currently it's turned half on, which is not good, prior versions were on). Shouldn't take long for the release to be submitted.
Meanwhile, you can use the good old -npl flag and make a bat with it like:
Code
@echo off
pixi.exe -npl <your rom's name.smc>
pause
*pause is optional*
*save it as <whatever name you want>.bat*
Next release this flag will do nothing but won't cause any harm and a new flag called -pl will be added to toggle perlevel insertion.
Any questions or issues, you can find me in discord.
Special thanks to Tattletale for his incredible work on this build. High expectations to just version be much more reliable compared to the old versions.
You forgot to update the changelog. I fixed that for you. I also slightly changed the comment at the top of Random.asm (it still mentioned Y instead of A).
also, someone should really backport these changes to the github repo
See what Erik said. The whole process with GIEPY still needs a bit more work before we can safely make the switch. This is a minor update to PIXI to stabilize it - after all, we don't want people using buggy tools just because GIEPY isn't fully ready yet.
This is a very minor update to the tool. I've upgraded the Asar library to 1.60 to help prevent the softlock issue. I've also fixed the Aiming routine, fixed the crash in ExtendedGetDrawInfo, and fixed various problems with the Random routine which were discovered in #asm a couple of minutes ago.
I undid the RTS->RTL, since that wasn't the main return in Star.asm, it was only a subroutine, which was called via JSR .SubHorzPos.
Also, these changes should probably be merged back into the GitHub repo too (which is a bit inconvenient, considering that the only active person who has push access to the repo is RPG Hacker but he doesn't have internet at home currently, only at work).
Fixed Star.asm, which didn't have a bank wrapper, thus not reading tables correctly, and changed a faulty RTS to RTL. Also fixed sa1def.asm, uncommenting the !7FAB64 define macro used for Extra Byte 4, and also correcting its default SA-1 address for !extra_byte_4 define, used by the tool, which was wrong (default was $4000D8 when the correct is meant to be $4000DB).
I'm going to port everything of my rom to a new one because i had a very old version of pixi. But yeah, i hope this version has no problem with "broken" cluster sprites.
No code changes to the application itself were made between 1.2 and 1.2.1, so sure, if you use the old version, it will behave just like version 1.2. Is there a good reason to do that? (Something broken with the new version?)
The display features barely work:
- Load m16 does nothing.
- Neither does Load GFX33.
- I assume the 8x8 Tile Selector would allow me to make my custom map16 tiles, but I can do nothing in it.
- Changing to 8x8 mode in both windows still only pastes 16x16 tiles, and no, I can't remove one by one, I can only remove the 4 or nothing.
- Who should I pray for this to save?
- You can't use the mousewheel to scroll.
-
with all due honesty never touch this again unless you plan to stick around, be responsive to the bug reports and keep up with our own progress in the pixi fork.
This version adds an option to disable per-level sprites insertion, which fixes the softlock. The option is not enabled by default, so running PIXI normally will not fix anything.
Potential resolutions (rather, workarounds) have been found and are being tested for inclusion in an unofficial future version of PIXI.
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.
Are you talking about my version or the original?
If you're talking about my version then it only contains the modified files so you still need to download the actual tool and replace the files.
If you downloaded the original tool then make sure to put it in it's own folder to not mess with other tools that might be using a different version of asar.dll
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.
NOTE: Fixed a couple of bugs in different ASM files, so if you downloaded the tool while it was still waiting for moderation, please redownload before doing anything else.
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:
Code
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.
Major problem:
1) I put this in list.txt: 00 donut_lift.cfg. I only put that sprite in and no other sprites for testing to see if it successfully inserts.
2) I run the exe file and put the ROM on it to insert. It spits out an error on my face:
Code
15 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:65 (called from sprites/donut_lift.asm:49): error: Relative branch out of bounds (distance is -223) [BNE .return]
routines/SubOffScreen.asm:68 (called from sprites/donut_lift.asm:49): error: Relative branch out of bounds (distance is -228) [BCS .return]
routines/SubOffScreen.asm:97 (called from sprites/donut_lift.asm:49): error: Relative branch out of bounds (distance is -286) [BPL .return]
Don't tell me that this is like GPS's sublabel problem/glitch, where if you use a .sublabel before a %CallSubroutine() whatever label inside CallSubroutine.asm is assumed present in the file that calls the sublabel causing it to error out saying no parent or redefined:
Code
MainLabel:
%CallSubroutine() ;>Whatever labels in this subroutine is assumed to be here rather than exclusively inside this.
.Sublabel
Bug with this tool
When I insert some sprites in a ROM with SA-1.
The basic shooters (Bullet Bill (C9) and Torpedo Launcher (CA)) doesn't work after the insertion.
Please fix that.
NOOOOO!!! It got accepted... Now they're only going to be these PIXI sprites... I'm going to have to delete all my sprite tool sprites? PLEASE NO SMWC... PLEASE NO!!!
Comments (177)
I'm surprised no one reported this issue
Made enough tests in order to verify the tool's stability. That being said, this can be accepted as is.
Comparison:
When comparing with akaginite's range RNG, (RangedRNG = floor(rand*(max+1)/256)) or RangedRNG = floor(rand*(max+1)/65536))), especially with larger ranges, Akaginite's have values that are more likely are spread out across the target range (test this), while the modulo one have values that are more likely are at the lower values, consecutively, in the range.
That still looks like it is performing Ranged_RNG = rand % Max+1, that's having modulo bias. You submitted the wrong file? Here's a better RNG patch, which included a better RNG range routine (calculated as RangedRNG = floor(rand*(max+1)/256)). Slight uneven distribution are up to 1/256 chance difference.
How it works? We treat this as cross-multiply: rand/256 = value/max+1 and round down. It is the equivalent of doing the same in javascript. A random number is 0 <= rand < 1 (0 included, 1 excluded), which is equivalent to rand/256 (but we don't divide yet to reduce rounding errors), when then take that number and multiply by max+1. This will scale the RNG with approximately equal distribution to a different-size range. Only difference is that in JS, because it supports floating points, you can scale to a larger range, where as integers, you cannot (without having some values in the enlarged range not possible).
After weeks testing sprite after sprite, I went into testing the misc sprites as well, among some of the new features and the normal stability test. Resuming everything, I did not find enough issues for a rejection, for everything I tested worked fine.
That being said, my only suggestion was to improve the readme, which is already being done for the next versions. This is minor, though, and won't sway my final decision, which is to accept this update.
If I put in 7B in PIXI.
I get a goal bar no matter what custom sprite I select.
Sorry to hear! Is the site accepting volunteers? I would need to be more active on the forums and qualify myself first, but I've been in this community for eight years on and off.
Can you do for both 32-bit and 64-bit versions?
I'm using Windows 10 32-bit (x86).
I am sorry. I don't know how to do it.
Also, why does the custom extended sprite increase YSpeed by 3 when gravity is applied? Normally it should increase by 2.
And do you know about this patch?
Yeah, I also find Sonikku’s hammer’s gravity a bit too much. But I’m using your patch with PIXI 1.40 and it works just fine from my testing. I even used the patch with Atari’s test suite version from a year ago and it worked just fine. All thanks to my rigorous testing!
Also, why does the custom extended sprite increase YSpeed by 3 when gravity is applied? Normally it should increase by 2.
And do you know about this patch?
If your rom crashes on sprite apply then delete all unused sprite files
Is there any way to fix it?
Does anyone know what this means/how to fix it? Idk what this patch its referring to is, and I cant find any info online
The patch is contained within Lunar Magic. It is applied as soon as you modify any levels of your ROM with it.
On any line (blank lines or on a sprite definition row) anything after a (;) will be considered a comment and be ignored while PIXI runs. This makes it easy to add notes, for example which ExGFX goes with which custom sprite.
Aside of the basic functionalities being preserved, I tested all the new additions and they work. Then, let's accept this.
If you're used to other smw hacking tools as AMK or GPS it shouldn't be that hard, but in any case, there's a tutorial here
This will be fixed within this week.
The tool is already hosted on the site. Link
how do i remove the rom sprite?
Yeah it's made in C/C++ (mostly C), it is not accounting for encoding whatsoever.
I will register that as a bug in the github, but do not expect that to be fixed lol.
The same happened to _header.asm and asm files of sprites I try to insert, though these file exist in a correct folder. I read readme and then think that this error is relevant to incsrc/incbin, but I don't know what this is and what I shoud do.
You fucked up your folder, they are all inside the zip file.
I didn't, but problem was resolved. It is because file path name is not alphabet that error happened.
The same happened to _header.asm and asm files of sprites I try to insert, though these file exist in a correct folder. I read readme and then think that this error is relevant to incsrc/incbin, but I don't know what this is and what I shoud do.
You fucked up your folder, they are all inside the zip file.
The same happened to _header.asm and asm files of sprites I try to insert, though these file exist in a correct folder. I read readme and then think that this error is relevant to incsrc/incbin, but I don't know what this is and what I shoud do.
No. Pixi doesn't touch anywhere near there.
Your rom is corrupted.
The only way to corrupt your rom with pixi is if you run pixi without any normal sprites in its list and then run it again, blowing up your rom. The issue is listed in the known issues link and this would cause your rom to crash before entering the showoff level, right after the nintendo presents screen.
If that's not the case, you will have to check on your own what corrupted your rom.
Great tool!!
Free speech and a not-so-free rate systems are a pretty cool combination, aren't them?
I don't care about pixi's ratings. What is he gonna do? Use another tool? Be my guest lmao.
Here's the fixed version.
I will update pixi with these two fixes (this and the other one I posted here) this weekend.
Replace it with this:
Or read my comment below.
I will make a new pixi release (1.2.5) and I will turn off the perlevel feature by default (currently it's turned half on, which is not good, prior versions were on). Shouldn't take long for the release to be submitted.
Meanwhile, you can use the good old -npl flag and make a bat with it like:
*pause is optional*
*save it as <whatever name you want>.bat*
Next release this flag will do nothing but won't cause any harm and a new flag called -pl will be added to toggle perlevel insertion.
Any questions or issues, you can find me in discord.
also, someone should really backport these changes to the github repo
Also, these changes should probably be merged back into the GitHub repo too (which is a bit inconvenient, considering that the only active person who has push access to the repo is RPG Hacker but he doesn't have internet at home currently, only at work).
I would prefer it to be a new version because it does not work with me, something needs to be improved
Test it if work or not?
- Load m16 does nothing.
- Neither does Load GFX33.
- I assume the 8x8 Tile Selector would allow me to make my custom map16 tiles, but I can do nothing in it.
- Changing to 8x8 mode in both windows still only pastes 16x16 tiles, and no, I can't remove one by one, I can only remove the 4 or nothing.
- Who should I pray for this to save?
- You can't use the mousewheel to scroll.
-
with all due honesty never touch this again unless you plan to stick around, be responsive to the bug reports and keep up with our own progress in the pixi fork.
Potential resolutions (rather, workarounds) have been found and are being tested for inclusion in an unofficial future version of PIXI.
besides that, what else, and is the softlock bug fixed?
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.
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.
If you're talking about my version then it only contains the modified files so you still need to download the actual tool and replace the files.
If you downloaded the original tool then make sure to put it in it's own folder to not mess with other tools that might be using a different version of asar.dll
Error: Asar library is missing, please redownload the tool or add the dll.
Edit: Now, I try this version, and I get a lot of errors:
18 Shared routines registered in "routines/"
An error has been detected:
sprites/birdo.asm:16: error: Unknown command. [TILEMAP dcb $8E,$AE,$8E,$EE,$CE,$AE]
sprites/birdo.asm:17: error: Unknown command. [VERT_DISP dcb $F0,$00,$F0,$00,$F0,$00]
sprites/birdo.asm:18: error: Unknown command. [PROPERTIES dcb $40,$00]
sprites/birdo.asm:25: error: Invalid number. [dcb "INIT"]
sprites/birdo.asm:26: error: Label SUB_GET_DIR not found [JSR SUB_GET_DIR]
sprites/birdo.asm:48: error: Invalid number. [dcb "MAIN"]
sprites/birdo.asm:49: error: Unknown command. [HAMMER_BRO_JSL PHB]
sprites/birdo.asm:53: error: Label START_HB_CODE not found [JSR START_HB_CODE]
sprites/birdo.asm:64: error: Unknown command. [DEC RAM_ThrowTimer,x]
sprites/birdo.asm:72: error: Unknown command. [X_SPEED dcb $00,$F8,$00,$08]
sprites/birdo.asm:73: error: Unknown command. [TIME_IN_POS dcb $50,$20,$50,$20]
sprites/birdo.asm:75: error: Unknown command. [RETURN RTS]
sprites/birdo.asm:76: error: Unknown command. [START_HB_CODE JSR SUB_GET_DIR]
sprites/birdo.asm:80: error: Label SUB_GFX not found [JSR SUB_GFX]
sprites/birdo.asm:83: error: Label RETURN not found [BNE RETURN]
sprites/birdo.asm:85: error: Label RETURN not found [BNE RETURN]
sprites/birdo.asm:87: error: Label SUB_OFF_SCREEN_HB not found [JSR SUB_OFF_SCREEN_HB]
sprites/birdo.asm:92: error: Label LABEL3 not found [BEQ LABEL3]
sprites/birdo.asm:98: error: Unknown command. [LABEL3 STA $1602,x]
sprites/birdo.asm:102: error: Label JUMP_BIRDO not found [BCS JUMP_BIRDO]
More errors too.
It just says this, and then hangs.
line: 00:00
num: 0, ex: 0, char: :
line: 00:00
num: 0, ex: 0, char: :
line: 1
num: 1, ex: 0, char: F
18 Shared routines registered in "routines/"
how can i fix it
Where did you put Pixi, for me it seems to work just fine.
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).
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.
mod edit: stop stretching tables
1) I put this in list.txt: 00 donut_lift.cfg. I only put that sprite in and no other sprites for testing to see if it successfully inserts.
2) I run the exe file and put the ROM on it to insert. It spits out an error on my face:
Don't tell me that this is like GPS's sublabel problem/glitch, where if you use a .sublabel before a %CallSubroutine() whatever label inside CallSubroutine.asm is assumed present in the file that calls the sublabel causing it to error out saying no parent or redefined:
Edit: blame asar for this buggy macro.
When I insert some sprites in a ROM with SA-1.
The basic shooters (Bullet Bill (C9) and Torpedo Launcher (CA)) doesn't work after the insertion.
Please fix that.
Sorry! We don't allow you to use the tool while on an outdated version of Windows. (Curse you, Windows XP!!!)
I tested on my Windows XP and Doesn't work with the "CFG Editor GUI"
and Tested with Windows 7 or Higher but It works Fine
I can fix This!
God damn it people, it's not the end of the world.
it's just one dude
First, >ASMtool
Second, how old is your hack if it cant handle gps
Third,
God damn it people, it's not the end of the world.
If no bugs are found in this tool, there will be no need for Romi's any more.