Joe Gunn - Spectrum Conversion.
29/03/2018.

A conversion of an excellent modern C64 game to the Spectrum.

There have been some very nice games for the C64 in the post-commercial era and Joe Gunn is one of my favourites.  It's one of several made by Georg "Endurion" Rottensteiner and appears to be a viable candidate for a conversion.  No scrolling to worry about, memory size OK, two-colour tiles, it's not dependent on colour or anything like that.  The main issue (as always) is making a good sprite routine to cope with the lack of hardware sprites.

So far......

29/03/2018.

I haven't worked on this for quite some time. Currently, it can display eight 16*21 sprites in about 2.25 frames (doing nothing but displaying sprites, restoring the background and a little game loop moving the sprites around). With this code, it might be enough to run the game at 16.7 fps, but that would be disappointing for a simple game with a static background. RAM would still be an issue, as it uses 4K of tables to do the real-time X-shifting.

The perfect scenario would be displaying those same sprites in about 1.75 frames (or less) and try to get the whole thing running at 25 fps (most of the time). This may prove to be impossible, although there are a few more things that could be tried (time permitting).

20/12/2013.

I have done some work on the sprites. With a little bit of clipping I have got the majority of the sprites down to 16*24 pixels. Some are unavoidably 24 wide, so they've been split into 2 sprites. I've also removed all the left-facing sprites (for those that face left or right) and will handle them using an X-flip table.

As a result, the sprite data now takes up 4,956 bytes and will fit into memory! Whether the sprite routine will fit into memory is another matter.

Many of the sprites are 17 pixels tall so, if I'm clever, I might be able to shrink the RAM footprint a bit more.

Joe's 16x24 sprite sheet

19/12/2013.

I now have a *very* short period of time to look at it again.

First step: Quantify the problems.

I have 8,931 bytes free (for the 48K).

Into that, I must fit the music (it'll be 128K-only music, so no problem there, just don't have any in 48K mode).

I'll need 257 bytes (if possible) for a stable IM 2 table.

I must fit the sprites and the sprite routine in.  This is awkward, as the whole set of sprites is currently taking up 11,376 bytes.  Additionally, a decent sprite routine will require 4K or more in buffers (I don't have the memory for preshifting).

A sprite routine without preshifting will be quite a bit slower.  The C64 game runs at 50hz, the sprite routine will take at least a frame and a half to do all the work I want (and that might be optimistic).

What I could do...

A lot of Joe's sprites are nearly small enough to fit into 16x16, so I could remove a few pixels here and there and make a saving.  I could add a table to flip some of Joe's sprites (but I would have to keep track of the X-positions, as they don't flip around the centre of the C64 sprites).

That's a fair amount of work, but I may need to do more than that.  The compressed levels (82 screens) are taking up 8,458 bytes.  I could figure out a better compression algorithm for them.  The (English) text is 3,311 bytes, that could be compressed for a smaller saving.  The original code was not optimised with regards to co-ord comparisons (etc), that could be done.  All in all, nothing quick.

(And if it's this hard for Joe Gunn, it'll be downright impossible for Guns 'n' Ghosts).

28/06/2013.

The first update...  At this point I have to declare that I first started communicating with Georg in October and started converting on the 10th of November 2012.  By early January I had converted it...  to the C128!  Why?  It was the ideal compromise machine, the C128 has both a 6502 variant and a Z80 (running at 2Mhz).  I could convert the original 6502 code into Z80 while still using the same hardware, thus making the process easier.

After that I started editing the levels so that they would fit into the Spectrum screen size (256 pixels wide) and produced a final C128 version with small levels (at least until I converted the SID routines into Z80 much later on).  This took a lot of work to try and get the game playing with a similar feel.  I then started converting the background graphics to the Spectrum and changed the char and tile routines so that they would output to the Spectrum screen.  After all the hard work before, this part was relatively easy and was done by mid-February.  I added some controls, made a fake sprite routine that used flashing attributes to show the rough position of the sprites and I had a playable version excluding sprite collision and proper sprites.

Now, all this was done with significant real-life time constraints, so I've had to stop several times and after some sprite experiments I had to stop again.  That is the current position, I can't start working on it again for now.

It's the Spectrum!

The level editor was hastily constructed on top of another older program.  Here you can see it showing, firstly, the 40-char wide map and, secondly, the 32-char wide map (both using the Spectrum graphics set).  The ability to see the adjacent screens and nearby enemy positions made it a lot easier to shrink the screens and keep things working.  It's also possible to drag the enemies (represented by the magenta tiles into new positions.

The level editor.

The C128 version with the 32-char wide screens is certainly a bizarre curiosity.  I don't know if anyone ever wrote a game in Z80 for it!

Shrunken C128 screens!

Problems

Sprites!  Sprites!  Sprites! 8 large hardware sprites is enormously difficult to do at a reasonable speed in software.  The best I can do at the moment is 5 (24*24) sprites in a full frame.  I'll need to shrink down the sprites and optimise everything to the nth degree.  Even then, I'll need to change the frame rate as there's no way I'll be able to get the sprite routine to do everything in half a frame.  Also, the original depends upon hardware sprite collision, so I'll need to replicate something for that too!

I'll also need to do something for the music and a loading screen.

Support

Thanks to Georg Rottensteiner for all the support in working on this.  He provided the original source code and tips along the way.

Bye,
James McKay

(Please remove the EGGROLL to reply).

(C) James McKay, 2013.