Language…
14 users online:  bebn legg, bradcomp, DanMario24YT, Dennsen86, Hammerer, KaptainAhab,  MarkAlarm, mikeeeeee83, oliver1, playagmes169,  Sayuri,  Segment1Zone2, signature_steve, Sweetdude - Guests: 310 - Bots: 387
Users: 64,795 (2,371 active)
Latest user: mathew

The GIEPY Standardization Project

(i know this looks long and that's because it is long but most of you are interested only in the middle part, i.e. the third list)

For those of you on Discord, I have hinted this for a while. It is time it finally went public.

In August 2017, the sprite remoderation was started. Let me state this right now: I do not think it was a mistake, but the choice of PIXI, a brand new tool, was definitely rushed. As it stands right now, the section is almost completely converted to PIXI, which turned out to be a very unstable tool. As a result, the community has become quite split over which sprite tool is the best. We should settle this once and for all.

My proposal for the definitive standard sprite tool is boldowa’s GIEPY. Like PIXI, it is new, but I hope that shouldn’t be a problem if everyone thoroughly tests it beforehand.

I will first cover my reasoning behind this whole proposal. If you’re not interested in that, you can skip to the middle of the post which outlines my plan for the standardization and how you can help with it.

Let me show you why I think GIEPY is a good choice by giving you a list of things it does better than SpriteTool and/or PIXI:

  • User friendliness. GIEPY has a command line interface (called GIEPY) and an easy-to-use GUI (called Piee). Unlike other tools (GPS with Grilled Pancake Salad, AddmusicK with AMKGUI), the GUI is not an unstable wrapper around the tool. Instead, both GIEPY and Piee use a library called Mewthree which handles sprite insertion.
  • Documentation. Unlike PIXI (and, to some extent, SpriteTool), GIEPY has detailed documentation which explains everything you need to know about using the tool, as well as its internals.
  • Support. boldowa is very active and responds quickly to issues on GitHub and messages in his Discord guild. Additionally, GIEPY’s code is quite clean, so it would be easy for someone else to manage it. Compare this to SpriteTool and PIXI, whose authors are inactive and whose source code is a mess.
  • Extra bits. GIEPY completely removes the concept of the extra bit. In SpriteTool and PIXI, the second extra bit was used to determine if a sprite is standard or custom, while the first extra bit was left free. GIEPY uses both extra bits as a single number called the “group”. Every group has a separate sprite list, so sprite 04 from group 2 and sprite 04 from group 3 can be completely different sprites. This allows it to override vanilla sprites and insert a total of 1024 sprites.
  • Shooters and generators. In SpriteTool and PIXI, a custom sprite’s type is determined based on its number. As we all know, C0-CF are shooters and D0-DF are generators. This meant you could have no more than 16 shooters and 16 generators in one ROM, which greatly limited their usefulness (so much, in fact, that most sprite remoderators decided it was better to completely drop support for generators). With GIEPY, the type of the sprite is specified in the CFG file, so you can have as many shooters and generators as you want.
  • Initializers and scrollers. GIEPY supports two new sprite types, initializer sprites (you might have heard them called run-once sprites) and scroller sprites (autoscroll generators).
  • Extra bytes. GIEPY handles extra bytes a lot better than PIXI did. The most important detail is that changing the number of extra bytes an inserted sprite has will no longer corrupt level sprite data. Additionally, generators, shooters, initializers, and scrollers all support extra bytes (up to 251 for scrollers).
  • Shared subroutines. GIEPY inserts shared subroutines (libraries) in a completely different way from GPS and PIXI. This makes them more stable and fixes the sublabel bug.
  • Assemblers. GIEPY supports inserting sprites with both Asar and TRASM. Additionally, it automatically detects a sprite’s intended assembler. In spite of this, I don’t think it’s wise to allow TRASM sprites into the section once again.
  • Compatibility. GIEPY is almost fully backward compatible with lists and sprites from both SpriteTool and PIXI.
  • Stability. GIEPY has strict assertion on every change it makes, so its system patch will refuse to assemble if it will break something. It also has the option of being completely uninstalled from a ROM.

Of course, there’s no way I won’t list disadvantages of GIEPY. Most of these can be worked around, however, and my plan for it can be found after this list.

  • SA-1. GIEPY has the same problem which PIXI does on SA-1: having more than 84 sprites in a level will crash the game, even though the SA-1 pack can supposedly handle up to 256. I’m currently debugging the issue and will hopefully manage to fix it soon.
  • Conversion. Unlike PIXI (which will attempt to remove SpriteTool when used), GIEPY will not remove any sprite tools previously used on a ROM. Instead it, it will simply refuse to install its system patch.
  • CFG editor. SpriteTool and PIXI both have their own CFG editor. GIEPY, on the hand, doesn’t. Additionally, its CFG format is different, so you have to edit CFG/JSON files manually.
  • Extra bits. As you may have guessed from the above list, GIEPY’s new group system breaks the concept every hacker is familiar with: the difference between a “clear” and a “set” extra bit. Naturally, this complicates sprites with different behavior based on the extra bit.
  • Spawning. Because of the group system, the procedure for spawning a new sprite is different. It involves swapping two instructions but does break every single resource which spawns sprites, including other sprites, blocks, UberASM code, etc.
  • Overworld sprites. GIEPY does not support inserting overworld sprites, but neither does PIXI. I’m still uncertain about boldowa’s plans for this, but there is no guarantee they will be added.

Now for the part which most of you will be interested in. This is my detailed plan for what should be done during the standardization, how I can deal with it, and how you can help with it. The first list documents what I think should be standardized. I ask every person to read this list and discuss the items on it in this thread.

  • Testing. GIEPY is a relatively new tool. I’ve already tested quite a bit with it, but I encourage people to test it themselves. I am not going to start any work on the standardization until everyone who tests it declares it bug-free.
  • Sprite configuration. GIEPY supports using both CFG and JSON files for sprites (YAML and other formats are also planned). Unlike PIXI (where only JSON supports specifying Lunar Magic display data), all supported formats can specify the same information, just laid out in a different format. To avoid confusion, we should standardize a format and convert all sprites to it (this can be done automatically with a script).
  • Extra bits. We have to decide on a standard for these. Up till now, sprites could easily have different behavior based on the first extra bit. My proposal is as follows: Convert all sprites which use the first extra bit and let them use either their group number or their extra bytes. If you insert the sprite with no extra bytes defined, it will use its separate behavior if it’s in group (extra bits field in Lunar Magic) 1 or 3. If you insert the sprite with at least one extra byte, it will instead use its first (or, if that’s in use, the next available) extra byte to determine its behavior. With this system, your old levels will still be compatible (because your sprites would use their group number) and usage of the “extra bit” will slowly fade away over time.
  • Sprite spawning. Unlike SpriteTool and PIXI, the sprite behind a number also depends on the group (extra bits field in Lunar Magic). If a sprite needs to be spawned, the group number should also be specified. My proposal is as follows: If a sprite uses defines in its ASM file to determine the sprite number to spawn, add another define for the group. If it uses its extra bytes, squeeze the group in them. If it uses its extra property bytes, use GIEPY’s new “unique number” CFG file (it is an 8-bit number which is loaded into A when a sprite is called). A lot of this could be automatically done with a script. In the case of GPS and other tools, modify the routines (and hosted resources) to accommodate the group.
  • Routines. GIEPY has a new library specification. I have two proposals here. One, we could ship GIEPY with PIXI’s routines (carefully tested and fixed) and require users to insert it with PIXI compatibility mode. Two, we could standardize a set of native GIEPY libraries (with GetDrawInfo, SubOffScreen, etc.) and convert every hosted sprite to use them instead (this can be automatically done with a script). I would rather implement the second proposal, but the first one requires less manual work.
  • Generators. GIEPY makes generators useful once again by dropping the hard limit. While they still are limited when compared to UberASM, they are easier to use. I propose to bring back the generators which were firebombed during the remoderation but also host them as UberASM code.

The items below require, at very least, ASM knowledge. The tools require higher-level programming languages. Those who want to help should reach out to me on Discord, preferably by DM-ing me (though you could also ping me in any channel). My tag is Telinc1#2670.

  • CFG editor. This is the first big problem. The creation of a new CFG editor is essential. Being the perfectionist I am, it would also be nice to make it an all-in-one tool which can also edit vanilla sprites (a la Tweaker). I am willing to create this editor myself but the best language I could program it with is Java since I don’t know any language which would be potentially more suitable. While this does mean it will be cross-platform, running it will require you to have the JRE installed (aside from all of Java’s quirks like a long start-up time). If anyone else is willing to create this editor in a language which is more suitable for the job (like C# or Qt with C++), please do say.
  • CFG file converter. GIEPY works with SpriteTool and PIXI configuration files, but it throws warnings for them. Additionally, generators and shooters need to be converted in order to be properly inserted. A good solution for this is a tool which can convert a whole directory of CFG/JSON files into the format we decide to standardize. If I build the CFG editor, I will make this a built-in feature of it.
  • Sprite tool remover. GIEPY does not (and will never) remove old sprite tools. The usability of PIXI on old ROMs was a big problem with the sprite remoderation, but it’s an even bigger problem now. I do not want to require anyone to port their hacks just because the staff team is pushing another standard, which is why I want a tool which can remove any sprite tool (obviously SpriteTool and GIEPY, but also exotic cases like Tessera, GEMS, Daiyousei, Cluster SpriteTool, manual insertion patches, and others). This ion cannon could very well be an Asar patch, but I’m not sure if SpriteTool can be removed through Asar’s limited looping functionality. I haven’t looked into this yet, but I might need external help.
  • Sprite remoderators. The standardization of GIEPY will require us to do a lot of manual work in bulk. I would like every current sprite remoderator to say if they would be interested in helping with this. Additionally, I’m looking for new helpers to take care of the GIEPY situation.

That should be about it. The project will start when we have decided what to make standard. If anyone is opposed to this, please state your reasoning. Any other comments or additions to the plan are welcome, too.

After reading what was posted and seeing some of the fresh comments from the Discord all I will say are that if helps push and stabilise SMW hacking then I am all for it.

I saw some comments on Discord for not needing a CFG Editor but I honestly think it would be a great addition as it allows for easy editing of existing sprites.
I know that hex editing and other tweaking is not the hardest in the world but it could throw off newcomers to hacking and delving into using custom assets.

I say the pros outweigh the cons and having an active creator just sounds like the most logic way to progress with adding in sprites and having a reliable and supported insert tool.
I might have significantly reduced free time these days but I'll try to help out as best as I can, given my experience with sprites in particular.



In the same boat as 1UPdudes, if this will help SMW hacking in the future (which I'm here thinking "of course it would!") then kick Pixi to the curb ASAP and replace it with GIEPY.
The cons that are present I think are justifiable in the sense of most of them can be fixed or just gotten used to, like the whole extra bit thing being different for example.

Seems like an obvious choice to me but eh, we'll see.
Layout by RanAS, modified by yours truly.

I mostly just want something that makes custom sprite programming easier to learn and do. I've never made a custom sprite before, and looking at the situation now, I don't want to make one at this time, so I hope GIEPY will make spriting better.

I don't know if I want to participate in making GIEPY the new standard. There are pros and cons, but I can't decide which outweighs which. The lack of a CFG editor really makes me less sure.
YouTube
I could try to help. My standards aren't always the same as everyone else's, but it should at least be better than working with PIXI. I'd be willing to resubmit the sprites I have in the section if necessary (except maybe the old crappy ones).

Also, I don't know about existing sprites, but new sprites definitely should not use the extra bit, and I don't want any of mine in there using it either.

And I would like to see new shared subroutines designed for GIEPY. I don't know what all is out there already, but I might have some to contribute, and we could ask Katrina if she'd let us use hers.

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

I'm working on a hack! Check it out here. Progress: 64/95 levels.
I'll be honest, I'm skeptical about it. Changing the extra bits to what you call "groups" sounds like a big change. Would every sprite in the sprites section have to be modified to use it's custom function? Also it doesn't come with a CFG editor, which seems a little odd to me. Also the change in procedure of spawning new sprites, which breaks other spawns in the hack.

The best thing I can say about it is how backwards compatible it is with everything, and how it handles extra bytes, but for me that doesn't outweigh PIXI. It seems to me like it does most of what PIXI can do except with different procedures. For that reason, my vote is not for it.
My youtube: https://www.youtube.com/channel/UCbX4pLm713laHTRtLj9xpxw
My twitch: https://www.twitch.tv/theqwollone
Originally posted by telinc1
As it stands right now, the section is almost completely converted to PIXI, which turned out to be a very unstable tool. As a result, the community has become quite split over which sprite tool is the best. We should settle this once and for all.


Complaints about PIXI being unstable are irreleveant now, the newest version (when using -npl option of course) is very stable and has no problems when inserting a big number of sprites. (as far as I have used it in my experience though)

Originally posted by telinc1
SA-1. GIEPY has the same problem which PIXI does on SA-1: having more than 84 sprites in a level will crash the game, even though the SA-1 pack can supposedly handle up to 256. I’m currently debugging the issue and will hopefully manage to fix it soon.


This doesn't depend on SA1 though, the index to level sprite data when loading sprites in the vanilla game was always 8 bit and every sprite took a minimum of 3 bytes, so you could only spawn 84 out of 128 possible sprites per level (even less if you used sprites that use extra bytes) However I fiddled around with PIXI's main.asm and came up with this:

Code
org $02ABF3
	db $7F	;be able to load 128 sprites without issues

org $028B1D		;hijack
	JSR Hmm

org $02B5EC
Hmm:			;extended sprite data
	LDA $CF
	PHA
	LDA $CE
	PHA
	JSR $A7FC
	PLA
	STA $CE
	PLA
	STA $CF
	RTS
Welp:
	DEX		;actually this could probably be put
	DEY		;somewhere before the Welp jumps
	DEY		;now that I think about it
	JMP $A846

org $02ABEF
	JMP Welp
org $02A9DB
	JMP Welp


Code
SprtOffset:
	DEY			; move index to sprite data byte 0
	LDA [$CE],y		; format: YYYYEEsy, EE = Extra bits
	LSR #2
	AND #$03		; \ EE bits into A high byte
	XBA			; /
	INY #2			; \
	LDA [$CE],y		; / sprite data byte 2 (sprite number)
	DEY #2			; back to start of sprite
	
	;A = 000000EE NNNNNNNN (index to size table)
	
	PHP
	REP #$10
	PHX
	TAX
	
	TYA			; \
	CLC			; | Y += Size table
	ADC.l Size,x		; |
	XBA : LDA #$00 : XBA 	; |
	TAY			; /



	CPY #$00F9		;extended sprite data read
	BCC +
	REP #$20
	LDA $CE
	CLC
	ADC #$0080		;clever code Kappa
	STA $CE
	TYA
	SEC
	SBC #$0080
	TAY
+


	PLX
	PLP
   	INX               ; restore code
	JML $02A82E|!BankB		; return to loop


This was taken from Naked Aprons' special PIXI, for which I contributed this code.

The first part is all new, while the second one is just a modification of a part of PIXI's original code.
I haven't checked out Giepy's source code, so I don't know how applicable this is. (if this isn't then PIXI has one more pro over Giepy >:] )

Also tbh the removal of Extra Bits is rather major and having to recode everything that spawns sprites is also ugh. I won't lie, I'm against this project, but I'm probably the minority here sadly.

While the groups sound interesting and the sprite type being dependent on cfg is neat (actually PIXI makes a distinction between normal custom sprites and generators/shooters in its sprite data table, I haven't checked, but if you edited PIXI's source code, maybe you would be able to insert shooters and generators in any slot or just make a manually editable 256 byte table), it doesn't win me over. Most of the pros just fix minor inconvieniences (initializers and scrollers sound like they're useless imo) and the cons are more serious.
Check out Team Hack Fix/Translations' thread full of fixed and translated SMW hacks!

