Banner
Views: 762,354,131
Time:
19 users online: B1_Gaming, Darolac,  Deeke, DPBOX, eric99333,  Erik, Flagpole1up, Fullcannon, gamerjohn1991, Infinity, jona255,  Meirdent, Mogu94,  Nameless,  Noivern,  randomdude999,  Sayuri, The Hacking Yoshi, Yung Gotenks - Guests: 56 - Bots: 309Users: 40,072 (1,956 active)
Latest: vcjameviu
Not logged in.
PIXI v1.2: Some Sprite Insertion Tool of Sorts
Forum Index - SMW Hacking - Resource & Tool Releases - PIXI v1.2: Some Sprite Insertion Tool of Sorts
Pages: « 1 2 3 411 12 »
Download
GitHub


Gotta have to change that GitHub repo name eventually...
Anyway, here it is, my new sprite tool. I did release a bit of a "preview" during C3 but this is a slightly more refined version.
I also spent the past week+ on converting some of the original sprite tool sprites for asar + sa-1 support. No need to thank me.
(That said, the sideway thwomps are a bit weird with their graphics appearing cut off. No idea why that happens, so if anybody figures that out, tell me :3)

  • Softcoded
    The old sprite tool inserted its code as a preassembled byte array and then sets up the calls (hijacks) for it. Put simply, it was a nightmare to read and figure out what hijacks it applied. Here, the applied asm file is available for editing. The tool only generates the binary tables that are included by the asm. So you can basically look at the code and edit it (to some extent) as you like.
  • Dynamic SA-1 support
    Kinda goes hand-in-hand with the softcoded part. The tool doesn't really care if the ROM is SA-1 or not. HOWEVER, there is an asm file with all sa-1 defines that will be default included in every sprite, so you don't have to stick that annoying read1() check for sa-1 at the beginning of every sprite. For all sprite relevant addresses, there exists a define. More info on that is in the readme.
  • GPS Interface
    I basically copied over the interface from p4plus2's GPS for 2 reasons.
    1. It's simple, easy and comfortable to use.
    2. It's a lot more comfortable to work with multiple tools if they all use the same interface.
  • Shared Routines
    Again, kinda goes hand-in-hand with the GPS interface, so why not copy that over as well? I mean that quite literally, that is 99% the code from GPS copied over. As a friend of mine likes to say: "Why bother to reinvent the wheel".
    As such, I included a bunch of common routines you may need in sprites. Check out the included sprites to see how some are used.
  • Asar Only
  • So yeah, this is one thing that's probably gonna be a problem for many people. The tool only allows asar coded sprites... no more TRASM. That is again for 2 simple reasons. 1. TRASM sucks and 2. I'd have had to literally overthrow the way my entire code works to include this shitty assembler, so no thank you.
  • Sprite Tool support
  • The tool basically works the same as sprite tool and can be applied on top of a ROM that used sprite tool before. It will of course remove all the sprites though.
  • Per Level Sprites
    So here it is, the real reason why I even got into this in the first place. My stupid crazy idea. I noticed we have a lot of things that run on a per level basis. With Vitor's uberASM tool now even NMI. So I thought to myself, "Why not sprites?" and with that, the idea was born.
    This tool "sacrifices" 16 global sprite slots and turns them into per level slots. Meaning, you can assign the same sprite number to different sprites depending on the level. Sprite B0 could be a thwomp in level 105 and a hammer bro in level 106 or a reverse boo in level 107.
    The 16 slots from B0-BF can be freely assigned across all $200 levels.
    Likewise, you can also have a shooter, that shoots sprite B0, which will spawn a sprite depending on the level.
    I figured this could be especially neat for collabs and such.
  • Poison Mushroom
    Sprite Tool had a needlessly complicated way to insert the poison mushroom with another preassembled code and then setting up hijacks, all wrapped in a cfg file that doesn't follow the same format as any other cfg file. So I just included a patch you can apply to enable the poison mushroom. It doesn't really have anything to do with the tool. Just grab asar, run the patch, done.
  • New CFG Editor
    Because I fucking can!!!

