struggling with loading bitmap

matteus · Post by **matteus** » Fri Mar 14, 2014 8:40 am

I understand everything bar this line

maxInd = USERINDEX + TILE_USERLENGTH - 1;

Where USERINDEX and TILE_USERLENGTH are not in my code?

and shouldn't

Code: Select all

VDP_setVerticalScroll(BPLAN, nextvpos);

be

Code: Select all

VDP_setVerticalScroll(BPLAN, 0);

?

Stef · Post by **Stef** » Fri Mar 14, 2014 9:05 am

Oh i should have wrote TILE_USERINDEX (i just fixed it).
TILE_USERLENGTH is the maximum number of tile for user (other is reserved for SGDK).

And for the scrolling, you should definitely use:

Code: Select all

VDP_setVerticalScroll(BPLAN, nextvpos);

As the idea is to upload the iamge first then display it

matteus · Post by **matteus** » Fri Mar 14, 2014 9:08 am

Using the code posted the image is off center every other frame? Any ideas why this would be...

matteus · Post by **matteus** » Fri Mar 14, 2014 9:14 am

Code: Select all

    VDP_drawImageEx(APLAN, &border, TILE_ATTR_FULL(PAL2, FALSE, FALSE, FALSE, ind), 0, 0, TRUE, TRUE);

    ind += border.tileset->numTile;

    newInd = ind;

    maxInd = TILE_USERINDEX + TILE_USERLENGTH - 1;

        for(i = 174; i < 214; i++)
        {
            //if(i == 37) {
            //music
            //    SND_startPlay_PCM(thundercats_music, sizeof(thundercats_music), SOUND_RATE_8000, SOUND_PAN_CENTER, FALSE);
            //}

            Image *img = images[i];
            
            // number of tile of current image
            u16 numTile = img->tileset->numTile;

            // no enough vram space for the current image ? restart
            if ((ind + numTile) >= maxInd) {
                ind = newInd;
            }

            u16 nextvpos =  vpos ^ 0x20;

            VDP_drawImageEx(BPLAN, img, TILE_ATTR_FULL(pal, FALSE, FALSE, FALSE, ind), 7, nextvpos + 4, TRUE, TRUE);

            // move to new image
            VDP_waitVSync();
            VDP_setVerticalScroll(BPLAN, nextvpos);

            ind += numTile;
            pal ^= 1;
            vpos = nextvpos;
            waitTick(100);
        }

    while(1)
    {
            VDP_waitVSync();
    }
    return 0;

Stef · Post by **Stef** » Fri Mar 14, 2014 3:46 pm

Ah yeah, you should use

Code: Select all

VDP_setVerticalScroll(BPLAN, nextvpos * 8);

as you set scrolling in pixel and not in tile, small typo :p

matteus · Post by **matteus** » Fri Mar 14, 2014 6:46 pm

And we have a winner! It's working 100%! Thank you so much for cleaning my code up Stef! I shall now focus entirely on the animation

Video update:
http://youtu.be/cOjiAQpLOrs

Stef · Post by **Stef** » Mon Mar 17, 2014 9:34 am

The last video looks really cool

By the way, you can improve greatly the audio quality by using the ADPCM driver instead. It will consume a bit more of rom space but you will have a 22 Khz playback instead of the very low 8 Khz

matteus · Post by **matteus** » Mon Mar 17, 2014 9:42 am

Stef wrote:The last video looks really cool
By the way, you can improve greatly the audio quality by using the ADPCM driver instead. It will consume a bit more of rom space but you will have a 22 Khz playback instead of the very low 8 Khz

Thanks Stef!

My next question is about ROM space, How much do I have? In standard cart sizes is it about 4MB (32MEG)?

I can't get the images to compress using RLE, I get tile corruption again, so I'm wondering how I can reduce the ROM size

matteus · Post by **matteus** » Mon Mar 17, 2014 10:31 am

The animation seems to get a lot more complex after the first 5 seconds lol lots of lens flair!

Stef · Post by **Stef** » Mon Mar 17, 2014 12:01 pm

If RLE compression give you corrupted tile that means i have a bug with my packing or unpacking, something i have to verify. Too bad the aplib compression is so slow to unpack, i have to introduce a faster packing method and with better compression ration than RLE.
Maximum ROM size is indeed 4 MB to stay compatible with addons. My BadApple demo does 8 MB but is not anymore compatible with sega CD and can be tested only with MegaEverdrive flash card.

r57shell · Post by **r57shell** » Mon Mar 17, 2014 1:34 pm

Aplib is slow

. May be you using C version?

Stef · Post by **Stef** » Mon Mar 17, 2014 2:25 pm

I'm using the ASM version, i think i even use your version which do not contain header information. The code is optimized for size but definitely not for speed. I believe i can improve it but still the compression schem is probably too slow for "real time" decompression. I have also the konami codec which appears to be quite good in term of compression (sometime better than aplib, sometime worst) and the unpacking speed is quite good too (at least better than aplib) but because i don't own the rights of this code i disabled it. I even contacted Konami but they definitely don't want that we distribute any of their code properties (at least not freely).

r57shell · Post by **r57shell** » Mon Mar 17, 2014 4:09 pm

I'm using the ASM version, i think i even use your version which do not contain header information.

Good.

The code is optimized for size but definitely not for speed.

Code uptimized for speed too. Aplib is very fast.

I believe i can improve it but still the compression schem is probably too slow for "real time" decompression.

I don't know what you mean by "real time" decompression. Do you want to decompress fullscreen image 60 fps in realtime? I don't think it's possible.

I even contacted Konami but they definitely don't want that we distribute any of their code properties (at least not freely).

You mad

You can implement some simple kind of LZxx (place instead xx anything you want). It's fastest way from top of my mind. :

Stef · Post by **Stef** » Mon Mar 17, 2014 5:20 pm

Code uptimized for speed too. Aplib is very fast.
..
I don't know what you mean by "real time" decompression. Do you want to decompress fullscreen image 60 fps in realtime? I don't think it's possible.

Of course i don't want to decompress big image

but even for medium sprite i assure you that aplib unpacking code is definitely not really fast... You cannot use it for fast medium sprite animation, i don't have numbers in mind but i definitely can't decompress a 64x64 sprite in a single frame for instance...

Stef wrote: You mad

You can implement some simple kind of LZxx (place instead xx anything you want). It's fastest way from top of my mind.

Well at least i tried :p
I will think about it later.. not a top feature as currently we have the RLE which is fast but compress badly and aplib which compress nicely but is, for me, a bit slow to decompress. Maybe a simpler scheme could do it

r57shell · Post by **r57shell** » Mon Mar 17, 2014 6:56 pm

For sprites, you must use different approach, and they really complicated.