Wanted Permabanned or Dead by new staff team
I have to agree that I don't really see the need to do such a big remoderation to get an active tool developer and a infinitve number of generators (which could also be done by converting them to uberasm, I never use generators anymore). And who needs more than 16 shooters...pls..
The drop of extra bits is indeed a huge change and the reason why I decided to use pixi over giepy in my current project.

It would be nice if we actually wait with the remoderation until giepy acutally offers a huge benefit over pixi (like the insertion of overworld sprites for example).
Not like I can change your opinion, but it would be nice to wait a little bit longer for the next big remoderation (of ALL sprites and sprite spawning resources)
My Youtube channel

Currently working on:
Project C

Finished project:
people saying to wait, or naysayers in general:

here's the problem with waiting. currently, we're in a situation where lots of people are on the border about pixi. some havent even used it (sticking with good ol mior's), some are maybe in the process of transitioning. if we wait, then we're effectively "too late" because everyone will be too comfortable with puxi. it needs to be done now, while the wound is still fresh (well, not exactly right now, but yeah). this is a golden opportunity to make beneficial changes (for smw hacking as a whole, not just for Your Hack™), so pls dont bully the standardization project

chances are the pixi sprites will be backed up anyway
Originally posted by Ladida
for smw hacking as a whole, not just for Your Hack™), so pls dont bully the standardization project


