Language…
10 users online: AJ1Ayrton, GRIMMKIN, Hidincuzimsmokin, Klug, Nirv, Oskise, playagmes169, Rykon-V73,  Telinc1, Tsquare07 - Guests: 248 - Bots: 261
Users: 64,795 (2,375 active)
Latest user: mathew

Official Tool/Sprite/Etc. Help Thread

Link Thread Closed
  • Pages:
  • 1
  • 2
  • 3
  • 4
  • 5
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
Well... looks like you made it even more wrong than we possibly have thought.

But first, let's talk about list.txt: All you did was to enter the sprite number but not the folder where they're located at. That's the previous. All of GIEPY's .
Second, and that's where you really have messed up, is that you have put the CFG and ASM in seperate folders. They're supposed to go together! If GIEPY and PIXI need a sprite's ASM file, they search in the same folder where the CFG file is located, hence the "ASM file not found" error. The "asm" folder is for their ASM files, not for the sprites' ones so all the sprites do is to rot on the harddrive. Did I mentioned that my PIXI insertion tutorial even mentions to put all files in the same folder?

I know you're new to SMW hacking but sometimes, people like you... Like, I don't want to scare newbies but seriously, even that is something which one shouldn't mess it up even when new to hacking.
Is there a clear limit to how many custom sprites you can have in a ROM?

I'm wondering if there's an address list that goes something like 00 to FF and if some of those addresses might be taken up by vanilla sprites.

My hack ideas are being outlined and I'd like to know the sheer limitations as they stand for an 8MB SA-1 ROM.



YouTube Twitter Twitch


If you use Giepy, you can have up to 1024 sprites in the game (including SMW's original sprite set, that is). You may run into space limits before reaching that point, though.

If you use Pixi, you can have 256 custom sprites, not including SMW's original sprite set. The reason there's such a difference between them is because of the two tools handle the extra bits differently; Giepy allows you to insert seperate sprites for each extra bit setting, whereas Pixi only allows you to insert one in addition to the corresponding vanilla sprite.

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


That sounds good. Would I be able to import sprites from both tools into the same hack?



YouTube Twitter Twitch


You can't apply both tools to the same hack, only one or the other. That said, GIEPY sorta features support for PIXI sprites (you have to do a bit of work to set it up, though; check the readme if you use), while PIXI does not provide support for the reverse. It's possible to convert completely between the two with a bit of editing though, but you'd need to know at least basic ASM to do that.

Professional frame-by-frame time wizard. YouTube - Twitter - SMW Glitch List - SMW Randomizer
Hello, I am having a problem with this sprite https://www.smwcentral.net/?p=section&a=details&id=3679 I tried inserting the bigger versions of these Yoshi's Island platforms but only the small tilemap is showing. I noticed another user was having the exact same problem, any ideas on how to fix this?
Is there any way to make G.P.S. outputs to the command screen the insertion address of each shared routine?


Run the program with the -d flag, i.e.

Code
gps -d MyHack.smc

This will print out debug information for each block inserted. The debug information contains the locations of all labels in the block, including any referenced shared subroutines.

Keep in mind that only shared routines that are explicitly referenced by one of the blocks are actually inserted. So even if it says something like "18 shared subroutines registered" at the top, if none of your blocks actually reference any of them, then none of them are actually inserted.

Professional frame-by-frame time wizard. YouTube - Twitter - SMW Glitch List - SMW Randomizer
Originally posted by Thomas
Run the program with the -d flag, i.e.

Code
gps -d MyHack.smc

This will print out debug information for each block inserted. The debug information contains the locations of all labels in the block, including any referenced shared subroutines.

Keep in mind that only shared routines that are explicitly referenced by one of the blocks are actually inserted. So even if it says something like "18 shared subroutines registered" at the top, if none of your blocks actually reference any of them, then none of them are actually inserted.


Thanks! Believe it or not, it helped me fix a nasty bug that was happening because of a long jump to a code that was very far away from block insertion address :)

By the way, do you happen to know if it is reliable to pinpoint those shared routine address for use with custom sprites? I ask that because there is a custom sprite I use that also uses ChangeMap16 routine (the same from GPS), so I wanted to know if it is worth saving some bytes by making my sprite JSL to the address GPS inserted it.

If I add more blocks, new routines, will GPS also repatch and change insertion address of already patched routines?


It is possible that the insertion address will change after inserting or removing blocks, so I recommend against doing that. The address locations are really only meant to be used for debugging.

If you really want to share a routine between multiple tools, your best bet would be to insert it as a separate patch altogether at a hardcoded address, and then reference that. However, that's probably not worth the trouble; you likely won't be that pressed on space, so it's much easier to just have the duplicate.

Professional frame-by-frame time wizard. YouTube - Twitter - SMW Glitch List - SMW Randomizer
Which Sprite Tool is more or less widely agreed to be the most stable right now? Romi's? PIXI or Giepy? I wanted to give some of the PIXI-exclusive sprites a chance, but I heard Giepy is still a WIP despite being compatible with TRASM sprites, so...I went for what I assumed was the most stable program (PIXI) and gave it a try.



The tool refuses to insert the Bomb Koopa sprite, that robot fella from Mario Land 1, and the donut lift sprite included with the tool, while other sprites like the Roto Disc and SMB3 Lakitu happen to be a fair game.

