After the success of Sub Hunter. We are very proud to get working on yet another new on-going game project for the good old Commodore C64. This time it is a game called Up In The Air. This game probably will not take as long as Sub Hunter, providing that I know what I really am doing and yet again it is going to be another pretty busy production.

So then what is this game all about? My plan is that it is to be a horizontal scrolling shoot 'em up game which Andrew Fisher had passed over to me. It was a game originally created using the Sideways Scrolling Shoot Em Up construction Kit. I received this title to get the idea of what this game is all about. Basically the game is to be a horizontal scrolling shoot 'em up, where you control a toy aeroplane and you have to blast enemies (Different types per level) down to score bonus points and fly over balloons so that you can burst those. You'll be able to see what Wayne is on about by taking a look at the SEUCK preview of the game.



However, Up in the Air is NOT going to be a SEUCK game when it is finished. Therefore I will be programming this game in ACME cross assembler on the PC and probably will feature music and sound effects also composed by me, unless someone else wants to have a little go. This project will be commencing in February 2009 and will continue until it is finished. The game should not take as long as Sub Hunter because I have a basic idea of what the game is meant to be all about, but plans are that graphics will need to be more enhanced and possibly multicolour as well. There might be power ups, bonuses and other things too.

28th February 2009 - Got some graphics. Well about a week and a half ago!

I have been browsing through some of my e-mail, which had an email from Andrew Fisher about graphics from Wayne (Alan Cartridge) Womersley. The graphics were created using the Firebird Graphics Editor by J.Fox. Now that was handy because I also own the tool as well and it is hell of a good C64 utility for creating graphics and maps, without having to use block and map data. This is mainly because I am not all that familiar with blocks and map programming. Maybe I should read some more information about it :o) Tile compression methods maybe.

Below you can see some of the sprites. Note: Not all sprites are showing on this page because that would spoil things for you wouldn't it? Hahaha, yes. :o)



.... and now for the 1- screen map (Upper screen and lower screen) :o)

Wayne has mentioned to me about the game graphics concept. Here is what he has said to me:

It sounds to me like it is going to be another Sub Hunter style of game. OMG, not another one ;o)

12th March 2009 - A bit of preparation and programming (Richard)

Since there was nothing good on television and I had nothing else planned for the evening, I decided to get myself started with the game project. I got the games graphics disk, and loaded up the cloud graphics that were done with Graphic Editor by Firebird Software. Then I used the Action Replay cartridge to save all the sprites, the game's charset, and the full screen data. Then I made my own folder and imported all of the .PRG files into the folder as well as copied the ACME cross assembler and decrunch programs.

Once all the .PRG files were imported to the folder called, upintheair. I loaded up Relaunch 64 and then started making the main file for the ACME Cross Compiler. The first project file (To be compiled) was a general building source, that would put all binary data (the .prg files) and imported source code into the project, ready for compression. Then I can use PuCrunch after compiling/assembly is successful.

As soon as the binary data source file was ready, it was time for me to work on some assembly code for the project. The first bit of code I added was to turn off the Kernal and also deactivate all existing interrupts - This will be future use for when I program things, such as the front end later on after the main game has been finished. Next I added some routines to clear the screen using the value of 32 to fill the screen with the spacebar character. Then after that I filled the screen with the data from the graphics binary file into the source code.

After the screen data routine came the initializing interrupts routine. Since I don't need to use KERNAL routines, I decided to use the standard non KERNAL interrupts, by setting the $001 value to $35 and the interrupt vectors were stored at $FFFE and $FFFF. Like I did with Sub Hunter, I had to make some multiple interrupts. Six in fact!

Now the interrupts were ready, it was time for me to test the source so far. So I compiled the source, compressed it with decrunch and did a test run of the compressed file in WinVice. Seems the program did decrunch well, but unfortunately the IRQs were not working. I realized what the problem was. It appeared that the IRQ INIT routine was missing the LDA #$1B : STA $D011, which was vital for my interrupts. The good news is after that. The routine worked. All I had to do was add the coloured splits for the testing (When it comes to doing the smooth parallax scroll routine).



It was time for me to do some smooth parallax scrolling. So I added 4 subroutines that would scroll the cloud chars and then if at the first column of each char row, the current char in the first column, gets copied on to the last column in exactly the same row. At the moment the scrolling was rough, but once I added new values of the C64 VIC HSP (Vertical Scroll Position) inside each split, we had a very nice smooth scrolling parallax of the clouds. A 4 layered parallax in fact.

Now the parallax scroll has been done, I shall work on adding the player and also some enemy sprites into the game. Hopefully I should be able to program some sprites into the game and have them moving around some time this weekend. Or maybe not. Depends what I am up to really.

13th March 2009 - Wayne's bit!

