White Light
From Retrosoftware
White Light by Tom Walker
Licence
Software licence TBC
Introduction
White Light is an unofficial sequel to FireTrack, publisher Electric Dream's 1987 vertically scrolling shoot-'em-up classic by Orlando. FireTrack, later re-released by Superior Software, was loosely based on Tehkan's 1984 arcade game Star Force and has long been regarded as one of the most technically advanced games ever made for the BBC Micro.
Features
- Runs at 50 frames per second (scrolling at 25)
- Multi-loading - a new set of graphics and enemies for each level
- Weapons can be upgraded through four power-up levels (and will be increased from this!)
- Parallax scrolling
- Supports full use of BeebSID add-on for background music
Sample Screenshots
 White Light title screen Posted: Jun 19, 2009 |  The first enemies Posted: Jun 19, 2009 | |
 Maximum upgraded firepower Posted: Apr 25, 2009 |  The second level Posted: Apr 26, 2009 |
Sample Video
White Light AVI Video (190 KB zipped, expands to 2.0 MB) (19 June 2009) White Light AVI Video (261 KB zipped, expands to 3.2 MB) (28 April 2009)
Development Diary
20th August 2013
Implemented destructible tiles, so that you can shoot at bits of map. After some fun concurrency issues this now mostly works, though there is an odd issue where collisions aren't detected correctly on some rows.
17th August 2013
Added more enemy types, using the new enemy logic. I added a new 'spawn' type, to reduce the size of the enemy list data; this should also allow enemies to be grouped, to allow for extra points and powerups when destroying all in a group.
Enemies can now also fire back at the player, though there's no collision detection for this yet.
14th August 2013
Changed how enemy logic routines worked. WL used to have the typical state machine type code, but now uses a co-operative multi-threading-like system blatantly 'inspired' by SCi's UFO system (used on Silkworm, SWIV, etc; described in [1]), mainly because it sounded interesting. This should make it easier to develop complex enemy behaviour.
3rd July 2013
Changed how the main loop functions, particularly with regard to enemies.
So far, White Light has had a regular main loop, triggered by a flag set by the vsync interrupt handler. In order to have a decent number of enemies on screen, enemy plotting is 'strobed', so of the 12 available, 3 are updated per frame. This works, but is a bit inflexible - enemies with smaller sprites could execute quicker, and with more on screen, but with this scheme the numbers are fixed.
Now though, all non-enemy-plotting related functions run in the interrupt handler, on the 50Hz tick, with the regular main loop dedicated to enemy plotting. Enemy logic is run from the interrupt handler, which sets a flag for the main loop to begin drawing.
This is much more flexible, and the benefits can easily be seen in-game; now when only a couple of enemies are on screen they run at 50 fps, with the framerate dropping as more appear. This setup is more complex than normal - enemy sprite routines now have to be completely seperated from everything else (as otherwise the interrupt routine would cause variable corruption) and there were quite a few bugs to be fixed. Anyone who's ever tried multi-thread programming would recognise some of the issues I've had - not quite as bad, but not far off at times!
30th June 2013
Wrote a new level editor. The old one was, frankly, crap, and the new one is better; somewhat better laid out and more logical to use, and with a normal Windows GUI. It also includes a tile editor, which is handy!
29th June 2013
Some internal reorganisation of code. White Light was not very well written, and was in need of desperate improvement! It's now better, though there's still far too much uncommented code and the use of zero page variables is extremely messy.
I also spend some time trying to do some game design. Part of the reason White Light stalled back in 2009 was that there was no real idea of what the game was to be - there was a vague idea that it should be a sort of unofficial sequel to Fire Track (hence the name, derived from the subtitle 'Search for the White Light'), but this lead to no real ideas other than 'throw in everything you can think of'. I therefore spent some time with Fire Track, attempting to come up with some solid design :
- I don't think White Light will follow Fire Track's ending; "Pulled into the spiraling vortex, you re-emerge in strange alien surrounding" sounds pretty vague and would lead to the open ended design that WL's already suffered from.
- This does present the question of what the 'White Light' actually is. Maybe it's stated somewhere, I haven't personally seen an answer.
- Ending each level by destroying power generators works for me, but the implementation is a little dull in FT - a fixed background with the regular enemies over it. I think WL can keep the idea but make it feel a bit more boss-like.
- I think some of the levels could be on land, destroying planet-based generators. Not sure if this entirely fits with FT's 'story', but WL is only a spiritual sequel rather than an actual one, so I think I can get away with it.
- Enemies feel slightly odd in FT; they're not connected to the level at all, simply being a few basic patterns repeated over and over, feeling more like they belong in something like Zalaga rather than a scrolling shooter. WL will implement them properly!
27th June 2013
Background plotting is now working, and is looking to be worthwhile.
It is a bit slower, but this can be partly mitigated by aligning enemy sprites. Of the four possible alignments vs a tile, only one requires an additional horizontal tile to be plotted. For enemies that only move vertically, it's trivial to position them to avoid this and hence save 1/3 of erasure cost.
While I was looking at the sprite routines, I also decided to implement proper masking. To date, sprites have only been masked on a whole-byte basis, with the inner loop looking like :
lda (src),y beq + sta (dst),y *
This is obviously quite quick, but looks pretty ugly! I decided to take the speed hit to mask them properly, using a 256-entry mask table to avoid having to store separate masks. I reduced the sprites to 16 lines (from an odd 19) to compensate - this also reduced how much background needs to be plotted.
26th June 2013
Picked up White Light again, let's see how long I stick with it this time.
Altered how background is saved & restored when plotting sprites.
Up until now White Light has stored the background before plotting sprites and restored it afterwards. This is normally a reasonable technique, but as WL is extremely short of memory (less than 16k available!), I decided this was unworkable.
Instead WL now just replots the background on top of the sprite when erasing. This required the game to keep track of what tiles are actually on screen, but requires only a 256 byte buffer - much better than the several K that the background store required! This is potentially slower, as in order for this to work the tiles plotted have to be correctly aligned and this may involve more plotting more than is strictly necessary.
It's not quite working 100% yet, so I don't yet know if it will be good enough to stay.
23 June 2009
Re-ordered drawing routines - stars no longer disappear when things get busy, but slightly more flicker on enemies. Added a new, more 'sweeping' fire mode.
20 June 2009
Increased the number of enemies on screen from 4 - initially I wanted 16 but settled on 12 as 16 flickered too much. Fixed most cases of enemies corrupting the background. Also we now have a working score!
19 June 2009
Fixed up collision detection. Enemies now have a 'health' of more than one shot - I added the ability to flash enemies white so this can be seen. Shots no longer pass through enemies.
16 June 2009
Added enemy collision detection - you can now shoot enemies, and they explode! Few bugs though. Also decided to keep a proper diary!
May 2009
Added proper enemy routines - enemies turn up at pre-defined points in the level (like most shooters, but unlike Firetrack) using pre-defined movement patterns. The menu system was rewritten, it's now possible to back out of the game back to the menu. Also basic music support was added - a music player can be called in the game, in the menu, and during loading. This version was demonstrated at the RCM open day at the end of May, with a SID tune.
April 2009
Quite a bit of progress - the game levels were seperated from the main code (so they can be loaded in independantly), and the player gained the ability to shoot. A second level was added (mainly to show the possibility of multiple levels) - it's almost entirely empty. The main first level was also designed around this time, using a new Windows-based level editor.
March 2009
After mentioning the existance of the game at Byte Back, I decided to revive it. I added (slightly) proper graphics, and a few other effects such as parallax scrolling stars.
November 2008
Work started, under the pretence of being a different type of game altogether. A basic scrolling demo gained player control, and some basic enemy routines. I intended to show this (privately) at the Retro Computer Museum open day, but for various reasons this never happened. The game was then shelved for a few months.