Sunday, 20 June 2021

Cruiser X-79 June Update #2

 20th June 2021

Since I have more or less run out of other C64 projects to work on, and pretty much up to date with everything. I decided to work a bit more on Cruiser-X 79. It has actually been a whole day's session. Yes, that's right, about 8 hours or so. I needed to get a lot of things done today and I had nothing else to do. Considering the weather has been rubbish today also.

The first part of today's session was working on the music and additional jingles. I loaded up Goat Tracker and I experimented a little with the music to come up with some suitable in game music. I ended up doing 3 different tunes. The initial  plan is for the game to have only 4 different in game tunes. All of the tunes turned out more upbeat, and the well done and game over jingles sound familiar to the level 1 jingle. 

The next part was slightly more painful. The easiest part was to setup the filename properties. The second part actually gave me a real headache to work on. The disk access multi-load system. I tried compressing the test level graphics, character set and map as well as the music for the game. Unfortunately, however the de-crunch routine was crashing all the time. 

I discovered that the music memory is at $1000, and I cannot unpack a music file at $1000 when it loads to that address with Exomizer. I also had issues with memory management. I had no spare memory to place packed data. So I decided to leave out the Exomizer level compression for the time-being and load the test files as unpacked data. The program worked, but loading time takes a bit longer. 

I might need to find some alternative to the mem -l packing in Exomizer. If there is a load and decrunch on the fly method, then I might consider using that method. Otherwise I might have to do the level packing the more slower way, using a Level Squeezer and unpack from the level unpacker code. We will have to wait and see.




 




Thursday, 10 June 2021

Cruiser-X 79 - June Update: 1

 10th June 2021

Over the past few months. I mainly worked on a few small game / demo / intro projects. There have been times where I have been doing more on my game project. I noticed that it has been a few months since I last did some more Cruiser-X 79. This was because I was literally unsure what to do next after the alien movement patterns. The main game engine is more or less finished (except for the bugs that are still left in the game). The only thing that is missing for the main game code are the level graphics. That is up to Saul :). 

Okay, so if I cannot code any more on the game, what shall I do now. I decided to work on the front end for the project. The title screen graphics are still there. So it wasn't much of a problem to import them into the game project. I also did a mock-hi score table. The front end is not 100% complete yet, but it does look quite nice (and erm - green, ha, ha.). The title screen also uses the same music as I used in the playable preview. Since the music was made for the title screen anyhow.



The title screen appears to look nice, but it does need some kind of action in the scene to make it look less boring. The game is supposed to be a space shoot 'em up so I might add some kind of star field like I did with Zzapped in the Butt DX. There are characters free for this cool effect.

Another thing I need to add, which I decided to do this hot and sticky afternoon is add a disk loader system to load the main game. This is only for testing purpose, as no level packing has been done yet. The game currently loads through the SFX de-crunch routine from Exomizer. Eventually changes will take place in this project because I will need to make alternative plans.


 

I took note of all of the memory which current data from the title screen and the game used. I need to do this in order to  allow the loader system to load the data to a range in memory in the game, where it cannot overwrite important data or code. Then the data can unpack from that area to the target memory at range. The game loader will need to be split into 4 different files. They are as follows:

- In game graphics charset
- In game graphics tile set
- In game graphics map
- In game music

Each of these files (once received) will be fed to the Exomizer using the mem -l  prefix. The Exomizer de-crunch source (which I used on Starfysh Remix) will be used to unpack each file respectively to the correct memory bank of where the original charset, tile set, map and music lies. 

More on this next time I get onto it :)



Friday, 16 April 2021

theC64 Challenge #6 - Para Lander DX - Part 3/3

 16th April 2021

This is the final chapter. So what happened then? Well, in part 2. I assumed the game was perhaps ready, but there had to be a couple of adjustments made to the game. Here is what happened:

Levels - now what happened?

I had a test of the game and it appeared that the level counter wasn't working. I had forgotten to increment the level pointer to read the next level. Thankfully it worked. There was also a suggestion that I removed the two digit counter from the screen. This level counter was indeed meant to be for testing that each level was working and should have been deleted after the levels were working. I removed the digit counter.

