FLICing more into my FLI player
Well the current state of my FLI/FLC player is that I managed to get some optimisations into the decoding code and managed to get the test 320×200 FLI video to play at around the same speed as QuickTime, ok next challenge was a 160×120 FLC file. Now the problem with FLC files is that they can have any size, unlike FLI files that are fixed 320×200 images, this should be fine as long as the image is smaller than the largest background size that the DS can handle. After reading the file format correctly for an FLI file the FLC file should be no problem – I was slightly wrong.
The first major issue (and the biggest improvement) is that the compressed frames are word aligned, not byte aligned, this led to the decoding code improving in speed on the 8-bit screen mode (I’m not reading the screen into a temp variable, updating it and then putting it back onto the screen) and making my code for the FLI (I’ll just copy and paste I thought) not work at all as the start of each encoded line can have a few opcodes, each opcode has to be read and parsed, there’s no way to just skip them (although one of the opcodes I did skip as I do not think anyone would use an odd sized width file). After getting the code to work (multiple itterations wondering why I’m only updating 75% of the 3rd line of my test video (this was the first line that used a specific encoding sequence) and ripping some of my hair out I finally got it to play perfectly. I added some code to the FLI decoder to tell my approximately how many vblanks were being used to render 1 frame of the video, to my surprise the 320×200 video was running @ about 3 vblanks per frame (or approx 20 fps) – which is about the correct FPS for that video. The FLC I had was running closer to 1.25 vblanks per frame (approximately 48 fps). The video should be running a lot slower than that, I think it should be running at 30 fps – so the code I’m using on a 160×120 video is fine (and in each frame I think nearly every line was changing in some major way). Now onto the real challenge, a 256×192 image. Even though I was scaling the background to fit the full video onto the DS’s screen, I should check the code on a 256×192 video that would be what most people that use this code would be using. Hunting around for a free application to save FLC files was not easy – most were for windows, and when I did find one that I could get the source for it’s input file format was PPM (a very old and dead file format), failing to find anything better I looked for something to convert to PPM files – The GIMP came to mind as it’s for Linux, Windows, etc. Checking the file save dialog I spotted a little godsend – FLIC (fli/flc) – GIMP knows how to deal with FLIC files 
. With this in mind I generated a short animation in Blender, and created my 256×192 FLC file within seconds (actually more like 5 minutes after having to re-arrange the files) and expectedly opened the file in my test nds file. Yeah I have an image… Crash….
After some investigation it turns out that GIMP’s FLC encoding is good, but not the best as it saves filler byte at the end of a frame chunk to make every frame start on an even byte. A quick change to my code and I have a fully running FLC player for any files generated by GIMP. Next step in this project – adding audio via the EGA_WAVE chunk that was added by the EGA application.
No demo this time as I’m going to play around with another of the projects I’ve got going at the moment. I’ll try and get something working that’s better than my current version and post a demo soon.