5th June 2009 - Wayne: Sprites 'n stuff

Not much to say this time, All I have done is work on sprites recently, I'm find it easier to focus on one set of graphics at the minute. I went home from work Monday night after whining to one of the girls at work that I had no ideas for new sprite enemies and promptly knocked up two new enemies!!! I haven't done any work on the backgrounds for quite a while now and I also need to update the clouds, the plan is to have a variety of different cloud formations that appear to give the player the illusion of a constantly changing background. Erm, Don't know if I should have told you that but I did, so there you go!!!  Meanwhile I can slowly seeing progress in the sprite graphics, I haven't tweaked anything for a while, which is a good sign. It dawned on me this morning I do need to draw a death sequence for the main player's plane. Also Im doing a feature or two for Commodore Free, to be honest Im not the biggest fan of typing  but I am going to be reviewing Fortress Of Narzod(?) what a brilliant game (I agree too Wayne.) , I really like this game! I've sent an Email Richard a couple of suggestions for enemy movement for the game today too. Bye for now!

This is a snapshot of the awesome game C64 version of Fortress of Narzod. This game is public domain software and can be downloaded from  here.

6th June 2009 - Richard: Some graphics and outstanding entries (Oops)

It has been a long time since I last added something to this project diary. Well, not done anything new yet. I took a look at the graphics, which Wayne did for the game and I was more happy with what I saw this time. I was extremely stunned by the amount of hard work, which Wayne done with this project behind my back using Firebird Software's graphic adventure. But I feel that the text chars should be somewhat different, but at the moment that is least important to do. Andrew Fisher also came up with some ideas of how I should work on the game's parallax (Sub hunter style) scrolling engine. The concept is basic, but would be appealing to the game project. Andrew suggested I should add a routine that will randomize the cloud types so that instead of the same clouds for each section, we get random clouds appearing. Sounds pretty good. Sadly I am not ready to program the game yet but I should hopefully work on something for it later on this week. I been messing around this week with Nyaaaah! 11, adding it to SEUCK redux. I really should stop messing around with making my old SEUCK games better, but I just could not help myself.

And now, some graphics examples done by Wayne. :)

Below here, you can see a little example of the intro screen, which probably might start where the player's plane will take off into the air.


Now here is a snippet of level 3's graphics. Clouds, mountains and trees. Welcome to 1985 heheheheheh.

  Now a few sprites. We don't want to give too much away do we? Nah!

Finally, level 5 - Flying in the darkness


13th June 2009 - Richard: Cue player and bullet
It has been a long time since I last did some programming for this game project. The last time I programmed something was way back on 12th March - Now that was hell of a long time don't you agree? I guess it is because I ended up with some other projects to do for other people, i.e. tape mastering for Psytronik Software, Trash Course for Inferior Software and also the start of Ultimate Stunt Boat Challenge (Which might have to wait until later on in the year as I am concentrating on this project).

Before I continued programming this project, I made a batch file which could do some assembling and testing (if assembly from ACME is successful or not). I created a batch file using notepad with the following commands:

@echo off
color b
cls
echo UP IN THE AIR (C) THE NEW DIMENSION AND ART RAVERS
del air.prg
del airtest1.prg
echo .
echo ASSEMBLING ...
acme code.a
if not exist air.prg goto error

echo ------------------------------------------
echo ASSEMBLY SUCCESSFUL ... COMPRESSING DATA
echo ------------------------------------------
exomizer sfx $4800 air.prg -o airtest1.prg -Di_effect=2 -q -n -s "lda #$00 sta $d011" -f "lda #$1b sta

$d011"
cls
if not exist airtest1.prg goto error2

echo ASSEMBLY AND COMPRESSION SUCCESSFUL:
echo ------------------------------------

goto execute
:error2
cls

echo .
echo COMPRESSION FAILED ... PLEASE CHECK SETTINGS IN T.BAT ...
goto end

:execute

echo EXECUTING: WINVICE (CLOSE WINVICE TO EXIT APPLICATION)
x64 airtest1.prg
goto end

:error

echo .
echo ASSEMBLY HAS FAILED ... PLEASE CHECK CODE ...
goto end2
:end

:end2

I created this batch file to make things quicker for assembly and compression, etc. The batch file also shows when there is an error. If assembly and compression is successful, the WinVice application activates and load + decrunch the packed source ready for testing.

After making the batch file I decided to work more on the game, but still using Wayne's first version of the cloud graphics (As I will work on the level graphic data near to the end of this project).  The first thing that I done was the demo credits screen, which is just a simple text display showing the credits and then asking the user to press fire in joystick port 2 to play. Then I continued with the game engine's code. If you remember last week, I had the cloud parallax scrolling, based on Sub Hunter? Well there were colour rasters that were used for the test mode. I disabled those and then I worked on with the player's properties.

