Going on from what RPG Hacker said addressing Qwoll I feel as if sticking with older tools is just not viable in the long run. If we keep using a tool with an inactive user and stability issues the problems only snowball overtime.

If you want to stick with using older versions of tools nothing is stopping you from archiving compatible sprites and resources. I know some people still use romis sprite tool which is understandable.

I feel as if " i dont wanna change to another tool " is just a lazy excuse.
I know I have had my gripes with using PIXI for myself and other tools but honestly most issues can be solved with a bit of effort. Changing now is better than when we NEED to change.
It cuts out a lot of time spent avoiding the issue.

Alright I hear you guys. You've given me a slight change of heart, so I suppose I'm in favor of giving it a shot.
——————————————
My youtube: https://www.youtube.com/channel/UCbX4pLm713laHTRtLj9xpxw
My twitch: https://www.twitch.tv/theqwollone

I'm sorry for my low activity as of late, but I'm really busy this week. Let me address some more replies. Right now it's looking like this standardization will happen, but do not be afraid to raise any further issues you have, especially related to testing GIEPY. After all, it's still quite new.

Before everything, let me once again say that if you're interested in helping with this project or you want to talk to me about it, feel free to message me on Discord, where I'm Telinc1#2670.

At this point, we need to agree on standard formats. More specifically, GIEPY supports CFG and JSON (others are planned). Unlike PIXI, your choice of format doesn't restrict what you can do, so we'll just have to decide on which one is the easiest to use. Even though CFG files are smaller, they're harder to edit manually and would easily become an even bigger mess if more features are added.

As for overworld sprites, boldowa is very uncertain about them, but I still want a user-friendly solution. I have idea for that, but for now we (programmers) should decide how to ultimately handle them in terms of RAM organization and general code structure. I write my proposal for the specification later (hopefully on Friday, but maybe next weekend if I'm way too busy).

I suggest that you read the first post's list of other concepts we should standardize. I don't want to force anything on anyone, so I'd rather have opinions on my plan.


There's no way extra bits won't exist, they're part of the level sprite data. They are, as you pointed out, just repurposed in GIEPY, which essentially treats them as an extension of the sprite number. That's what allows more sprites. The tool itself is built to work transparently with SpriteTool's standard and my plan does take that into consideration. I do not plan on forcing anyone to convert to GIEPY's methodology, you'll be able to treat the extra bits as you do now if you so choose.

As for whether this is for the greater good of hacking, it's for you to decide. In my opinion, it is, especially if we do it correctly.


You're right. Tessera's primary problem was its lack of backward compatibility and generally personal design decisions. There was nobody who was interested in pushing it forward and hacking back then was too simple to need a tool like it.


My main reason for deciding to use Java (if I do end up being the one to make it) is its strong object oriented design and platform independence. A sprite property editor which handles both CFG/JSON files and ROMs has many shared features and fewer features which depend on the file being edited. Java would make it easy to write that in a clean and manageable way.


I agree with you there. A CFG editor is not necessary, especially if we pick JSON as the standard format (see my previous post; JSON files essentially describe themselves). Still, it is a nice thing to have, especially if it can also replace Tweaker.

Converting to native GIEPY subroutines won't make the standardization that much harder (automated scripts) and will pretty much make PIXI compatibility mode unnecessary. It's more future-proof.


I'm definitely interested. Is there any chance we could talk further? Discord seems like a decent option if you're comfortable with it.

As in the past, I definitely vote for JSON as a format again, since it's very human-readable, easy to edit, a well-known standard and the slightly bigger size doesn't really matter in this day and age (we're talking about differences in the, at most, KB range, and since they're just meta files and don't go into the ROM, noone really cares about a few KB of extra space required).

--------------------
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!

That's true. It would only really be bigger if it somehow ended up being > 4 KB.

--------------------
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!

Boldowa is currently planning on adding support for 2 more formats for sprite config: yaml and ucl. I think the sprites in SMWC should still be in json format for now though. Also, it looks like boldowa is planning to create an uninstaller of other sprite systems himself.

I don't think it matters at all what format our cfgs are hosted in so long as there will be an editor to edit all of them (which shouldn't be hard since this is basic data storage in really easy and same-featured formats).

--------------------
Your layout has been removed.

Will still be a good idea to set a standard for hosting sprites, though, so that if a new tool shall ever be made in the future, it technically only needs to support one of those formats for full backwards-compatibility with our section. If we host all the file types, new tools will also have to support all of them (or, at the very least, provide some conversion script). So I suggest going just with a single standard that's easy to work with, even with no tool at hand (my personal vote goes to either JSON or YAML, don't really know what UCL is).

