BadApple... again :)

djcouchycouch · Post by **djcouchycouch** » Sun Sep 02, 2012 11:39 pm

Can you somehow use a layer containing solid white or black tiles to help in optimization? Imagine the frame is broken up into two layers, one solid color and the other one with opposite color containing the "silihouette" of the character.

HardWareMan · Post by **HardWareMan** » Mon Sep 03, 2012 2:48 am

I recommend to look at "Red Zone". They use some techniques, that can be useful to this demo.

Stef · Post by **Stef** » Mon Sep 03, 2012 8:28 am

I already use the black and white solid tiles to optimize plain area

I use a single plan but i don't think using 2 plans could help here (as i will have to update both tilemap)... the code which handle plain area take a very low part of CPU time. The bottleneck is just the tile decompression code, sometime i can have up to 200 tiles to unpack in a frame and that's way more that i can handle (my code to unpack a tile take approximately 5 to 16 scanlines where it should take no more than 3 scanlines to keep 30 FPS).

Red Zone is doing their monochrome movie this way : they use a single tile to display 4 frames by switching palette color. So for 4 monochrome frames you only need to send one 16 colors frames to the VDP, this way you are less limited by VDP bandwidth.
Actually i already using that method to display 2 frames in a single tile (i can do only 2 frames as i have 4 colors) by switching palette so i am not limited by the VDP bandwidth

Unfortunately to achieve a good compression ratio i cannot directly pack the 4bpp tiles, i have to pack them as 2bpp tile and reconstruct 4bpp on the fly after the unpack process... that is also a problem in my compression scheme.

HardWareMan · Post by **HardWareMan** » Mon Sep 03, 2012 10:02 am

If you were smart, you were doing a preliminary decompression where there is time. I want to say that you can extract part of the tiles in advance. For example: the 1st frame uses 30 tiles, 2nd frame uses 130. Time between change frames is enough for unpacking 100 tiles. If you unpack each frame when you need it, then the first frame will be a lot of free time and second a lack of it. But if you allocate tile unpacking, say, 30 + 60 in 1st frame time and other 70 in second frame time you get result right in time. I hope you got idea.

Stef · Post by **Stef** » Mon Sep 03, 2012 2:43 pm

HardWareMan wrote:If you were smart, you were doing a preliminary decompression where there is time. I want to say that you can extract part of the tiles in advance. For example: the 1st frame uses 30 tiles, 2nd frame uses 130. Time between change frames is enough for unpacking 100 tiles. If you unpack each frame when you need it, then the first frame will be a lot of free time and second a lack of it. But if you allocate tile unpacking, say, 30 + 60 in 1st frame time and other 70 in second frame time you get result right in time. I hope you got idea.

Yep but the only problem with that is memory... i am already doing that on a 4 frames timeslice (2 frames are unpacked while 2 frames are being transferred to the VDP in blank period) and i cannot fit more in memory.
And honestly you rarely have 30 / 100 / 40 schemes... usually the modification rate change a bit on a frame unit so when you have many changes on a single frame you can be sure you have many changes on the previous one and the next one too (in almost case).
So even if 200 tiles to unpack is the worst case, you have to maintain close to that rate on a frame basis :-/

djcouchycouch · Post by **djcouchycouch** » Mon Sep 03, 2012 3:00 pm

wacky ideas time: instead of decoding video to data, how about decoding video directly to code. Or encode the video into VDP calls.

Stef · Post by **Stef** » Mon Sep 03, 2012 3:24 pm

Here again it's all related to rom space... packing generated code would not be as efficient than packing data in term of rom space usage. I am already to the limit of 4MB and want to fit in 4 MB

I know, i probably want too much :p
Something i want to try is to generate code instead of holding dictionary data.
The dictionaries are not that big so even with code it should fit in 4 MB... but my dico unpacking code is already optimized and i am not sure and i can w gain that much by generating code... also that would require again lot of paintfull debug :p

Stef · Post by **Stef** » Mon Sep 03, 2012 3:26 pm

sorry for triple post :p

Stef · Post by **Stef** » Mon Sep 03, 2012 3:28 pm

sorry for triple post :p

Chilly Willy · Post by **Chilly Willy** » Mon Sep 03, 2012 6:30 pm

HardWareMan wrote:If you were smart, you were doing a preliminary decompression where there is time. I want to say that you can extract part of the tiles in advance. For example: the 1st frame uses 30 tiles, 2nd frame uses 130. Time between change frames is enough for unpacking 100 tiles. If you unpack each frame when you need it, then the first frame will be a lot of free time and second a lack of it. But if you allocate tile unpacking, say, 30 + 60 in 1st frame time and other 70 in second frame time you get result right in time. I hope you got idea.

It's called "buffering" and I thought of that as well, and of the response - "what memory?" That's one problem with the MD - only 64KB of ram. You could really only buffer a few frames worth of tiles, which won't do much good on some sections.

Anywho, this issue with speed of decompression is why Nintendo had special chips for the SNES - do the decompression on the cart and you don't have this issue. Of course, now you're requiring special hardware.

bioloid · Post by **bioloid** » Mon Sep 03, 2012 6:58 pm

this things rocks!

HardWareMan · Post by **HardWareMan** » Tue Sep 04, 2012 2:57 am

Yeah. 64 KB is suck. Remind me some famous quote: "640K ought to be enough for anybody". :3

djcouchycouch · Post by **djcouchycouch** » Tue Sep 04, 2012 6:05 pm

Would frame skipping be too bad? At what framerate does the encoded run at?

Stef · Post by **Stef** » Tue Sep 04, 2012 7:50 pm

The video is basically done to be played at 30 FPS.
I could reduce frame rate but then we will have less frames to encore and so less rom space used.. in that case i could simplify the compression and have higher frame rate

But i want 30 FPS, that really make the video better

Honestly we could easily do 30 FPS if the rom space is not a matter...

djcouchycouch · Post by **djcouchycouch** » Tue Sep 04, 2012 8:07 pm

If you dropped it to 28 or 24 frames per second, it wouldn't help? You'd have a bit more time for processing a frame, which is the bottleneck, right?

When I worked at Ubisoft, achieving 30 frames per second on a game usually meant around 25