Saturday, 7 October 2017

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

Thursday, 5 October 2017

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.

Saturday, 19 August 2017

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

Friday, 18 August 2017

Cruiser X-79 Update #9

13th - 18th August 2017

Not much happened on the game programming front, but at least I made an effort to do something for the production. While I was away from this project for a few weeks or so, I recently received some new graphics for the game. It wasn't more levels, but graphics for a new front end. Saul Cross designed a great new logo for the title screen. So what happened this week? I programmed a front end and bolted it to the game, itself. Hope you like the result.

While I am waiting for the new level maps, I will be working on the order of alien attack patterns according to levels, and of course re-use the test level's map and setup different colour schemes for each level. Each alien attack pattern consists of 26 bytes, so hopefully I should have enough memory to store compressed levels of each map, then extract each level to address $4800-$5800 (since $5800 is the start address of the game's code). Each level should not exceed 320 4x4 blocks in height, as at the end of the 320th block row a level complete is automatically detected. :)

For now, here's the result of the title screen - although it is not official at the moment :) Enjoy the video.





Saturday, 24 June 2017

Cruiser X-79 - Update #8

20th-24th June 2017

It has been too hot this week, apart from yesterday and today. Despite the really hot UK weather I had recently, still that hasn't stopped  me from doing more on this game project. Quite a big update as well.

So then what has been happening this time round. For a start off I continued from a couple of weeks ago. This was where code was based on sprite / background collision. I originally worked on a subroutine where the player crashed should it hit a deadly character. Now this time I focused on the player bullet shooting to deadly background. I tried doing the bullet/background table read method, but that didn't quite work out. There were times where the player bullet kept on missing the deadly background and the bullet just flew over. A bit of additional hard work was required to this. I created a large listing to compare to a certain character to the bullet object position. If the central bullet reaches the deadly background, the bullet will disappear. Thus allowing the player to fire again. After testing this phase, things looked much better.

The next step was to do a little something different. I worked on the new title music for the game, using GoatTracker. I was unable to combine the title music with the other sounds, as there was a memory overlap. So I trimmed out the title music and placed it into a separate position and put it in the temporary preview title screen. I also programmed built in option where using a joystick in port 2 selects the sound mode (Music + SFX, Music Only, SFX Only, Silence).

Today I have been working on fixing some of the bugs in the game, and also adding some additional sprites. The sprites which represented Game Over and Stage Complete. In the stage complete phase, the player ship is automatically central before the Level Complete message appears on screen. During the player moving or the game over scene, all sprites get switched off, then after fitting the Game Over, Well Done screen, only 2 sprites are switched on.

The main game had some problems with the alien formation test. There were aliens that appeared incorrectly on screen while moving. I had forgotten to update offset code to reset the formation counter, so that aliens started in the correct position. After trying the game out, things looked very promising indeed. That was until, I came across the camel head aliens. They were flickering everywhere instead of using a proper formation. I managed to fix this problem by updating the low+hi byte tables for alien formation and properties. I tested the whole thing again and things looked a whole lot better.

As my final task today. I took a look at IRQ source code and tried to implement some subroutines. Reason being - The aliens and laser sprites were still visible over the black raster, that covers the scrolling background. In order to fix this problem, I altered the background colour to black (So no grey raster line could be seen). Then after that, a new subroutine was added to mask existing sprites as blank sprites. The trick worked, and the result was pretty good - although there is a minor glitch inside the score panel raster. It flickers for a split millisecond, but all in all, the game is playable.

Still no selected alien formation for each level yet, but that will be happening some time soon. Enjoy the latest video of what has been resulted this week.


Sunday, 11 June 2017

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.

Saturday, 3 June 2017

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.

 



Friday, 26 May 2017

Cruiser X-79 Update #5

14th May - 26th May 2017

Lots of things have been going on over the past couple of weeks or so. I have such little time to put a lot of info about what has been happening into this blog. Also I don't have a video this time round. Anyway, here's what has been happening behind the scenes this time round:

First of I wanted to make some slight improvements to the background graphics, although some glitches still existed inside the background graphics. This was because I was only doing rough ideas, not actually implementing the proper games graphics. I will be looking for a C64 buddy to do this.