Unreadable character found

The letter "Q" in the text on the title screen / hi score looked too much like the letter "D". Rather than use theC64 and Multi-Screen Construction Kit just to fix up a character set. I decided to export the character set to my PC and re-import it into Charpad V2.7 then I re-imported the charset into the game code in 64tass as a raw file. The letter looked much better.

Flashing status looked a bit off

The Well Done and Game Over sprites looked off with the grey pixels around them, so I set the colour for each flash as just a single colour. Like with the Charset, I imported the sprites into Sprite Pad to do a fix up of the sprites. Although the "well done" and "game over" text were still displayed as multi colour sprites, they both looked much better and more readable.

The count down was unfair

Para Lander DX had scenes where the player was jumping for joy, but it appears to be unfair for the player. This is because the clock was still ticking down while the player was jumping for joy. The problem was solved by stopping the timer.

I wanted to be oldschool, but I felt had to use Exomizer

With the test build of "Para Lander DX" I had to put up with having to link, pack and crunch several times while using ECA Compactor V4S and Cruel Cruncher V2.5. The oldschool packing and crunching was a lengthy process. I decided at the end to just use Exomizer and disguise the de-cruncher as some of the old favourite crunchers from back in the 1980's. I went for disguising the Exomizer depacker as the Matcham Speed Packer V1.2 (pictured). Considering that I used Future Composer V4.1 to do the intro music (Or ripped it from my previous intro for Ray Fish) ;). I thought it should have an 1980's feel to it :)




Finally the game is finished and mastering is done. I will be releasing the game next week. For now, here is a video of the final production. This is the digital tape version:

The game is intended to be released next week on 23/04/2021 at The New Dimension or Para Lander DX page

Wednesday, 14 April 2021

Cruiser-X 79 - April Update #1

14th April 2021  

Previous update was deleted along with the Para Lander DX blog entry. This entry from 3rd April  is what has been remembered from that day.

3rd April 2021

Last time I was dealing with alien patterns. The next task was to put these into levels. I also was setting up the colour settings for each level table. Of course, last time all aliens were put into order of sequence and were being tested.

That week (for this part in the development) I mainly focused on the level alien attack patterns. Instead of all aliens being in sequence 0-40. I setup alien selection tables for each level. The idea was to ensure that each table has a specific level of difficulty. There are 40 different alien tables (some of which are duplicated enemies doing different things). The idea is that the harder faster enemies get used after a few levels. There are 16 levels in total.

Now that all the alien patterns are in place for each level. There is not really much I can do to the game right now. Although I will need to work on doing different tunes for each level of the game. 16 different tunes might be too many to compose, so maybe I do a few tunes and then create a table to load specific music files. Still, that will do for now :)


 



 

Tuesday, 13 April 2021

theC64 Challenege #6 Para Lander DX - Part 2/3

 1st April - 13th April 2021 (Continued)

Last time in my blog I mentioned about the Para Lander Mini, and also how I thought the game was finished. Things did not really go according to plan. In this next part, this is where I decided to stick to 64tass instead of using Turbo Macro Pro. 


 

Last time

I prepared, designed and developed an enhanced edition of Para Lander DX on theC64 with aid of an Action Replay cartridge plugin, some C64 applications, including Turbo Macro Pro. I worked my socks off on the game project and finally came out with a working game. However things did not turn out how I expected. Although I had a fully working title screen, hi-score table and game. There were some elements missing in the game. So here is what happened.

A new intro - Nice

Friday last week I ended up with a new picture for a TND intro by Hugues. I worked on programming it, added a Future Composer soundtrack, and the result turned out great. I then packed and crunched the game with the Sledge Hammer II and Cruel Cruncher V2.5+ to continue with the old-school theme. Then I wrote the game documentation. Unfortunately however the game was still not ready to release. So it was back to the game code once more.

Random situation

