News: 11 March 2016 - Forum Rules

Author Topic: Getting Started on Graphic Asset Manipulation/Replacement (GBA)  (Read 490 times)


  • Newbie
  • *
  • Posts: 1
    • View Profile
Hi everyone,

I'm hoping to do some purely aesthetic changes to a GBA title Summon Night Swordcraft Story 2 but I'm not quite sure where to start and go about accessing the graphical data and editing/replacing it with customised art. In particular, I was hoping to change some characters portraits as well as character/weapon sprite visuals. I've come across some tools like the No$gba Debugger and Tile Molester but I don't really understand how to use it and as a result I feel like I'm missing something crucial to making any progress. Can anybody point me in the right direction?



  • Hero Member
  • *****
  • Posts: 5006
  • The cat screams with the voice of a man.
    • View Profile
Re: Getting Started on Graphic Asset Manipulation/Replacement (GBA)
« Reply #1 on: August 05, 2021, 09:57:17 pm »
GBA graphics tend to be compressed, usually with the algorithm built into the GBA BIOS. Examples abound; see for instance .

Also, are you quite sure no one else on the Internet has attempted any manipulation of this game before? It is always easier to build off someone else's work.

And if you missed it:

The Newbie Package of REQUIRED Material FAQ: You ask, we answer! Getting Started Section: Newbies Go HERE! Documents Section!
How to ask questions the smart way.
On the Essence of ROM Hacking
Talk with experienced people in our IRC chat and ask specific questions there.
This signature is an illusion and is a trap devised by Satan. Go ahead dauntlessly! Make rapid progres!


  • Hero Member
  • *****
  • Posts: 3301
    • View Profile
Re: Getting Started on Graphic Asset Manipulation/Replacement (GBA)
« Reply #2 on: August 06, 2021, 08:28:28 am »
I do use that game as an example of the some of the more exotic aspects of GBA graphics in my guide to such things,14708.0.html
That being palette based animations, as well as dynamic palettes.

As the super basic intro though then

Systems tend to have hardware built to accept certain formats and so tile editors play to those.

The GBA technically has two modes, though practically it is more like 4 plus custom tile sizes.

The main two modes are
GBA 4bpp. 4 bits per pixel, not as many colour combinations as some later ones (4 bits per pixel means 16 in a palette, or 15 plus transparent) but smaller sizes, more palettes to pick from and more options in certain scenarios.
GBA 8bpp. 8 bits per pixel. More colours, more storage/memory needed, more options for certain things but less in others.

The third is "1bpp" which is technically a type of compression (some prefer packing, indeed the BIOS documentation will tend to refer to it as packing, and may be combined with filtering) but the compression is so basic that you can treat it as an editable format which most big boy compression types will not appreciate. Normally seen in fonts where "is colour, is not colour" is the main choice, though the GBA certainly has plenty of nice shaded and more modern style fonts too.

The fourth is rarely seen and Crystaltile2, the main thing to support it, calls it XBPP as it is a weird arrangement/decoding seen in some games so tends to be what others call it.

The GBA leans more into 4bpp than the DS which has much the same hardware but saw many games spend a lot of time with 8bpp (and 3d but different story there).

Computer game graphics tend not to be bitmap images either where every pixel is the colour and instead it is all a big game of paint by numbers, that being the pixels reference an external colour key. This key is known as a palette. Tile editors will tend to have a default one (usually some random colours) or selection thereof (usually random plus a few black and white or single colour gradients) that will likely not be what your game uses. Some can edit this way (if you just one want of the same pixel just extended over you might not care it is hot pink where in the game it is forest green, just need to use a bit of abstraction).
As mentioned above the GBA Summon Night games use palette animations -- you can change pixels/whole tiles, change the location on screen (see OAM) or change their colours after all to make something change on screen.

Finding palettes can be done in multiple ways.
1) From the emulator/savestate.
As palettes are selected, altered and edited at runtime then they can be fished out memory to provide to the tile editor/viewer. Some tile viewers will even be able read savestates from specific emulators (tiled2002, one of my more preferred GBA editors, does an older version of VBA if memory serves).

GBA palettes and SNES palettes use a very similar format for some modes too. Hence why a lot of the SNES ports to the GBA that suffered a brightness bump to deal with the dark screen of the original GBA were relatively easily swapped back.

2) Found in the ROM.
This is what you will want if you want to edit the palettes, or don't want to have to get to a point in the game the thing you want to edit is on screen/in memory with palette there as well.

