Let's bounce

Saturday 13th August 2011

I am feeling afresh from my 2 week break in Somerset. Now I am ready for some more programming and music composing. On Thursday (Although I didn't mention it in the blog) I have been drawing some test graphics and sprites for the "Horizontal scrolling platform framework" for the 16KB cartridge game for the RGCD competition, which is currently in progress (And I am aiming to get it released down there in November). I also designed a map for the framework. Looks very basic and sort of rubbish graphics, but well, it's not the actual game graphics for Woolly Jumper. As Shaun's working on those :)

Today I felt like doing some more programming on the platform scroll engine. Although on Thursday I did add the new map to the project, I decided to update the scroll engine slightly. It appeared that I was using the KERNAL IRQ vectors, using #$37 as the $01 value. Because this was limited. I decided to switch off the basic KERNAL vectors, by simply changing the value of $01 to #$35 and then I changed all $0314 and $0315 vectors to $fffe and $ffff. I also add pointers to $fffa and $fffb to disable the RESTORE key from crashing the program. As soon as I was happy with the interrupts, I added an extra interrupt in which uses a standard multicolour for the water, and also a different colour scheme for the platforms. I made the default map colour to use a red scheme. Okay, not really bad. :) I tested the scroll and the scroll seems to work well.

There appears to be something missing. Those of which are SPRITES :). I imported the test sprites into the source code, as raw sprites. Then I got the sprites to display on to the screen. Well, just the player sprite for now that is :). Next I worked on the joystick read routine, so that the player can move up/down left or right (no shooting yet). Once I did that, the next job was to program in the self-modifying Sprite to background collision detection. So I check the value of the character sets which were being used for the top of the platform. The basic idea is to test to see if the player touches any part of the upper charset that represents the platform (anywhere on screen). If the player touches it, the sheep will flash until it is off the background.

After testing the routine was working, I programmed some additional routines that will make the sheep jump continuously. So that I could get the jumping slightly more at an accurate level. After a lot of tweaking with the jumping routine, I altered the joystick routine even more and got the player jumping and falling perfectly. Finally I added the moving aliens (Which still require a variety of movements, which will be implemented later on this week.) I also enabled the player to be able to fire bullets as well. After assembly of the framework so far, things are starting to take shape quite nicely. Enjoy the video! :)

Let's go Psychedelic ... Baaaaaah!

15th February 2011

The past 2 afternoons, I have been working on Sheepoid - again :). I think so far the game's coming out quite nicely. Yesterday afternoon, I was working on the end part for the game. To build the end, I captured the field at the bottom of the screen and turned it into a straight field, without the upwards field from level 1. Then I saved the colour and screen data of the modified field.

After that was done my next task was to program some imaginative ending in a style of Yak the Hairy. Well, I could not really think of much of an ending and opened my imagination. Caught in the world of psychedelia. I decided that I had no option but to do an ending where there's a washing machine, someone throws a brick into it while the wheels are spinning and then self-destruct. Nope. I could have done that I suppose. Nah! What I really done was based it where a space ship lands back on to the field. The sheep jumps out. The space ship takes off and then the rest of the ending - a big surprise. I shall not tell you, but it does involve some hairy beasties :)

Today I decided to redesign my front end and implement it into the code. The first thing I did was remove those horrible looking thick raster beams. Recreated the title screen logo. It looked too much like 1985 or something like that. There was also too much flashing, so I decided to do away with some of it. I added an extra raster split and programmed a routine for the top scroll text. I put the flashing text on to the PRESS FIRE TO PLAY message. The top scroll was made for a purpose. After playing Revenge of the Mutant Camels and Sheep In Space, I decided to base the high score table on typing silly phrases of 40 characters. Just the way how the great Yak did for those two games. I also added a scroll text which scrolled the high scores across the front end slowly.

The worst part had come for the front end. I wanted to get rid of those horrible colour bars and replace them with something that would look much nicer. Any guesses? Yes, that's absolutely correct, demo-style raster colour bars. Glerk! They're easy to program into the raster split, but the worst part of it for me was timing the darn things so that they are straight. So I spent about an hour or so fiddling around with the timing tables and come up with a nice looking front end.

The last part I did today was updated the music using Goat Tracker. I wanted to make a modern version of the title screen tune for Sheepoid, as just using one sawtooth instrument was so 1984. So I added a few leads and also some drums (Oh no, Master Bayliss is going to put some techno/trance style beats to the production - gibber!). Then I altered the notes to play a rock-style tune for the title screen. No techno/trance for a change. Then I imported the remixed version of the sawtooth tune into the title screen code. It turned out very well :)