Sorry, i didn't mean it that way.
I'm 100% for improving smw hacking and if the asmers on this site think that these changes are the right direction, then I'm supporting the project.
A backup would be kind of nice though, at least for a limited time.
My Youtube channel

Currently working on:
Project C

Finished project:
Skepticism over the repurposed extra bit was exactly what I feared would happen, especially with people who haven't used or tried GIEPY before. Let me state this argument once again, since it could have been missed by many (why does the first post have to be so big). By repurposing extra bits and using the extra bytes instead, you're opening up at least twice as many sprite slots (much more in practice). This doesn't seem like much, but it's incredibly good for team hacks and other big projects. If you don't see how, Team Haunted had this exact problem and GIEPY is ultimately how we solved it. By using extra bytes, you also get way more than just 2 options (up to about 4 billion if you use all 4).

The best part about my plan? It works for everyone. Both GIEPY and I have considered how difficult it is to switch to such a new system. GIEPY, by default, inserts sprites into group 2 and 3 if you omit the group number from the list file. This means that a legacy sprite can use the low bit of its group number (the old first extra bit) to change its behavior. For the end user (you), there won't be any change - you will still use extra bit 2 for a custom sprite with normal behavior and 3 for the same sprite with different behavior. My plan considers this - read the first post again. If we go through with this, we'll include legacy CFG/JSON files (guys, please do remember this is something you're supposed to be discussing, too) which will let you have your beloved extra bits. Hackers who are technically skilled enough to see the usefulness of GIEPY's groups can use extra bytes, instead. This gives everyone the workflow they prefer.

Originally posted by Qwoll
Changing the extra bits to what you call "groups" sounds like a big change. Would every sprite in the sprites section have to be modified to use it's custom function?

Sadly, yes, but as you can tell from the first couple of replies, there are people who are willing to help with it. Besides, it's not actually that hard at all for someone who knows what they're doing. It's true, it will take time (if I have to, I'll do everything myself, but I'll make sure it doesn't take half a year like the remoderation), but the end result will be easier to scale and a lot cleaner.

