BadApple... again :)
Moderator: Mask of Destiny
-
- Very interested
- Posts: 710
- Joined: Sat Feb 18, 2012 2:44 am
-
- Very interested
- Posts: 745
- Joined: Sat Dec 15, 2007 7:49 am
- Location: Kazakhstan, Pavlodar
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
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.
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.
-
- Very interested
- Posts: 745
- Joined: Sat Dec 15, 2007 7:49 am
- Location: Kazakhstan, Pavlodar
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.
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
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.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.
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 :-/
-
- Very interested
- Posts: 710
- Joined: Sat Feb 18, 2012 2:44 am
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
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
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
Last edited by Stef on Mon Sep 03, 2012 8:03 pm, edited 3 times in total.
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
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.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.
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.
-
- Very interested
- Posts: 745
- Joined: Sat Dec 15, 2007 7:49 am
- Location: Kazakhstan, Pavlodar
-
- Very interested
- Posts: 710
- Joined: Sat Feb 18, 2012 2:44 am
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
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...
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...
-
- Very interested
- Posts: 710
- Joined: Sat Feb 18, 2012 2:44 am