Trashing time.

Sunday 3rd May 2009

I have been a bit busy today preparing some stuff for Trash Course, now that Thorsten (Sledgie) has showed me the final BETA of the game. It was time for me to do some sideways SEUCK enhancements. Well, not quite. I booted up DMC V5.0+ to make the in-game and title screen music a bit longer first, and sound better. Seems to have worked fine. Now that I was happy with the music, I decided to use the DMC V5.0 packer and relocate the music to $9000. How lucky I was that although 4 or 5 tunes were in the same music file that the compressed music file did not go over $2000. Brilliant.

The next thing I done was loaded in Thorsten's snap shot of the SEUCK game, and then I saved the SEUCK game as a finished game from the SEUCK menu. Then I loaded the finished game from BASIC and did the usual SEUCK cleaning and hacking technique (So that the menu was completely wiped away and that there was more room for spare memory. Especially when I get round to working on the new front end for the game.)

As soon as memory was filled with zeroes, I took a look at the Gold Quest 4 waterfall animation hack that I did, and used the same technique to get the game's waterfall animated. Then I saved bits of the 2 SEUCK data (Memory $0900-$6600 and also memory $b6c0 - $ffff as those were compulsory for the game, especially that at $6580 I added the background animation routine).

Now that was done, I needed to sort out a new char set and also D-Flame/Blazon/Crypt's logo. So first of all, I took my font from my old Square Pit 64 game, which I wrote in 2007 for the Forever party. Then I used GangED to convert D-Flame's picture into 3 files (Bitmap, colour RAM and Video RAM). Then I painted sprites for the game options section for my new front end.

After the graphics were sorted out. I created a folder on the PC and converted the C64 files (SEUCK, music, graphics data, etc) into the new folder. After that was done, I copied the cross-assembly and compression .exe files into the project file and got started with programming.

The first thing I had done was a simple test file. Basically, test SEUCK to see if it will decompress and run with a hacked routine that adds the in music to the game. First, this did not work because the first half of the SEUCK game data file was at $0800 instead of $0900. Doh, very silly of me! After correcting this, and crunching again the game started fine with music in the background and also animated background. Brilliant. I am glad that worked.

Now it was time for me to program the main front end. First of all I did the text data (Presentation lines, scroll text and high scores) and then worked on with the main code for the new front end. I imported all C64 files into the source files, then I programmed routines to display the colours of the logo. I also programmed 3 different splits. The first split was for the bitmap logo, which is about 6 or 7 chars high. Then another split for the still text and the last split for the scroll text. Once that was done, I worked on routines that will do the usual Richard Bayliss colour washing technique and also I programmed a routine that will change page after a certain amount of time. One page for the main credits and the other page for the high score table. Colour washing routines change per page as well. I was very happy with this result although still unfinished, because I have a Get Ready, Game Over, High Score entry and also end screen to do.

Tomorrow is a bank holiday, but I wont be doing any programming tomorrow. I'm thinking about digging out some old C64 tapes and playing those. Like, Armalyte, Blazing Thunder, etc.

Stuck in the Amazon - Episode 2

23rd March 2009

If you remember a few weeks back, I did a new front end for Last Amazon - Special Edition, but yesterday I received an E-mail from Kenz that the Special Edition could do with a new and better front end. So he sent me a mockup up of what himself and Alf would love to see for the new front end. Well, it seems I have another job to do so yesterday evening I got started on it and then felt a bit tired and called it a day.

Today I did loads of programming for this new front end. I was originally scratching my head wondering if I could get anywhere to matching Kenz's example. I estimated the number of raster splits that would have been required for the title screen for this game. It turned out that I needed 10 of those. So I made some test splits (Border colour splits) to work out the areas for where the splits lie, and where I should change the font for the text. Mainly because the text is mixed with 1x1 characters and also 2x2 characters.

After I done the splits, I worked on a few other routines, for example a routine that will the normal SEUCK title screen, so that whenever RESTORE is pressed or the player quits the game it will jump straight back to the new title screen code, not the old SEUCK title screen. Then I added the scroll text, with the colour detail. Then I programmed the options that gives the player to chose between 1 player or 2 plays, and to choose whether to have in game music or sound effects. I tested the front end. Looks very nice. I shall now send it to Kenz :)

Enter the cheetah!

1st March 2009

I read my emails and one of the messages was from Kenz, about the new front end for The Last Amazon that I sent him yesterday. There were a few things missing. I had forgotten to credit him for the logo and also I did not add the Last Amazon's eyes to the end of the fading text. So I worked on the front end a little more and added the missing elements. Now I tested the front end. All was okay, apart from the eyes. So instead of using the !SCR command, I used the !BYTE command, and set values for the eyes chars and .... it worked!