The game was working out quite well, but the main problem was the game play. The zeppelins were moving slow across the screen but the game was just too easy to play. I decided to create a random table of speed and I set random speed timers and pointers to the zeppelins. Unfortunately however I was unable to continue using Turbo Macro Pro as once again, the bottom area of the screen messed up and this time it crashed. This de-motivated me more from using Turbo Macro Pro for this game. I must have used all the memory perhaps?

As a drastic measure I decided to from now with the project use the 64tass on my PC. I created the random tables, generated them and compiled the game (and crunched it with Exomizer) and run the game in VICE. It was working quite nicely. After I completed the first round, Zeppelins randomly changed their speed. I came across another issue. The zeppelins were going past too fast. 

This resulted to only setting the speed of the zeppelin to the slowest speed, and play with the drag rates, between 0 and 3. After compiling and sharing the build with Hugues and another tester. They felt that the game would be better off using levels. So ...

Rank up

I felt there was something missing in the hi-score display. The title and game have music, but the hi-score display re-uses the title music. I felt that there should be at least one more tune for the game. For this, I decided to browse through the HVSC under my name, and I found a tune I feel that would have been great for the high score table. Feel Great. As a bonus this tune was also composed in DMC V4.0. I relocated the music to $8000, and placed it into the game project c64 folder and re-built the source. It worked. Excellent.

Level up

Random zeppelins in the game code didn't really work out, so it was time to make levels. Actually that was pretty much simple. I deleted all of the random tables and I entered the drag speed value for each level. The table for each zeppelin's drag rate was 16 bytes. The drag rate was still set between 0-3. Although setting the drag rate of 3 to 2 sort of looks as if the zeppelins are moving at the same speed, but in fact the speed is actually set to faster. After setting up the last level the game should loop. I then re-linked the game to the TND intro and prepared for a release candidate on my Ultimate 64. Yet again I used the native C64 tools to pack and crunch the game, like it would have been back in the 1990's. I then sent the game to testers. Some bad news - there were still bugs.

Stop bugging me

I decided at the end that I'll just stick to using 64TASS and Exomizer for all the packing and linking of this project, but I can disguise it to look like some of the old memorable packers . This saves me having to mess about all the time using old packers and crunchers just for the sake of old-school - then finding out something else gone wrong with this project.

The bugs in the game were that the hi score name entry routine allowed unwanted characters, which made a mess in the name entry. This was supposed to allow alpha-numeric characters, delete, space bar and return keys only It turned out I had set an incorrect range value (perhaps a typo) that read from number 0 and all the PETSCII character code before shift+A. Pah!

The second bug was that the total number of levels = 15 instead of 16 before looping back to 01. I set an incorrect value in the level compare code. It should have read 17 as the max value instead of 16, otherwise it would have been 15 levels. I re-compiled the source and fed the project through Exomizer, and after a few seconds, the game was working. The game has now been sent to the testers. Hopefully this could be a better result. We'll have to wait and see.




Update: Still not ready yet, but nearly there. Fingers crossed ;)

theC64 Challenge: #6 Para Lander DX - Part 1 / 3

1st April - 13th April 2021 

First of all, you may noticed that I deleted the previous dev-blog entry based on this project. Sorry about that, but I wanted to try and squeeze things down more and give you slightly less to read.

You may remember back in December 2020 I wrote a couple of games for the Cassette 50 Charity competition and I submitted them into the competition. The two games were Rocket Away (source code now lost) and Para Lander Mini (Created on theC64 in Turbo Assembler). 


During the Easter holidays, I felt like setting myself a challenge in creating an enhanced version of Para Lander Mini and write Para Lander DX. I was quite font with the development of Para Lander Mini. I also felt that this game could have looked and felt much better if I enhanced it. Since the source code was still on my USB I decided to set myself a new theC64 game development challenge to make it happen.

I chose to develop the game fully on theC64 using the following C64 applications:

* Faces Sprite Editor V1.3 (Sprites)
* Jon Well's Multi Screen Construction Kit (Charset graphics and game design)
* Face Painter V1.0 (Title screen logo)
* DMC V4.0 (Music composing)
* I-Relocator (Music relocating)
* Starion Text Editor (Scroll Text Writing)
* Action Replay MK VI cartridge plugin (Freezer and M/C monitor usage)
* Style's Turbo Macro Pro V1.2  (Programming) 
* ECA Compactor/Linker V4S (Packing/Linking)
* Cross' Cruel Cruncher V2.5+ (Crunching)

* Loader Game Tape Master Kit V3 (On the Ultimate 64)

The cross development applications used:

* Notepad ++ (Writing code and batch files)
* 64Tass cross assembler (Compiling code)
* Style's Dir Master (Disk Mastering)
* Exomizer V3.1.0 (Packing/Linking/Crunching)

The majority of the game was developed using those applications above. However there have been cases where I had to move source to the PC and use Notepad and 64TASS, more about that later as we get along through this feature.

Preparation

In order to prepare myself for this project, I needed to use Style's DIR master utility to create blank work disks (Since that cannot be done on theC64 itself). Then I imported all of the applications to the utilities .D64 image. I also made a .CJM file to disable the accuratedisk function, and allow fullheight mode. This is because by default I set theC64's root directory to use those functions. Once ready, I ejected the USB stick and placed it into my theC64. Then I attached the Action Replay MK VI artridge plugin to theC64 via the media manager. (I also own the original physical cartridge).

The graphics

The first stage was to prepare the game graphics. I started by using the Faces Sprite Editor V1.2 to draw the game sprites. The main sprites were the helicopter, the player, splash frames, platforms, Game Over and Well Done messages. The Game Over and Well Done messages consists of the game sprites.



The second stage was preparing the main game background and game scene graphics. I chose to use Jon Well's Multi-Screen Construction Kit for this task. As there were not many screen editors that allowed me to design screens and background objects the easy way MSCK did. I designed the text character sets and screen background objects then saved to disk as charset, object and screen data and also colour data. (Note: The pic below was an earlier layout of the game's graphics. The final result is a bit different).



Next on the graphics part, I pressed the Power + Right Shift Key on my theC64 to activate the Action Replay Freeze mode. Then it was time to enter the machine monitor and type in a small routine that will grab the colour and screen data and paste it into memory. I executed it and saved the colour and screen data onto a disk. 

Making music

