Pleased to see the wiki updates have resumed, sorry to hear you've been ill.

Do you think you'll be well enough to make it to the Lass on Saturday for a coding sesh?

Sorry to get your hopes up there Dave with the wiki entry. I managed to make a bit of progress last weekend but I'm still feeling pretty rough and finding it difficult to concentrate on anything so there won't be any more updates on the game for a little while.

It doesn't look like I'll be able to make it to the Lass. I don't want to be spreading my lurgy around

Work has now resumed on the game and I'm starting to make some progress again. It's surprising how difficult it is to get back into a project when you lose the momentum.

Anyway, on to the point of this post. At the moment I'm writing the code to display and control the main player sprite. Once that's done, it would be a good time to put some more eye candy on the wiki page and I was thinking of doing a short video.

Is there a preferred/recommended way to do this, such as the RetroSoftware channel on YouTube or should I just upload the AVI from BeebEm?

If you upload a video to YouTube, you can easily embed it on the wiki and/or the forum for streaming - check the FAQ for instructions.

However, some members aren't massively enamoured with the frame rate of YouTube videos, so another option is to simply upload a bigger AVI to the wiki for download.

Or do both - stream a YouTube version, and have a link beneath to a higher quality AVI version, as Rich has done with Blurp.

Sam.

I've been checking the Wiki page regularly and obviously I'm pleased to see that everything's moving along again!

Do you think you'll be able to have a WIP demo up-and-running by the second week of September?

If so, even if you can't make it to Huddersfield yourself (which would be a shame), would we be able to demo it at the Acorn World/Retro Reunited show?

Crikey! Over a month since I was last here. Looks like I've got some catching up to do.

Some (limited) progress is being made on the game again after the extended period of inactivity. No excuses, just a severe lack of time and motivation.

If it's any consolation, there's no way this thing would have been in a demonstrable state for RR/AW.

The problem, as always, is the lack of memory. There are now less than 100 free bytes left to play with, and adding new code inevitably means having to find something else to squeeze down. This has slowed progress to a crawl which is really frustrating. I seem to be spending all my time doing data compression rather than writing the game mechanics.

So, to kickstart my butt into gear I decided to forget about the code for a while and work on some more creative graphical/musical things. With that done, what do I find? The music data is too large and needs to be compressed! Arrgghh!

Still, I've got my 'mojo' back and at least have some enthusiasm for the game again. Here's hoping I'll be able to keep it up and do more regular updates in future.

Hi Paul,

I can relate to the long periods without momentum, I'm sure all us old school coders are nodding with that knowing look

I'm at that stage where I'm thinking of my next project and can already see major memory issues, for me, as I'm converting DOWN from a PC game to the beeb, I'm going for multi-phase development. This is basically get the core playable game together - and then add the flowery 'bits' one at a time - priorty coding. This I learnt when converting Amiga games down to the Speccy.... the phrase 'that's got to go!' was heard a lot

I'm just starting a nose around the forum so had a sneaky peek at your Wiki page and like the fact you also are keeping a diary of the development! Would love to see the video - or a WIP SSD of the main character moving around the screen.
Being slighty nerdy I'd love to see your cross compiler as well, and would be great to hear how you compress the sprites ( byte run? ).

How you are going to handling the low memory issue? It's always nice to share experiences and I'll be sure to let you know how I jump these hurdles.

Finally I just wanted to say, the game screen shots are looking great, looking forward to the next installment,

Neil

Hi Neil,


It is frustrating though, only getting half an hour or so every now and then to work on the game. It's taking months to write something that could have been knocked out in a few weeks. Oh well, just have to keep chipping away at it I guess.


The problem with my game is that it was written for a 64K machine and the graphics in particular use up a lot of memory. But it's such a simple game there's very little that can be thrown away!


The video never happened because there wasn't enough memory to hold the screen map and sprites at the same time. I'm probably going to forget about doing a video and just create a small playable demo instead when everything is squeezed in.


I was thinking of releasing the game's source code when it's finished. That would also mean having to bundle the assembler along with it to be able to build the game from source. While I don't have any plans to officially release or support the assembler in any way, I could knock up some documentation and let anyone who's interested have a play with it.


I decided to leave the sprites uncompressed since I need as much speed as possible for the game to run smoothly on the Electron. The only 'compression' as such is eliminating sprites that are mirror images of each other and flipping them on the fly.

The tile graphics are heavily compressed, first by encoding them as 1 or 2 bit images rather than the usual 4 bit for mode 2, then by doing RLE to compress byte runs and a variant of LZ to compress repeated blocks. It was a bit of a balancing act between the effectiveness of the compression and the speed of unpacking to the screen.


The memory limitations have been overcome in several ways:

1. shrinking the screen to the size of the play area freed up around 8K!
2. compressing the data, in particular the graphics and music.
3. using as much of the memory below &E00 as possible.
4. building in some breathing room - for example I've got the screen maps aligned to 64 byte boundaries but they only use 52 bytes. This could be used to reclaim around 600 bytes if (or should that be when) things get really tight.


Thanks for the encouragement I really should get around to doing some more up-to-date screen shots... so little time!

Well, it's glad to see you are still 'at it'!

