12 users online:  AmperSam, ElpoderosoBv, gemstonezVA, Israelcv12cv, kaigem, Kimota, kyasarintsu, MarsAmpere, monkey03297, RenanSV, ShyGuyCentral, VinylHeart - Guests: 82 - Bots: 220
Users: 54,954 (2,121 active)
Latest user: DiegoLedezma

The GIEPY Standardization Project

Originally posted by Erik
After further consideration, the staff team has decided that, going forward, PIXI will be the standard tool for sprite insertion. Several key factors took part on why we reached this decision, including:
  • Compared to when initially released, PIXI is an stable tool which can insert standard, extended and cluster sprites correctly. GIEPY, on the other hand, currently suffers from some issues with SA-1 ROMs, has a conflict when inserting extended and cluster sprites at the same time, and the uninstaller is unfinished to account for the latest tool update. Most of these would require to recompile the tool, which isn't an easy task;
  • PIXI has the backing of active developing by many users, with future updates planned which might end up breaking GIEPY's support for PIXI mode even further. GIEPY, as it stands right now, only has Telinc1 as his active developer, and while its source code is open to contributors, it is still boldowa/6646's tool - who is inactive. And;
  • A move to GIEPY would imply having yet another massive sprite remoderation. When you consider the fact that some sprites are still unconverted from SpriteTool 1.40, having yet another remoderation alongside the ongoing patch one would not only be an extra burden for the already small ASM team, when you consider that PIXI would still be receiving support in parallel, there's always the risk that standards are implemented differently between tools - something which should preferrably be avoided.

We will still host GIEPY as an alternative for those who use it, but to the normal user we recommend you go with PIXI, as most of the sprites we host are either for PIXI or have a PIXI-compatible version.

It's great to already have a standard. It will surely make life easier to mods, coders and users.

Originally posted by Roberto zampari
What about the GIEPY sprites?
Would the staff convert them into PIXI?

MarioFanGamer converted all of my C3 sprites to PIXI and it's going to upload them into the section soon. I am also going to update the Annoying Bee sprite as soon as I can. I think only mine, last C3 Erik sprites and some of Mandew's are GIEPY-only, so its not going to be a big issue.
Does that mean this thread will need to be renamed "The GIEPY Alternativization Project?"

I'm certainly okay with this, as I have up to this point had no opportunities to mess with GIEPY or learn how to use it, haha. So it's nice to know that I'll be able to stick with PIXI without running the risk of falling behind the times.
                   --> My Spotify playlist <--

Deserved gratitude to Tattletale, the person who improved PIXI a lot and made it more reliable.

Layout made by MaxodeX
2021 TRENO vibe check thread
There are few mikeyk sprites that weren't converted into PIXI, such as...

-Albatross and bomber
-Ground Pound Koopa and boss

Does these sprites useless? we go again...


I'm working on a hack! Check it out here.
Originally posted by imamelia we go again...

I also would have prefered to have GIEPY as the standard tool, as it's the better tool by some difference and has a quite some things over PIXI, but I think having a clear standard to stick with outweights the benefits of using GIEPY. Besides, the current version of PIXI is far from the buggy tool it was in the past.
Originally posted by Darolac
Besides, the current version of PIXI is far from the buggy tool it was in the past.

It certainly isn't. I've used the two most recent versions of PIXI since I got back into hacking and haven't encountered a single "bug" that didn't turn out to be user error.
                   --> My Spotify playlist <--

Originally posted by anonimzwx
Also the new giepy have a weird error, for some random frames, custom sprites execute code of an original sprite, i really don't know why.

I've finally isolated the issue if this hasn't been found yet. There are a couple of instances of this in normspr.asm:
lda.b <--	!9e,x

Causing the sprite number to be read as a single byte. I noticed this while running SMW in a debugger. The best level to see happen consistently is 102. Anyway just changing all of them to .w seems to fix the issue.
Came across another small bug but this one seems to be with the tool itself. Using Extended and Cluster sprites, the tool seems to think of them as part of the same list so if you have 2 sprites using slot 09 for example, it considers them duplicates and throws an error.

Edit: Also seem to have found another bug. The "Invincible to star/cape/fire/bounce blk." bit in json files doesn't seem to get set into sprite's tweaker bytes. Maybe there's more bits like this in other ram addresses that don't get set but this one definitely doesn't.

Reconfirmed this bug, on a SA-1 rom with nothing else applied this still keeps happening, not every bit set in the json file seems to be set when loaded in game.
Triple posting but I did find some solid info on the above tweaker bits issue. I set all the bits in the json file so they'd all read #$FF so I could easily see which bits weren't being set, then I found the table in ROM where the data is inserted and found them.

And to easily show which bits these are that aren't being set -

iirc faerie either forgets or adds an extra . in the name of the setting which is wrong. you have to remove/add it manually by editing the json
Wow, you're right, that is an EXTREMELY obscure thing that you can easily miss. I originally wasn't going to bother using faerie since it was still an early release but I was mass porting a ton of my own sprites and it was way easier to use it to port the old cfg settings using it rather than by hand. And here I was thinking I was going to have to make a patch and manually edit the tables myself until it got fixed. Thanks for the info Erik.