First of all, I needed to set up the default positions, etc. for all of the sprites. Because for now I only want player 1's sprite, I set the visible positions for the player's sprite. Then set the colours. After that I expanded the colours of the player and then animated it. As soon as all those were done, I got the player to move around the screen, and then fire the bullet sprite under the condition where if the player bullet is offset (not on screen), the player can shoot another bullet.



Finally I imported one of Andrew Fisher's old tunes (Which I remember from Commodore Scene issue 31), called "Springtime" into the game's source code and tested the program. The player can move and shoot and music plays in the background.


17th June 2009 - Cloud Nine

I got an email from Wayne, with yet another diary update. Here it goes:

Aaargh, This week I am off work which should mean computer work but unfortunately am helping my girlfriend  with house improvements- the living room looks like a bomb site, we have a skip coming at the weekend and also add to this my parents are having there heating system in there house stripped out of all there rooms and redone and they need my help too, so I am having to empty there house out as well as Carols-oh my god what a bloody nightmare!!! Today I got to the library and read that Richard had done a playable preview, this was the news I could have heard, we went to Haworth yesterday and I spent 2 hours stripping the attic walls at Carols when we got home, I was sweating buckets I tell you, no sander just sand paper and my bare hands( as opposed to my feet which I use to stir my tea - giggle ).  I did manage to do some new graphics last week which included enemy planes and I tweaked one or two baddies, but generally things are looking nice, I also decided Saturday night that I should knock up a collection of clouds for Richard to grab from screen memory and use within the game, with this in mind I thoughtfully and imaginatively knocked up a collection called - Cloud collection 1, Ha bet you didn't know i was gonna call them that did you? I may do some more to make sure there is plenty of variety in clouds and I also intend when I get time to sit down and play about with some on-screen colour combinations, And Finally I wish to do some BIG enemies for the end of levels!

Richard's bit:
No, no, no Wayne, it is not a playable preview yet. I worked on the preview last week, but all that can move at the moment are a couple of things. Just the player and also its bullet. Hopefully I should have the enemies moving this weekend mate. I captured the new screen and colour graphics  and charset and imported the new cloud graphics into the game's code. This looks much nicer, but some more work still needs to be added to the clouds scroller, as we don't want the same old screen wrapping method all the time. We want to vary the clouds. But before I do that, I'll just work on the main game attack waves this weekend.



Thursday 2nd July 2009 - ???

Greetings fans, today is the 2nd of July, thankfully things in my "real life" are beginning to calm down now, we filled the skip at my girlfriend's house. We've also got the plasterers round at the moment. My parents house is also done and I've just about finished sorting all the things I took out to the garage at my parents (yes all my computer stuff!) I brought my work in progress disks back into the house this morning for all my other game projects: Camels In Space 2, Bouncy Cars, Wizards And Warlocks 2 etc... Anyway enough blah dee blah, Earlier this week I retrieved my UP IN THE AIR disks from my girlfriend's and brought them home. I've done some more work on the game, as mentioned I decided to do some more clouds for the game to allow for more variety in clouds, and yes I did call this Cloud Collection 2!  I did what I said I was going to do and created two new colour schemes for the levels too, very pleasing! I also decided to update Level 3. Andrew Fisher had mentioned to me that the trees were not quite up to scratch.

 I sat down and after quite a while of fiddling with the graphics they seemed to be improved!  I sent copies of these off to Andrew Fisher who should have them right now ROYAL MAIL permitting, I also found a very old disk from either 1995 or 1996 with CITY BOMBER work - yes that's right WAYNE of ART RAVERS was going to do graphic work on this epic game, fingers crossed Andrew will kindly pass this on to FRANK GASKING of GTW site, god I love that site and Frank Gasking is ace, I've met him a couple of times at computer shows really nice bloke :-> ! I also sent preview copies of the game's levels to Jon Wells & Jason "KENZ" Mackenzie, Kenz very kindly wrote back yesterday with some very kind words and advice ( yes I will improve the graphics for Level 10 Kenz! ), he also said he would be interested in releasing the game through his Psytronik software label - Wooooah! No pressure on me and Richard to make a fantastic game then ! :-> A big thank you this time to Rachel at work for being so kind and helpful with comments and suggestions for the game. You are a star babe!!!

4th July 2009 -Two week break on holiday (Richard)
No work done today. Why? well, I am going on holiday until 18th July of course. Therefore further programming will have to be after 18th July 2009. Looking forward to my break in Devon. :)

26th Jul 2009 - Introducing the enemy parameters (Richard)

