Stevens Programming Site Blog

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 )

Current status: On Hold

I’ve put this little project on hold for the time being as I am unable to actually do it with my current coding style – hack at the code, what design document???

So I’ve put the project on hold while I actually sit down and design the project correctly – unfortunately this will mean that it may never be done as I can not design anything without wanting to code something, and I also suffer from a mental issue which I like to call “Oh shiny, shiny lets do that”, in other words I get distracted way too easy from projects unless I’m enjoying doing it.  I will return to the unified console project once I get something major done on the design document – I will actually get something done on it, it will just take a little while longer than I originally wanted.

Anyway the shiny that’s caught my eye today was a document I wrote a while back for a game I wanted to write – and yes I did write it as if I can remember correctly at the time I was working and had a lot of free time at work, and without access to a game or development environment I started to type up this game idea, and I want to actually work on it – but the problem there is that the document is not all there, some of the pages are missing, and it looks like I spilt coffee on it at some point XD.  Anyway it got me thinking the background of the game, where it came from etc, and I started to write down a couple of idea’s for me to pursue – one is a game, the other is something to do with my current console code, and if anyone knows me on the #DSDEV IRC channel they may have spotted me taking to WinterMute about UTF-16 / UCS-2 and UTF-8 encoding standards.  Well I’ve decided to head back to my Homebrew Menu interface and this time do something other than the original plan of DSi like menu system.

I’m going to use my graphics console but I need to find some good fonts that are UTF-16/UCS-2 compatible for the end product, but for now I’m going to use simple ascii file names.

While attempting to code a homebrew menu graphical interface I started to see that the way I’ve coded the graphical console technical demo’s and code could not actually be transferred onto the sprite system easily, so I’ve had to do a little bit of thinking about a unified console system that works on all 3 modes that the DS has:

• Tile
• Bitmap
• Sprite

To enable a console output in the tile or sprite modes would mean a totally separate console sub-system, which would mean having 3 or 4 different ways to output a character glyph onto the different modes, so I’ve started to break down a console system into a very simple framework that will contain just one set of code that will work in all screen modes.

Other things that I will have to take into account would be the screen colours – 4/8/15 bit modes – that require their own output code.  This little project will take a while to do but it will be the first real project I do for the DS, and the homebrew menu interface will be the example project for it.

The current devkitPro contains a hidden gem of an application a Homebrew Menu application that allows some of the newer features to be used correctly (nitrofs file system compatibility one of them that I am aware of), and while it’s nice it’s not the best looking application to show off the features of the DS.  I’d put a screen shot here to show you what it looks like as there is no emulators that emulate FAT SD cards correctly at the moment, so the following is what it sort of looks like (it is in text mode on the DS.)

fat:/
------------------------------
*App1.nds
 App2.nds

So yeah it’s crappy XD.  Anyway what I’m hopefully going to do is a nice GUI for it, something along the lines of the DSi’s new interface.  I’ve already got the basic sprites designed, and a quick test with the sprites put at static positions looks ok, so far.  I’ve still got some work to do on getting the application to work correctly.  Since the bottom screen is used only for the application the top screen can be used for other things, at the moment I’m looking at putting a calendar on there along with some of the features of the old DS firmware (Profile name, time, etc).

Since the current version is very limited (it’s static information at the moment) a working version may possibly take a few days to get right before I have something that works.

I’ve just finished getting the distribution of the graphics console together, you can download it here.  I’ve included some fonts for people to play with and hopefully I will be able to get a working font editor working on the DS, and windows, but I’m not sure when.

It’s been about a month since my last update on here, and what have I done in that time? Nothing.

Well I slightly lie, I’ve been looking for work, and when not doing that I’ve been playing games, chucking out rubbish, and finding some old notes on things that I wanted to do a while back.  One of these is an old game design that is for a base building simulation like moon base (on the Amiga) or any of the modern base building simulations.  I have also started to get my graphics console application ready for release, and using the current console examples within the devkitPro packages.

Once the graphical console is sorted then I will start work on a couple of game idea’s I have for the DS and / or the PC.  I already have some information wrote up for one of the games on paper at the moment, I’ll get round to writing up the document in a more computer readable format at some point soon.  My first game idea that I had posted about is still floating around, but it may end up getting mixed into the game notes that I wrote about finding.

Anyway time to get back to the conversion of the examples.

In about 1 weeks time I will be unemployed, thanks to the current global economic downturn, and this has given me some much needed perspective on life.  I’ve spent the last 3 weeks looking for work, and so far there’s been no replies, I’m still optimistic about finding a job.

While I’ve not been looking for work (there’s only so many sources of jobs to search and apply to) I’ve been doing some coding for the Nintendo DS, so far 2 little tech demo’s, a voxel terrain and a graphical console application.

Voxel Terrain Engine

