This year does not only mark the 40th anniversary of the Commodore 64, but it also marks the 50th anniversary of the cult classic two player arcade game PONG (The screenshot below is a PONG V1.0 by TND contributor Matteo Angelini. Quite recently, Retro Programmers Inside launched a programming challenge on their Facebook page in which is to make a PONG style game to celebrate the 50th anniversary.
To mark the celebration of the 50th anniversary of PONG (and ironically celebrating the 20th anniversary of POING). I will be doing a lucky 7th theC64 challenge on my theC64 full size computer, with aid of an Action Replay plugin and a few utilities. This type of game should be suitable enough to create and design on RGLs computer, unlike a couple of games I had failed on, due to memory issues. After project is finished, I will also be including the source code.
I remember back in 2002 I wrote a C64 game called POING, which ironically had a second sequel. To celebrate the 50th anniversary of PONG and also my 20th anniversary of POING, there is going to be just one more POING. I remember someone contacting me a few years back suggesting I should re-master Matteo Angelini's game to give it background effects, and stuff like that. I didn't quite get round to doing that. However, as I'm not all that familiar with CC65, and don't like scripting languages like C, C# and Java. I have decided to just make my own version instead.
I do remember POING being written back in 2002 completely in Turbo Assembler, and Action Replay, but the game had many bugs left inside. After I released the game, it crashed at times. So a second version was released.
Three years later, I created a sequel, which was called MEGA POING. (Renamed from Poing 2). The game graphics design was slightly improved but felt too much the same as the original POING. There was also a 1 player mode, which only had the player moving up/down constantly. There was no AI programming involved in this version of the game. The game had no sound effects, and had only music. There were also 4 different screens, but the size of the game field was way too small. The same problem was with the original POING.
Moving on to 2022, I have decided to make at least one more sequel to POING, but with the more better skills I have in C64 game development, compared to back in the early 2000s. I am aiming to make POING 3 look more modern. It will feature a colourful presentation, and also (as suggested years ago by another C64 coder) will feature full animated background and some up-tempo music (unless sound effects has been selected). The only difference is that the project will be developed with a modern look on my theC64, without use of PC cross development tools for graphics design, sound, and programming. I will be doing all this on theC64. Then the finished production will be mastered to a digital tape image using "Tape Master Pro V4.0" via my 1541 Ultimate (Since VICE in current theC64 firmware doesn't support tape writing support).
I have already picked out a selection of utilities from the Public Domain C64 scene. The CSDB has so many scene-related utilities, but I have only picked out my favourite tools for this project. They are as follows:
Graphics:
Multi-Screen Construction Kit V2 by Jon Wells (previously commercial, owned)
Char Machine char size converter by Sub Zero (public domain)
Sprite Editor V1.3 by Faces (public domain)
Face Painter by Faces (public domain)
Sound and music:
DMC V4.0 (Demo Music Creator) by Graffity (public domain)
All Round Relocator (for just incase I need to move music) by the Syndrom (public domain)
Programming and development:
Action Replay MK VI by Datel (previously commercial, owned)
Retro Replay V3.8Q by Cyberpunx (Public domain)
Programming, compression and linking
Turbo Assembler by Omikron (public domain)
64TASS (Cross-development compiler by Singular)
Exomizer (I don't want to spend ages packing and crunching, unlike what I used to do back in the 1990s-very early 2000s :)
Mastering
TND branded Presentation intro by Richard/TND
Tape Master Pro V4.0 by Martin Piper and Richard/TND
I have until 20th June 2022 to develop and produce this game project, but with all the free time I currently have at the moment in the evenings during poor quality TV shows (Let us put it this way, prime time on a weekday is over-run by extended news programmes and soap operas.
It is most likely my project is to be completed before that specific date unless things change. Of course, I will also be continuing with my Reset 64 mix-i-disk game project and also Cruiser-X 79. Which a new blog will be posted about the project next week. Wish me good luck :)
Please note: screen shots featured in this blog are screenshots taken from VICE - although the game project is *officially* being programmed on theC64 full size.
Sunday 22nd May 2022
The in game graphics scene
It was quite an easy task for the first part of this challenge. During Sunday night, I booted up theC64 and loaded up the Multi Screen Construction Kit and I drew out the game graphics scene. If you look at the screenshot below. You can see that the game screen has been designed like a traditional PONG court, but there is a bit of modern design implemented into the graphics.
I didn't want the game to look very basic like the traditional PONG, but instead I wanted to make something more colourful and quite attractive. There could be a possibility that later on the background graphics might be tidied up a little more. We'll have to wait and see how time goes with this. Then again, my text charset has always looked the same, but that will of course be for the title screen (along with a nifty bitmap logo). I take a look at the value of each charset, and take notes of which chars represent the scoring number chars, also the lasers and blue tiles. These have been noted on paper for a good purpose. I need to keep those as reference for when I am actually coding the game.
Although the game screen has been designed and stored and saved to a finished library. For the main game project I will not be using the finished library file. This is because for a game simple as this, the library file is too big, and perhaps not compatible with the Turbo Assembler when loaded. I tried this a few times, when I created Balloonacy and a few older games back in the very early 2000s. There were plenty of pitfalls.
Instead, I push the freeze button on the Action Replay and then I code a subroutine which extracts the screen and colour RAM and place it into memory, where I can just save it out as a whole chunk of data. The routine then jumps to $FCE2 which soft resets the C64. However the charset, object and object colour files all have to be saved first before I can add the routine and perform the action. At the end of the day, I don't want to lose everything if it all goes wrong. I can be a clumsy coder at times. The routine used was this:
Monday 23rd May 2022
The sprites
The next task was to draw some sprites for the game. I wanted only a few sprites (for now). I loaded up the Sprite Editor V1.3 and setup some colours to test the look of the sprites. I chose brown, white and cyan. Unlike some sprite editors, the changeable sprite multi-colour stays that same colour all the way through. Of course, when I work on coding the game, the sprite colours will be different. The ball intends to be silver, player 1 intends to be light blue, and player 2 intends to be light red. We'll have to wait and see.
I drew the bat (a single sprite, but this can change later on in the project), using 3 colours, also I drew the ball and also an explosion animation. The explosion animation should more or less cater for the size of the bat, to give a good effect. To be honest, I am not all that happy with my explosion animation frames, and feel that something could be changed. I can do that later on in the project. There is plenty of time - and I currently have it at the moment.
Sprite 00: Bat
Sprite 01: Ball
Sprite 02-06: Explosion (Will be improved later in the project!!!)
Coding - Session #1
Now it is time to code the main game. No title screen, yet. The main game will be the most important aspect of coding. First the Action Replay cartridge has to be set and completely initialise all of the data in memory. Pressing F1 (Configure memory) usually does the trick. Next, a soft reset to the Action Replay menu and into fastload. As I don't need accurate disk (_AD ) for the software which I am using for my theC64 game development challenge.
The next task is to load the graphics data, and other work data. I also extracted an old tune from a note writer to use as a test soundtrack for the game project. I will be doing music and sound effects in DMC V4.0 later on during the project. I chose the layout for where to put everything so far in the project:
$0800-$0fff - Game screen and colour data
$1000-$1xxx - Game music and sound effects
$2000-$2400 - Game sprite data (There only needs to be a small number of sprites AFAIK)
$2800-$2fff - Game character set data
$3000+ - Game code
I load up the Turbo Assembler and then enter SYS26880 (This version of TASS used was shortened and modified by Samar and has $9600 as the jump address in order to make more memory for code listings). Then I did another soft reset on theC64 and type OFF in the fastload option. F8 is then pressed to enter the machine code monitor. I load the game graphics, test music, sprites, and charset data into the chosen locations, and then I save the whole set of data as a big chunk.
Next I enter G 9600 to enter the Turbo Assembler and I got started with coding. The first part was to get the game screen onto to the main screen. Then after I successfully got that on display, I got to play some music in the background, via an IRQ raster interrupt. The music player has not yet been used to play in PAL/NTSC speed. That could be done in my next coding session. The main idea is to get the game graphics to display on screen, and ensure that my IRQ raster interrupts are working. Brilliant.
You may remember earlier on when I designed the blue tiles inside the game arena, and I also added some lasers. Well, these I don't want to be just static, I want all of those to be able to scroll. The laser beam on the left should scroll upwards, and the laser on the right should scroll downwards. Before I am able to get those to scroll. Pointers (worth single bytes) must be entered to time the speed of the scroll. Also I need a pointer to the synchronize with raster interrupts. Also to scroll the lasers I have to set the scroll time to a delay value. Then reset the delay value, and then scroll laser characters. character 40 represented the laser up, and character 41 represented the laser down character.
How do I scroll the characters? Well a whole character consists of 8 bytes in memory. To scroll a character upwards, I would have to grab the very first byte of the character, store it to a pointer or zeropage, and then call a loop that pulls the remaining characters back. After that is performed, I simply load and store the zeropage into the last bit value of the character. Scrolling lasers downwards is a reverse operation. I prefer to use zeropages or pointers to collect and store the bytes instead of using the pha and pla command in order to avoid confusion.
An example for scrolling chars upwards:
lda charset+(40*8)
sta chartemp1
ldx #$00
scrollchar
lda charset+(40*8)+1,x
sta charset+(40*8),x
inx
cpx #7
bne scrollchar
lda chartemp1
sta charset+(40*8)+7
Also char scrolling backwards
lda charset+(41*8)+7
sta chartemp2
ldx #$06
scrollchar2
lda charset+(41*8),x
sta charset+(41*8)+1,x
dex
bpl scrollchar2
lda chartemp2
sta charset+(41*8)
After assembling the source code done so far, the screen displayed, music plays and also the left and right lasers are scrolling perfectly.
The next thing I want to do is make the blue tiles scroll in eight different directions via a timer. A new routine has been programmed to perform this operation. After assembly and running the program, the tile scrolling routine worked, but for some strange reason there was a big split/tearing in one of the bytes between the characters. I think I will have to re-program that scrolling routine. I am sure I did the code correctly, but perhaps there is something else interfering with it. I'll see what I can do tomorrow.
Tuesday 24th May 2022
Coding Session #2
Yesterday, I came across the problem with the moving grid inside the game screen, where a row of the charset was chopped away. Today I decided to forget about this feature and delete the routine, in Turbo Assembler and just keep the lasers (for now). Today's session has been cut short, because I only had some small things to do today.
After deleting the moving grid code (it will be implemented later on in the project, so I haven't axed it completely). My main goal for today is to get the sprites positioned on screen and moving. I place a nice shiny blue bat at the left of the screen, and I also put a pink (light red) bat on the right of the screen. A ball is then placed in the middle. I assemble the source and run the code. It looks much nicer, but wouldn't be much better if the sprites could actually move?
The next part is to have the ball moving. However the ball needs to move according to the direction of the X / Y axis. A couple of pointers have been made to make in order to process the X / Y direction the ball should move. Also boundaries have been set to ensure that the ball does not leave the screen. I tried to make it possible for the ball to hit the laser chars without using any sprite to charset collision routines. The trick seems to work nicely.
Now that the ball is bouncing happily around the screen. I must get the correct player to score points, as the ball hits the goal behind the opponent. Well, how do I work this out? First I freeze the game screen using the Action Replay freezer. Then I go into the text editor, and note down the screen character area where the scoring characters are. I note these into my notebook, and then get back into the game and into the Turbo Assembler. Some variables are added at the start of the code, then some scoring routines are added. The scoring routines are slightly more complex compared to how I am usually used to doing those. This is because I used custom characters that form the numbers. A set table was made yesterday. So I will need to read the table and store those characters to the screen. It is a bit like putting a jigsaw together. After a few minutes adding some more code to the source. It is time to test the result. Superb, it is working nicely.
My next step is now to both players working via joystick control. Player 1 (the blue bat) should be controlled with a joystick in port 2, and Player 2 (the pink bat) should be controlled with a joystick in port 1. Normally to code routines for a two player game it is easier to write macros and link those to each player. Sadly Turbo Assembler V5.F does not support macro commands, unlike cross-assemblers. So I just have to re-type the same routines again for player 2.
Now both players are now moving quite nicely. There is only one more thing for me to do today. This time it is maximum scoring detection. When I make the title screen (Which is highly likely to fit complete with the game code source), I will want to add some in game options where a maximum number of points is set in order to win the game. So I create two maximum score pointers where one represents tens and and the other as units. Then I do a comparison of the player score and whether it has reached the maximum score set for that game. I added a border flash to test player 1 winning and a background flash to test player 2 winning. Brilliant, Result, it all works !!!
It is now time for me to call it a day for today. However the bats cannot hit the ball. There is no sprite/sprite collision detection or animation. That will have to wait until my next session.
Wednesday 25th May 2022
Coding session #3
I don't have any more screen shots to show you at the moment, but there is some good progress. Yesterday I left the project where the players are able to score points when the ball hits the laser. Now what about allowing the bat to hit the ball? Today this is my task for the day, along with a couple of tasks.
First the speed of both ball and bats are a bit too fast. The speed value has been reduced and now the player bats and the ball moves just about right. There needs to be a collision detection between the ball and the two bats. I made a one size fits all sprites collision detection, which appears to work quite nicely in the game. Also the ball can rebound from the bat as well as the two lasers.
I am very happy with the sprite to sprite collision detection. It seems to be working quite nicely on my theC64. Now it is time to try add a bit of AI code into player 2 (should the player select to play against the computer by choosing 1 player mode). I want to make the computer as smart as possible to be able to hit the ball and make it harder for the player to score a goal, unless it is possible. In AI mode, the value of player 2's vertical position is set to match the ball's vertical position. However the ball is faster. I test run the code and the bat in AI mode is hitting the ball quite nicely. There might need to be some more work to be done in this feature. Perhaps when I next get back onto it this weekend.
You may remember a couple of days ago, I mentioned about the scrolling tiles having an issue. That issue of course was where there was some tearing around the charsets. It turns out that I was close to being correct with the moving tile effect, but I grabbed the chars too and stored the chars too late. Today this issue has been solved.
Well that is enough for today. My next session with this project is most likely to be on Saturday (the project continues on Sunday instead), where I move both players closer to the laser beams, and also try and improve the graphics, sprites and perhaps implement some power ups/features to enhance game play. Tomorrow night and Friday night have been reserved for Captain Ishtar and Cruiser-X 79 level 9.
Sunday 29th May 2022
Coding session #4:
This continues from the last coding session of this game. The player is active, and also AI control has been added as well, but the AI just keeps on following the ball and appears to be rough. I might have to solve this issue later on in the project, since I haven't done AI programming before. It is slightly harder than I thought. It has also made the game a lot harder.
Today I load in the source code and then work on the explosion. The explosion should take effect whenever the the ball leaves the opponent's goal. Then a point should be scored. The first thing to do is to locate the code that jumps to the scoring, then add a jump subroutine that calls a loop to read an exploding sprites table, and make the player explode - then restore the player's sprite after the exploding routine has finished. Perfect, the explosion work but I still don't like the explosion sprites very much.
Next I notice how the bat and ball collision detection is quite clumsy at times. The ball is bouncing around the bat too often. The collision register is just too big and the co-ordinates need to be reduced in order to fit the bat. After a test the ball bounces back. There is still another problem, which I shall deal with. The ball's X direction rebounds correctly, but the ball's Y direction appears to stick to the same direction after the bat hits it. The Y direction of the ball only rebounds after it has hit the minimum or maximum vertical position set on screen.
To solve the issue with the ball rebound, I can add a new pointer, which detects whether or not player 1 or player 2 can bounce the ball upwards or downwards after hitting the ball. Basically, if the player shifts up, the ball will bounce up, if the player shifts down, the ball will bounce that direction. If the ball stays idle, then the last Y position read from the joystick is automatically stored to the ball and it will rebound that direction.
Problem solved, now to make things harder and quite funnier, the bats can hit the ball, and the ball bounces against the walls. This makes it pretty much too easy and boring to play. However I have come up with a cunning plan. Wouldn't it be more fun, and crazy to have the ball increasing the speed after a specific number of rebounds? I have now placed in a rebound counter and set it to 10 rebounds. After 10 rebounds have expired, the ball will bounce faster, and make the game slightly more frantic than before. This affects both the X and the Y speed of the ball. After testing, this is looking much better. I shall now save the game code to my work disk image on USB (plugged into theC64), and do a backup of it on my dev system, ready for my next task. More graphics.
I can take a little break from the code and now work a bit more on the graphics. There's going to be an improved explosion for the bat and some new sprites. I have some ideas what those could be. Still no screenshots to show you, but hopefully the next session should have one or two more.
One more thing to add. The game will not be called "POING 3", I have renamed it as POING Ultra instead. The deadline for the PONG compo is coming closer. About 3 weeks in fact, so I'd better get my skates on !!!
Tuesday 31st May 2022
More game graphics and a tiny bit of code.
I am mainly focussed doing some more game graphics today. I will be doing the game sprites, then afterwards I will be improving the in game character set graphics slightly, so that the game looks much better. Okay, I shall start with loading up theC64 and setting everything up. Action Replay cartridge... ready ... PD Utilities disk image ... ready ... Sprite editor ... ready ... previous sprites ... ready.
I think you have worked out what I am making right now. That's right, the game sprites. Using the cursor keys and the * key on theC64, I removed all of the frames that built the explosion effect. The reason for that was because I wasn't very happy with it. I then draw some new explosion sprite frames. They look much better. I'm happy with that.
POING Ultra shouldn't just be all about player 1 and player 2 in court, bashing the ball and attempting to reach their opponent's goal. I want to add some kind of fun additional features to the game. The court needs an alien. That's right, a ball and power up spawning alien. The alien can consist of 4 frames for animation. It will cycle the existing colours inside it, and also animate lasers above and beside it. Afterwards I will draw the power ups. They are slow ball (ball with two chevrons pointing to the left), fast ball (ball with two chevrons pointing to the right), freeze bat (bat in ice), speed bat (bat with two chevrons pointing to the right), slow bat (bat with two chevrons pointing to the left), reverse bat (bat with a double-sided arrow underneath), lose 2 points (warning sign with -2 underneath) and instant death (skull and crossbones).
The power up sprites are finished, I'm very happy with those, so now it is just draw 1 UP WINS and 2 UP WINS sprites and I'm done with the game sprites. Brilliant, I am very happy with the result and the sprites are all done. I'm running out of space on workdisk 001, so I have moved onto workdisk 002 to save the sprites. Below is a video (recorded from VICE) of all of the game sprites I have made for POING Ultra. There are not many sprites there, but I think that there is enough of those for this game anyway. Also I have to keep my memory well managed.
You may remember that a few days I worked on the game graphics. I was pleased with how they looked, but I felt that something really needs to be done with the scoring objects. I now load up the Multi Screen Construction Kit and insert disk 001, to load in the charset graphics, object and screen data and colour data. Then the charsets get edited. The letter characters have been reduced a little, and the scoring characters have been tweaked to look a bit like a digital clock. No colour has been changed because there was no need for me to do that. I adjust the characters that form the blue tiles, and they look a lot better. I attach work disk 002 and save the graphics to that disk image.
Next it is time to tweak the main program. I load up Turbo Assembler, then I zero fill memory $0800-$95ff. Then I load in the old game graphics data file from disk 001. Disk 002 then gets attached and I load the new sprites and charset data. Then the complete data file gets saved as gamedata2. Next I go into the Turbo Assembler, and load in the game code from Disk 001. I do a test run. The new explosion sprites were sort of working, but were missing some sprites. So I expanded the explosion sprite frame table, and then saved everything to Disk 002. One more test and great, the new sprites and graphics are working fine. Here's a second video in today's featuring the new game graphics.
Wednesday 1st June 2022
Coding #5 and a bit of a change
Last night I watched Phaze101's stream announcing the PONG 50th Anniversary and the Towel Day feature. Sadly I could not watch the whole of the stream due to it getting late. I also learned that there is one specific feature that is missing in my game. Basically two major flaws I did with the original POING and POING 2 was that the player could only whack the ball diagonally and only the X-Axis of the ball was altered. Although POING ULTRA has a diagonal change in direction when the bat is moving up or down. When moving idle, the ball should move horizontally.
It is time for me to load up the Turbo Assembler and work on some code to fix the problem with the ball angle changes. It is easily solved. When I was programming a routine 3 or 4 days ago of the player moving. I added a labelled pointer known as player1dir (or was it bat1dir?), and player2dir (or was it bat2dir?). If the value of the player direction = 0, it means the ball's Y-Axis goes up, if however the player direction = 1 the Y-Axis of the ball goes down. What if the bat is still. Previously there were only two directions for the ball. Now if I add a values of 2 to the player1dir and player2dir, and add a check where no joystick control takes place. It should work. ... It does.
Now my next task is to add the power ups and the power up spawning alien (Sprite 3). First I add the code to place it in the middle centre of the screen. That's good it's there, and it is green. Next, I shall animate the sprite to use its four frames. That looks even better. Now let's colour cycle it with a blue/purple pulsating colour. Nice, it fits perfectly. There is just one more trick to do to animate the sprite. I need the alien to move up and down. After a label pointer for the spawn direction, and a bit of code, it works nicely. At the moment the ball spawns from out of nowhere. I want it to spawn out of the power up spawning alien. The value of the X, Y position of the ball sprite is now stored onto the X, Y position of the spawning alien. A quick test, and YES! It is working great. The ball spawns out of the alien every time the game starts, or the ball moves out of the screen.
The spawning alien spawns the balls no problem, but I now have to work on the random power ups generation. Each power up should generate after a set time period, and also the direction selected should also be chosen at random. I create a label pointer for the spawn direction. Then I call a routine to test the directional movement of the power up sprite (Sprite 4). First the routine is tested with the pointer set to 0 (left). Great, the sprite is moving to the left. Next a routine is tested with the pointer set to 1 (right). Yes, that also works nicely. Now it is time to create a pointer of the power up, and then call a subroutine which selects one of eight different power ups at random, then store it to the power up pointer. The code listing gets saved, and I test the game code. The bats are hitting the balls, the balls are working how they should, and the alien is spitting out power ups. Brilliant I'm happy with that.
Before I call it a day, there is at least one more thing I want to do today. That is to add a sprite to sprite collision detection routine for the players and the power up. Unfortunately that did not go according to plan, as the version of Turbo Assembler I chose for this project didn't allow me to type in any more code. It spat out a label overflow error message. I might have to find another assembler. I don't want to fail my challenge like I did with the past 3. All was going really well with this game project until I encountered this problem.
I loaded one of my old PD disks, which had an older version of Turbo Assembler (V5.2 improved by The Beast/The Ancient Temple), and I loaded the sequential file containing my source code. Although it has less memory for long listings, the program I was writing did not exceed its limitations. I am now able to finish off the collision test subroutine. Great, the collision routine works, and the test is complete. Now I can save the file and then tomorrow, I shall add the actual power up routines and put them in to action.
I shall now call it for the day and continue with the project some time tomorrow. Then hopefully on Saturday, I could be ready to make sound effects and music for the game. I'm still well on track for the submission deadline for RPI's PONG 50th Anniversary game jam.
Thursday 2nd June 2022
Coding #6
You may have read that yesterday's session of POING Ultra had power ups added to the game code, but no effects were taking place, due to time. Today I have decided to put the power ups into action. First of all some labels are created to make the value of the sprite frames that form the power ups. Then at the bottom of the code, the numbered bytes are renamed into the sprite frame labels. We could actually call those variables.
Next I edit the game code player to power up collision routine so that instead of changing the colour of the player, the power up gives some kind of effect. The routines check the frame value of the hardware sprite type 4. If the value of the sprite = the sprite frame read from the table (selected at random) the effect should take place on the player who collects it. Of course I have to alter some of the player's code so that some of the power ups take affect. For example the bat in ice should freeze the player permanently and ignores control (or computer AI mode) until a ball reaches the goal. Also the $DC00 and $DC01 values have to be swapped if the player collects the bat icon with an arrow pointing both directions. Also the bat should use fastest or slowest speed during game play until the ball passes it. There is also a power up which sets the speed of the ball, subtract 2 points from the player who collects the power up and also a power up, which just jumps to the player's death subroutine. I assemble the game and test the power ups in action. Great!!! they are working.
There is just one more thing I will need to do now. A week ago, players were able to score points and after a maximum score has reached. Player 1 winning called a loop that flashed the border, and player 2 winning called a loop that flashed. A couple of days ago I drew a single sprite to represent which player has won the match. All I need to do is add those correct sprites in place, and a copy of the synchronized timer loop, with expanded sprites msb and background animation. Job done. I assemble test the game once more. I give it a play. Well, I have to admit it is looking good. The only downside is that it is lacking music and sound effects and a title screen with in game options. Not to worry, this will be next on my list. This weekend in fact. Anyway, enjoy this little video of the work done so far.
Oh, okay, I spotted a bug in the ball speed reduction. I'll fix that this weekend before I code the sound effects and then work on the game music.
Saturday 4th June 2022
Coding #7
I will be programming in game sound effects today. First, I will create some pointers for PAL/NTSC video detection. Next, I will make some tables to make my very own in game sound effects. I will need to create a sound option point. Then create some tables to represent the sound effects. Unfortunately now, I can't add anymore code or bytes, because the Turbo Assembler has thrown a wobbly at me on theC64. I received another "LABEL OVERLOAD". Just as I thought the main game was close to completion, a problem like this happens. I write the code to the work disk as a sequential file and I will continue with the code later on. I honestly want to finish this project on theC64 full size. Unfortunately the version of Turbo Assembler blocked me from producing any more code. My last hope will be the Turbo Action ROM by Dekadence.
Sunday 5th June 2022
Bitmap graphics and music #1
After yesterday's major disappointment and Turbo Assembler blocking me from adding any more labels/pointers (which I dearly need to include in the project). I have decided to relax and work on making some music and also some graphics. First I load up DMC V4.0 and compose the title music. Hmm, yes, the music is very upbeat - and feels like one of those Happy Hardcore soundtracks. I like the composition. I will include it in the title screen. The music will need to be relocated. Next I compose the in game music. The music is slightly less happy hardcore, but more like early 90s techno or something like that. That tune doesn't need to be relocated.
Next I load Face Painter into my theC64 and draw some graphics. I am drawing a colourful logo for the title screen. This actually took more time than I expected because of not being very happy with the design of my previous logos and scrapping the ideas. Now this logo (Pictured below) looks ever so nice. I may be no graphics artist, but I am really happy with this logo.
Next I start a loading bitmap for the game. It should be based on the actual game. The picture should have two lasers, two bats, a ball, and possibly a few other things. The picture is not yet finished, but I have been enjoying working on Face Painter. It is likely that in the future I could be drawing more logos on the C64 - mainly for stuff like intros, game projects, and of course Scene World. This is actually quite an achievement. Tomorrow, I shall search for a better Turbo Assembler, and pop it onto theC64. I'm thinking about SounDemon's TASM/CODENET,which I enhanced a whole SEUCK game (Rocket and Roll) with. If the cartridge image works on theC64.
Monday 6th June 2022
More coding #8 and headaches
During the weekend I came across some very awkward programming pitfalls. Turbo Assembler blocking me from adding any more code, etc. I was unable to finish the sound effects off for the game code. That was until I had some helpful advice from Robin, regarding the Turbo Assembler. It is best to save the code to a sequential file and the load it up into the assembler once more. I tried a few versions of Turbo Assembler. The trick did work, but I thought I try TASM/CODENET first. Unfortunately, I made a bad choice. This is because the assembler was operating very slow on theC64 (it also lags in VICE, so not recommended unless using on the Ultimate64 or a stock C64 with 1541Ultimate 2). I even tried it on my Ultimate 64. Nah, Turbo Action Replay by Dekadence keyboard input lags too much.
I decided to change the cartridge image, and tried Cyberpunx's Retro Replay V3.8Q. It also has a built in Turbo Assembler. I load up the sequential file that was saved. It loads up, and I continue with the sound effects tables. After setting up sound effects table and implementing it into the SFX player (and setting values to the SFX). I get really good results. The sounds are all working perfectly.
The game is working out really well, there are sound effects in place. I just need to add one more trick to the game code. The alien that spawns the balls and power ups. It would be interesting to add a rebound X whenever the ball hits the spawning alien. So if the player hits the ball, and it hits the alien, the ball's vertical position should reflect towards the player's goal. Of course, that was a quick and easy fix. I test the game once more and watch everything in action. Absolutely brilliant. All is working nicely.
Before I start working on the title screen (game options), I load up the new in game music and try it out in the game. Also I move the screen and colour data $0800-$0fff to $4800-$4cff as $0800-$0fff is now replaced by the 2x2 character set which I have made for the scroll text. I save all of the new game data, and then I start coding the title screen.
First I switch off all of the IRQ raster interrupts and switch the screen off in order to initialise the routines. I prepare the logo data and copy from estimated Koalapaint colour RAM and video RAM memory and paste it to BANK 2 screen RAM ($4400-$45b8) and the colour RAM data goes directily to the $D800-$D5B8 memory. Drawing of each colour and video RAM data uses 40 columns and 9 rows. Then I set up three IRQ raster interrupts, where the top raster represents a a bitmap logo, the second IRQ represents the 1x1 character set text and the last IRQ represents the smooth 2x2 scroll text, synchronized timer value of 1, and PAL/NTSC music player. Of course I code the PAL/NTSC music speed player and run it. Hmm, yes, it looks okay, but a bit messy. The logo isn't loaded in place yet, but I can leave it as that.
Next I go to the Retro Replay fast load BASIC and then I edit the text to add names of all of the in game objects. Including the bat, ball, spawning alien and power ups. Then I capture the text lines using the Machine Code monitor's Transfer subroutine. Afterwards, I edit the game options menu text for the front end. I grab the text and put that into place. Finally I write a scroll text inside the machine code monitor, where free space is available. Then I save everything as GAMEDATA5.
Back to the Turbo Assembler, I first code the sprite displayer and text underneath to represent the sprite. The text displayer is controlled by a simple delay subroutine, which will count 256 cycles before it switches to the next text in line. I test run the title screen. Nice, it is working. Next I work on the 2x2 scroll text. I test the title code. Good, the scroll is working, but I must store the pointer value to $D016 to have it move more smoothly. I did that. Great. It is all working. I still have more to do on this, but I'll do that tomorrow. I save the text to disk ready for the next session.
Tuesday 7th June 2022
Coding #8 and extra headaches
I continue programming the title screen. All has been going really well, until "LABEL OVERFLOW" constantly popped by on the screen. I made several attempts at saving the source code using the -W function and re-loading everything, but the problem still occurred. I was so close, close to the coding side end of the game project. I will have to cheat the very last part of the coding phase. The source code sequential file is exported to PC assembler format, for use in 64TASS. I also create a separate folder to put all the program files in place. - After finishing the code for the title screen. Hopefully, I can re-convert to Turbo Assembler, and then edit the last bit of code. Sadly it cannot be today.
Wednesday 8th June 2022
Coding #9 and I'm nearly there.
I have been finishing off the title screen code today in 64TASS also I have made some new scrolling voids and colour table. I tried to convert the complete source code to Turbo Assembler. Unfortunately I have produced too much code and the Turbo Assembler has crashed. The reason for this problem is because I also included the title code as the same file as the game code and hoped that I would get away with it. WRONG MOVE!!!
Now, the code is going to be split into two separate source files. One for the title screen and one game options, and the other for the game. I think that is more or less a sensible choice. Of course I will have to check where the pointers are for the game menu settings.
I also had a go at converting the 64TASS code back to Turbo Assembler for the final production. Unfortunately things did not go according to plan. I used Holy Moses' 64TASS to Turbo Assembler converter which converted 64TASS code into Turbo Assembler. I load up the title screen assembly source and edited it to work in Turbo Assembler source. However when it came to editing the game source code to work in Turbo Assembler - a lot of labels and stuff had gone missing. It looks as if 64TASS to Turbo Assembler is limited with its file size.
Thursday 9th June 2022
Tweaking and fixing
I have been tweaking the graphics for the main title screen. The character sets to be honest. They looked too much like the character set you would have seen in the SEUCK menu. Instead, I decided to make a minor adjustment to my character set and make it look more chunky and fun. I have used Cunieform to edit the chars. Next I load up Sprite Pad. The game sprites look pretty messy and ugly. Especially the power up spawning alien, and the power ups. I make some tidier sprites, then assemble and run the game. Great, it looks so much better. Check out the new front end :)
Now there is still one thing that bugs me in the main game. There is a case where the player spawns straight away and picks up a power up, it goes into effect. That is not really a fair way on the player to collect something like a frozen player power up or instant death. So I have decided to add one more feature to the game. A short term shield every time the player spawns into the game field. The power ups can sail past the player while it is in shield mode. I fixed these in place and finally the game is finished. Well, not quite - I have the final loader picture to finish off, and also a loading tune. That will take place tomorrow.
I know this is a lengthy blog entry, but you will be pleased to hear that you have nearly reached the end of it.
Friday 10th June + Saturday 11th June 2022
A bit of drawing, more music, tweaking and final mastering
Finally this is my very last entry to this very lengthy blog. I start this weekend's session by typing a longer scroll text, as I found memory to fit a larger one on Thursday. After doing that, I transfer the new scroll to the source code and compile the code in 64TASS. It fits nicely.
The next thing for me to do is to finish off the loading picture. I load up Face Painter and draw more stuff onto the screen. Those included score and the ball and power up spawning alien. The picture looks quite funny, but I am really happy with how I progressed drawing the picture. I am no artist, but it was good fun.
After finishing off the loading bitmap, I needed to have something for it. A loading tune. I load up the DMC V4.0 and compose a tune. Unfortunately my loader tune didn't really suit the theme for the game, and I saved the tune for a future production. So I worked on something more happy, like with the rest of the game. It was 90s techno/trance/happy hardcore, you name it :)
The tune is finished, I now have to port all the data to my 64TASS and generate a picture linker, before I do the last bit of the project, the disk and digital tape mastering. After building the raw versions of the game project and the picture linker. I built everything with 64TASS and crunched all of the necessary files with the Exomizer, with no decrunch effect option.
Next I prepare the files for the tape mastering stage. I load up my fun Tape Master Pro V4.0, edit the loading scroll text, and then made a tape mastering D64 (just in case people want to make their own free physical copies of the game onto a tape or something like that). I then prepare the tape master. My master tape for recording on threw red border load errors. Mind you, it is a very old C90 tape, which I used many times. As an alternative I used the "capture save to tape" option instead. The loader worked.
Finally the game production is finished and ready to be submitted to Retro Programmer's Inside. The game will be publicly available
after the deadline of the PONG 50th Anniversary challenge, on
20th June 2022.The web site is
https://richard-tnd.itch.io/poingultra
