White Light/DevelopmentDiary

22nd March 2017
Started populating some of the levels with enemies. The game seemed to go incredibly slowly, so I started looking at optimisations. Some sleuthing determined that a huge chunk of CPU time was taken up drawing the score! The text plotting routine was written for size rather than speed, so inadvertently took something like 40% of CPU time. This was quickly resolved! Drawing one digit per frame rather than everything at once made a massive impact on speed.

I also made some optimisations to the sprite routines, which might have a slight negative visual impact when sprites overlap, but this shouldn't be the case too often. The extra performance is worth the slight visual trade-off in my mind.

21st March 2017
Over the last couple of days I finished off the sound effects, fixed a few bugs and made some tweaks. To be honest updates like this aren't hugely interesting; the late stages of a game tend to be a bit like this I'm afraid!

Probably the only change of interest is that enemy sprites + strength are now part of the level data. This allows for weaker enemies earlier in the game.

16th March 2017
Following a lot of trimming and fiddling around with the code, we now have both music and sound effects simultaneously. Priority system is very basic - sound effects take priority over music, and prevent any notes being played on the affected voice. Seems to work okay!

14th March 2017
Been doing a fair bit of bug fixing in the last week, including actually running the game on a real Beeb for the first time in ages. Found a nasty bug in the CRTC setup code... now fixed thankfully!

I've also been looking at rebalancing the difficulty of the game. I've played with the weapons a bit; I couldn't really make three distinct weapons, plus I wanted a bit of memory back, so there are now two weapons - 'spread' and 'pulse' - with 4 different fire levels. I've also tweaked enemy health a bit, trying to find a balance between 'incredibly easy, especially with weapons maxed out' and 'impossible'!

7th March 2017
Spent the last few days squishing, hacking, and generally butchering the music driver until it fits in the actual game. It's not without casualties though - the sound effects code had to be removed, and there's only 1 byte left so it's unlikely to fit back in, though I will try! I suspect I will have to provide a choice between music and sound effects; less than ideal, but that's the reality of 32k. If only Acorn had put 48k in the machine...

28th February 2017
Added the all important joystick support. Also played around with the memory map a bit - WL is using surprisingly little of zero page, so I moved some arrays down there which freed up a bit of memory.

27th February 2017
Some further playing with the music player. Mainly confirmed that I am sadly not a composer. Oh well. I'll muddle something together for the final game.

Added music to the intermission and high score screens. This at least confirms that drawing a starfield doesn't screw up the music player! I doubt that adding it to the actual game will be as painless.

15th November 2016
High score entry screen now completed. High scores are saved to disc - one of the perks of being disc only!

14th November 2016
Added an 'intermission' screen to help glue the game together, acting as the loader for the next level and giving the player a quick summary of progress. Also made a start on a high score screen, using most of the same code. Both of these run as regular (if shrunken) MODE 2 screens without any raster effects, so I can run the music player flat-out with all effects, with no concerns for CPU time or IRQ latency.

26th October 2016
Added drums. They're not very good, but they're better than the normal BBC 'noise only' variety, and they're definitely better than the ones in Demo 128.

25th October 2016
Added low frequency bass, plus a 'special effect' which will only be heard on the high score music due to CPU time requirements...

24th October 2016
More music work. There's a proper pitch enveloping system now, supporting vibrato and arpeggios, and the basic sequencer is there.

23rd October 2016
Started writing a music player. Firetrack had music in 32k, so White Light needs it as well! Might be tough, with only about 300 bytes remaining...

2nd October 2016
I'm useless at updating this diary...

In any case though, hit an important milestone today. It is now possible to finish a level! This sounds minor but in theory now this allows for levels to be played in sequence instead of just loading them from a menu, meaning the entire game could now be assembled. Or at least it will be possible once I've finished the loader. But all the code in the main game binary is now there to support this.

I also did some bug fixing - fixed the issue where sometimes the level didn't 'scroll on' properly at the start of a game, and the bug where enemies you crashed into never actually disappeared. Freed a smidge of memory in the process!

16th July 2016
Finally got John's levels crammed into the game. In addition to the RLE compression previously used for level data, I've added an LZ77-type scheme (where data earlier in the compressed stream can be referred to later via an offset/size pair) which saves a few hundred bytes. As well as that I've limited the number of tiles available to 56 (saving another 512 bytes), limited the number of sprites to 16, and packed the enemy wave definitions in with some of the tiles. I did also have to remove the sound engine. However, the levels now fit and are playable, and look great!