This is a simple little engine that I wrote to see if the DS was capable of producing a working voxel terrain landscape.  It can, but it takes a little long to produce the landscape using the code I have here.  I would like to make this little tech demo better / faster at some point, so that it becomes something useable in a game – Valley flying game where you have to shoot things, or something better.

Known limitations in the current code:

• Map Memory – limited to 256×256 currently
• Slow code, the code can possibly optimised a little since it was based on a BASIC program.

Graphical Console

A nice little extension to the normal console output that is supplied with libnds.  The font’s are from the ByteMap Font site.  While some fonts are not perfect for the DS’s screen size (one font is 239 pixels high), or too hard to read on any screen (a 3×3 font!) there are some nice sizes, as can be seen in the screen grab to the right.

The current version of the console code works with the iprintf() that is provided by libnds, and includes support for many of the standard ANSI escape sequences that work on any ANSI terminal, including one of the more unusual codes – <ESC>[1?m – to allow the console to change the font glyphs part way though a line of text.

The main bad news – Thanks to the current economic downturn, and the lack of people actually flying with BA now, I’ve not had my contract renewed for the next year.  So I’m now having a few days holiday prior to starting the lovely “Hunt a job” game.  Fingers crossed I’ll not be out of work too long…

As for the good news – I’m starting to code a few little demo’s on the Nintendo DS, the first of which is a little voxel terrain engine.  The current version is very simple and does not contain any major great things, but it does do the basics:

• Voxel landscape
• Colour map
• A very simple LOD fog

I’ll write up a little about the project a little later, as well as a full blown article on how it works.

Other bad news:

• It looks like the EMS project that I was working on may have entered the abandon-ware status, mainly as I’ve not done any coding on it for so long and that the amount of features I want to have on it has went up..  I may attempt to work on it again in the future, but at the moment, it’s a dead project.
• My game project that I was going to do did not get past the “OOOH I’ll write a game” stage, mainly down to lack of time.  the work I’m doing on this voxel terrain engine has got me thinking of getting back into that frame of mind, but with a different game idea altogether.

One thing I know, with more spare time I will be updating this blog more as well as coding more, so I’ll start to feel a little happier

Well I’ve started a new project – a game, but at the moment I’ve got no name for it, and I’m still working on the design document for it (I’ll be putting it up on a page on my blog as soon as it’s ready).  The thought behind this new project was mainly to force me to do something other than play Eve-Online, or watching TV shows.  More information will be posted as and when it’s available, but I will be posting every little thing about this project, as well as doing a proper little web site on this site.  The basic idea for the game is to try and emulate the great space resource management games of the past – Project: Space Station, Millennium 2.2, Deuteros, and E.O.S (Earth Orbit Stations).

While these games are different, they all have a unifying theme – they are fun to play and I’ve not seen anything like this released in the past few years (nearly every game out there is some form of FPS or some high graphics low game play style thing).  I’ve set myself a target of getting the first milestone (the design document) wrote and started on some mock up screen’s and graphics that will be in the game.  I’ve not decided on the target platform at the moment, but the DS may very well be the target platform, since the platform is portable, and this type of game might be good on that system.

Well I got the splitter bar working, very nicely as well, I’ll post a better write up about it at some point as at the moment I’m back at work and looking at some very ugly decorations (why do companies insist on putting decorations up in a multi-cultural office???).  EMS and SPIC have been going though some interesting changes over the last couple of days, one major change is in the debug level code, I’ve simplified the process and now I’ve only got 5 main levels (Normal, Flow, Warning, Error, Information), 3 developer levels ( Developer output, Memory Allocations, XML Dev out), and 2 options to enable module and API logging – reducing the EMS log files a little in the process.

One major problem has been hit by a user of the system when it comes to the ECM integration, apparently it’s not working correctly, so I’ve had to create a special version of EMS just for him, and I’m hoping that the changes will help identify the issue that he is having.  I’ve left the changes in for the next couple of versions of EMS, mainly as the changes are for logging the data flow of the system, and basically they are logging information that I never thought I needed to monitor, a lesson learnt there – have a flow log call at the start of every function except the logging one of course .

SPIC is coming along nicely, I’ve spent the last week working on the splitter bar for this project and as I said it’s working almost the way I want it to, I’ve got a few additional items I want to change on it, but they can wait until SPIC is out the door.  One thing that I have noted is with spitter bars, or this could just be down to the way I have made mine to work, is that you need 4 windows to handle them, a parent window that contains the splitter bar and two other windows, these other windows could be a splitter parent or even the view windows for a document / view style window layout.  Even at this early stage of development I’ve been thinking about how the scheduling window at the bottom of the SPIC screen will look, and how it will give the user an idea of what skills they will be training over the next few hours / days / weeks / months, and I will be writing up a full thought process blog entry closer to the time that I do this.

Anyway back to the coding.