--------------------
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!

Let me also say that boldowa is planning on dropping support for JSON files in the future, so it'd be a good idea not to go with them.

I'd be fine with either YAML or UCL. From what I've researched, UCL is an extension to JSON which supports comments and can have a simpler structure with less quotes. YAML is something I've rarely used because of its sensitivity to whitespace. As randomdude informed me, however, it turns out that YAML is compatible with JSON, so that makes it a good candidate, too.

I almost want to say that I support YAML more than UCL simply because it's more popular and so it'd be easy to support it. UCL seems rather obscure and I haven't yet managed to find a single parser for it, so actively supporting it might be harder.

If UCL is literally just JSON + X, then yeah, using UCL would be even better than using JSON. But yeah, if it's between YAML and UCL, I would probably also prioritize YAML, because it's actually easy to find information on it, whereas searching the web for UCL gives hundreds of results that have nothing to do with the language.

--------------------
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!

This looks like an UCL parser to me. (also it has nice docs about the format itself)

Currently we are debating between 3 human readable config formats. All three are compatible with JSON. (this actually means that boldowa dropping JSON wouldn't be too big of a deal, we would just have to rename the .json files to .yml or .ucl). I still vote to use JSON since it's more common and probably easier to generate and parse by other tools.

Reading some of the features of UCL, I'm not sure if I'd want to go with that. Things like "automatic arrays creation" just seem like they can introduce all kind of accidental, unwanted behavior into your configuration (for example: accidentally specifying some value twice and making it an array when really you only wanted to have that value once - that will probably confuse some people).

--------------------
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!

After checking some of the formats, I think YAML might be the best one to go. It seems fairly to understand & edit and should not be too much complicated to implement.

I'm in a all favor of putting GIEPY as the new standard, considering the premature PIXI switch was and how unstable it's been going. This is not just for the future of the SMW Hacking, but also a question of surviving: people are getting frustrated with PIXI and this is not good at all -- sooner or later we will start losing SMW hackers because of an unreliable tool.

The only thing I was afraid of was the different sprite spawning routine, but yesterday I suggested a potential workaround for telinc1 and I believe it might make possible to we still have compatibility with the old sprite spawning routine.

--------------------
GitHub - Twitter - YouTube - SnesLab Discord

HOCON looks really really confusing to write, sadly. At least from all the examples given, it just looked like it had a bit too many specific rules for really simple stuff.

--------------------
Your layout has been removed.

The length or number of characters a tab uses can vary from one OS to another, or even between text editors, so it's quite the opposite of bullshit to disallow them in my humble opinion. By only allowing space-based tabs, you ensure that your data is always clean as long as you use a fixed width font. Besides, I assume HOCON is not really supported and known as much as YAML.

For this reason, as well as readability and ease of modification, I'm voting for YAML like Vitor.

But tabs are always the same width on every person's individual editor of choice, so I'm not sure how it would differ from spaces...
Whether there's 2 spaces per level of indent or a tab looking 2/4/8 spaces, the indentation level will always be clearly readable on all ends, while keeping the person's personal preference of indentation width intact.

--------------------
Your layout has been removed.

Notepad++ have a tab with of 5 (not exactly sure what is the tab width). However you can change that by going into Settings -> Preferences -> Language and on tab size. Set that to 8.

--------------------
Give thanks to RPG hacker for working on Asar.

I think leod's point is that tab width doesn't even matter as long as you don't mix tabs with spaces in your document. Indentations will be consistent as long as you use only tabs or only spaces.

--------------------
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!