As well as this, I have been putting in pointers in which should call the low/hi-byte values of the alien formation tables. This also involved manually creating, drawing and testing enemy sprites for each formation. The idea is to later on, on each level call different alien formation to the game. A couple weeks before I created the patterns for the alien formation. After testing all of the formation today. I was happy with most aliens, but there were a couple of formation patterns that might need to be altered in the future. One pattern was very buggy.

Finally the player now has fully working power ups. Every time it picks up a rocket tile, a power up gets rewarded to the player. The player cannot fire a new power up / default bullet until after the last bullet has moved offset.

So far I am very pleased with the result. It looks as if the main game framework could be finished soon. Just some debugging to the interrupts, bullet firing and of course replacing tacky alien formation movement with a better custom formation. Also of course there is the alien firing bug, which needs to be fixed, to avoid bullets firing where you cannot see the aliens.

The background snapshot below looks entirely messy, but I'm hoping that there will be someone available to help me work on the in game graphics and game sprites.


Saturday, 29 April 2017

Cruiser X-79 - Update #4



Saturday 29th April 2017

Here comes yet more progress made with this great Commodore 64 game project. The game is starting to work out much better. The player / enemy bullet collision finally got implemented. I did have a few issues with the sprite/charset collision subroutine, so it was time to take a look at that. There were some missing values, so those got fixed in. This took some time and I felt quite frustrated with the sprite/background collision subroutine. I decided to take a look at the source code of X-Force to see where I actually went wrong. Sometimes it is always good to have backups of older game projects, when in doubt :)

After fixing those. I decided to work on a few additional background tiles, also swapped colour attributes. This is so that on later levels, all 3 colours of the background ($d021, $d022, $d023) can be different. The additional tiles build are power up tiles. The tiles got exported into the source code. The tiles made were a shield for player's invincibility – for a temporary moment of time, rocket tile – for increasing the player's laser speed and a bomb – for a press space bar smart bomb feature (not implemented into the source yet). I tried reading the player ship to background collision, it read fine for the shield and laser. Strangely enough however when I tried to call the collision test to the bomb tiles, the code seemed to have read the wrong part of the background, which caused a wrong area disappear. This will be looked at some time next week.

You may also remember last week I added a player death subroutine. There wasn't a lives indicator. So that got implemented today. The yellow diamond characters represent the number of lives (including zero) which the player has. After the player explodes, the yellow diamond becomes red. The player has 4 lives at the start of the game, and will eventually be able to get extra lives later on in the game – Not implemented yet. A Game Over jingle was produced for the game.

I also implemented a STAGE CLEAR message at the end of the level. Before the message appears on screen, I made it so that the player moves up.

Anyway, time to backup this project and show you yet another video preview. Yet some more bugs in the code, but this is still a WIP anyhow :)


Saturday, 22 April 2017

Cruiser X-79 Update #3

22nd April 2017

It has been quite a while since I last blogged something in. This time I have no video to show you, but a few snapshots, to prove more work has been done on the project.

Anyway what has been happening this week. Well, today in fact. Some more game sprites were drawn, and another 2 alien formation tables were set up. Although no path movement tables have yet been set. This will happen occasionally. Some new space ships were created to make alien waves move downwards, and diagonal through a table. There's also another downwards formation, where circular robotic ships move in different speeds. They appear in more than just one go.

I also focused on scoring. A score subroutine was added and linked to the enemy death subroutines, so that the player scores points per alien shot.

Then came the sprite/background collision. I referred to the source in Trance Sector Ultimate, to try and get a 2x2 char sprite/background collision, and even implemented one on the 2x3 characters. I wanted to give this game a Uridium/Warhawk type of feeling, so made it possible that the player can destroy background objects to boost the score. The other sprite/background collision resembles to the player / wall collision.

After adding the collision subroutines, the player was missing something vitally important. A shield counter - to give the player chance to escape collision, when in re-spawn mode. Also an explosion animation to the player. So that every time the player hit an enemy, when the shields are out it explodes.

Now here's the latest WIP video of the work that has been done so far on this project.


Tune in next time for another project update :)

Saturday, 1 April 2017

Cruiser X-79 Update #2

1st April 2017

Okay, just a quick update in the blog. Well, today was quite a hard going session. More work has been done in the game project, and seems to be going quite well. I programmed some additional 1-way alien formation patterns. Although I do intend to create path formations in the near future. Also added are some newer enemies, and also a parallax effect in some parts of the space station. I won't say any more, check out this video below :)




Saturday, 25 March 2017

Zenox Attack is now Cruiser X-79