When it comes to programming games, logic thinking is desirable. We can't keep moving objects one direction all the same time can we? Therefore to make this game more interesting and exciting. I have decided to so something more interesting. You may have discovered already that most of my games always used the same "Sprite going straight across the screen in the same direction and wrapping to another place - going the same direction as before” technique. Well, this is rather a monotonous thing which has happened in many of my games since 1999.

Since this has been happening all the time. I have made a big decision to think more logically about how I would want the enemies to move and also some interesting things that I could try to get those enemies moving in a more exciting and accurate manner. So that this game gets a more positive karma, unlike some of the rubbish I churned up in the past. What could be the ideal solution to this issue? Labelled variables of course. So today I generated some labelled variables to get me started. I didn't feel like doing the main programming for the enemies today, due to lack of motivation. But later on this week or maybe next week I could continue with the main programming side of this project.

2nd August 2009 - Come Fly With Me (Richard)

Well it has been yet another busy afternoon, and still a lot of work is to be done before I can get a fully working level. Last week I was working on preparing the labels for the enemy parameters. Well, today I have done some programming, using parameters and it took a long time to prepare and program, but it was worth the Sunday afternoon for 3 or 4 hours or so.

First of all, I created the data tables (!byte tables) to represent the behaviour of enemy's movement. The movement tables will later on be put inside a timed loop, so that we can vary the enemy's directional movements. Each table will consist with only '0' and '1'. '0' represents the selected direction the enemy moves is switched off, and the '1' represents the selected direction the enemy moves is switched on. For example if I wanted one enemy to move to the left, directions UP, DOWN and RIGHT will be switched off and LEFT will be switched on. Or if I wanted an enemy sprite to move upwards and left, UP and LEFT will be switched on and DOWN and RIGHT will be switched off.

However, I wanted to get this routine working in a correct possible manner, and it took lines of code to program. I had to make an enemy direction store value, so that the directional table that is switched on will make the active enemy sprite move a specified direction. I had to create a LOT of routines to get this to work properly. Mainly comparing the value of the stored direction. If the stored direction label equals 1, the enemy can move that direction. Otherwise the enemy cannot move the specified direction.  To make sure the enemy could or could not move, I tested each enemy by setting the first value of the 60 bytes for each table (according to the direction I wanted the enemies to move) and then I assembled and test the movement. Fantastic, it worked. Okay, so it is not ready yet, but it was a good start for enemy movements. My next task will be to vary the movements of the enemies, and then get the floating balloons animated.

5th August 2009 - Head on collision - BANG (Richard)

Feels like a holiday after being made redundant last week. Yeah, I know. I am still looking for work, but I also need a break as well :o). So today I decided to progress onwards (and upwards) on this game project of mine. A couple of days ago, Andrew sent me another 2 disk images which contained yet more graphics for the game. I had a quick glimpse at the new graphics that wayne did, and I was pretty much impressed with the work that was done, and the commitment he has made with this game project. Despite me making it a slow start :o) No rush anyway.

Today I have been working on the software sprite to sprite collision routine. Well, there is no point in having a game that will not use sprite/sprite collision otherwise it would not be classed as a game eh? I created some routines that will allow the player to shoot at the test enemies and it works okay, still some minor bugs in the routine, but as soon as I have ironed those out, it should work nicely. At the moment there are no explosion animation, etc. for when the enemies are hit because I want to get everything right first. Well, this is still at its earlier stages.

So then, how did I do the sprite to sprite collision routine?. Well, very similar to Sub Hunter. I created a variable called CollisionXY and created a routine to calculate the XY positions for the sprite to touch before a collision is made. The routine looked something like this as below

;==============================================================================
;Enemy Sprite/Bullet Sprite collision and Enemy Sprite/Player Sprite collision
;==============================================================================

.TestCollision

                lda objpos+$00 ;Player (Sprite unexpanded)
                sec
                sbc #$06
                sta CollisionXY
                clc
                adc #$0c
                sta CollisionXY+1

                lda objpos+$01
                sec
                sbc #$0c
                sta CollisionXY+2
                clc
                adc #$18
                sta CollisionXY+3

                lda objpos+$02 ;Player bullet (Sprite unexpanded)
                sec
                sbc #$06
                sta CollisionXY+4
                clc
                adc #$0c
                sta CollisionXY+5
                lda objpos+$03
                sec
                sbc #$0c
                sta CollisionXY+6
                clc
                adc #$18
                sta CollisionXY+7
               
                REST OF PROGRAM

