Language…
21 users online: akawo, Alex No,  AmperSam, CharlieUltra, CroNo, DanMario24YT, Fullcannon, Gemini0, Golden Yoshi, Gulaschko, Hammerer, kurtistrydiz,  MarioFanGamer, MarkVD100, Maw, mtheordinarygamer, NewPointless, Spedinja, steelsburg, superbot12, Tulip Time Scholarship Games - Guests: 281 - Bots: 349
Users: 64,795 (2,370 active)
Latest user: mathew

The GIEPY Standardization Project

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 GreenHammerBro
Originally posted by leod
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.
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.

Actually, Notepad++ has a default tab width of 4. (Seriously, who uses tab widths that are not a power of 2?)

Originally posted by RPG Hacker
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.

This is also the reason why Python allows both spaces and tabs, despite being about as sensitive about whitespace as YAML, because as long as you are consistent with your whitespace, everything will work out just fine.


P.S.: Elastic tabstops are just another advantage of tabs over spaces.

I made a script that should remove Romi's Sprite Tool from your ROM. Just patch it to your ROM using Asar. Telinc1 said he'll "make the full patch probably later this week" (which will also remove other sprite tools). Link
Edit: Also note that it's quite slow - for me it took 1.5 minutes to clean a 1MB ROM.
Originally posted by randomdude999
I made a script that should remove Romi's Sprite Tool from your ROM. Just patch it to your ROM using Asar. Telinc1 said he'll "make the full patch probably later this week" (which will also remove other sprite tools). Link

