Having done some groundwork, I'm thinking about doing another Electron title next year, but I want to put the source code out there now in case someone else fancies doing something with it.

Inspired by Moon Raider and slightly regretful that Castle Quest never made it to the Electron, my plan for Castle Raider is to bring some kind of horizontal scrolling platform game to the Electron. As you might expect, this comes with a lot of compromises.

The attached screenshot shows the current state of the graphics and level design. The level is only 16 rows high, but the player's character is 3 rows high so there's probably plenty of space to play with if the level is designed cleverly. Since the levels are designed by humans this time - as opposed to an algorithm in Jungle Journey - there's a chance for other people to get involved with level design if they're prepared to accept certain constraints.

Is there a chance you could set up another source code repository for me, Sam?

Nice one, good luck with it!

Wasn't Castle Raider the original name for Castle Quest or did I dream that?

Thanks! I'll try to upload a video to YouTube later this week and put up work-in-progress tape and disk images. The video is of the code running on a real Electron so it shows that the scrolling technique works in practice and not just in an emulator, which I'm very pleased about.

According to this message on the stardot forums, Castle Raider was the original title for Castle Quest. Perhaps a rethink is in order...

It was indeed!

You can actually download a disk image of the "Raider" pre-release from the Lost & Found page on STH: http://www.stairwaytohell.com/lostandfound

However, I don't see why you should completely rename your project - if anything, I think it would be a welcome 'nod' to the origins of the game that inspired it.

Though maybe a slight name change e.g. the addition of a suffix, might be a wise idea ("Castle Raider 2000", perhaps?)

Btw, really enjoyed Jungle Journey (seems to be earning rave reviews across the board!) so I can't WAIT to see the WIP vids and images of Castle Raider ...

err .. email sent following a shocking delay in response time. I'm afraid I lost track of the forums recently, and only just noticed this. Feel free to ping me direct in future if you don't hear back from me in the forums. I can setup a new repo for you - have you settled on a name?

Sam.

Here ya go, David:

http://www.retrosoftware.co.uk/hg/castleraider

Thanks, I'll upload everything at the weekend and create a Wiki page then.

OK, I've pushed the code to the repository and, thanks to my brother, there's now a video of an early version of the game. I'll create a Wiki page soon.

Enjoy!

Wow, that's excellent! That's really running on an Electron?

Presumably that's a software scroll then, because an Electron doesn't do horizontal hardware scrolling very well, right? It's a really nice looking demo - look forward to seeing how it develops!

Having just looked at it again, I'm a little baffled even - it looks as if it's scrolling 2 pixels at a time, but also looks as if it's in Mode 5. So either I'm mistaken or you're doing something incredibly cunning there!

And it also runs incredibly well for an Electron... I was wondering if you were doing something clever like only having to update edges between different tiles when it scrolls, but the graphics look too complicated for that to be an option.

You gonna keep a development diary?

Not all that cunning.



Well, that is exactly what I do. Just to back up a couple of steps, I got the idea of updating the difference between tiles from Moon Raider which, as far as I can tell, does that for its landscape. That game scrolls impressively quickly for an Electron game, also in steps of 2 pixels, and all the landscape is a uniform colour so you don't notice. It occurred to me that it could have used a repeating pattern of 2 pixels (perhaps a 2x2 dithered pattern) but that would have ruined the illusion.

What I did was to use two screen banks, one with sprites offset by 2 pixels, and plot changes as each bank scrolls by two steps (= 4 pixels = 1 tile width), switching between banks to give the illusion of movement. What I found quite remarkable is that the Electron does this pretty much without flicker.



I think so. Although the arguably most interesting part has already been done, I should document what I did a bit better, and the diary format is probably one of the better ways to do that.

Wow, that is ingenious!!

I love these kind of tricks, and I have to say you've pulled it off with style. The demo looks brilliant, and the graphics and map look complicated enough that it'd be hard to guess how you were doing it. I'd noticed that all the graphics seemed to repeat every 4 pixels, but I didn't consider that with 2 screens you could actually scroll in steps of 2 pixels. Love it!!! The nice thing about the use of a back buffer is that you automatically eliminate flicker, for free!

How are you plotting the 2-pixel-offset graphics? Do you have the graphics stored twice, the second time offset by 2 pixels? There'd still be some masking to do there... unless you've once again got a cunning trick up your sleeve!

I start with the regular 4x8 tiles. The Python code to generate the map data creates a "rotated" version of each of these in which the 2 columns of pixels on the left hand side of the sprite are taken from the 2 columns at the right hand side of the original, and the 2 columns on the right hand side are taken from the left hand side of the original. Basically, a scrolled version of each sprite.

To handle the joins between spans of different tiles is easy in the first screen bank because each tile is plotted in a separate column of bytes - the usual MODE 5 screen layout. In bank 2, the data for adjacent tiles overlaps, as you mention.

I thought about plotting one type of tile then either masking a "rotated" tile and overplotting, or even storing tile edges separately and using OR operations to plot them (removing the need to mask), but this would still need any existing screen data to be erased first. What could be done is to combine the ends of two tiles and plot that instead. I might end up doing that, for reasons explained below.

For convenience (laziness), I instead look for combinations of adjacent tile types in the level data when I generate it and create a set of sprites that can be plotted directly. This is quite wasteful - with 8 tile types, there could potentially be 56 of these "merged" tiles, and the level format isn't able to address this many so care needs to be taken when designing a level. I don't really like this limitation, and it's possible that preparing and plotting a sprite for a join between two tiles isn't that expensive, so perhaps that might be something I'll try.

It's good to know that I've got you scratching your head, in any case.

Gotcha! I think it's a brilliant idea, and I'm glad you had enough faith in it to get this far.

I don't reckon there'd be particularly much overhead in 'building' merged tiles as required, as long as you stored two versions (i.e. 1234 becomes 0012 and 3400), which can be simply ORed and stored directly to the screen.

Looking forward to the next demo!