Cruiser-X 79: A touch of glass

I am back in action working on Cruiser-X 79. The next level is once again based in space. I wanted to make another ice-themed level for this game. I loaded up level 6's map in Charpad V2, and created a brand new map from it before adjusting the character sets to make a rough design.

Well, Level 14 is still ice themed, but this time round, it is based in space, rather than inside the original base. I wanted to make some glass windows for the base, so that it looks as if it is some kind of glass-ice base. Also I adjusted some of the background charsets to make the base look slightly different. Yet again some more deadly obstacles with an incentive have been added. This time the obstacles/full blockade is a further distance than the shield. It is up to the player to pick up the shield and try to fly over the blockade otherwise the player will die.

After completing my rough design of the game map and altered the character graphics. I went onto working some music. This time, I decided to do a spacey themed tune. It is still up-tempo, but quite moody. In some parts of the tune, there is one part which reminds me of the theme tune to the 1980s TV show, Street Hawk. But of course the music in the game is definitely not that.

After finishing the music I exported all of the charset, tiles and map data into the project source code, and then compiled and run a new D64 with level 14 added. I am very pleased with how the music turned out during play of the game build. As for the game graphics, it is just temporary until they have been given the magic touch by Saul.

There are only 2 more levels for me to design before I go back to the game code and make some minor improvements. The project is shaping up really well. I am confident that this game will be finished and released some time this year.

Cruiser-X 79 Update

1st May - 26th May 2016

While things have looked very quiet on this project. It doesn't mean that we are not continuing with the game project. In fact, the hardest part of the game code is practically out of the way. There are 16 alien formation tables set up so far, but there's still more to go. For the time being I have decided to leave the additional alien group property tables for the time being and focus on trying to get the main game engine repaired.

The aliens were unable to shoot at the time, and I tried to re-install the alien firing. However because I had deleted a lot of the old code (as I assumed it wasn't necessary) C64Studio processed loads of errors. I looked through the code, and tried to work a way round fixing the error result. Good news is that I managed to find the result. I re-created the enemy firing routine, selected the aliens to fire at random (via a pointer and value selector). If the alien was alive, the pointer and the bullet was out of the screen.

After fixing the alien firing I decided to fiddle about with the front end a little more. I added a flashing effect to the game's title screen. Also a page flip routine was added in order to flip between the front end credits and also the high score table. The result turned out pretty good.

Next the main game. The aliens were originally spawning in sequence. However, I didn't want the alien groups to spawn in order of the values 1 -17, so I setup the level pointers and some custom sequence tables to get the aliens spawning in a chosen value for that particular level. The video below shows you how the feature results during game play.

Update 11/09/2020: I just want to let you know that this game has NOT been cancelled. At the moment, I am stuck in a loop where on the coding side, I cannot really continue until the new set of level graphics come in. This project is therefore currently frozen until further notice.

Cruising for a Bruising

20th January 2019 

Well, 2018 sure has been a bit of a roller coaster of a ride, where C64 productivity and time was concerned. I mainly have been busy on SEUCK projects, but finally I have got time to do what I want. I will be on an Assemble It tutorial game project later on this week, but today I decided to concentrate a bit more on Cruiser-X 79. 

So then, what has been done today?. Before launching the playable preview, I have been doing a little more design to the test game map, which Saul originally did. This was mainly because the map looked pretty much plain space after about a quarter of the game map was drawn. So I decided to add some more tiles into the game's map and I tried to make it look as cool as I could. As soon as I finished with the map, it was time for me to export it to the game project.

Next was to load up the CBM PRG Studio and tweak some of the game code. There were some bugs inside the game, where sprites could be visible in the black lines between the game screen and the score panel. I simply fixed this issue by moving a subroutine which masked blank sprites into that particular screen area. After re-compiling the game, I could see my trick was working.

The next trick to was deal with the main game engine. I found that while playing this game, the player ship was just moving way too fast. The player was able to crash into the aliens or the deadly background too quickly. So I reduced the X, and Y speed of the player, so that it was moving at the slowest X speed and the Y speed is near enough to the correct X speed of the player.

Following that, I wanted to tweak the power ups slightly. There are 3 different tiles, marked B, M and S. The B tile is the smart bomb, M is the missile upgrade, and S is the shield. I wanted to make some alterations to the smart bomb and the missile. I started with the missile. The player's missile did work, but shouldn't the player have to pay the penalty for a cost of a life?. I altered the life lost code, so that then the player's missile was set to default - every time the player dies and fires the next bullet when spawned again.

The Smart Bomb feature was the next for me to enhance. Last time (originally) the smart bomb had a bug in the code, in which while a batch of aliens were being destroyed. Half a batch visible may have destroyed, but other alien sprites of the same group appeared. This just didn't look good for me. So I decided to do something about it. I added a trick which was to explode all of the aliens in one go. This was done simply by setting the code to enable all aliens, and make them dead straight away.

While still working on the Smart Bomb feature. I felt that the smart bomb code should be changed. So I altered the feature by adding some flashing background, to indicate the explosion. Also the feature was better off not being automatic, but manual. So I added a new subroutine and pointer where the player checks for the bomb carried. If carried, the Space Bar key activates the smart bomb feature, which destroys all or spawning aliens and awards the player 500 points.

The player has a penalty feature. If the smart bomb is carried, and the player loses a life, it loses the smart bomb power up, as well as the bullet power up.

I was going to launch a playable preview of this game on to the TND web site today, but I have decided to postpone it, due to a weird collision bug that is in place in the main game's code. The sprite/sprite collision code needs to be re-written from scratch, and some of the code needs to be inside macros. Once this has been dealt with, a playable demo of the game will be launched on to TND. Watch this space.

Cruiser X-79 Update #12

7th October 2017

This is a just a quick update. You may remember a couple of days ago, I mentioned about having trouble getting the tape loader to work using multi-load, and  the game crashed. I finally managed to get my way around this problem, simply by not triggering RTS after the loader had finished loading a file. Of course, I had to edit the game code, where RTS was originally called for setting up new levels. This was replaced with a jump start to the main game code. I also implemented the same code with the disk multi loader.

The tape turbo code also needed a slight altering, so that it could switch off the tape motor, call Exomizer to level-decrunch the program file loaded, then call a subroutine to check whether or not all files have loaded. If so, then jump to the main game code, otherwise keep on loading the level graphics data (Charset, tile set, map) until all 3 files have loaded in and run through Exomizer's decruncher. Thankfully, it all worked.

Now Cruiser X-79 can have digital disk and tape versions. :)

