Stevens Programming Site Blog

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.

Well yesterday was my birthday, 33 years old and I’m already looking for a major project to work on while my unemployment continues.

A couple of days ago I was attempting to assist someone on the devkitPro forums without sounding like a complete know all and making them look like idiots (the post was not submitted as I could not put my response in a polite manor at the time) for attempting to do a directory search for there NDS file on a card, they had linked to a site with instructions on how to do a recursive search of the SD card to find your NDS file.  Well I was curious a little and wanted to know what the site was, and what the owner of the site was attempting to do.  It’s a site dedicated to a homebrew games developer that is blogging about the game they are working on.  From what I gathered on the site the game idea is something that is only in Japan and I could not understand it at all.  What did peek my interest in the site was the small projects that they had wrote to test various parts of the game engine that they are working on, well one thing that got me was the Japanese version of a Rick Roll, a small anime video that looped with some music repeating in the background – it was a nice idea, something simple to test their animation format I thought, until I looked a little closer.  The animation format was actually 40-odd frames long, and each frame was a full screen raw image that was read into memory and then dmaCopied into video ram.  After talking to a few people in the dsdev IRC channel, I remembered about the FLI / FLC video format from the good old days of DOS VGA video modes (320×200 256 mode 13h) and the PC’s then being little more than a 486 DX4 100 or even the Pentium CPU’s that were introduced in 1993.  The FLIC video format was created by Autodesk for their Autodesk Animator and Autodesk Animator Pro applications, it’s an easy to understand format and was designed for the 320×200 video resolution of the day (FLI had to be 320×200, using 8 bit / 256 colours and was compressed using fast RLE compression techniques). I then had a look around for a program to make FLI files from series of images, but unable to find anything that was free I decided to look for some example files.  After locating a couple of possible test files I prepared myself for the following day’s onslaught of coding.

After my daily job search (I’m still unemployed) and finding a job I could possibly do (WOO HOO) I started work on the decoding of a simple FLI file that I had selected as the test file.  After about an hour or two I managed to get the header, colour chunk and the first data frame read correctly.  Taking a break for lunch and some visitors to the house I got back to coding the next hurdle the most common, yet hardest to understand chunk the chuck that is the difference between what’s on the screen, and what should be on the screen.  I got the code working straight away to decode the frame information, but it just was not correctly updating the screen, a little debugging and I still could not sort it out.  It took me another 4 hours to get the code working, actually it was working correctly all along, I was just forgetting that the video format was wrote for 8bit display modes accessed in 8bit increments, not the 16 that the DS insists on, which means that the skip unchanged pixels was being added incorrectly to the offsets, which resulted in strange shimmering of the screen display, coupled onto this that I was pre-scaling the output display to show the entire 320×200 video on the 256×192 display and screaming at the emulator about screwing up and only updating 1 pixel at a time and not the 2 I was telling it to.  Once I worked out the issue, the video ran smooth as it should, and in fact at about the correct speed as well, as I ran the original video scaled down to 256×160 on the QuickTime player and had my DS next to it.  They ran in sync for a while, but the QuickTime player slowly pulled ahead.  I was not bothered about that, as this was only a prototype test of the possibility of displaying FLIC files on the DS, I have a couple of idea for increasing the speed, but so far it’s working.

Console Update

A quick update on the state of play with my console, I’ve managed to get the console to display utf8 encoded characters with minimal of fuss, the only issue is that you need 3 font files for 1 utf8 decryption, and the only characters available are the ones from the DS’s normal input keyboards (use pictochat and you will see what I mean).  Using a loading screen from Overlord II as a backdrop I have also managed to update a couple of the functions so that you can have text on top of an image with out the image getting corrupted.

File Links for the above examples

You can download the test files for the above two entries below:

FLI Player test application – no source code this

If you don’t have a nitroFS aware home brew launcher, then you will need this file, put it in a directory called fli in the root of your SD card to run it on hardware that does not like libfilesystem based applications.

UTF8 Test application this will run on any emulator that exposes a user profile (not many that I know of) but will run best on a DS if your DS user profile has non-Latin characters in it they will be displayed correctly (I hope )