Now the front end (as far as I know) was finished, it was then time for me to add a game over routine for after the last life of the player is lost. Kenz came up with a great idea for the game over sequence, which is to have the Last Amazon running across the screen, and then have some cheetahs chasing after her (Din-dins for the cheetahs). So I ripped some sprites from the game, and stored those to $6c00-$6d00 and imported them into the game over source. I then programmed the game over screen in ACME cross assembler, making new interrupts and sprite expansion routines. Once I did all the programming for the end screen, I bolted it to the SEUCK game and tested it. The game over sequence works nicely.

For the final stage of this game, I programmed a small end screen, which shows just yellow text, using the 1x1 charset and linked the ending to where the SEUCK game scroller loop routine was. For the final test, I played the whole game in cheat mode to see if anything was wrong. It seems that everything was fine. Hopefully another Last Amazon front end finally finished. Finger crossed!

Now that was done, I dug out some tunes for The Last Amazon 2 (I will be doing a new front end and enhancements for this game when the first Last Amazon game has been given the OK), and relocated those. Then I loaded up the Last Amazon 2 SEUCK game and added the music to the game, and compressed it with Exomizer, disabling the effect when uncompressing the file and then I put both Last Amazon games on to the .D64 and sent it to Kenz.

I also could not resist playing The Last Amazon 2. It is another of Alf's memorable classic SEUCK games. Alf made many excellent SEUCK games with the great SEUCK editor. I have played many of Alf's classic SEUCK games in my time. I used to love games that were in the Cops series, and also Archetype was one of my all time favorites.

Once again in the Amazon

28th February 2009

Well it seems as if I have been rather busy on the programming side of things today. Kenz has sent me a .d64 with the enhanced version of The Last Amazon. (See his blog here) The game sure was cool with bonus weaponry, and also the animation of the flowing water was excellent.


Kenz showed me a .gif preview of the type of Front End he would like for this game. It seems to me that he wants a very simple front end with a bitmap logo at the top, a 2x2 charset in the middle of the screen and 1x1 charset at the bottom of the screen. So I took all of the main SEUCK game files , relocated the tunes for the game, and also the other bits of data and created an ACME cross assembler project then I worked on the main code and compressed it, and my result turned out the same as what Kenz expected on the the .gif image example he showed.

Although Kenz did send a text file for me to add to the message lines, I was unable to add the eyes graphics, and numbers, because the text data was being used as !SCR commands in ACME cross assembler. So some of the things had to be left out! After all programming and testing, it seems that I have got a nice result!

Lost in the Amazon!

22nd February 2009

Today I have been busy, programming a new front for a Psytronik software SEUCK game. I was given a .c64 image one of the games in the The Last Amazon series. Because I am not all that comfortable with CCS64, I decided to make a .tap of the Sideways Scrolling SEUCK game (Left version as there was no right scrolling version) and then save i to the .tap image.

After I saved the SEUCK game on to a .tap image, I loaded the .tap into WinVice which took some time to load - the stripes are strange? I thought SEUCK used multicoloured stripes like Novaload originally did.

After the game loaded, I filled unwanted data with zeroes (Between $6580-$b6c0) and edited $54EF from LDA $8000,y to LDA $5000,y so that the enemy bullets in the SEUCK game will fire on a random basis. I created a work disk and saved 2 separate files for the SEUCK game. From $0900-$6580 and $B6C0-$FFFF.

Next I loaded a disk with a few different files which Kenz supplied me. The disk contained the logo files, and loaded up the Vidcom paint image and saved the image as three separate files on to my work disk and I also saved the 2x1 charset on to the disk as well. Then I drew some sprites using Faces's Sprite Editor.



Now the next thing for me to do was to extract the title and game music by WAZ, from the very first Last Amazon game (Which was suggested by Kenz that I should use this music for the front end of this game). So I saved two separate music files in Voicetracker/Music Assembler format. Then I loaded up the Dutch USA Team Music Assembler and relocated the tunes to estimated possible locations for when I write my new front end for the game.


Once the music was saved, all I had to do was prepare my cross-assembly project, by making a new folder and put all the C64 data into that folder, along with the and also the ACME cross-assembler and also the brilliant Exomizer cruncher.

Now that all files were prepared, I opened Relaunch 64 and I did a test build of the game, by linking all C64 data into the source, using the !bin "filename.prg",,2 command. So as a small test I entered the two SEUCK files and compiled the source then used the Exomizer to compress the data down and tested it all in WinVice.