Cruiser X-79 [UPDATE 11] - Not much ... Or is it?

5th October 2017

I really should have back dated this Friday+Saturday last week, as nothing had been done today. I've been running late. Anyway, last week, I was doing some brain storming, and slight of hand updating of the game code.

Originally Cruiser X-79 used a 3xIRQ interrupt, but since that was just UNECESSARY, I decided to reduce it to a 2xinterrupt instead. Reason being fixing the smooth scrolling, so that it could scroll smoothly.

Other implementations which had taken place last week was related to access to levels. The size of the game map 320 blocks in height. That is way too much for one file - even compressed. Now imaging having to pack 16 levels and try to cram that into a single file? Not really possible, due to the memory restrictions.

In order to solve this problem, I decided to implement a disk load subroutine, along with the Exomizer level decruncher. Each file to decrunch has to be a game character set, tile set and also a map. To make the level packing more simpler, I decided to create a project in Endurion's excellent C64Studio suite, and call Exomizer to compress each level file, and then import the files on to a .D64.Then I set up the file names, low + hi-byte of the END address of the program for Exomizer to decrunch. At first I had crashes, probably due to some silly mistakes I made into the code. After several attempts the code worked, and a working game / preview was in place. Brilliant.

This may sound as if the game is turning out to be disk only? Well, not necessary. I had a bash at making a 2-sided tape version of the game with TapeToolBuildV2, and my modified  version of Martin's source. Where after loading the game with picture and music. The front end comes on, then a message on screen should prompt the user to flip tape to side 2 and rewind (Or in .tap form, simply eject side 1 or the tap file, and then start side 2  - Since I use 1541Ultimate more than a tape - in order to reduce loading programs and finding load errors :D ).