I cheated a little where it came to writing music for Para Lander DX. I did use DMC V4.0 (As by far it is one of my all time favourite C64 based music editors and I used it since the mid-late 1990's). You may noticed that I imported all the utilities into the D64, but what I did not mention was that I imported my Happy Blocks music into one of the work disks. After loading Happy Blocks. I cleared the old music and written all the title and game music. The result turned out great. It made me feel great also.


The Game Code

The easy stuff was all done and dusted, so now it was time to get into the hard stuff. The game code. I did a zero memory fill of the C64, using a hard reset. Then I went into the Action Replay fast load option and I loaded the desired files into memory:

* Game graphics charset = $0800
* Game music = $1000
* Game sprites = $2000
* Game screen and colour data capture = $2800

Next I loaded up Turbo Macro Pro and got programming the game from source I did when I made Para Lander Mini in December. The first part was to remove a lot of the old subroutines from the game. I used the linefeed delete option. Next I produced a routine that would display the new graphics onto the screen. This was called by reading the game screen and colour data capture from $2800-$2be8 and colour data capture $2c00-$2fe8 and place it into the screen and colour RAM ($0400-$07e8, $D800-$DBE8). Then I run the source.

Setting up the new game graphics data

Having the graphics data to display worked more or less. However while the zeppelins were being dragged across the screen (using the old source interrupt code) the colour did not move. I got back to the code and I decided to cheat a little by creating a routine that writes the character colour of the zeppelin to the whole row of the C64's colour RAM. I repeated it with the other zeppelins. Everything was working great. I saved the code again.

Scroll them like you should

The colour layout was sorted out, but the zeppelins were still dragging across the screen in a rough fashion. Just like the Cassette 50 Charity Competition entry. Something needed to be done about this. I edited IRQ code to give it some multiple interrupts. There were five in total. Then in three of the interrupts raster splits, I set the target speed stored from the hard scroll routine and stored it to the horizontal scroll position ($D016). After running the source code, the zeppelins were moving at a much smoother pace. I was very happy with the result.

Animation

The next step was to deal with the sprite animation. The helicopter, the player and the happy landing sprites all consist of 4 sprites. For the sprite animation the pointers needed to be set and so had the tables for each sprite frame. A subroutine was required to be added to make the animation happen inside a loop. Then of course the animation should be stored to the actual sprite number that was being used in the game. After a few simple routines, I got the sprite animation to how I wanted it.

The other routine that was missing was the character animation. The water was still and the reeds in the background were still. I created a subroutine that could animate the characters. The reeds had to scroll up, and the water had to scroll left. There is something I did not mention about, regarding the IRQ. The botttom IRQ background colour was set to blue to blend in with the water.

Splash down

My next task was to generate a scene that breaks a looping code, and creates a new loop that causes the player to fall to its death and splash into the water. This event takes place every time the player hits a zeppelin. Also the water splash was another scene for itself.

Yippee

There was another part in the game code where the player lands onto the launch pads, the player disappears. I wanted to do something more fun, so I created a little routine which made the player jump for joy then disappear. However I did not want the pads to disappear. Instead I wanted them to go into the water. With a little tweak of code that was done.

Great the main game play was dealt with, but what about scoring? I moved the score panel to the bottom of the screen. Just as I was about to generate a score routine. Turbo Macro Pro got messed up at the bottom. I ended up with garbage. I estimated it as running out of memory for game code. So I decided to move the code to 64TASS and use Notepad ++ to update and fix the game code. Then after adding the time routine and scoring routine. I exported the assembler file back to thec64 and re-assembled with Turbo Macro Pro. Awesome, I have a working score and clock and lives counter.

Status

Although I had a working clock, there were a couple of things mission. The Game Over and Well Done routines. I got the player to lose all lives but no GAME OVER. I got the player to complete all six pads, but no WELL DONE. Just a flashing inc $d020 jmp *-3. I created a couple of routines that awarded bonus points to the player. Then I placed two sprites Well Done on level complete and Game Over. I got those to flash and then saved everything. I was very happy with the game. It was time to save all of the code and move on to the next step. The front end.

Designing the front end

Not much had to be done here regarding front end design. I did have something missing. A logo. I loaded up Face Painter V1.0 and I got working on a logo for the game project. Like with Spider Maze and a couple of my other game projects. I created a basic logo for the title screen. I filled each character with one colour. Then I painted the characters with a few colours. The Commodore 64's multi colour bitmap mode can only allow 3 different colours and the main background colour in each cell. The result looked pretty good for someone who is not really an artist :) After finishing, I saved it as a Vidcom image (Using Action Replay's Screen Grabber).


Writing a scroll text

I loaded up Starion Text Editor and wrote down my scroll text for the title screen. Basically it was all about the credits, game instructions and also the usual scrolling messages.

Making a title screen

Having a logo may have been easy enough, however something needed to be done to it. The game was missing a front end. I loaded all the game data (as before) and then I loaded up Turbo Macro Pro V1.2 again and I started programming the front end. I wanted to make a front end which contains a scroll text and some credits. However I wanted to also include the game background graphics, and a bit of flashing text. Well, eventually that did happen. Here is the result below:

Hi Scores

