Language…
6 users online: crm0622, Danik2343, Firstnamebutt, Mario's GameBase,  Segment1Zone2, tOaO - Guests: 146 - Bots: 337
Users: 64,795 (2,381 active)
Latest user: mathew

The GIEPY Standardization Project

Finally, due to the new sprite hijacks my modified Tessera was no longer any good so I ended up having to wait on this, but I also wanted to use something more "official" anyway. Very much appreciated Telinc, will report any bugs I find.

Edit: So I don't know if this was part of the update yet or not but 6MB+ SA-1 roms still don't work, that's all I've noticed for the moment.
Originally posted by Telinc1
If you use Lunar Magic 3.00's new features on a ROM, the game will crash at the title screen unless you reinstall the system patch (see above) afterward. As usual, keep backups, too.

What features you're talking about? The size of the levels?
By the way, how can i do backups?

Would you plan to upload GIEPY in the tools section?
Originally posted by Roberto zampari
By the way, how can i do backups?

By making a copy of your rom and saving it somewhere periodically?
                                                                                                                  
                              
Originally posted by mario90
Edit: So I don't know if this was part of the update yet or not but 6MB+ SA-1 roms still don't work, that's all I've noticed for the moment.

I'm sure you have to manually change sa1rom to fullsa1rom in GIEPY's ASM files to fix that.
Originally posted by Erik
I'm sure you have to manually change sa1rom to fullsa1rom in GIEPY's ASM files to fix that.


This was the first thing I tried in fact, didn't work. It just claims the rom has no space at all if extended past 4MB
hm. the asar version is probably outdated then... I'd tell you to just replace the dll with the latest version, but I think something inside Asar changed starting in 1.60 which breaks some older stuff. So you'll have to wait for Telinc to get confirmation on if you can just replace it or if he'll need to update stuff for that to work.
Please keep at it. I don't know what to do with my hacking project, when it comes to sprites. Do I wait for GIEPY?



YouTube Twitter Twitch
Originally posted by Conal
Please keep at it. I don't know what to do with my hacking project, when it comes to sprites. Do I wait for GIEPY?

I'm going to echo this question. Except I also just have no idea how GIEPY works. I took one look at it and went NOPE! It looks a lot more complicated than pixi.

I figure since I'm starting a new project I might as well use all of the brand new tools, including this one since it will become standard. I tried the readme file on how to use it, but couldn't understand a word of it.
                                                                                                                  
                              
Originally posted by LethalBrownies
Originally posted by Conal
Please keep at it. I don't know what to do with my hacking project, when it comes to sprites. Do I wait for GIEPY?

I'm going to echo this question. Except I also just have no idea how GIEPY works. I took one look at it and went NOPE! It looks a lot more complicated than pixi.

I figure since I'm starting a new project I might as well use all of the brand new tools, including this one since it will become standard. I tried the readme file on how to use it, but couldn't understand a word of it.

The list.txt functions just like it PIXI's, just with some format changes. You should use Piee, which is the GUI of GIEPY and super user-friendly. Also take this into account that if you want to use PIXI sprites.
Originally posted by Conal
Please keep at it. I don't know what to do with my hacking project, when it comes to sprites. Do I wait for GIEPY?


I'll lay out the information so you can make an informed decision here. GIEPY allows you to use around 768 sprites. You can even replace vanilla ones, or edit disassemblies of the originals and replace them with those. For example, either you or someone else with ASM knowledge could use a disassembly of the timed lift sprite and have the timer be set by the extension bytes in LM. Because of this, you don't bother with extra bit settings or inserting cfg files for the same sprite in multiple slots for different timers. You simply have 1 sprite and you can change its settings right in LM. You can do more than this of course, because each sprite can have up to 4 extention bytes. So while you can use 1 of those for the timer, you could use another to set it to move in certain directions for example and more. If you're capable of making use of any these things then GIEPY is right up your alley. Even if you yourself can't do it, then it probably sounds really appealing for the future does it not?

Originally posted by LethalBrownies
I'm going to echo this question. Except I also just have no idea how GIEPY works. I took one look at it and went NOPE! It looks a lot more complicated than pixi.

I figure since I'm starting a new project I might as well use all of the brand new tools, including this one since it will become standard. I tried the readme file on how to use it, but couldn't understand a word of it.