10th July 2016
Got the first level from John (after fixing some embarrassing bugs in the level editor!). Looks fantastic but as-is it's too big to fit in the game. Looks like I need to improve the level compression.

9th July 2016
John Blythe (Dethmunk) has offered to do graphics! This is excellent news as I am an appalling artist.

28th June 2016
Used up most of the remaining memory on a basic sound effects engine. I did consider using the OS sound handler, but as that would involve allowing the OS IRQ handler to run I decided against it and wrote a basic engine of my own. It's pretty basic - has frequency + delta, volume + delta, channel number and sound length - but having even basic sound is quite an improvement! I just hope I can claw back enough memory for music at some point.

27th June 2016
Added more enemy types.

23rd June 2016
Optimised memory usage a bit - now a whole 536 bytes free! Bet that will last long...

16th June 2016
Added some more wave types. Ran out of memory (again!)

8th June 2016
Had a play with defining enemy waves, now that the editor supports it. I've confirmed that the current enemy limits (16 enemies on screen at once, ~512 bytes for wave definitions per level) provides for adequate levels of mayhem; I had been worried that I was going to do more re-work to free up memory / CPU time! I added a couple of static enemy types - a completely static box/crate thing for releasing powerups, and a gun turret. But I think more will be needed, at present the enemy waves feel a tad repetitive.

6th June 2016
Level editor now supports enemy positioning. Seems to work, though my UI design leaves something to be desired. I think if I try this sort of project again I will write the editor in something other than plain C.



2nd April 2016
Finished up demo for Wakefield. This involved :
 * Restoring the 'attract mode'
 * Adding a basic level selector - a bit tricky, as by the time it's invoked the game has trashed VDU workspace
 * Re-enabled player vulnerability, which has been disabled for a while
 * Sorting out an enemy roster - currently this is present in the game code rather than level data (as it isn't supported by the editor yet), so it's a fixed pattern for every level
 * Put together some kind of level end - the scrolling now stops at the end of the level, but as there's no boss type thing to destroy the game just goes on until the player is killed
 * Bug fixes!

1st April 2016
Implemented powerups. Powerups are generated when a group of enemies are destroyed, and will also be generated once certain ground structures are destroyed (once I implement them!). Currently four types of powerup - smartbomb (not yet implemented), 'spread', 'pulse' and 'multiple'. Random number generator isn't doing a very good job of randomly selecting them though...

28th March 2016
Started creating 'land' tileset, influenced a little by Xevious, and 'fleet' tileset, influenced by Star Force. My current plan is to alternate between space, land, and fleet/comspace levels, with about 5 sets in total (15 levels).

25th March 2016
Added a few more enemy behaviours. Also re-added the ability for enemies to shoot, which got broken at some point a while back.

23rd March 2016
Some experimentation with tilesets, nothing usable yet.

12th March 2016
Some playing around with palettes. Added palette selection to the editor, which does make life a bit easier.

8th March 2016
Added some more sprites, including the ship banking left/right sprites that DaveM kept asking for.

7th March 2016
Fixed up a couple of crashes caused by the last few changes to the game.

4th March 2016
Started modifying the game to handle the new output of the level editor. Discovered in the process quite how little memory is left! I suspect this is something that is going to be a running theme...

13th February 2016
Added a basic sprite editor to the level editor. Very primitive, and needs more work!

31st January 2016
Started altering the level editor to handle the new reality of 2bpp graphics.

Also created a 'classic' Firetrack tile set as an exercise.

24th January 2016
Been coming to terms with an issue I've been aware of for a while now - that there just isn't enough memory for 4 bits-per-pixel tiles and sprites. This limits the game to 32 tiles and a handful of sprites, which are not enough! With the existing limit it's not even possible to use a Firetrack tileset. In addition the routines for plotting 4 bpp sprites and restoring the background just aren't fast enough.

Instead I've reverted to how Firetrack does it - split the 4 bpp screen in half, using 2 bpp for sprites and 2 bpp for tiles.

This has some benefits - more graphics (as sprites and tiles are now effectively interleaved in memory), faster sprite plotting (as masking is no longer required - just replace the sprite half of screen data with the new sprite) and faster sprite erasure (just mask the affected screen data with 0xf0).

This does have the obvious disadvantage of reducing the available colours. Firetrack often uses the same colours for sprites and background, which make it look like a MODE 5 game. It should be possible to mitigate this using palette splitting though.

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 ), 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.