Although I was nearly here, in exactly the same code I prepared a high score table. The high score table data was made by using a normal basic screen, an Action Replay freeze, and in the text editor I set up the table and noted down the values for each name and list. The high score name detection had to be changed a few times, due to a lot of problems I have been having with the zeropages. I even tried the longer method, but it left too many bugs. I decided to re-write the Shock Raid hi-score name entry routine but I used different zeropage values. It worked nicely. Next I manually linked the hi-score name entry to the game code. The name entry routine was keyboard based. This was actually the most easiest part in the name entry. Especially when the whole game project was using Kernal routines and IRQs ($01 = #$37).

Hi Score Disk Access

The final part of this task was to create a high score saver/loader routine. This part of the role had to be done in 64tass. This is because I wouldn't have known if theC64 was writing / reading the high score table. This is because theC64's accuratedisk mode has problems. So I had to rely on 64tass. I did many versions of the hi-score loading/saving code but it just didn't go very well. There were a lot of crashing going on. This had to be investigated, but I realised I used routines and zeropages I should not have used in the game, that caused it to crash. Finally this got fixed.

Compiling - Oldschool Style

Well, finally I get to compile, pack and crunch the project. All of this which I decided to do on my Ultimate 64, due to the features it has. I loaded up the ECA Compactor/Linker and packed the whole chunk of game data with this program. (And also endured the noise while doing the job). Then I set the jump address of the disk loader ($5780) and saved the packed file.

Next I loaded up the Cross Cruel Cruncher V2.5+. I typed in a 1-liner de-crunch text and set my Ultimate 64 into 48MHz mode for high speed crunching. - I set the jump address to $0810 (The jump address of the ECA Linker's de-packing routine) and then crunched the program. It only took a few seconds, whereas if it was at 1mhz mode, it would have took about 15 minutes. I saved the game to disk. I tested it and run the game. Result. I have a full working game. 


Is the game ready to release? ...   Not yet, you'll find out in the second part of this blog. The game will be released. You will just have to wait and see.

Saturday, 27 March 2021

March 2021 Cruiser-X Progress Update #2

 27th March 2021

A couple of weeks ago I had left you with where I last left off. It was mainly based on the power ups based system. Now 2 weeks later, more work gets done. Last week, I finished off fixing the SEUCK Title Screen Maker disk, by fixing a bug in one of the example games (Which wasn't the fault of the title screen maker).

This session was mainly based on level setup. Of course I may not have the level graphics yet for level packing, etc. First I have to set up different sound effects for each bullet type the player carries.



I can still start on setting up the level scheme and enemy selection. Last time I managed to get all enemies to appear in order of sequence. Today I have been making a sequence for level 1 of the game. This is now based on the colour scheme table read, and also the alien selection table (based on levels).

After setting up the level routines, the enemies are able to fire bullets but the bullets do not collide into the player. So in order to fix this, a subroutine is programmed in to read the X, Y co-ordinate range of both sprites, and if inside the collision area. The player will die, unless a shield is in place. Then the player respawns.

Well, that looks good, but not really good enough. When shooting at aliens or shooting destructable background characters, The player should score points. A subroutine reads pointers for the player's score, lives and level. Then it copies it to the score panel on screen. I decided to do it this way this time round, because it is a way to prevent the player cheating by freezing the game with the Action Replay cartridge and editing the score/lives value with the screen editor. I cannot code protection routines, plus I cannot be bothered with those anyway :)

The enemy scoring should be based on the enemy sequence value that is used. I set a new table which creates the new score values for each alien, after it has been shot. The values are based as 1-5. Where 500 points is the maximum score which the player can score. Shooting background and collecting power ups also gives the player some points.So can the activation of the player's smart bomb (Which is triggered with the fire button).

The player's lives indicator also needed to be updated to decrement, and when lives have reached 00, the player will lose the game, and GAME OVER commences. Of course even if I was updating score, lives and level pointers (or restarting the game) I would need to update the score panel via a subroutine.  I am happy that it all seems to be working.

Now on to one final problem. The alien spawn sequence is set based on the chosen level, the enemy bullet can now kill the player, the score panel is working. The final problem for today - the aliens are firing too rapidly. How can that be solved? Simple, before randomly selecting the enemy to shoot a bullet. A delay pointer, and delay expiry counter should be set. Adding one of those makes the enemy fire bullets less rapidly. There is a chance I could make a table like with the scoring table, where I could base the enemy firing rate. That might be some time next weekend. We will have to wait and see. But for now, here's an updated video of my work in progress.