v1.1
  • Cluster and Extended Sprites
    Now supports the insertion of cluster and extended sprites, done so, via the same list file. Just use the header "CLUSTER:" or "EXTENDED:" to switch modes. (or "SPRITE:" but that's default).
    Cluster and extended sprites are capped at 0x80 slots. They also get inserted in addition to their original lists, not like custom sprites with their own lists. Which basically just means that, when inserting a cluster sprite in slot 0, you actually have to spawn number 0x09 (and 0x13 for extended).
    I realize this might be slightly stupid, but in the end, it's up to the coder to just add the offsets. Better than leaving it up the the enduser to start with slot 9/13. Also, sa1def.asm provides defines:
    Code
    !ClusterOffset  = $09
    !ExtendedOffset = $13


    Also, the way they are inserted now, as oppose to previous tools, they have to end in an RTL, not RTS! The entry point is also no longer controlled by labels, instead it is tagged just like other sprites with:
    Code
    print "MAIN ",pc

  • Up to 4 Extra Bytes
    Controlled via the cfg file and supported by Lunar Magic, you can set up to 4 bytes of custom properties when placing the sprite in the level. Which means you now have 1024 times as many options per sprite as with just the extra bit.
    I'd however advice against abusing this too much. For A) sprites still work in 8bit mode and can thus only support 255 bytes of sprite data. Randomly enabling more custom bytes just handicaps yourself. Use it for variable number settings (like how many projectiles a piranha plant shoots).
    On the other hand, sprites B0-BF (the per level sprites) always have all 4 custom bytes enabled.
    Also, be EXTREMELY CAUTIONS with this feature. Changing the number of extra bytes for an already inserted sprite will corrupt the level data, as Lunar Magic will expect the sprite to be a different size than it is. So make sure to delete all instances of a sprite before changing it's number.
    Again, sa1def.asm provides defines to access these bytes within your code:
    Code
    !extra_byte_1
    !extra_byte_2
    !extra_byte_3
    !extra_byte_4

  • New Command-Line Options
    In addition to the new options for the cluster and extended directory, I changed some of the option names for using custom directories as command line option, so do lookout for that if you had some scripts setup or something.
  • Updated the CFG Editor
    Other than fixing bugs and implementing the new extra bytes, it can now also function as Tweaker for ROMs. So basically, you can open your ROM with it and use it like the Tweaker tool, except this one has all the bits named :3


Pointless Screencap:
Wow. How nice.
Now GPS Stuffs are in Sprite Tool!
Actually we can save a lot of bytes by doing that, also it gives some ease with programming.

Originally posted by JackTheSpades
Per Level Sprites


How will it affect with LM's custom sprite list by the way?

--------------------
Receiving?
Was there anything wrong with the C3 thread? And what does the name stand for?

Anyway...well, it's still not Daiyousei, so I'll just have to keep waiting. It's something, though.
Originally posted by imamelia
Anyway...well, it's still not Daiyousei, so I'll just have to keep waiting. It's something, though.

I'm too lazy to read everything about that tool, what makes it special/different compared to this one?
imamelia has some very specific requirements before he can do literally anything that can actually be worked around already but that doesn't seem to work for him for some reason.

--------------------
Your layout has been removed.
Originally posted by Erik557
Originally posted by imamelia
Anyway...well, it's still not Daiyousei, so I'll just have to keep waiting. It's something, though.

I'm too lazy to read everything about that tool, what makes it special/different compared to this one?

Some core ideas of Daiyousei, as far as I can recall are:
hijacks for all types of sprites
mirrors for the 16 bit addresses within sprites
using the extra bytes for sprites which is an element supported by Lunar Magic
using the EE bits in the sprites as part of the sprite number, thus going from 00-FF to 000-3FF.
Enhanced CFG files.

My main problem lies withe last part as this would break backwards compatibility with most sprite tool sprites.
As for other stuff, there is actually a lot that I want to add to this tool such as:

-Cluster and Extended sprites seem to have easy enough hijacks to add support for.
-The additional bytes per sprite also seem neat, since they allow for vast custom behavior per sprite slot. Plus things seam easy enough to pull of.
-More stuff in CFG files: Like information to build .ssc, mwt, mw2 and s16 files for Lunar Magic.

For now though, I just want confirmation that this works as intended :3

Originally posted by imamelia
Was there anything wrong with the C3 thread? And what does the name stand for?

Pretty Inaccurate Xylophone Imitation.
Also yes, the C3 version was a bit buggy. Most notable the fact that it didn't put the routines file in the correct folder.

--------------------
Anime statistic on MyAnimeList:
400 animes completed ✓
6000 episodes completed ✓
100 Days completed ✓
... what even am I doing with my life?
Can you make it insert OW sprites in SA-1, just like you inserted them with some kind of system on VLDC9?

--------------------
Your layout has been removed.
What was used for VLDC9 was actually just a patch Lui37 made.
Though Jack could totally include that if he wants to, I'd be fine with all the sprites I made to be included too.

--------------------
Your layout has been removed.
Originally posted by leod
What was used for VLDC9 was actually just a patch Lui37 made.
Though Jack could totally include that if he wants to, I'd be fine with all the sprites I made to be included too.

I know that, but I looked through his file in but no luck

--------------------
Your layout has been removed.
This seems like a really good alternative to Sprite Tool... I was looking for a different program or a way to work around the fact that Sprite Tool seems to like causing my game to freeze at the "Nintendo Presents" screen, and I thought I'd try this, but whenever I try to insert any sprites I get a list of errors like this:

sprites/fire_bro.asm:24: error: Unknown command. [TILEMAP dcb $42,$4A,$7F,$00]
sprites/fire_bro.asm:25: error: Invalid input. [dcb $42,$5A,$2F,$00]
sprites/fire_bro.asm:26: error: Invalid input. [dcb $44,$4A,$7F,$00]
sprites/fire_bro.asm:27: error: Invalid input. [dcb $44,$5A,$2F,$00]
sprites/fire_bro.asm:29: error: Unknown command. [HORZ_DISP dcb $00,$00,$08]
sprites/fire_bro.asm:30: error: Invalid input. [dcb $00,$08,$00]
sprites/fire_bro.asm:31: error: Unknown command. [VERT_DISP dcb $F8,$08,$08]
sprites/fire_bro.asm:32: error: Unknown command. [TILE_SIZE dcb $02,$00,$00]
sprites/fire_bro.asm:34: error: Unknown command. [PROPERTIES dcb $40,$00]
sprites/fire_bro.asm:42: error: Invalid number. [dcb "INIT"]
sprites/fire_bro.asm:43: error: Label SUB_GET_DIR not found [JSR SUB_GET_DIR]
sprites/fire_bro.asm:65: error: Invalid number. [dcb "MAIN"]
sprites/fire_bro.asm:66: error: Unknown command. [HAMMER_BRO_JSL PHB]
sprites/fire_bro.asm:69: error: Label START_HB_CODE not found [JSR START_HB_CODE]
sprites/fire_bro.asm:78: error: Unknown command. [X_SPEED dcb $00,$F8,$00,$08]
sprites/fire_bro.asm:79: error: Unknown command. [TIME_IN_POS dcb $50,$20,$50,$20]
sprites/fire_bro.asm:80: error: Unknown command. [TIME_TILL_THROW dcb $20,$72]
sprites/fire_bro.asm:82: error: Unknown command. [RETURN RTS]

(Just a small excerpt because the actual full output was pretty long)

Did I miss something or is this a bug? It's probably me because I don't really know much about this stuff yet. I'm using the SA-1 1.26 patch if that helps... And I've already run the SA-1 converter on these sprites.

--------------------
Someday, I will finish what I sta-
It's not a bug. It's caused by the fact that this spritetool forces the use of asar however the sprites aren't written in asar format (Labels work a bit different, dcb is db in asar etc)

There's this tool to convert it though.
Copy the contents of your ASM file to this tool, then replace the old contents with the output the tool gives.

e: fuk u
Thank you both so much! :)

