I'm not really sure.
Maybe some compression using the LZO library for uzebox by Braddock to increase the average number of pixels per sd-card read, and intense use of a buffer for the compressed input. Then it could immediately decompress data to the screen (assuming the time is constant).
At the very least, the blank parts of the screen (not sure how much of it there is already) shouldn't be stored. Instead that time should be used to read in more data.
I'm not really sure about any of these thoughts, since I haven't taken the time to understand the code for the movie player.
When I do get back to programing, I'll probably want to work on a video mode I'll call "video mode X1", which will be geared towards drawing polygons(lines, 2-d non rotated rectangles, and filed triangles).
8 Bit Trip -- Got to see this!
Re: 8 Bit Trip -- Got to see this!
When I was doing this movie mode, there was just so much technical limitations to overcome it's unbelievable it worked at all. Sometime, I need to write more about video modes and how they work.
-Uze
-Uze
Re: 8 Bit Trip -- Got to see this!
I've finished converting this to the uzebox video codec
I've sent the video file to uze. So enjoy.
P.S. I finally got the AVcore, yay!
Had to use a TV in a random room to test it though.I've sent the video file to uze. So enjoy.
P.S. I finally got the AVcore, yay!
Re: 8 Bit Trip -- Got to see this!
Just viewed it...awesome! Conversion is as perfect as it can get! When you get a few minutes, what about writing a quick wiki page about the final conversion process you used (or post here, I'll add to the wiki)?
We now have a much better demo for the movie player! I've uploaded it here for everyone to enjoy: http://uzebox.org/files/8bit_trip.zip
-Uze
We now have a much better demo for the movie player! I've uploaded it here for everyone to enjoy: http://uzebox.org/files/8bit_trip.zip
-Uze