The GBA has two main video modes
They are called GBA 4bpp and GBA 8bpp in most editors, though some of the older ones lack 8bpp support.
The GBA also has compression readily available for developers to use, and they did, and if it is anything like their efforts on the DS then Marvelous/Natsume love them some compression. Fortunately it was usually a known type rather than whatever the developer could cook up and get to run like it was on older systems.
Three ways to deal with compression (if someone does not tell you where it is anyway)
1) A scanning tool. Compression usually has fingerprints that things can detect.
2) SWI logging. The part about known types above also has that most of those will use the GBA BIOS' inbuilt decompression commands. Various emulators will allow you to log the calls to these commands and by design there include the type of compression used and location of the thing in question. Fire your decompression tool at said locations and hopefully you get what you want, for some of them you might even be able to feed it a log from the emulator and have it do it for you.
3) Big boy tracing.
https://www.romhacking.net/documents/361/ has how to do it for VBA-SDL-h but the same ideas work with the more graphical no$gba
http://problemkaputt.de/gba.htm
Where the others might fail to find what you want for various reasons then this can not fail outside of user error. It is the start of what many consider the top tier skill of ROM hacking (that being editing assembly code) but is actually not that bad to learn just that
If you want to get technical then
http://members.iinet.net.au/~freeaxs/gbacomp/#BIOS Decompression Functions and if you want to get really technical then
http://problemkaputt.de/gbatek.htm#biosdecompressionfunctions
I do have some more in my guide
https://gbatemp.net/threads/gbatemp-rom-hacking-documentation-project-new-2016-edition-out.73394/ , especially for the tools mentioned in 1) and 2) above. (probably in section 1.7.4)