#2889 - Andy - Fri Feb 14, 2003 7:17 am
I used HAM to make a programe that like a photo album, left_right key for selection of photos. Then I converted 60 photos into 240X160(bitmap mode4). The problem is:
1, if I put 4 photos only on the rom, then works fine on VBA or FA card (with MULTIBOOT option).
2, if I put 60 photos on the rom, then it can not work on VBA or FA card (with MULTIBOOT option). The screen becomes white color.
3, if I put 60 photos on the rom, then it can work only on VBA (without MULTIBOOT option).
Would anyone tell me how to fix it? I need to modify the program or patch the FA card or something else.
Thanks.
_________________
Keep smile
#2899 - gb_feedback - Fri Feb 14, 2003 10:31 am
Multiboot programs have to be small enough to fit in External RAM. 60 pictures will no doubt exceed the space available.
#2903 - Lord Graga - Fri Feb 14, 2003 10:53 am
Be sure that the variables who holds the photos is:
(or just const).
Const means that you can only read from the variables, it is a good thing because the gba has limited space for variables.
#2910 - Quirky - Fri Feb 14, 2003 1:36 pm
Each 240*160 bmp is around 40kb (240*10 = 38400, plus another 512 bytes for the palette data). Doing the maths, you can fit around 6 pics in before they exceed the 256kb of EWRAM. That is assuming the HAM display code takes up little space (10kb or so?)
To store more, try compressing the pics and then decompressing them directly to VRAM. You would still not be able to fit 60 into 256kb, but you might squeeze a few more in. The rom not working as non multiboot is odd. It should be fine (as 60 bmps are around 2MB)
#2933 - ampz - Fri Feb 14, 2003 5:23 pm
One way to get ~200 extra bytes of RAM when multibooting is to put variables in the header area. The header is only needed for the BIOS to boot, after that you can most probably use the area for whatever purpose you see fit.
200 bytes is not much, but if you are really tight on RAM... ;-)
#2935 - tepples - Fri Feb 14, 2003 6:55 pm
What sort of image compression do you recommend that's both more space efficient than GBA LZ77 and more time efficient than Jeff F's JPEG decoder (3 seconds for a full screen image)?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#2939 - tom - Fri Feb 14, 2003 7:38 pm
tepples,
just out of boredom i tried once aplib (which was originally written for apack, a dos executable compressor) on the gba. it compresses fairly well. i don't have the code here right now, so i can't give you exact results, but i (think i) remember that depacking a 240x160 image took ~ 1.0 / 1.3 seconds (depacked into ewram/vram)
http://www.ibsensoftware.com/products_aPLib.html
(the aplib source code is not available, but a depacker written in c is included in the archive)
#2944 - tepples - Fri Feb 14, 2003 9:15 pm
And how small was the image packed with aplib, compared to the same image packed with GBA LZ77? Is it smaller than the same image packed with LZO?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#2973 - tom - Sat Feb 15, 2003 10:36 am
image was 240x160, 16bpp
unpacked: 76800 bytes
gba lz77 (gba crusher): 27260 bytes
lzop: 22892 bytes
aplib: 21629 bytes
of course more tests should be done to get meaningful results.
anyway, thanks for pointing out lzo, it seems to be very fast, it might be worth giving a try on the gba.
#2974 - tom - Sat Feb 15, 2003 10:41 am
| tom wrote: |
| lzop: 22892 bytes |
that was with highest compression (-9 switch)
#2979 - tepples - Sat Feb 15, 2003 3:56 pm
| tom wrote: |
| gba lz77 (gba crusher): 27260 bytes |
Of course, the big problem with GBA LZ77 is the fact that its match length goes up to only 18, while some other LZ implementations will often make matches up to 256 by making the match length field non-linear.
I used LZO for TOD M2, and I liked it. It's good for homebrew, but for commercial projects, the author of LZO charges money for use in non-GPL game engines, and he's unreachable by non-PGP e-mail.
I guess that the figures you gave me point toward an absolute limit for packing lossless pixels. So are there any lossy image codecs that decompress quickly on the GBA?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#2992 - tom - Sat Feb 15, 2003 8:58 pm
| tepples wrote: |
| I used LZO for TOD M2, and I liked it. |
so, what did you use then ? the minilzo thingy ?
and if so, was it hard to get it to work on the gba ?
(i guess you have to do some modifications to make it depack correctly into vram...)
#3039 - Andy - Mon Feb 17, 2003 2:50 am
Thanks for suggestions.
However, for my understanding if MULTIBOOT is used, GBA will start at EWRAM, and start at GAME PAK ROM without MULTIBOOT. I think some RPG games also stored many pictures in the ROM (I guess over 200pcs at least) but why they can do that? And why VBA can work fine without MULTIBOOT? Is it any limitation on HAM?
Thanks.
_________________
Keep smile
#3041 - kiwibonga - Mon Feb 17, 2003 4:59 am
Maybe you should read about multiboot...
_________________
http://www.kiwibonga.com
#3074 - tepples - Mon Feb 17, 2003 7:31 pm
| tom wrote: |
so, what did you use then ? the minilzo thingy ?
and if so, was it hard to get it to work on the gba ? |
Minilzo was quite straightforward to get working on the GBA.
| Quote: |
| (i guess you have to do some modifications to make it depack correctly into vram...) |
I unpack everything to EWRAM. For one thing, it lets me "prefetch" unpacked data by a couple frames, which is useful for the technique in my "Managing Sprite Cel VRAM" document.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.