I assume the tool might have been broken during an update because having allegedly compatible sprites being faulty out of nowhere is honestly quite weird (heck, now that I remember even the new Venus Fire Trap fails at throwing the fireball correctly), but at the same time I haven't been around that much as of late, so I dunno. Should I jump straight to Giepy or keep trying to make PIXI work?

Edit:
Originally posted by Telinc1
Those errors look like a PIXI bug with shared subroutines and sublabels. Calling a shared subroutine for the first time across all sprites changes the main label and breaks and succeeding sublabels. This can be worked around by adding a call to the routine before any sprite code so that it won't be the first call in the actual sprite code.


Tried just that and it didn't work, so I tried again but this time calling the code around the very end of the sprite (right before where the tilemap starts) and PIXI inserted it with no problems. Sadly the tool refused to make the Mario Land robot work no matter where I made it call the "buggy" code, so I guess I'll replace it with something else until Giepy's far more stable. Thanks for the help :)
Those errors look like a PIXI bug with shared subroutines and sublabels. Calling a shared subroutine for the first time across all sprites changes the main label and breaks and succeeding sublabels. This can be worked around by adding a call to the routine before any sprite code so that it won't be the first call in the actual sprite code.

As for GIEPY, the official release is not a WIP. The only known problem is that it doesn't work with 6 and 8 MB SA-1 ROMs and that's likely fixed in the unreleased master branch. The official release, however, has incomplete example subroutines, has the same problems PIXI does with extra bytes overflowing the sprite data index, and doesn't work with a lot of our current sprites. All three of the problems are solved by my fork, which, while technically unofficial, will be the one we use after we make the switch to GIEPY. You can download it from the GIEPY announcement thread. Combined with this part of the documentation, you can use all PIXI sprites with GIEPY.

Romi's SpriteTool, while arguably the most stable and most tested tool, is probably not worth your time at this point. Almost none of the sprites we host will work with it as it lacks many features introduced in PIXI and future sprite tools.
Hey there, I'm having some trouble with the Ninji disassembly sprite (https://www.smwcentral.net/?p=section&a=details&id=3701)

I have set the tilemap to $82,$84 and all is well, the Ninji works correctly however whenever I jump on them the death animation goes back to being whatever sprite is occupying $A7,$A9 in the ExGFX (which is where the Ninji usually is)

What should I do in that situation? Thanks!
I'm facing an issue with the custom growing vines, as I want it to grow downwards.

Code
; Extra bytes: 1
; - Bit 0: Direction. 0 = up, 1 = down.
; - Bit 1: Spawn a different tile when reaching the top of the level.
; - Bits 2-7: Unused.


So bit 0 at 1 means 00000001 to put in hex in Extra property bytes 1, right? And 00000001 = 1 in hex.

So:



Yet it doesn't work. Still growing upwards.
Is there something I'm missing? Probably, but I read an explanations from Frost like 6 times on the subject, and I still don't see what I'm doing wrong.
Super Mario Pants World
Luigi's Lost Levels
New Super Mario Pants World
Luigi's Lost Levels 2 - Back With A Revenge
Luigi's Lost Levels 3 - Electrik Boogaloo
VLDC12 - 72HoKaizo#1
"Extra bytes" in the sense of "extension", not "extra property bytes".
Unlike the extra property bytes, which are set by the CFG editor, extra bytes are set when you place the sprite. Specifically, when you insert a sprite manually, you'll notice that one field is called "extension". This is how you set the extra byte.
Originally posted by MarioFanGamer
"Extra bytes" in the sense of "extension", not "extra property bytes".
Unlike the extra property bytes, which are set by the CFG editor, extra bytes are set when you place the sprite. Specifically, when you insert a sprite manually, you'll notice that one field is called "extension". This is how you set the extra byte.

Oh! Ok
Then how can I make a GHB question mark block spawn a downward growing vine?
I thought that if the direction was set in the cfg, then I would just have to tell my block to spawn the sprite, but now I need to tell it to spawn the sprite with the extension and I didn't find such a thing
Super Mario Pants World
Luigi's Lost Levels
New Super Mario Pants World
Luigi's Lost Levels 2 - Back With A Revenge
Luigi's Lost Levels 3 - Electrik Boogaloo
VLDC12 - 72HoKaizo#1
Is there any way to make the music accelerate when timer is below 100 if using MSU1 enhancement chip?

Hello! The most recent version of Lunar Magic is confirmed to be functional on Windows XP. Does it work on Windows 2000?
"Glauben Sie nicht alles, was Sie im Internet lesen." - Karl Marx
I would like to know how I could change the propriety of a foreground title.
The idea is that I would like to change the propirety of a custom surface to make it damage Mario when he touch it.
Originally posted by Zanoss
I would like to know how I oculd change the propriety of a foreground title.
The idea is that I would like to change the propirety of a custom surface to make it damage Mario when he touch it.

Select the map16 tile you want to change the behaviour in the map16 editor #lm{16x} and then just change the "Act as" value of the tile. Changing it to 12F will make the tile act like a muncher (and thus, damage Mario on contact).
  • Pages:
  • 1
  • 2
  • 3
  • 4
  • 5
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
Link Thread Closed