Now to get the collision I wanted for each enemy. I created six JSR commands so that I could test the player bullet to enemy at a time. I had to compare the value of each enemy (X/Y co-ordinates) with CollisionXY+Value so that I had a positive collision. After setting up the collision values I added some routines that would take the enemy off the screen if a bullet hit it. Yes I know, just a simple enemy disappear routine, no explosion animation quite yet. BWAHAHAHA! When testing the player bullet to enemy collision. It appears that enemy 2 disappeared, but the player's bullet didn't. Oops! Blame the programmer (Ha, ha!). Seems I found a small error in the routine. I used BCC twice when checking for 2 co-oordinates of the X-position for enemy 2. I have now corrected that problem.

The next task which I have done was set up the enemy to player collision, but this time instead of checking one enemy at a time, I made a loop that could check whether or not the player will collide into any enemy, except for the balloon object. Because of this being a test routine, I made it that any enemy that touches the player, will flash the player's sprite's changeable colour ($d027) to show that a collision has been made.Also if the player hits a balloon, the balloon disappears :o) Now that I am happy with the sprite/sprite collision routines. I can now get to work on making an actual Level 1, which will test the enemy sprite's behavior later on this week.

8th August 2009 - Flying through pointers (Richard)

Today I have been working on the test enemy death pointers. You may have remembered a few days ago I have been working on the collision detection routine. Well today, I have decided to add another routine, which can detect whether or not all of the enemies are dead or have left the screen, before we can the enemy sprites. At the moment I have made it that no more enemies on the same come on to screen until all of those are dead. This does not apply to the balloon sprite, as I will be adding this on to the screen now and then via a timer. But that will be later on during the game.

Now that I successfully got all the enemies reset after all are dead. I decided to work on the control of the enemies. Where after all enemies are dead, the enemies will change type, colour, direction and also speed. I have decided to leave out the changing of enemy types and positions for now, as I am more concerned about getting the direction control for the enemies to work how it should. So I created some new labels and some more tables that will control the speed of the enemies, using a controlled loop. Well, that wasn't much of a problem. I created some new variables and a counter variable, which is called SpeedCounter. Before I put a routine to work on the controlled loop, I zeroed the SpeedCounter and then added a JSR (Inside the SYNC loop) to perform a loop and count up to 60 times (As each table for each enemy control  is 60 bytes long) and the table will not go up until after all the enemies are dead. I had a few problems first, where I went a bit wrong with the routine. After I fixed the routine, the enemy behaviour worked correctly with my test values that I added for the enemy speed, and direction values. This is much easier and shorter, compared to Sub Hunter, which I just kept on writing the same routine again, again and again. Thus taking up a lot of memory. And with this project, I have plenty of memory to use.

Memory start for code                                                            Memory finish for code, below. Data table memory.

Thursday 13th August 2009 - Wayne's game ideas (Wayne)

Things are going well with the Graphics, Am still doing work at Carols house( Am currently painting the attic-this will be my computer room when I move in!!! ).  Since last time I have drawn a Gunship as I had intended, also I had a mad rush of late night graphic drawing with loads of new planes and enemies being drawn, in fact the sprite editor now only has 2 frames free. I have added some weather conditions too but I dont want to spoil that for you, lets just say you will be seeing various elements as you progress through the game. I've also gone back ( again ) and tweaked the character set graphics.  I've started to work out the final order for the attack waves too, rather than just have stuff thrown at you randomly I thought it might be nice to see you progress through the game as if you are going through the years of aviation progression. 

To begin with you will shoot birds but then you come up against hang gliders, basket balloons, etc leading up to more advanced weaponry like STEALTH BOMBERS and TANKS etc., I had a discussion with Gary Sutton again at work and he suggested an idea for the end of the game which I have drawn, and I've also added an idea of my own too!  On the music front I am hoping Andrew Fisher could do a ROB HUBBARD ( famous C64 musician, fact fans! ) meets 99 RED BALLOONS type of tune in-game, either that or just have it as a level complete jingle. Also I would love a WE ARE THE CHEEKY GIRLS theme tune on the high score table ( and then I wonder why people think I am camp? Giggle ) (No covers - pleeeeease :oP - Richard). Meanwhile in my real life, I went to Huddersfield a couple of weeks ago, on my way home I called in at Brighouse Computer shop and ended up talking to the guy who programmed McDonald Land for the C64-I kid you not! Am hoping to get his Email address so Andrew Fisher can interview him, I got Nick Pelling's Email for Andrew a couple of years ago so hopefully fingers crossed I can do it again,

might ask him if he wants to do a C64 game with me too!  Also I have started working out the colour schemes for the levels, I reckon if I can do this it will save

Richard some time, have included the first four colour schemes with this entry for Richard.  The plan for the finished game is to have 20 Levels including Bonus Levels, Its slowly coming together now it sup to Richard to do all the hard stuff and make the enemy movements look good-Geez intense stuff-I love it! :->

Thursday 13th August 2009 - More and more information to keep in mind