The "full patch" refers to the bloated monstrosity which will detect and remove (safely, I hope) every single known sprite tool or sprite patch (such as Sonikku's C3 extended sprites).

I also want to add that I've made quite good progress on the new CFG editor. When it's a little more stable, I will make a separate thread for it in the tool releases forum.
Hi, I think this tool has a lot of potential and wanted to use it recently.

I'm having this problem when I try to compile GIEPY on Manjaro, I wonder if it's due to the lack of determined libraries or the place where they are stored.

I think the C libraries are stored in /usr/include/



Maybe I have to chage something in the build script... to be honest I'm not very experienced with compilation yet...

Current project: working on a personal website and a portfolio.
I think GIEPY's repository actually mentions it, but you need to clone the repo with submodules (git clone --recurse-submodules https://...).
I cloned the repository using the --recurse-submodules this time, but it still does not compile correctly.

Image

First I got the '"libasar.so" is minnsing...' error, then I just copied the libasar.so into the build folder and ran the script again.

Current project: working on a personal website and a portfolio.
Sorry for bumping this, but...

What's happened with the GIEPHY? Any news?

I have some doubts about this tool. Is it alright to use it?
Because i can't use something buggy.

If anyone dislike PIXI, why don't you submit GIEPHY in the tool section and wait for reports?
Oddly, there are few GIEPHY sprites in the sprite section.
Okay, it's time for an official update about the GIEPY standardization.

First of all, the latest version of GIEPY has been stable and has worked with almost all the sprites we host. I don't think there will be a problem with the transition process.

boldowa has been clear that he will not provide any routines for GIEPY because of his lack of experience with sprite coding. He also hasn't uploaded GIEPY to the section, leaving that job for the ASM team. Because the official release of GIEPY is not suitable for direct use with our resources, I created a fork of it with a well-tested and extensive routine library, as well as several modifications to greatly improve backward compatibility. I released a preview of the fork during the last C3; so far, it's proven to be relatively stable and hasn't had any ASM changes to it.

The fork of GIEPY which will ultimately become standard may be downloaded from my filebin. This is not the final version - there will be at least one more which will fix a problem with system reinstallation and add several new routines related to sprite spawning and item memory. The routine library of the current version of the fork may be downloaded separately here.

The GIEPY sprites currently hosted in the section were all moderated by me using this fork and its routine library. As of now, any future GIEPY sprites should expect the presence of and use these routines, not the ones which ship with the official release of GIEPY. For anyone starting a new project, I recommend you use the fork I linked to above, keeping in mind that you currently cannot force re-install the system with it.

The final requirement for this project is the new beta version of Faerie, which will have all of the functionality necessary to allow conversion of old sprite configuration files, making it much easier to migrate an existing hack. I have gathered several big base ROMs to ascertain that conversion would go smoothly even for an advanced project.
Originally posted by Roberto zampari
Sorry for bumping this, but...

What's happened with the GIEPHY? Any news?

I have some doubts about this tool. Is it alright to use it?
Because i can't use something buggy.

If anyone dislike PIXI, why don't you submit GIEPHY in the tool section and wait for reports?
Oddly, there are few GIEPHY sprites in the sprite section.


99% of the problems you might experiment are related to the fact that the some sprites on the sprites section are still not fully compatible without modifications, and/or problems with the routines (as the C3 release of GIEPY carries diferent routines that the oficcial 1.02 release and PIXI ). Anyway, all of those will be solved with the sprite section revision, so you should'nt worry too much.

As you pointed out, there are now some GIEPY sprites submitted and I think it's for those reasons:

-since it will be the new standard, submitting sprites for it is a good way of promoting it, and:

-for the spriters to slowly adapt to the differences between coding GIEPY and PIXI sprites.
I want to report something.

When i insert the newer GIEPHY sprites, it shows messages like:

Code
SuboffscreenA not found [JSL Suboffscreen A]
SubHorzPos not found [JSL SubHorzPos]
GetDrawInfo not found [JSL GetDrawInfo]


Examples:

One Ride Platform
Celeste
Winged Thwomp

How can i fix this?
Originally posted by Roberto zampari
Code
SuboffscreenA not found [JSL Suboffscreen A]
SubHorzPos not found [JSL SubHorzPos]
GetDrawInfo not found [JSL GetDrawInfo]

SubHorzPos and GetDrawInfo shouldn't be causing such problems, so update your routine library. SubOffScreenA is not a standard routine (the sprite was made before I released the library); change it to just SubOffScreen.
That's weird, i downloaded the routine library and the result is the same.
Could this be the prompt code? It's here:

Code
-w -L routines -p


Should i replace "routines" with libraries?
PIXI sprites doesn't work without "routines" folder.
Originally posted by Roberto zampari
That's weird, i downloaded the routine library and the result is the same.
Could this be the prompt code? It's here:

Code
-w -L routines -p


Should i replace "routines" with libraries?
PIXI sprites doesn't work without "routines" folder.

-L routines moves the library folder to routines, leaving libraries unused, so you should paste my library routines into the routines folder. Alternatively, you could paste PIXI's routines into libraries and get rid of -L routines.
If i paste routines folder to libraries folder:

Code
Unknown macro

PIXI routines are missing.

If i paste libraries folder to routines folder:

Code
SuboffscreenA not found [JSL Suboffscreen A]
SubHorzPos not found [JSL SubHorzPos]
GetDrawInfo not found [JSL GetDrawInfo]


The result is the same.

Can you explain how to fix this? Tell me the instructions...
Originally posted by Roberto zampari
If i paste routines folder to libraries folder:

Code
Unknown macro

PIXI routines are missing.

If i paste libraries folder to routines folder:

Code
SuboffscreenA not found [JSL Suboffscreen A]
SubHorzPos not found [JSL SubHorzPos]
GetDrawInfo not found [JSL GetDrawInfo]


The result is the same.

Can you explain how to fix this? Tell me the instructions...


For the
Code
JSL SubOffScreenA
problem, just find all instances of
Code
SubOffScreenA
in your sprites codes and change them to
Code
SubOffScreen
manually (SubOffScreenA will not be used after remoderation). For the other problems, try reapplying GIEPY after making sure you have the routines that C3 GIEPY packs in your routines folder (and your PIXI routines too). Also, I think there are some problems related to reinstalling GIEPY with the C3 fork, so if the issues persist you may want to try if it works on a ROM with GIEPY not installed.
Try to reinsert this, but the result is the same.
Changing "SuboffScreenA" to "Suboffscreen" is still the same.
The labels are missing...

Example:

Code
Label *** not found [JSL ***]


Code
Label SubHorzPos not found [JSL SubHorzPos]
Label GetDrawInfo not found [JSL GetDrawInfo]


Do you understand it?
While I hope this project is still going along behind the scenes, I just wanted to point out a little thing:

Quote
Tip: Use PIXI to insert custom sprites into your hack.


The site still promotes PIXI as a (if not the) custom sprite tool in its Tip bar, so if GIEPY really is striving to become the standard tool, it might be a good idea to get it changed before more new users start to get used to PIXI. Same goes for the F.A.Q.
Good catch. The tips and the FAQ as a whole are quite outdated, so that's not the only problem which needs correction. I don't want to modify them without consulting the rest of the team, so I'll go ask.
So, I tried to make GIEPY work by myself (reading previous posts) and I think I actually got it. In short, to make PIXI's sprites work I did:

-Copy PIXI routines to GIEPY's folder.
-Activate PIXI compatibility.
-Attempt to insert the sprites and look the labels which gives errors.
-Change every instance of those labels to "JSL label" instead. So for example, for %GetDrawInfo() it should be JSL GetDrawInfo

And so. However I got cases where some macros gave me errors, as BEC, for example (which I could fix thanks to lx5).

Some GIEPY sprites already submitted in the sprites section also give me errors, but those where easy to fix. However I don't know why and how the fix I did actually work.

As a example, Erik's Crash Badicoot TNT gave me this error "Define !7FAB40 not found". Right in the ASM file, in the line itself I found a "LDA !7FAB40,x" and 7 lines above, there was the same code but with 10 instead of 40. Replacing the 40 with 10 apparently fixed the error, but I don't know if this is the correct fix to do or not (and if it is, why).

Other than that, GIEPY worked fine. Most of the time the CFG or JSON files didn't work at all, but I guess it's because of the format to read them (the reason why Telinc1 is developing Fearie, I guess?). And I used the GUI all the time (Piee), I guess using it is safe, right?

EDIT: Thanks again to lx5 who give me more advice in the topic: the errors about GIEPY sprites were because I didn't enable the Extra Bytes option in Piee. After enabling it, the sprites worked without having to edit the !7F.... lines (now, knowing these are related to Extra Bytes) The same happened to the BEC macro, which made the sprite work without modifying anything related to it (however, in this last case, lx5 said they should have work even without the Extra Bytes options enabled, stating those macros should be in GIEPY by default)
Layout made by MaxodeX
2021 TRENO vibe check thread
$7FAB40 (which also included !7FAB40) is an actual RAM address used in a few sprites. Specifically, this is where the first extra byte is stored. Changing $7FAB40 to $7FAB10 will mess up the sprite because $7FAB10 contains the custom bit and both extra bits/sprite number high byte, neither which are used for customisability (well, except for one extra byte à la romi's Sprite Tool but still a bad idea).

The way to fix it is to either enable extra bytes (which you not only need to enable it manually but also reinstall GIEPY, see the GUI) or change $7FAB40 to $7FAB28 (which makes the sprite use the first extra property byte instead the first extra byte).