Page 9 of 10
Posted: Fri Mar 14, 2014 8:40 am
by matteus
I understand everything bar this line
Code: Select all
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
?
Posted: Fri Mar 14, 2014 9:05 am
by Stef
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

Posted: Fri Mar 14, 2014 9:08 am
by matteus
Using the code posted the image is off center every other frame? Any ideas why this would be...
Posted: Fri Mar 14, 2014 9:14 am
by matteus
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;
Posted: Fri Mar 14, 2014 3:46 pm
by Stef
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
Posted: Fri Mar 14, 2014 6:46 pm
by matteus
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
Posted: Mon Mar 17, 2014 9:34 am
by Stef
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

Posted: Mon Mar 17, 2014 9:42 am
by matteus
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

Posted: Mon Mar 17, 2014 10:31 am
by matteus
The animation seems to get a lot more complex after the first 5 seconds lol lots of lens flair!
Posted: Mon Mar 17, 2014 12:01 pm
by Stef
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.
Posted: Mon Mar 17, 2014 1:34 pm
by r57shell
Aplib is slow

. May be you using C version?
Posted: Mon Mar 17, 2014 2:25 pm
by Stef
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).
Posted: Mon Mar 17, 2014 4:09 pm
by r57shell
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. :
Posted: Mon Mar 17, 2014 5:20 pm
by Stef
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

Posted: Mon Mar 17, 2014 6:56 pm
by r57shell
For sprites, you must use different approach, and they really complicated.