I had an email on Tuesday, but I did not bother typing anything in this diary, as it was something very small. Anyway here is what happened on Tuesday. First of all I had an email back from Andrew about the game talking about enemy movements. He said that II should take a look at the SEUCK game example and try to implement that. Secondly I also had to remove the ability for the player to shoot the balloons. As in the game, the player is meant to collect the balloons, not shoot them. So I removed some routines that I did not need for this part of the game. So now the player can only collect balloons (Sprite 8) rather than burst them with its bullets.

Well, I may as well reveal some stuff about this game project. So far. I was over curious about the plans of my own about making this game, but Wayne had his own ideas. So, this project should hopefully be easy enough to program and put together. The idea is completely different to what I had in mind with this project. Earlier on when discussing about the project, Wayne came up with SEUCK examples about how the game should work. When I was playing the SEUCK example a couple of days ago, I was surprised to see how easy this project will actually be. Wayne wants the game to play the same way just like the SEUCK example, but the player has to collect enough balloons to advance on to the next level. Should be easy enough.

Wayne also sent me an email today revealing the colour schemes for the first 4 levels. I have made a note of those and will implement them when I am ready to put all of the levels together. It is the main game attack stages I will need to work on first, before I go any further with implementing more levels.

Some parts of the game makes me think that I should have a brain wave for some of the levels. Later levels of the SEUCK example showed enemies shooting on screen, but I need to think this idea through. Should I reduce the no. of enemies that come on screen and make them shoot bullets as sprites, or should I attempt to make a routine that will allow the enemy sprites fire bullets by using chars instead as I can't do sprite multiplexors?. Well, anything is possible. Sprites would be better because of the smooth speed. Chars would be too rough. So if I had to sacrifice one sprite to become the bullet (after an enemy goes off screen or is shot) then that probably might be a possible solution. More of this later. I have to work on the enemy movements before I decide all this shooting business. :o)

Sunday 16th August 2009 - 99 More Balloons (Wayne)

Greetings C64 dudes (and ladies of course! )

Last time I forgot to mention so I will do it this time. While drawing in the sprite editor, I decided it would be really cool to allow the player to choose on the title screen if they wanted to play as a plane or a helicopter, a simple thing but its a nice addition that I thought people might like, perhaps Richard might be able to have slightly different control methods for the plane and the helicopter, i.e. the helicopter is a bit slower and hovers up and down when the player does not touch the joystick and maybe it could have slightly different firepower?

I think the best way of choosing between which ship you fly would be by choosing with a joystick on the title screen like on the Sub Hunter title screen when you choose between music and sound effects. I have also tweaked Level 6. On Thursday, the colour scheme was nice but I needed to add some new graphics for the cacti (?) At the moment its just a case of me going through everything I have done and choosing the colours to go in the final game.

When I have sorted that, I will start doing some new levels. I just can't wait! I also need to draw a bitmap screen for the title screen/loader and work out what the title screen is going to look like.  Oooooh, also I sent the latest updates of the character set and Sprite Editor and a new version of level 4 ( I think?) to Andrew yesterday.

On a personal note Richard got back to me and said I can't have 99 Red Balloons in the game for the theme tune cos of copyright issues! Lets just say I am a bit annoyed about that, I never thought about that-DOH! Maybe the guys could do me a custom version with that music in HA HA HA!  It looks like I will have to settle for something "safe" for the finished version, although I do like the current music running in the demo I possess, its an Andrew Fisher composition!

Richard's bit:

16th August 2009 - Up, Stop, Down, Stop, and away we go! (Richard)

Well, Wayne has been working hard on game graphics again. Pretty good job that it is not me doing the graphics at the moment. I'm not all that good on that. However, when I emailed Wayne, regarding the music. I did not say that we can't do a C64 version of 99 Red Balloons. I said that I did not like the idea about adding a cover tune into a game if it is going to be a commercial game, due to music licensing and copyright issues. I am glad he likes the current music in the later game demo. The music was actually composed by me (Called "Secret Man's Search for a Star"), not Andrew. But I will look forward to Andrew's music for this game project.

I have been doing some more programming today. Well, after taking a look at Wayne's SEUCK example, I decided to update the code so that the enemy movements were similar to Wayne's sideways SEUCK example. I thought that this was actually going to be really easy to do. Well, the idea was very easy, but I had a few headaches with the control of the enemy gliders (Probably change those to birds if Wayne wants me to). The general feature for the gliders (or hang gliders) was to use a table of values which are: up, stop, down, stop and constantly move like that. So to do this I added a new variable/label called MoveTimer. MoveTimer is the controlled variable which will calculate the time of the enemy movement or directions. I added an extra JSR routine, which was to operate the MoveTimer variable, and if the clock equals #$32 then reset and  add values from the data table to update the movement and enemy speed. The routine looks something  like this