Nothing stopping you from finding the palette with 1) and searching the ROM to make 2), indeed even if it is an animated palette (can be seen in an emulator, open palette viewer and click the update in real time option and it will be very apparent) you can search for a large chunk of the non animated side and probably still find it. I will skip the relative search stuff for now.

GBA graphics mindset and tile sizes.
In general graphics regardless of what format they use will be split into two main aspects.
1) BG aka backgrounds.
These are usually used for backgrounds, text layers, menus and such. Still use tiles, though some bitmap options are available, and arrange things (map tending to be the term used to refer to the thing what arranges background tiles). Multiple layers available, as well as ability to stack them with transparency, usually called windowing. I usually note the beds in summon night and how your character walks in but looks underneath the sheets as an example of stacking things, and how you can then disable layers, though some of that might be sprites.
The GBA has a few fancy options here, including a mode7 a like to do pseudo 3d and some interesting effects.
Your portraits will probably be BG based setups, though I have seen otherwise in some things.
2) Sprites aka objects aka objs.
If you are reading this you probably know what a sprite is as it pertains to games. But yeah player characters, some effects. items in the world. Can stack many sprites together to one mega sprite, as might be seen in boss characters. Not normally seen for text but on rare occasions it can be, as might decorative text.
Controlled by the OAM.

Tile sizes.
On older systems every tile will tend to be 8x8 or 16x16 pixels, or some combo of 8 and 16. The GBA does not generally deviate too far from this, especially not compared to the DS where you will regularly see paletted images 256 pixels wide by 192 tall if not taller, but there are plenty of options for other custom sizes. Tiled2002 tends to struggle here so I suggest crystaltile2 if you have these.

Finding graphics.
"open tile editor, press down/page down a lot". Crude but it works. Do remember you have potentially 4 modes to go through, plus tile sizes. Also one of the ways people discover unused graphics (if they are never loaded by the game then the others might struggle) such that make up the contents of tcrf, unseen64, gaming alexandria and all the rest.

Corruption. Edit some bits in the ROM, see what changed (make sure to run it and not revert to a savestate lest it is already in memory, though forcing a redraw by going to a new level/room/menu is acceptable). Very crude but will find you things eventually.

The ripping from RAM (VRAM in this case) and searching the ROM for it is a thing you can do.

Pointer inference. You may hear it said GBA pointers start with 08 and look like 08?????? (give or take big/little endian). This is not strictly true as there are both an additional 16 megabytes of space that uses 09 and mirrors for those that do different things (though are rarely used). That said if you are browsing through a ROM in a hex editor and see a whole bunch of values with 08 and six other digits between them repeated a lot, possibly counting upwards each time, then you have found some pointers. Could be for anything else in the game (music, text, levels, code, stats...) but tends to be something worth seeing. As GBA graphics tend to be a fairly fixed size as well then the numbers it counts up each time will also tend to be fairly fixed compared to the randomness of text.
You will want to learn pointers as well -- if you fancy adding a bunch of stuff or changing the location of something then this will be how you do it. GBA games by and large have oodles of space available or easily generated (the 09 thing corresponding to the uppper 16 megs -- most games are 16 megs or less and those that do make it to 32 are mostly the GBA videos, aka probably more than 99% of GBA games have a free 16 megabytes or more of space available to anybody that asks, though for the sake of some emulator and flash cart users try to keep it 16 megs if you can).

Compression is a thing on the GBA, however unlike the older systems the GBA BIOS carries with it decompression algorithms that most games use, or will use the equivalent of it. Compared to the DS I don't know that I would say most GBA games use it but I would not be surprised in the least to find any game from any dev at any point in the life cycle using it extensively.
Being BIOS calls (sometimes called by the broader category of SWI aka software interrupt) then you can play the game, log them in various emulators and feed those logs (which say exactly where, how much and what type of compression is being used) and feed said logs to some GBA compression tools to get things, or direct more manual tools.
You can search for it as well as it has some fingerprints, not quite as nice as some of the DS ones (which use much the same again) but hey.

Finally we have tracing, the king of all methods, and what your no$gba debugger is likely to be useful for (though its viewers, along with those of VBA/VBAM, are good stuff too for some of the simpler things).
I usually link to as an example of tracing, though it uses an older fork of VBA that is command line based. If you can adapt what it says there to no$gba's graphical options then you pretty much have it sorted.
Anyway as you are literally going through the code then no compression, fancy trick, modification or whatever will be a surprise as you are watching it happen, you will know what mode it is in, where it is in the ROM and anything else like that. As however you are watching a complicated coding language happen it is a far cry from "open ROM in tile editor, press page down a lot".