Update: It works!

--------------------
Someday, I will finish what I sta-
The tool includes Trashkas, btw., though the readme could have mentioned that and what to do in case you have an error like that.

--------------------
Okay, my layout looks ugly.
If the PIXI is accepted and SpriteTool become obsolete, i wonder what would be the new version of Lunar Magic for custom sprites insertion.


Originally posted by Roberto zampari
If the PIXI is accepted and SpriteTool become obsolete, i wonder what would be the new version of Lunar Magic for custom sprites insertion.


It would be almost the same thing, nothing more, nothing less; it's unlikely that newer versions of LM would change THAT much. The thing would be the handling of the new properties and such.

Sincerely, I'm hoping to see this tool replacing SpriteTool. The concept of use seems better, and the assembler used definitely is a plus (TRASM syntax gives me the creeps). The idea of shared routines, as seen with GPS, is the perfect solution to avoid the waste of ROM space from all those GET_DRAW_INFO, SUB_OFF_SCREEN and SUB_HORZ_POS routines we had to include in every sprite. I'm surprised that this feature wasn't implemented before.

--------------------


Signed Major Flare, a.k.a Br OW Hacker.


Does it support status override?
I mean, the highest bit of Extra Properties Byte 2.
It crashes when I tried to use the sprites that use it on this tool.

--------------------
Receiving?
No idea what status override is suppose to be. First time I've ever heard of it. Much of the code was just taken from sprite_tool, so if it worked there it should work here too.
That said, as far as I recall, extra property byte 2 (just like 1) is just an additional byte in memory. It doesn't serve any special purpose other than allowing you to have different behaviors on the same asm file with different cfg files.

--------------------
Anime statistic on MyAnimeList:
400 animes completed ✓
6000 episodes completed ✓
100 Days completed ✓
... what even am I doing with my life?
Bit 7 of extra property byte 2 can enable status override so it isn't "just" an additional byte you can use.
Status override allows you to override sprite states ($14C8) so you can write your own. Sonikku talked about that a bit in the Advanced asm thread
But yeah, the feature is almost never used and not a lot of people even know about it.
Pages: « 1 2 3 411 12 »
Forum Index - SMW Hacking - Resource & Tool Releases - PIXI v1.2: Some Sprite Insertion Tool of Sorts

The purpose of this site is not to distribute copyrighted material, but to honor one of our favourite games.

Copyright © 2005 - 2019 - SMW Central
Legal Information - Privacy Policy - Link To Us


Total queries: 21

Menu

Follow Us On

  • Facebook
  • Twitter
  • YouTube

Affiliates

  • Talkhaus
  • SMBX Community
  • GTx0
  • Super Luigi Bros
  • ROMhacking.net
  • MFGG
  • Gaming Reinvented