.TimeMovement
                   lda MoveTimer
                   cmp #$32 ;Count up to 50
                   beq .ResetTimer
                   inc MoverTimer
                   rts
.ResetTimer        lda #$00
                   sta MoveTimer
                   inc SpeedCounter
                   inc MoveCounter
                   rts

Anytime the counter reaches 50 (or #$32) , the MoveTimer is reset and then adds the value of the SpeedCounter and MoveCounter (Read from the byte tables). This made the enemies move up and down. But there was still a problem. The enemies may have been moving up and down, but I may have made a typo error somewhere on the byte tables (up, stop, down, stop) control. I took a look and realized, that the calculation of each table was not equal. I decided to try and experiment a little with the table control routines, and reduced the size of the tables being read. So instead of 55 bytes per table, I reduced it to 4 bytes per table. After a test, the enemies were going up, then stopping, then going down, then stopping to the way they should have moved in the first place. Now all I need to do is change the up/down control table a little for each of the enemy sprites, so that all of the gliders are not moving the same direction at the same time. So I tweaked the tables nicely, and now it works.
Whoa!... Oh, never mind! Well the glider control is working fine, but I will need to set some routines that will stop the gliders leaving the Y-positions of the game screen.

So how can I stop the gliders going past Y positions and avoid overlapping them overlapping the status bar? ... Well, simply enough I updated the up and down positions, to check whether or not the enemy goes behind value #$32 or goes over #$d2, depending on whether or not the sprites are moving up or down. If a sprite tries to go over #$d2, it will stop at position #'$d2 and if the sprite tries to go below #$32 it will stop at #$32. Now things are looking much better.

Now that level 1 is roughly done, (just random positioning for enemies to go, now and then) I thought that the score in the game should be changed, so I updated the status bar slightly, so that the player will be able to score points. So now, I have updated it. So instead of items, it is changed to balloons. Also, level is 2 digits, and energy has been changed to damage. Time is at the bottom and is still 4 digits. Where's the lives counter? Well, at the moment I am not adding this in to the game. The damage counter will act as the lives counter, but it could all change later on before the game is finished. There might be newer ideas, for the status bar below etc.

 Tomorrow evening, I might do a bit more programming on this game project, by implementing enemy explosion effects and also get the score board working, and also later on this week, create the enemy Y-position randomizer routine for any time an enemy moves off screen in any 'X' position (Depending on the direction that it is moving). Also, I shall sort out the scoreboard and also the level time and other routines that should work on the status bar.

17th August 2009 - Relocate, relocate (Richard)

Today, Andrew passed me another .D64 with the Up in the Air project graphics. This time yet more great sprites, and a new version of level 6, which I could implement into the game's code later on this week. Anyway, I loaded up the sprites. So many of them, in fact too many of those. It did not put me off though. I decided to relocate the graphics data and use BANK 2 instead of BANK 1, as that way it would make things much easier for me, as the sprites overlapped if loaded at $2000. So now the game source has changed its memory. Here's what we have so far:

$0800-$1000 - Spare memory (That could possibly be used for extra variables, or maybe additional code for the title screen.
$1000-$2400 - The music (Although if the music is larger, as some music editors players like DMC,  I could expand it more, otherwise, I could add the exomizer decrunch code in this place)

$2400-$2800 - Decrunched screen data
$2800-$2c00 - Decrunched screen colour data

$2C00 - $4000 - Spare memory, maybe for crunched screen data and exomizer decruncher

$4000 - $7300 - Game sprites data (Bank #$02). Wayne filled a lot of memory with various sprites. Perhaps he got carried away here. Heheheh. Still not to worry, that's where I have placed them.

$7400-$7800 - That will be for the actual screen used!

$7800-$8000 - Game charset

$8000-$C000 - Game code. I am not too sure how big the game code will be, but I have switched the Kernal off by setting #$35 at $01. Which hopefully means I can add further code here. Good eh?

$C800-$CC00 - Title screen logo colour RAM data
$CC00-$D000 - Title screen logo video RAM data
$E000- $FF70 - Title screen bitmap data.

Sadly I did not get round to doing the randomizing of data, scoring, etc but I can continue with that later on this week. So stay tuned. :o) Okay. Now for a can of Foster's lager and a spot of C64 gaming! :o) Oooh, nice!

20th August 2009 - Random thinking (Richard)

This weekend I'll be adding some explosion animation and get the score/damage counters working. :o)

24th August 2009 - Wayne

Geez, The last 4 days I have been having toothache I went to the dentist today on my day off, they said please come back at 2.15pm, the pain is blinking unbearable, hope they yank the bleeder out!  Done no work on the game due to toothache, its been hard enough going in to work, I just want to lie down and cabbage.  I might do some more work on Friday night!  Also I don't mean to be a pain but as regards the game story you are supposed to be a world war one fighter pilot like biggles but not biggles for copyright reasons obviously. (I second that - Richard)  I DO like the game legend Richard created " Get ready for the flight of your life" Sheer genius that, I blinking love it! I wonder if JSL would draw a title screen for the game like he did for BOMB CHASE, that would be nice! (We must get the game finished first before we decide about the logo. Because it depends on how much memory would be spare at the end. - Richard)
 

24th August 2009 - Fatal PC problems finally solved  (Richard)

Bah. Don't you just hate it when the PC you are working on breaks down and not power up and you have no other choice but to buy a new unit? Well, unfortunately, that is what had happened to me. Well, that old PC was several years old and to today's standards was pretty crap and slow. Nice to have a faster one, although it was spent with some of my redundancy money, which I was saving up for a years supply of Foster's (Just kidding about the Foster's - honest) . Therefore I was unable to continue with the Up in the Air game project. I am very lucky that I did back this project up beforehand. Maybe I will get somewhere with the project this weekend, now this new unit is up and running :o)