Had to break it up for size reasons
Links for fun and health
Tile editors. Many older ones (not sure if tile molestor ever gained the ability, I rarely see GBA hackers use it though) will not support GBA stuff, or be limited to GBA 4bpp modes if they do so you will want one geared for the GBA.

Tiled2002, old but has some things I like, especially the ability to shift the colours along by one at a time in the palette.

Crystaltile2, for my money the best tile editor out there (though it also does a lot of other things). Its palette grabbing (and inserted, when it says palette to ROM it will indeed shove the palette data into the ROM without confirmation) is in the hex window. If you are looking at a DS game then it has further options, including an awareness of many DS formats in the DS window. Sadly the GBA commercial world did not see fit to give us a file system to have ROMs be nice an explorable.

tiledggd and more recent fork that might be interesting
Not an editor but a viewer, however probably the most adaptable viewer out there. Can struggle with some aspects of 3d textures but that is not a GBA problem. Does not use the GBA 4bpp/8bpp naming convention and instead is more first principles/descriptive.

Information (and some emulators I guess)
The hardware reference for the GBA (and DS)
The debug version of no$gba from the same site ( ) also being what I suggest for debugging these days, though I still maintain a bit of a soft spot for vba-sdl-h and vbam has a few abilities here (don't know if its gdb is up to much these days) and others are exploring more exotic options . mgba has some options here ( is not the emulator but some good articles from the author of it). Don't bother with anything older at this point. Higan apparently gained GBA emulator options at one point but I don't know what its debug stuff is up to.

Cowbite. Older but has some nice info.
TONC, aimed more at programmers but introduces some things in a more practical sense
Headspin's page
More for compression (coming shortly) than for simple graphics but has good info. Also a download for GBA crusher which is a nice little command line tool for effecting GBA compression types.
Managing sprite vram. is probably not going to teach you much, however it is wonderful thought exercise of sorts.

I already linked my guide to GBA and DS ROM hacking. There is a lot of game specific stuff in various communities (pokemon tending to be where people first meet something, indeed the advanced palette editor that will be first on the link I give in the compression bit, and its tools are second to almost none) is mostly for that. However Fire Emblem, Advance Wars, Golden Sun, Mario Kart, Mario platformers, Fire Pro Wrestling and a few others have some good stuff in among the game specific worlds. Some people were doing a Summon Night Swordcraft Story 3 patch as well so might have some info on the general approaches used by the series (the games were one year after the other, with other games also being made at the same time, so probably not too much in the change front)

For general approach
and crystaltile2 has some options here.
Get a copy of GBA crusher as well.
Others will use tools that read logs or search for compression and try to display it. nlzgba, unlz gba, gba multi decompressor and more available is a general overview of compression and how it works if you want such a thing, while it says lempelziv (the LZ part of various compression types you might have seen) and indeed is mostly about that its coverage of huffman, RLE and others before then is enough to give you a good grounding.
Naturally gbatek details compression options as it pertains to the GBA extensively.

I will note the GBA has two broad types of compression, that being VRAM (video RAM) safe and WRAM (work RAM, aka what everything that is not graphics uses). Some tools, including graphics ones like the ones from the link above, don't necessarily use the VRAM safe where they should which is why I tend to go manual and know what I am doing here.

But really despite all this open up the ROM in your editor of choice, scroll until you find something (don't really care what), take it to the edit options (tiled2002 has another window you send tiles to and from as it allows you to build a more complete picture, literally, to help things there if it has things scattered around, crystaltile2 has a separate window/page much like the hex editor and assembly viewers you probably saw when clicking icons on the top bar), edit a few pixels to be something different and then see that in the game. Once you have done that and feel reasonably confident in doing something there everything else tends to drop in place or be simple additions to the base skill set.
« Last Edit: August 06, 2021, 08:40:23 am by FAST6191 »


  • Hero Member
  • *****
  • Posts: 5006
  • The cat screams with the voice of a man.
    • View Profile
Re: Getting Started on Graphic Asset Manipulation/Replacement (GBA)
« Reply #3 on: August 06, 2021, 09:45:33 am »
I do use that game as an example of the some of the more exotic aspects of GBA graphics in my guide to such things,14708.0.html
That being palette based animations, as well as dynamic palettes.
I knew that thread was somewhere, but I could not quite recall how to find it.

Anyway, you probably intended to link to .
This signature is an illusion and is a trap devised by Satan. Go ahead dauntlessly! Make rapid progres!