[Spindaboy]

Hey all. I'm working on trying to figure out the best way to find and export graphics (I'm talking everything: sprites, animations, tile sets, etc.) from FFIV Advance for reuse in a homebrew project. I know sheets for these already exist but I was hoping to extract them directly from an editor to save myself the tedious process of having to recreate each one pixel by pixel. So I guess what I'm asking is advice on how I might go about pinning down the location of the graphics (to view in an editor) as well as their respective palettes?

[FAST6191]

Animations I would probably do by hand -- most animations on game consoles are little more than play this sprite for 10 frames, swap to this for 5 and so forth, maybe change palette. Even if you did rip them as is then they will tend to be tied to screen positions so unless you homebrew game also wants to be 240x160 pixels then you will be doing work.


"recreate each one pixel by pixel"
?
Most sprite sheets are nice PNG images that you either slice out of the greater sheet or click select all similar colours on the lime green/pink/blue background and lose those colours. 5000x quicker to slice them out of such a thing and redo it, even if you still had to watch videos to get timings for animations.

If it is for export then we would usually suggest an emulator -- they have nice tile/sprite viewers for everything in memory along with any palettes (including accounting for palette based animations, though you will have to watch and see what goes for that). Play the game with that, use some cheats to get to the hidden bits, use some 100% saves to do whatever, use some cheats to force you to face the first boss as a starting enemy...
If the game has a bestiary then do take advantage of that.


Beyond that then every game is different.
If I wanted to though then I would probably figure out how the game/devs classified the graphics (usually it will be something simple but sometimes you might have slight tweaks between players, npcs, overworld, dungeon...). Rip one of each of those the long winded way (compression scan, tracing, reverse searching) and then you will probably have the method used, typical format, rough location and hopefully pointers to it and so forth. Rinse and repeat for the rest of the images which will probably be next.

[Spindaboy]

Even if you did rip them as is then they will tend to be tied to screen positions so unless you homebrew game also wants to be 240x160 pixels then you will be doing work.

Actually the plan is to create is to create it for the GBA so this shouldn't be an issue That's actually why I wanted to find the graphics in the ROM rather than using an already existing sheet or taking from memory; I figured that it'd be easier copy/pasting from one graphics editor to another rather than recreating them  by hand. I'm just having trouble finding the locations using unLZ-GBA unfortunately.

[Jorpho]

That's actually why I wanted to find the graphics in the ROM rather than using an already existing sheet or taking from memory; I figured that it'd be easier copy/pasting from one graphics editor to another rather than recreating them  by hand.

Like M. Fast, I am very confused as to what exactly you think you have to do by hand and what makes you think finding them in the ROM would let you avoid doing something by hand.

Have you tried looking at a different game with uncompressed graphics? Does it work the way you think it does?

[Asaki]

This is the program I used to work with compressed GBA graphics...there was a tutorial on how to do it, once upon a time, but I can't find it now. It might be in the readme for the program itself?
I seem to recall it requiring a specific fork of VBA. VBA-M I believe?

As for the palettes, I'm not sure. I tried looking for them in that game before, but couldn't find them without using a trace debugger.

[Spindaboy]

Like M. Fast, I am very confused as to what exactly you think you have to do by hand and what makes you think finding them in the ROM would let you avoid doing something by hand.

Have you tried looking at a different game with uncompressed graphics? Does it work the way you think it does?

What I mean is selecting a sprite as it appears in a graphics editor, ctrl+C-ing it, and ctrl+V-ing it in another instance of the same program. I have used this method with yy-chr in the past and it has worked exactly as I would expect.

This is the program I used to work with compressed GBA graphics...there was a tutorial on how to do it, once upon a time, but I can't find it now. It might be in the readme for the program itself?

As for the palettes, I'm not sure. I tried looking for them in that game before, but couldn't find them without using a trace debugger.

Could you share the name of the program you mentioned?

[FAST6191]

Various tile editors will allow you to import PNG and BMP images and copy paste things around. Crystaltile2 being one such example.

As far as compression goes.

The GBA has compression routines built into the BIOS

http://members.iinet.net.au/~freeaxs/gbacomp/#BIOS%20Decompression%20Functions
http://problemkaputt.de/gbatek.htm#biosdecompressionfunctions
https://www.cs.rit.edu/~tjh8300/CowBite/CowBiteSpec.htm#BIOS%20(Software%20Interrupts)

This means emulators can log calls to these functions (known as SWI aka software interrupt, SWI logs tending to be how compression programs phrase it) and compression programs can direct their own functions to those locations. Even vanilla VBA should have made these though so should not have go to running for one of the many forks.

Not all games will use the BIOS, mainly as it can be done quicker in code. They will usually however still be compatible and thus able to be found with compression scanning tools (if you know what you are looking for then compression leaves a lot of fingerprints).
http://www.romhacking.net/utilities/431/
http://www.romhacking.net/utilities/529/
http://www.romhacking.net/utilities/362/
Being several examples of this, and there are more. Worth knowing about but far from the whole story or "will work with every game", not least of all because games can and do use their own straight up custom stuff (even if it is usually a minor tweak on the existing stuff https://ece.uwaterloo.ca/~ece611/LempelZiv.pdf covering how compression tends to be done in general and thus what sort of changes you might see when a developer decided to do their own thing).
https://www.romhacking.net/utilities/826/ is good stuff in general and for example source code. You might also like https://github.com/barubary/dsdecmp but it is more DS focused.


Palettes. My usual start is watch the palette in real time just to make sure there is no palette animation (if you need an example see either rainbow blocks in Mr Driller 2 or the save swords in Summon Night Swordcraft Story as they pulse), if there is you can still try with a non changing chunk.
Anyway palettes in memory are not always compressed (they tend to be small and thus not likely to gain much if you do compress them) and are seldom altered along the way (some games have a dynamic palette, options menu tending to be where you find it, usually so they can appear nice on a washed out GBA, less washed out GBA SP 001 or GB player. Never seen anything with a SP 101 colour profile) so you can slice out the palette from RAM and use that to search the ROM for that.
Otherwise yeah corruption, maybe a light bit of elimination, guesswork (palettes tend to be near graphics), hoping your compression logs yield something or just straight up tracing https://www.romhacking.net/documents/361/ (for an old fork of VBA, for tracing I would suggest no$gba debug these days http://problemkaputt.de/gba.htm ).


Animations. You can watch these play out in real time -- sprite positions on screen are controlled with the OAM (object area memory, objects being what some programmers/manuals/... call sprites). Background animations are a thing and controlled similarly.
The DS has some animation files that some games use but the GBA will tend to call it up from within the code itself so you either watch the code or watch the OAM logs and recreate from that. Plus palette animations but we already covered that.

[Asaki]

Could you share the name of the program you mentioned?

Whoops. I thought I pasted the link, but it must have slipped by me: https://www.romhacking.net/utilities/431/

[loveshove18s]

This is the program I used to work with compressed GBA graphics...there was a tutorial on how to do it, once upon a time, but I can't find it now. It might be in the readme for the program itself?

As for the palettes, I'm not sure. I tried looking for them in that game before, but couldn't find them without using a trace debugger.
in a sentence