30th August 2009 - Explosive action - crash and burn (Richard)

Now that everything I wanted to install and configure has successfully added on to my new PC, I am now able to carry on with the Up in the Air project. Last week I was going to do some more programming on this project, but because of the PC constantly being slow and unresponsive, then would not power up and died. I was unable to continue with the project. However, I feel very lucky that I did backup the latest update from 20th August, otherwise I would have had to start the entire project all over again.

So what has been happening this time? Well, I wanted to add some explosion animation in to the game for whenever the player shoots an enemy and then place the enemy at a new position offset from the screen. So what I did was programmed a routine which will check whether or not an enemy is dead. If the enemy is dead, then the explosion process starts. How was the death animation made? If the sub routine for the enemy death trigger is switched on , this turns on the enemy death animation routine, otherwise the enemy frame stays as it is (Enemy alive).  The death animation routines are controlled by a pointer, which will increment a value until reached the total number of frames, which you want the animation routine to stop at. Then zero the pointer and unlock the enemy death routine as soon as the enemy has been repositioned offset at it's newer Y-position location. This worked a treat. I wrote one routine per enemy, but after testing. I noticed that the scrolling clouds were messed up. It appears that I have used $7FFx instead of $77Fx for some of the enemies, as the game character set data is positioned at $7800-$7FFF (Which is where it belongs). After I corrected the problem, the clouds were right again. Doh, what a clumsy clot I am :o)

Now although the enemies are dead whenever shot by the player. The player can still keep on shooting at the explosion. That makes the game a bit more stupid. So I should add settings to turn off the Enemy/Bullet collision if the death trigger is turned on for the particular enemy. That would make things much fairer. So now, if the enemy death trigger is not switched on, enemy/bullet collision is turned on, otherwise the enemy/bullet collision is ignored. Pretty good.

Now that the enemy to bullet collision has been sorted out, I can now do the same to the enemy/player collision routine. Now that this is done. My next job is to get the player damage status working. Rather than make a char of the status disappear. I think it would be much nicer if each char of the damage status indicator was green. Then after an enemy hits the player, a character of the damage status indicator turns from green to red. After the damage status bar is fully red. The player gets destroyed. For now (Game Over mode), I just flashed the player's $D027 colour sprite constantly. I didn't like the status bar Wayne did, so I made one of my own, using Cuneiform. :o). Then update the enemy reset positions so that enemy Y-Positions are random, just like they were after they left the screen during movement after the explosion process has finished.

Blowing enemies up!                                                           

So far so good, but before we have a bit of a game here. There are still parts of the game that has not been done yet. For example, the score needs to work, and also the balloons status should be active. So I added a routine to get the scores and balloons counter working, specially for the game, and also the time as well. Now that the clock, the balloons counter and the damage counter is working. We have a game, but the player's bullet is still too fast. I think I should slow that down a bit. So I have reduced the bullet speed from 6 down to 4, much more comfortable now.

My next task will be to update the player death sequence. The basic idea is so that the player will animate when falling and then explode as soon as the player hits the bottom of the screen. I added some values that will lock the game play, so that when the player is dead. It cannot shoot the enemies that are in sight. After adding the player death sequence, I added the Game Over sprites on to the game. Looks more like a game now. That will do for today.

Mayday, mayday, dive, dive, dive ... CRASH!               

Quite a lot of work to be done here in one day. Next time with the project, I'll be updating the collision registers and also adding a bit more variety to the first level, so that there are birds as well as hang gliders for the first level. Also, we introduce a big boss bird the player has to defeat to complete level 1.

NEXT PAGE