Although this felt like a great idea. I had to disect Martin Piper's turbo loader system, through his source. So I created a second source, which made two loads for each file. Basically, the idea is to load a test pilot $0200-$0240, then load in the selected charset/tile/map file. After each file has loaded, the loader should point the end low/byte address to the decrunch address. Then call the loader again, another two times, then after the last decrunch. Run the game. Sadly this didn't work for me. The turbo did load the data to the correct end address, and the low/hi byte of the end address, did get stored to the correct self-mod decrunch from address of Exomizer. However, instead of actually running the decruncher, after loading (Where I added an RTS at the end of the loader (The loader is mean't to be a subroutine), the program crashed completely with a CPU JAM. I will need to investigate further into this issue. The test disk version loads fine. I'll let you know how I progress through making a .tap version of my game.

Cruiser X-79 - Update #10

19th August 2017

More action has been taking place today. First of all, Saul suggested that I should reduce the animation speed for the aliens and also the explosion. Basically double the delay of the animation. Also I had a go at setting up level pointers, where after each level advances, the game sets up the next level settings. For example, pick out the chosen alien type, formation, level colour scheme, etc. I tried compressing a test level map, using Exomizer, then imported it into the source code 16 times, to set each level. Sadly this trick didn't work and caused a memory overflow.

In order to solve this issue. I have decided to make this game multi-load based. This means that after 1 level is complete, the disk or tape image should load the next game file.There is just not enough memory for me to place even 8 level compressed versions of test maps that exceed $0300 bytes (Compressed). I will make sure disk loading will also be SDIEC compatible as well. Tape version is intended to be mastered using Freeload or the Thunderload Multi-Load companion tool.

You will notice a slight difference in the game during this test video of cheat mode below.  :)

Cruiser X-79 Update #7

11th June 2017

Not much time has been spent on this project this week, due to other things, but at least I did put some of my commitment into this game project today. I did have a long weekend, but I have been working on some stuff for the demo scene, also been learning a bit of Unity PC Game development . This won't stop me from continuing C64 game projects. Anyway what has been happening today.

Although it doesn't really sound like much. In fact a lot of work was put into the game code. A new sprite/background collision had to be made, which corresponded to the player's bullet. The idea is basically to allow the player to shoot certain background objects in order to destroy them and score a few more points.

I used a similar approach to the player/background collision, but this time assigned the player bullet's central area to the background object. Should the centre of the player's bullet hit the background object, it should destroy it. I added a few JSR statements to check which background the bullet sprite should read, and then generated a subroutine which transformed the 4 chars of the background into a destroyed object. The player can shoot and destroy shutters, parked ships, stripey buildings and also the glass domes.

This is called by assigning a row+column into a zeropage, check the char co-ords and the char value of the zero page, then modify the charset to an actual new value.

See you Saturday next week (Hopefully) with another blog update to this project, where I update the bullet sprite/background settings to remove the bullet every time it fires at a high deadly background, and maybe setup the first level attack waves.

Cruiser X-64 Update 6

2nd June 2017

Well things sure are turning out quite nicely. Although this week hasn't been a very nice week on a personal side. Still, the weekend arrived yesterday and I decided to plod on with my shoot 'em up project.

So what has happened recently? Well, I have found a C64 graphics designer to design and create the level background graphics and sprites. The speed of the graphics and sprites developed was really fast. The result was very impressive. Saul Cross has joined this game project. The game sprites were pretty awesome, and some of the game sprites were improved versions of some of my original sprites. The game background was very breath-taking. Much better than what I originally created. :) Absolutely stunning.

I implemented the new graphics into the game project, but I also had to re-write the sequence table for the game sprites. That didn't really cause any trouble. The animation for all of the aliens and explosion turned out how I expected. Excellent.

The next task was to re-write some of the sprite/background collision. I asked Saul if he could send me a snippet of which tiles should be shot and which tiles should represent the killer chars. He e-mailed me back the amended charpad file, which revealed the killer chars and shootable chars. These were marked with material values in charpad. Now that was much helpful. However, I had to add the markers for the collectable tiles, so that when the ship flies over that tile, it should get a power up or activate.

3rd June 2017

Today's session has been only a morning session. Yesterday I was fixing up the new sprite animation tables. Today was something else. Working on the sprite to background collision. There were a lot of killer chars indicated in the Char Pad material char. Writing a very long routine to compare the sprite to background collision could write up a lot of memory. So in order to fix this problem, I decided to cheat a bit. There are 32 chars that represent killer chars. To make the collision code shorter for the killer chars, I decided to put the 32 values into 8 tables, and call a loop which rolls each value at a very fast pace. This is so that every time a collision char is read and the player is anywhere on it, the player will explode. I called a continuous loop that cycles 8 tables, which consist of 4 bytes (32 bytes overall), and added a compare value of the player's X/Y hit co-ordinates to check for a collision. After the 4th byte has been read, the subroutine resets the killer character pointer and cycles through the process again. The IRQ control is very fast, and a collision to the player worked  out quite nicely.

The next task was to implement the new power up tiles to the sprite/background collision subroutine. At first I had problems where I tried to read the correct value characters to disappear and reward the player. Unfortunately that didn't quite work. Why was that? Simple, I extracted the incorrect background charset, tile and map data. So I corrected that one.

Over the next week or so, I will be restoring the player bullet to background collision. Should  the player shoot some of the background, it should get destroyed. Here's a snapshot of the game's new graphics. This really is looking nice. Time for me to backup the data and source code.