25th March 2017

It has been a very long time since the last time I was working on this space shoot 'em up. Probably due to the long term lack in motivation to code a new game. Also due to getting sidetracked with other tasks as well. Not, to mention the organizing of the SEUCK Compo 2016/17, and getting the prizes done quickly before my holiday ended last week.


Now finally I have returned to this game project. Also I have migrated this game project over to Arthur Jordison's CBMPRGStudio V3.10.0, a great C64 programming suite on the PC. Come BASIC or assembly. :). I have renamed the game project Cruiser X-79.

A lot of changes to the code and also music has been made, although I don't really have anything specifically new to show you at the moment. The same graphics, and also the same sprites are currently used. However the game features new music, which I think works quite well with this game project so far.

So then, what things have been going on this week. Well, for a start off, after the migration of the code and data into CBMPRGSTUDIO V3.10.0 (As I promised Arthur, I create something using his C64 development suite). I created some subroutines, which perform a check when is the best time to spawn aliens. Only a small simple test has been made to test the alien spawning. Basically, check to see if any aliens are offset in the game. If so, then wait until all aliens are out of the screen (or dead). Then set the timer to wait for new aliens to spawn.

Another subroutine created, linked to enemies, are based on enemy movement. I created some checks to see which direction the last alien movement should be, and also which part of the screen should the alien exit. Should an alien leave the screen going a certain direction, the subroutine automatically kills that particular alien.

The video below shows the latest ongoing progress of this game project, which will be released at The New Dimension games division on the downloads page - for absolutely nothing. The game design isn't all that exciting at the moment. No change to graphics or sprites at the moment, but eventually it will happen. Aliens only move straight formation, but I will do better ones in the future. Enjoy the video of the preview and expect to see more progress during the times ahead :)





Saturday, 28 January 2017

And the name of the game is ... Zenox Attack

27th - 28th January 2017

My week's holiday has come to an end, and things are back to normal once again. Most of the holiday was mainly composing music, and also starting on a C64 game project, formerly known as an unnamed shoot 'em up. Well,guess what? The game now has a name. I have decided to call it Zenox Attack.

Yesterday I made a start on the new in game graphics, which gives a sort of a Denarius feeling to it. If you look at the video carefully, you'll notice how much hard work I spent on creating the very first level.

On the alien sprites front. I designed some test alien sprites, which haven't been animated. Also I programmed in some in game sound effects, which could be used when mixed with in game music through my GoatTracker tunes. The player can play sounds when firing lasers. The aliens now have a box sprite/sprite collision detection. The enemy movement isn't very exciting, and the aliens cannot fire. This will be changed next time I work on this project, sometime next week (As well as Precinct 20 - Dead Strange, a SEUCK Redux creation by Alf Yngve). For now, enjoy this second WIP video with remnants of the game in action.



Wednesday, 25 January 2017

Scrolling without S.E.U.C.K

25th January 2016

 Flipping heck. This week has been a SEUCK marathon. Anyway, time for a little change. Back in 2015, I mentioned to some people in the past that I'd love to attempt to create a vertical scrolling shoot 'em up game, without the aid of SEUCK. I examined the code in Codebase64 and I managed to get a rough map scroller. However getting a soft scroll to work right was a plain in the backside. So I left the code for a couple of years or so backed up.

However last week, I attempted to continue achieve my goal. Basically by getting the soft scroll to work much better. There were a few mistakes left in the scrolling code last time. It turned out that I wasn't copying the last row, and pasting it inside a subroutine. Also the score panel at the bottom of the screen was flickering like hell. In order to solve the problem, I examined some code in an old TND Contributor's C64 game, to see how the status panel stayed static while a vertical scrolling map was scrolling down. I noticed something very interesting. A stack inside an interrupt, had a control over the VIC2 Screen vertical position, which made the status panel more still. I attempted to place a similar routine, and that trick worked. The VSP scroll worked a treat.

This week, I have been making some more alterations to the scroller framework, and started a little game project. At the moment it is an Unnamed Shoot Em Up, (which the video below will show you). However I'm feeling ambitious to make a sort of a onward scrolling Denarius/Warhawk style futuristic shoot 'em up, without the aid of SEUCK. I created some test sprites and a little test panel in order to get the player moving and blasting. The asteroids that move constantly cannot be shot, and will not be the only thing in the game. This is just the start of a fresh new C64 game project I am willing to produce this year :)