Code is therapy...

As alluded to in earlier posts, the graphic data is laregely done, say, 90% percent complete.

Being a bit of a sadist, I decided I couldn't be bothered writing code on the ZX Spectrum to rip the graphics. I've put this down to three reasons:

• I'm thoroughly lazy
• I'm not clever enough to do that on the speccy
• I'm thoroughly lazy

It would be "much easier"* I thought, to write my own sprite editor and just draw the grahics on the screen. I suppose it was "easy" but it was very time-consuming. Still, writing the editor was interesting: I wrote a version first in Extended Basic which worked fine, and was much faster than similar programs I had seen running in Extended Basic, through the use of a few cunning tricks.

Of course, it would be much better if I wrote it in C. Why would it be better? Well, you know, because it would! I therefore determined I would re-write a perfectly working and fully functional peice of code in C**, "because I could". Still, the finished result (youtube video below) was pretty nice, in a retro-uber-geek-this-guy-should-get-out-more kind of way.

So, that was the graphics done, and imported into my source files. What next?

Well, I decided to just dive right in and start the code to define the graphics for each level:

For those that aren't in the know, the video memory on the TI-99/4A (or indeed any machine using the TMS9919 video graphics processor) is seperate from the CPU memory. The chip has a two text modes (1:32x24, 16 colours 2:40 x 24, 1 colour) and a bitmap mode. As a remarkable stroke of luck, the screen resolution is exactly the same as the ZX Spectrum: 256 x 192 pixels.

Now, the ZX spectrum screen is bitmapped only - there are no text modes. However, the spectrum's video memory is normal CPU addressable memory, so access to it is very fast. Access to the TI's video memory is through memory mapped IO: two addresses, one for reading, one for writing. A third address allows you to set up the VDP address that you are interested in, and after that, subsequent accesses will auto-increment the address for you. Nice.

Well, after a lot of thought, I determined that the 32x24 pattern mode would be fine for my needs. There are 256 definable characters, and after analysing every level using JSWED, I determined that every level would fit.

In pattern mode, the 256 ASCII character set is further subdivided into sets of 8 characters. Each set may have one forground and one background colour, thus careful planning is required to group your characters according to the colour attributes required. This took a few evenings of chin scratching. Excel to the rescue: I built a spreadsheet to work out the character assignments.

I now knew exactly which ASCII characters would hold which definitions on each level. For simplicity of code, all common objects occupy the same characters between levels (walls, floor, keys, doors, conveyors etc) only their colours and actualy graphical definitions change between levels.





* Feel free to laugh
** What's wrong with me?

Still bubbling away...

Well, it's been a while since I last posted to this blog, so I thought it high time I posted an update. You could be forgiven for thinking that no progress has been made, or indeed that development on the project has ceased. However, you'd be wrong!

Nay my friends, I have been having a veritable code frenzy of Manic Miner-ness. Part of the reason for the massive delay has been due to me making a very serious mistake. Some time ago, a discussion at work about programming languages led me to declare to all that would listen that Forth was, and I quote: "Shit". I then went on a rant about how unreadable it was, and that it was stupid because everything was written 'backwards'.

"Oh" said my colleagues, in a "there-must-be-more-to-life-than-this" type of way.

A few hours later, guilt somewhat got the better of me. I mean, there I was telling everyone how crap Forth was, and the truth was that I actually knew *nothing* about it. I mean, totally and completely bugger all. As a result, I determined I would learn a little bit about the language, just, you know, so I could blast it a bit more and really sound like I knew what I was talking about when I told everyone how crap it was.

Trouble is, it's not rubbish. It's actually amazing. Brilliant. Perhaps the most simple, beautiful language I have ever seen. When I finally got the Interpreted Threaded Code concept, and how code was compiled, I was simply hooked. I simply had to have a go at it. So, I somewhat naively launched into writing my own Forth engine in 9900 assembly (you know, as you do). I even invested in some old books. You'll be glad to know (though not half as glad as me) that the code written so far works, and is very fast. It runs Forth code just fine. I've just got to finish the command line interpreter and fully test all the words and it will be maybe 98% finished (just block commands to finish).

So, that's the reason for the delay. I spent days and days coding my Forth engine, and totally left Manic Miner to languish. A poor show.

Accept, it's not really a poor show is it? One of the cool things about coding in your own time is that you get to work on the things you want to work on when you want to work on them. Coding up the graphics for Manic Miner was such a large job, including coding up my own sprite editor and animator, that it sapped my energy and enthusiasm for while, only to be replaced with Forth.

A few weeks ago, I decided to revisit the code I had done for Manic Miner to 'remind' myself of how it all worked, only to find that there wasn't really any code at all - just lots of data, so I thought I would spend an evening or two putting some code together to test my data. You know, as you do... That was probably over a month ago, and an awful lot of progress has been made. In the next few posts I'll summarise where I am with the code so far. Stay tuned!