gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Coding > JPEG_DecompressImage problem

#37857 - emgie - Thu Mar 17, 2005 11:18 pm

Hi,

I'm trying to decompress a JPEG image from source located in ROM (I think...), but I get no results.

mandrill.h:

Code:

unsigned char MANDRILL_DAT[6194]  ={
0xFF,0xD8,0xFF,0xE0,0x00,0x10,0x4A,0x46,0x49, ... and so on...


main.c:

Code:

#include "gfx/mandrill.h"

JPEG_DecompressImage(MANDRILL_DAT, MEM_BG_PTR, 240, 160);


When I first copy MANDRILL_DAT to a buffer in EWRAM (unsigned char buf[240*160*2] MEM_IN_EWRAM) and then unpack it from there, all goes well. The same if I use gbfs filesystem.

Anyone to tell me what's wrong in #include and right in other methods?

Regards,
Maciek

#37877 - tepples - Fri Mar 18, 2005 3:05 am

emgie wrote:
I'm trying to decompress a JPEG image from source located in ROM (I think...), but I get no results.

mandrill.h:

Code:

unsigned char MANDRILL_DAT[6194]  ={
0xFF,0xD8,0xFF,0xE0,0x00,0x10,0x4A,0x46,0x49, ... and so on...

Change the first line to
Code:

unsigned char MANDRILL_DAT[6194] __attribute__((aligned(4))) =


And this is JPEG_DecompressImage from Burton Radons library, right?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#38105 - emgie - Tue Mar 22, 2005 12:08 am

Unfortunately, it doesn't work for me.
I've tried also 8 and 256 aligning, but it doesn't help either.
It does work when I set this data to be MEM_IN_EWRAM, so I'm suspecting that the JPEG library (by Burton Radons, yes) needs to have a write access to the memory where the source is.
But then, why does it work when I use the gbfs filesystem?

Is there any documentation for the library? What are the third and fourth parameters? When I displayed 144x144 image, and invoked the function like this:
Code:
JPEG_DecompressImage(IMG_DATA, MEM_BG_PTR, 144, 144);

the image got messed.
Again, I had to decompress it to a buffer in EWRAM, using (240, 160) as parameters and then blit a 144x144 part of it to the screen.

#38125 - gb_feedback - Tue Mar 22, 2005 3:18 pm

It should work fine from ROM - it certainly worked for me. I don't even think I dword aligned it. Couple of thoughts though. It's been a while since I wrote any GBA code, but don't you need to say 'const' to get it left in ROM?

The business about the 3rd and 4th params. I seem to remember having the same experience and using the same fix. I think the reason has to do with the duel purpose nature of the code. With a very small change it can be made to run on a PC, and I think it is the specific mapping of GBA video memory which means you have to use 240 pixels width. You have to live with it if you don't want to re-write it.
_________________
http://www.bookreader.co.uk/

#38147 - emgie - Wed Mar 23, 2005 12:27 am

gb_feedback wrote:
It should work fine from ROM - it certainly worked for me. I don't even think I dword aligned it. Couple of thoughts though. It's been a while since I wrote any GBA code, but don't you need to say 'const' to get it left in ROM?


Exactly. Using
Code:
const unsigned char MANDRILL_DAT[6194]  = {

solved the problem. Thanks!

BTW. I still don't quite understand why it goes like that... Does the data get lost if I don't use "const"... ;-)
I've forgot many things since my C days (now using perl & php).

#38161 - gb_feedback - Wed Mar 23, 2005 9:30 am

Quote:
I still don't quite understand why it goes like that... Does the data get lost if I don't use "const"... ;-)


The data will be copied by the startup code into RAM and referred to at that location during your program. It may well be that space constraints have caused a data loss. You prpbably only have to lose the end of the jpeg to crash the display code. Examine the .map file to see where it went.
_________________
http://www.bookreader.co.uk/