I'm still trying to .. firstly fix a few issues in Invaders, plan my next big game, write up another cheap and cheerful game while I ponder the issues of the bigger project. It's a nightmare, but FUN! LOL
With regards your gfx compression, removing repeated blocks - is that checking on stored lines? The only reason I ask is have written run-length where there was offset table for each line, stripping out the repeated lines. I'm so nosey! I've just in the process of writting Huffman compression for a PC game I'm developing (Just as a filler while I think about how I'm going to code the functionality I need) and I keep thinking - should I write a huffman decoder for the beeb... JUST to say I have! I'll keep it straight 8bit compression, unlike the PC - that ranges from 2bit to 32bit I'll stop as I feel my own eyes glaze over ..!

Paul - no pressure here, but when you get the source together, would love to see your complier in motion. Also the game!

I've started to look into the use of the shadow ram for the video, keeping my new game in mode2... I've got this fitted on my BBC B(+) and also my Master. I suppose I might be limiting my market for the game, but it has it's advantages. Also would be good to do a pole to see how many people have shadow ram fitted on their beebs!

Right, better stop rambling and think about going home,
Cheers - Neil

I reckon a better option is to insist on 16k of sideways RAM, rather than a shadow RAM bank, as this way you can include expanded BBC Bs too! That should give you more than enough space for your code and data, and also means you don't have to worry about paging shadow RAM in and out (which also removes the limit of having to put all your screen access code below address $3000).

The game Doctor Who and the Mines of Terror went a step further and actually came with a paged ROM which you had to fit, to achieve more or less the same purpose!

It was originally, but I took that out because it wasn't saving enough memory to justify being in there. All the compression is now local to a character row 'strip' of the tile. It uses slightly more memory but keeps the decompression speed up.


Okay, I'll add it to the ever-expanding to do list


Hmm, this is something I was looking in to as well, but decided against it in the end.

Although I haven't announced it, I'm writing an island editor for the game. And because the editor needs access to the filesystem and a full mode 2 screen, there's even less free memory to play with.

I'm inclined to agree with Rich here. Very few model B owners will have that kind of expansion, whereas sideways RAM is much more common. For my editor, I decided to write the code in such a way that it can be run either as a ROM, or from main memory which then copies the graphics into sideways RAM.

Added some more recent screenshots to the wiki.

clickety click

This is looking absolutely fantastic, and very exciting. And it's lovely you're taking the time and trouble to do an Acorn Electron version too.

I can't wait to play it!

Cor, it looks as if it's REALLY taking shape now - thanks for the update!

Glad to hear that you've managed to squeeze everything in (and you say there'll be room for high scores + extra baddies as well? Wow!) ... its particularly heartening to see a Leccy screenshot too (which looks fab!).

Keep going Paul!!

Ditto to previous comments, nice work.

Thanks for the encouragement, guys. The Electron version certainly seems to be generating a bit of excitement!

I must admit, I did walk into that (doing an elk port) with my eyes shut. Having never owned or even seen one before, I wasn't aware just how different they are to work with.

When I first started on the elk code, I was worried that it wouldn't be possible to fit everything in or get it running at an acceptable speed. Still, after hours of optimising the graphics, cutting a few corners and the odd bit of trickery, the end result is a game that plays almost as smoothly as the beeb version. I'm really pleased with how it's turning out.

Have you made a tune for Electron version yet?
Out of interest I had a quick go at one today (Just to see how it would come out) and got the first verse (if I can call it that) done.

See what you think.
(Hmm, the board won't allow .ssd extensions so...)
http://www.thedeathzone.free-online.co.uk/oddfiles/tunes.ssd

The file to load is the "TREDEMO" file (the others are just works in progress up to that point)

Incidently, there is also a Commodore 64 version which uses the keyboard for control
Keys Q,A,I,O,N (up, down, left, right, fire)
The ZX Spectrum version seems a bit faster and with no music.

FAQ 1.6 - Zip it.

Sam.

Hmm, hadn't noticed that. Should have.
Anyway, I've uploaded it to my webspace (s'only 5k) and editied my post.
Cheers!

I did the tune for both versions a while back. It's all the same data and player routine with a small amount of conditional code for each machine.

Your program makes a good attempt at recreating the two-channel tune. It's got a kind of bouncy, arcadey feel to it It actually sounds nicer than mine does and I think I've figured out why...

If you listen carefully to the original tune, you can hear that there are pauses in between many of the notes, they don't just all run into each other. This works nicely when the sound has a volume envelope applied to it, like on the beeb, but does sound a bit harsh on the elk.

I noticed, listening to your program, that you have all the notes running into one another without pauses. This seems to make the sound smoother and less jarring, even if its less faithful to the original tune.

All this brings up an interesting question about how to deal with the single channel sound limitation of the Electron.

I'd like to get other Elk owners opinions on this. Would you prefer a clean, if somewhat bland, single channel melody or the full dual channel tune with the characteristic 'warbling' effect?


I've played those versions too and found them a bit disappointing. The C64 version has a bug in the sprite collision detection which allows Jim to sneak past blocking pirates vertically (there's a video of it on YouTube). Since the whole point of the game is the strategic use of cutlasses to kill these pirates, the bug makes makes the game pretty much irrelevant

The speccy version is just nasty! Bad, bad, conversion.

For once, the humble Plus/4 got the better deal with this game. Everything that was wrong with the original C64 game was fixed for the Plus/4 and it played so much better. That's why I'm basing my conversion on the Plus/4 game. Well, that and the fact I'm a bit of a Plus/4 fanboi

Thanks for your interest in the game BTW!