I'm sure GIEPY will be a lot easier to use once its standardized. Like Darolac mentioned, Piee takes care of most of the user friendly side of things. I'm pretty sure the complications come from people splitting focus between GIEPY and Pixi and making different versions of their sprites for both because of their different libraries and formats. Strictly speaking, GIEPY is better for the reasons I replied to Conal with. Its much better for the community, and I definitely know that it would make community and team hacks easier to manage with sprite usage. And I'm just gonna echo Ladida for the rest because he said it best earlier in the thread.

Originally posted by Ladida
this is a golden opportunity to make beneficial changes (for smw hacking as a whole, not just for Your Hack™)
I was testing the new giepy (using lm 3.00 and sa1) and my sprites works different, the RandomRange doesn't work properly and the spawn of original sprites is not working.

I was using SpawnSpriteAtOffset, SpawnSprite and RangedRandom.

EDIT:
The RangedRandom routine doesn't work, i did this, that works fine:

https://pastebin.com/PXNFR1DA

Basically calculates MaxValue*RandomValue/255

The original sprite routine, spawn incorrect sprites, for example if i try to spawn a mushroom, it spawn a boo, i want to spawn a Key, it spawn a goomba.

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.

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

Youtube
Twitter
SMWControlLibX GitHub
My Discord Server
Snestorage where you can download my resources
Originally posted by anonimzwx
I was testing the new giepy (using lm 3.00 and sa1) and my sprites works different, the RandomRange doesn't work properly and the spawn of original sprites is not working.

I was using SpawnSpriteAtOffset, SpawnSprite and RangedRandom.

EDIT:
The RangedRandom routine doesn't work, i did this, that works fine:

https://pastebin.com/PXNFR1DA

Basically calculates MaxValue*RandomValue/255

The original sprite routine, spawn incorrect sprites, for example if i try to spawn a mushroom, it spawn a boo, i want to spawn a Key, it spawn a goomba.

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.

Is the sprite spawning routine the same as the one Telinc1 published in this thread? Because if it is I had no problem making my boss spawn thrown blocks, which are a original sprite.
Originally posted by anonimzwx
Even normal sprites acts weird:


That seems like another problem related to load.asm. I will try to reproduce this.
Originally posted by Darolac
Originally posted by anonimzwx
I was testing the new giepy (using lm 3.00 and sa1) and my sprites works different, the RandomRange doesn't work properly and the spawn of original sprites is not working.

I was using SpawnSpriteAtOffset, SpawnSprite and RangedRandom.

EDIT:
The RangedRandom routine doesn't work, i did this, that works fine:

https://pastebin.com/PXNFR1DA

Basically calculates MaxValue*RandomValue/255

The original sprite routine, spawn incorrect sprites, for example if i try to spawn a mushroom, it spawn a boo, i want to spawn a Key, it spawn a goomba.

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.

Is the sprite spawning routine the same as the one Telinc1 published in this thread? Because if it is I had no problem making my boss spawn thrown blocks, which are a original sprite.
Originally posted by anonimzwx
Even normal sprites acts weird:


That seems like another problem related to load.asm. I will try to reproduce this.


I am using the spawn routine that is on the new giepy.
I am using LM 3.00 and Sa1 maybe that affects, i dont know.

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

Youtube
Twitter
SMWControlLibX GitHub
My Discord Server
Snestorage where you can download my resources
Originally posted by anonimzwx
I am using the spawn routine that is on the new giepy.
I am using LM 3.00 and Sa1 maybe that affects, i dont know.


Could you try redownloading the spawning routine (spawn.asm) from that thread and trying again? Maybe Telinc1 forgot to add it on the new GIEPY (judging by the "last edited" data).
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 development 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.
What about the GIEPY sprites?
Would the staff convert them into PIXI?
Originally posted by Roberto zampari
What about the GIEPY sprites?
Would the staff convert them into PIXI?


Aren't most of GIEPY sprites made by active people? These should be converted by the actual creators instead of the ASM team, especially when they're busy with the patch remod, I believe.
Originally posted by Roberto zampari
What about the GIEPY sprites?
Would the staff convert them into PIXI?

What LX5 said; for my part, I already started to convert my GIEPY sprites to add a PIXI version, and I recommend all other coders of GIEPY sprites to do so.