Originally posted by Qwoll
Also it doesn't come with a CFG editor, which seems a little odd to me.

A CFG editor is not necessary to edit CFGs, it just makes it easier. Besides, if we decide to use JSON, a CFG editor will be unneeded the file itself describes what everything is for. Open the JSON file of the Fire Bro in a text editor and tell me if you don't agree (if there no newlines, use something like Notepad++). GIEPY's JSON files are even more readable, by the way (they don't have Base64 data in them).

Originally posted by Qwoll
Also the change in procedure of spawning new sprites, which breaks other spawns in the hack.

Originally posted by Super Maks 64
...having to recode everything that spawns sprites is also ugh.

The hosted sprites can be taken care of with a script. Everything else will take no more than a minute to fix because converting the algorithm involves swapping two instructions.

Originally posted by Super Maks 64
Complaints about PIXI being unstable are irreleveant now, the newest version (when using -npl option of course) is very stable and has no problems when inserting a big number of sprites. (as far as I have used it in my experience though)

This is not something I can agree with. Even if you disable per level sprites to work around the freedata align bug, you're still left with all of PIXI's problems such as the sublabel bug when calling shared routines for the first time.

Originally posted by Super Maks 64
Also tbh the removal of Extra Bits is rather major...

Originally posted by NGB
The drop of extra bits is indeed a huge change and the reason why I decided to use pixi over giepy in my current project.

See the second paragraph of this post. My plan involves fixing everything in such a way that you can use the same procedure for inserting sprites.

Originally posted by NGB
I have to agree that I don't really see the need to do such a big remoderation to get an active tool developer and a infinitve number of generators (which could also be done by converting them to uberasm, I never use generators anymore). And who needs more than 16 shooters...pls..

An active tool developer is a lot more valuable than you think. Most of PIXI's problems came from Jack's inactivity and disinterest. Besides, GIEPY's clean code means anyone could manage it, not just boldowa. Generators may be useless for you (and me), but are easier for new hackers. 16 shooters might sound like a lot to you, but it's not that many in a big hack or a team project.

Originally posted by NGB
It would be nice if we actually wait with the remoderation until giepy acutally offers a huge benefit over pixi (like the insertion of overworld sprites for example).
Not like I can change your opinion, but it would be nice to wait a little bit longer for the next big remoderation (of ALL sprites and sprite spawning resources)

I agree that the lack of overworld sprites is a big problem. I would be willing to write the ASM for them and I'll talk to boldowa about implementing them along with minor extended sprites in a future version. Other than that, I do think GIEPY is already better. Don't worry about my opinion, the whole point of this thread is to change it. I'll repeat this again, converting sprite spawning resources can be done automatically.

Edit: I talked to boldowa about overworld sprites. He's against implementing them into GIEPY (even though I said I'd write all of the ASM for it) simply because it would make insertion speed slower (and also because they can't be used together with the other sprite types). I'm going to keep trying to convince him because that's not the best argument and I do agree that it's better to have overworld sprites in GIEPY rather than another tool or patch.

That should be all replies for now. Please ignore any mistakes I've made, it's not easy to type such a big post on Android.
Originally posted by telinc1
Routines. GIEPY has a new library specification. I have two proposals here. One, we could ship GIEPY with PIXI’s routines (carefully tested and fixed) and require users to insert it with PIXI compatibility mode. Two, we could standardize a set of native GIEPY libraries (with GetDrawInfo, SubOffScreen, etc.) and convert every hosted sprite to use them instead (this can be automatically done with a script). I would rather implement the second proposal, but the first one requires less manual work.


Just throwing this one in, but there will soon be a third option for what to do. This week, I've finally implemented include search paths into Asar, and I plan to extend it further by allowing you to drop a simple TXT file directly into the Asar directory (and potentially any directory with an Asar DLL) to make it read include paths from it.
What does this mean? Well, it would allow us to, for the first time, have a practical way of supporting a shared SMW ASM library among all of our tools that we could update independently of the tools and that would make code for the different tools more unified and thus easier to read.

To give a simple example, we could distribute a "libsmw.zip" on SMW Central (either directly with Asar/each respective tool or, preferably, as a separate file, since it would make it possible to update it without updating all of the tools). This ZIP file could have the following contents:
Code
libswm.zip:
-stdincludes.txt
-libsmw
--libsmw
---smw.asm
---sprites.asm
---blocks.asm
---[...]

Where stdincludes.txt would contain:
Code
./libsmw

You could now just unzip the contents of this ZIP file into the directory of Asar or your respective tool and it would automatically add libswm as an include path to everything it assembles. Now in each of our sprites, we could do something like
Code
incsrc "libsmw/smw.asm"
incsrc "libsmw/sprites.asm"

to get access to all of the defines, macros and routines we need. For example: smw.asm could do certain stuff that every single resources needs to do, anyways (such as setting SA-1 defines). One con of this would be that it would require all tools to use a unified way of handling routines, but I suppose that should be doable somehow? Also it would, of course, require the next version of Asar to actually be released, but I'm at a point where I actually have some steady progress going and have the most important features for a new version out of the way, so I feel somewhat condifdent that (unless something unexpected happens) it should at most take a couple of weeks for a new version to be ready, and since I expect this new standardization process to take some time to get started, anyways (mostly due to requiring tools), it seems like a reasonable enough time frame.

Now what this new shared library would be based on doesn't matter too much in my opinion, so it could as well be based on GIEPY.

But yeah, that's just one proposal for how to handle this. I see a couple of benefits in doing it like this, with maybe a few cons, but I think the pros outweigh the cons here.
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
So basically, extra bits will still exist, but with a different name and usage? That's what I conclude.

I barely hack SMW nowdays, but if this is going to be a progress in hacking (because honestly, PIXI was not) I'm in favor of this.
Layout made by MaxodeX
2021 TRENO vibe check thread
> Re: Shared routines.
I would say, the most common routines can be adopted in a such way that they are compatible with PIXI sprites (i.e. the input for SubOffScreen is A instead of Y) but others, the rarer used routines, can get replaced entirely.
For example, SubVertPos can get an update so that it stores the whole distance into scratch RAM just like SubHorzPos does (PIXI's SubVertPos stores the low byte to $0F and the high byte to A whereas SubHorzPos the whole distance to $0E) and has got the advantage.

> Re: Generators:
I have to say, moving all generators to UberASM was quite a bit of a dumb idea. I mean, sure, quite a few of them makes more sense as UberASM code instead of generators but others like sprite spawners are often build to be in-between some boundaries, not to mention that quite few became "lost" (aka they're neither found on the sprites nor on the section). So yeah, I wish at least some of the generators (specifically these used to spawn sprites) back.
You know, I completely hear how all the issues that would be made from this could be compensated for in the long run, but the way I'm feeling, they say don't fix what isn't broken, and I feel that having to recode every single sprite in the sprites section, as well as having to recode all the sprite spawns in a hack, could cause a variety of issues we're not considering because we haven't crossed that bridge yet.

I'd just rather not diverge from what's working around here. We have a good solid system, I prefer not to change it.
My youtube: https://www.youtube.com/channel/UCbX4pLm713laHTRtLj9xpxw
My twitch: https://www.twitch.tv/theqwollone
My layout has recently been updated, but you still have the old stylesheet cached and things might therefore not look as intended, as such, it’s recommended to reload the page.
Originally posted by telinc1
Let me show you why I think GIEPY is a good choice by giving you a list of things it does better than SpriteTool and/or PIXI:
  • Extra bits. GIEPY completely removes the concept of the extra bit.

Well, Tessera did this way back in 2013, but sadly, it didn’t end up being used much at all.

Originally posted by telinc1
  • CFG editor. This is the first big problem. The creation of a new CFG editor is essential. Being the perfectionist I am, it would also be nice to make it an all-in-one tool which can also edit vanilla sprites (a la Tweaker). I am willing to create this editor myself but the best language I could program it with is Java since I don’t know any language which would be potentially more suitable. While this does mean it will be cross-platform, running it will require you to have the JRE installed (aside from all of Java’s quirks like a long start-up time). If anyone else is willing to create this editor in a language which is more suitable for the job (like C# or Qt with C++), please do say.

Java is a pretty good language for this in my opinion.

I know the whole "completely drop out the extra bit concept" can sound a little too harsh since it has proven to be so useful for us over the years, but the Extra Byte concept is already so much more powerful that I won't ever miss the old extra bit. I'm all in for the replacement of extra bytes > bit.
A CFG Editor is not a major problem imo. Of course, it's useful, but it's not major enough to not consider GIPEY worth standardizing due to not having it. I'm also in favor of converting everything to use native subroutines from GIEPY. Yes it takes some work but still is a whole lot cleaner than just merging with PIXI's.

General thoughs on the re-standardizing:
SMW Hacking has always been a collection of community progress in utility/practicality and it's not the first time we drop out obsolete methods for the coming of a new better one. I'm in favor of migrating to GIEPY ASAP so we can start reporting it's bugs for people to fix. This is a long and slow process and the sooner we start, the better. I wouldn't even mind losing all sprites we have now if that meant we could settle the SPRITETOOL matter once and for all.

I'm glad people are willing to put effort in making a new better sprite tool. I can only imagine how stressful and tiring it can be. It's not very rewarding too... but if 1% of the community is willing to do it for the greater good, I feel like we ALL should feel grateful for that.

Originally posted by Ladida
(for smw hacking as a whole, not just for Your Hack™)
👏
I can help with writing a CFG editor.
Your layout has been removed.
Originally posted by Qwoll
they say don't fix what isn't broken


But that's precisely the point. PIXI is fundamentally broken, and a lot of people are displeased with it. Sure, it may work fine for other people, but that doesn't change the fact it is still a broken tool, and since the author lost interest and noone else seems interested in fixing those problems (either because of coding style or because there are simply too many of them), switching to a more promising alternative by someone who is still active and interested and which (I assume, I haven't actually looked yet) is more stable and/or has a cleaner coding style is actually a move that makes sense. The slight inconvenience of potentially having to switch tools or do some extra coding work should not make people want to stick to the inferior and buggier tool. Otherwise we would still be using xkas today, just because "it worked".
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!