It seems that the SEUCK game worked, so now I linked all C64 files to possible locations in the source and got ready to program my new front end for the game.

The first thing which I had to do was make some source files for the scroll text and also the front end text. After that was done, I worked on a once at a time run routine. This is where defaults will be set on the title screen for the very first time after decompression had finished. Next I added a routine that turns off all interrupts and a delay routine, so when game is over, the title screen is delayed for a very short amount of time.


Next I added a colour and screen routine, for displaying the colour data for the title screen text and also the logo's colour data. Then I worked on with the main IRQ interrupt routines. Before I did this, I switched off the KERNAL by setting #$35 at $01. This allowed me to use higher memory after $a000-$ffff, except for memory between $d000-$e000, which obviously needs to be used as POKE storage lines anyway!

Now I programmed the raster interrupt init routine. Usually I use the KERNAL $0314-$0315, but this time I used something more complex, which was $FFFE and $FFFF. This made IRQs longer, but I did not need to use KERNAL.

I used 3 IRQs to make 3 raster splits. The first one was for the scroll text, the second was for the bitmap logo and the last one was for the still text. I had to fiddle around with the charset values, so that I could display a charset that was at $7000 while screen memory is at $7c00. I managed to succeed to display the logo and the static 2x1 text.

After the success of the splits, I was programming the 2x1 scroll text, until I came across a problem. After assembling and compressing the program, no scroll text displayed. There was a problem there. I was scratching my head wondering what was up with the routine. Well, the routine was correct, but the scroll text was being pasted at the wrong screen memory. I used the $0400-$07e8 screen RAM instead of the $7C00-$7FE8 screen RAM. Hahahaha, how dumb was that? :oD. After I changed the scroll's screen memory I got the text to tick along the screen. There was no smooth scroll, but I managed to fix this problem by updating the bottom split, so that $D016 was run by the scroll control code.

My next step was to add and position the sprites and expand the sprite positions. So I used the typical software sprite expansion mode which I used for many of my games and programs, by ROR-ing $D010 as usual. I got the sprites to display, so now it was time for me to do some functions for the sprites.

So my next job was to program the options routine. This had to be done where the joystick direction from either joystick port can choose the number of players or to choose music or sound effects, pressing fire will take the player to the game. This was done by creating some labels and routines, that could display the correct sprites that correspond to the option the player selects. There is more to it though, because as well as sprite options, I needed to program the functions for each option, by building some extra routines. Just simple pokes really.

Where I had to program the in game music function. I had to put BIT routines where the SEUCK was playing the sound memory for the game sound effects. I also had to add a poke that would initialize and play the in game music, without being interrupted by the sound effects. When I tried this, the routine unfortunately crashed. I found out where I went wrong here. I was POKEing the wrong address, which was somewhere in the SEUCK's IRQ memory. That was bad! I managed to fix the routine by using the correct address to POKE for initializing the in game music.

The sound effects bit was similar to the in game music method, but I had to restore the correct poke values for the where sounds originally had BIT next to them and should be replaced with STA only for sound effects. This worked successfully.

The only thing that was missing in the game options was the player options, so I added some routines to select between 1 or 2 players by using the standard SEUCK player mode pokes. This worked a treat, and I was happy with the final result.

To end it all, I added the typical Richard Bayliss colour wash routine on to the scroll text, so that there is something interesting going on in the front end. Hahahahaha.

Now all I had to do was have a quick test to see if the game is working. Well, seems it is working at the moment. After game was over, I decided to test the whole game to see if all works. Well fantastic news. The game works, no crashes or missing sprites. Fantastic!

Now I shall send it off to Kenz to look at and also pass to Alf to see what he thinks of the new front end bolted to his magnificent sideways SEUCK game.

A new intro

21st February 2009

As well as my normal C64 web site, featuring my own game productions. I have finally built up a blog page for anyone interested to see some of the things that I get up to and what I have been doing as well.

I have been doing a bit of programming this morning in ACME. Well, I did originally start is a few days ago. About a few weeks ago, somebody had emailed me a TND logo, so I decided to program a new TND intro, using the ACME cross assembler. I had a few slowdowns with this piece of code, due to making little mistakes with the raster time. I even had crashed the C64 by making a typo error with the 2x1 scroll text display routine. After the typo was fixed, the intro finally turned out pretty nice. I might use that for any future games, demos or utilities I write :)

Here's a video of the intro in action (Recorded in WinVice and converted to MPEG)