Another ?: about "corrupted" graphics with BGcon/Dehuff

[Madroms]

Another maybe dumb question:

Does anyone notice some corrupted pixels (2-3) at the bottom right part of a the picture when:

- convert a .tga to .bin with BGcon using DHUFF compression

- load the compressed .bin to RAM with Gfs_Load

- decompress it with Dehuff()

- then copy the data to VRAM

?

Here are 2 pictures: before (original) and after (rendered with SSF emu and captured with the PrintScreen key):

http://madroms.free.fr/white.png

http://madroms.free.fr/whiteSSF.png

It could be an emulator issue (I can't test it on yabause as it doesn't load the picture correctly or on a real saturn right now), or it could be a pb with Bgcon or Dehuff.

I also notice this problem on the LAVA picture of Rockin'B in the SaturnGameTutorial sample (when lanched in SSF).

This problem is not a MAJOR problem but you notice it when your picture has a white background, as you got some black pixels at the bottom right part.

Does anyone has a clue ?

 

[RockinB]

Hello Madroms,

nice to see your progress, are you working on an entry for the Saturn Coding Contest?

About dhuff: I also experienced problems with dhuff'ed pictures on emulators like yabause or the older SSF-Emulators. But they were more serious than just 3 corrupt pixels (are you storing the image at an odd VRAM-address?).

Most likely it's an emulator only problem with the Dhuff routine. I've never expected any problem on a real Saturn with dhuff'ed images, other than decompression taking WAY to much time (try out decompressing to/from VRAM directly).

If you would dump the image from Emulator-VRAM and compare it with an uncompressed binary version created with BGCON, then you'll see some difference if it's not emulated properly.

Because of decompression time, I am using LZO compression for the Police Officer Smith game.

 

[Madroms]

I don't know if I can submit my work as I only modify your source codes (you know on what I am working )

I am also new to c dev and saturn dev. In fact, I never touched c codes before

Ok, so you think it is a pb of emu compatibility. So I must try it on real hardware to be sure.

I used Dhuff routine for background images only, so the speed is not really an issue. Could you tell me how many sec is needed to decompress a Dhuff image on real hardware ?

I am also using your own img2VRAM function

Hmm, I have another simple question:

is it possible to allocate some memory that can be used in all the functions, like a global variable ?

something like:

void *data;

data = (void *)malloc(0x29400);

but not limited to the function where it is defined.

 

[RockinB]

It's absolutely okay to use the code for a C4 entry, it has been done before and it was intended to give some sort of startingpoint.

Also don't waste your time with the dhuff problem, as there actually is no problem for you.

Hmm, I have another simple question:

is it possible to allocate some memory that can be used in all the functions, like a global variable ?

something like:

void *data;

data = (void *)malloc(0x29400);

but not limited to the function where it is defined.

Yes, you could just define the data variable outside a function and assign a malloc'ed memory space pointer to it at startup.

Declaring an empty array may also suit your needs:

unsigned char data[0x29400];

Note that this one is placed into high work RAM (unless you play with the link script).

If you know what your doing, you can explicitly assign the memory location, like the 1MByte of low work RAM:

void *data = (void *)0x200000;

 

[Madroms]

Thanks for the answer Rockin'B! Vbt told me exactly the same thing on IRC for declaring an empty array

For a c4 entry, I will send you a sample so you will tell me if it could be an valid entry, if I finish it

 

[CyberWarriorX]

Just wanted to let you guys know I'm pulling out of the contest. I don't have the time for it right now and I won't have anything significant ready anytime soon.