Scrolling without S.E.U.C.K

25th January 2016

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

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

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

Darker than Light

3rd-8th July 2014

Back in January 2014. I worked on a SEUCK game co-op with Alf Yngve called "Dark Force". The challenge was originally to get a first release out for new year's day. It failed and got released later on during that month. February/March saw a re-relase of the same game, with a few extra enhancements. Only major drawback was the SEUCK slow-down syndrome... Eurgh!

Now today on 8th July 2014 before I set off to my work place. I am very pleased to reveal the that the final version of Dark Force. It is Dark Force - Redux. The whole game data was imported into the SEUCK Redux frame work, which Martin Piper supplied on github. I also did a lot of additional hard work programming this production the past 4 days. Including re-programming the new front end. Enhancing the background level settings. Here's the overall result.

- Black/Blue loading screen with loading picture and music (Music from the TND intro on the disk version 'Emotions from Heaven')
- New front end with Hi-Score table, as before, but logo had to be carefully downgraded to 3 colour logo mode, due to lack of memory space for bitmaps.
- Slight tweak of an instrument on the front end tune
- Different background colour schemes for each level
- Intelligent enemy fire (Fires bullets in the direction of where the player was last positioned).
- Most important of them all ... No more SEUCK slow-down syndrome

What originally was meant to have been an experiment with SEUCK, turned into a fun 'game inspired by 'Light Force' by FTL.

If you would like to try out the SEUCK Redux engine, then check out:

Martin's C64 Repository on Github

For the C64 game Dark Force, please visit:

The New Dimension - Download games page

Enter the Trap

29th-31st August 2013

Last time, I was working on the main game engine, hoping that everything was working. I was quite pleased with the result of the work so far. However, the colour of the tiles didn't look right on a CRT screen, so I changed the Blue+Purple tiles into Red+Purple. That looked much better. I had a great idea which was to add some kind of effect for every time the player is inverting the tiles. So I drew a sprite which creates a form of a dissolve/fade routine and added routines in the game to make this take effect. Basically, when the player hits a tile that inverts, the second sprite is used to form an animation over that particular tile. Now that I was very happy an impressed with the work done to the game so far.

I decided to move on to something else, related to the project. So I worked on a front end for the game. Unlike many of the front end title screens, where you have a static logo, credits and a scroll text. I wanted to do something completely different. I loaded in JSL's logo for the title screen. Then I converted the bitmap picture into a logo (Charset + Matrix) format. At the moment, this was just a static logo. So I decided to convert it into Swing Logo format. I downloaded Paramount's Shake It utility and converted the logo into a swinging logo format. 

Now I was happy with the swinging logo format. I exported the charset and swing matrix data into the project. Then I worked on the new front end. The 1x1 font was used to display the credits. I programmed in some multiple IRQ raster interrupts into the game's title screen code. Added the screen cuts. Top row of the screen has the first logo. The second row of the screen has the credits, which use the 1x1 charset, the third row has a 1x2 charset, which uses a smooth scrolling text message. Finally the bottom row has the second logo, which swings in reverse. I added some subroutines that would cycle the colour of the logo after a few seconds or so. This idea was inspired by common old-school C64 intros. The result turned out quite nice.

Now what about the game? So far I had 8 levels designed, so I decided to do some more tests on some of the newer obstacles. Unfortunately, for the blob, it stops at an incorrect position, causing the game to mess up. So to solve this problem, I added some simple checks and compared which direction the player was at. If the player was moving a longer distance, I had to trim the move distance slightly for a more accurate position. After I worked on the check subroutine for all 4 of those player directions (Up, Down, Left, Right), I worked on a few more levels, in which introduced the trap switches. If the player moves on to those either the trapdoors will remain closed, or they will all open. The T tile (correct direction) opens the trapdoors holes, and the T (upside down) represented the closing of the trapdoors. This trick worked, and some of the stages (up to level 12) are puzzling. As I positioned trap switches in various places to confuse the player.The result turned out great.

I also did some updates to the music. The in game music high notes part sounded pretty awful to the ears, so I changed the closing melody to the tune. The title screen instrument, which originally used sawtooth, was changed into a pulse ($41) and made the introduction of the tune sound much better. 

The assembled program is so far 10KB and it is going pretty well, and I seem to be progressing pretty quickly with this game. It may look as in the game could be ready for submission bby the end of September this year. Considering the extra free time I have been having recently :)

The Cops Strike Back

9th May 2013

If you remember buying Commodore Force, and ZZap 64. You may have remembered Alf Yngve's Public Domain SEUCK games called Cops and Holiday Cops. Well, you'll be surprised to hear that planned over the past 2 or 3 years, was the "Ultimate Cops" series. In which was to feature enhanced versions of all of the COPS games, which Alf wrote back in time. Well, good news is that the overall project will be seeing the light of day soon with thanks to myself, Alf and Psytronik Software.

I have been very busy the past few weeks (or months) working on this compilation - which should have been produced a very long time ago. Anyway, what did I do for the games? Cops, Holiday Cops have brand new front ends and in game enhancements with music. All 3 games here will be featured on side 1 of the disk. Where as on side 2 is the last ever episode of the Cops series, "Cops the Final Chapter". The story sees Mike 'Mad Dog' McTavish, and Singh 'Big Bang' Kapoor about to be facing retirement. Bad news was that a criminal gang blew up a high security prison, and set one of the most evil criminals 'Maledict I' on the loose.  The commissioner called on Mike and Singh to recapture 'Maledict' in one of the biggest arcade adventures (Split into 3 parts). The game also features additional enhancements such as game options, in game music and also power ups, and background char animation. The overall result gives the game a commercial appeal.

A tape version for Psytronik is finished now. (I think), with a huge thank you to Mase for his awesome loading picture. I did a loading tune specially for this series. Which I feel suits the tape loader pretty nicely. Since the second part of  "Cops the Final Chapter". Although the mastering was complete. I felt that the disadvantage was that I tried to make the tape mastering system *much easier* so that after mastering one main file, it automatically loads the next file. Sadly this method failed as it interfered with the tape mastering code. So rather than just messing about with the code for the tape mastering. I created separate tape masters - which must be loaded straight after the tape mastering was complete (Sorry Kenz). A disk menu for the disk version is still under development, but should be ready in time for the end of this weekend. Mainly due to no major plans this coming weekend. So fingers crossed, the compilation should be ready. Then on to Shoot Em Up Destruction Set #3 (Another 5 new unseen Alf Yngve games compilation).

Bet you got square eyes :)

9th January 2013

Back in 2010 I wrote my first ever tape loader game for the C64 (Cool). That game was called "Moo-Tilation". It was a funny shoot 'em up game, in which you had to defend your hapless cows from being abducted by aliens. In the late 2011 I wrote yet another C64 loader game, called "Happy Blocks", inspired by one of the games I played on FB. HB was a game in which you shift your block, having to avoid getting smashed by the falling blocks. The game required a lot of action.

So then. If you remember those two games quite well. There's a new kid in town. Back in 2007 I wrote a game for a demo group, Civitas called "Square Pit 64" now it's back once again, resurrected as a tape loader game with a slightly new look and a different Euro-disco style tune. I originally planned to rip the original Square Pit 64 game source and implement it into the loader. Unfortunately, I had some problems doing exactly that, so I decided to quickly program the game from scratch, with the aid of the existing resources. I originally was going to go for a techno/trance style theme for the game. Where every time the drum kick came on screen, the screen flashed. I decided not to bother at the end, as the result turned out quite bad.

Instead, I added some pulsating flash routines on to all of the sprites, apart from the small square (Which will stay as white). I also added a fitting track into the source, and tested the game inside an IRQ interrupt. Seemed to have worked quite nicely, but there appeared to have been something wrong. I noticed the scores were placed in the wrong place after a new game was started. I soon fixed that problem. Finally the game was working. So now it was time to remove the IRQ interrupts, and link the game to the Thunderload tape loader.

The biggest mistake I noticed in 2012 was that Thunderload Series Six loader never was compressed, because I had to keep on changing the scroll text and tunes for it. Well, this time round, I decided to compress Square Pit, using Exomizer's level compression mode. Then assemble a decruncher source from the Exomizer, itself. I had to use DASM for this. After assembly and compression and linking the decruncher to the compressed source, I linked the final build to the tape loader source. I altered the LoaderGame init address to call the decruncher routine (Which I placed at $5000) and the set the play address at where the main loops in the game occurred. I altered the batch file to build the .tap using SQUAREPIT.PRG instead. I picked a program to be loaded after the loader game, as a test guinea pig, which was of course "Trance Sector". I tested the tape loader system and it worked a treat :)

Here's a video of the tape loader in action.

Enter the natives

30th September 2012

More productivity at work today, but before I go on my 12-8 shift, I decided to spend this morning (Since 8:45pm) working a bit more on the Amazon Tales project. The deadline is looming closer, but I still manage to spare some of my free time on C64 activities. So what's been happening today? First of all last week, I got the player on screen, move around and shoot. Now it's time to insert some enemies, in which the player will have to shoot at.

First of all, I wanted to test the game sprites to ensure that they all appear on the screen okay, without any movement. I built a test in which shows four natives a dart (which the natives will shoot, and also an aztec coin). Nothing on the enemy front is supposed to move anywhere on screen. Well, it worked out pretty well. Pretty much happy with this so far.

My next job was to get those enemies moving across the screen (or downwards). The plan for the coins will be for those to drop down on to the ground, prompting the player to pick them up. The coins purpose will be to give the player a better ability to shoot at the baddies or move faster - but that will be revealed later on in the blog. If a life gets lost, he loses all abilities. The bullet sprite will be indestructible. More on that later in the blog, when I get round to working on collision.

I got the enemy and bullet sprites moving in a straight line at the same speed - but that wasn't the end of it. I need to add speed table pointers. This is so that the enemies can move at various different speed values. So I added value X + Y tables, according to the speed and direction of the enemy's movement. I also put that into a loop as well. It worked out quite nicely.

Not much time for any more work on this, so I'll be doing more on this game project later on this week.

Enter the Sector

1st-6th September 2012

Over this week I have been working on preparing and building the 32 levels for Trance Sector - fixing some additional bugs, building improvements for the game and programming the intro presentation for it. Now finally, the hard work is nearly done, it is on with the BETA test phase, which I hope will get great feedback.

I tested the new levels myself, and I'm not that good a gamer to be honest. I struggled on some of the levels in Trance Sector in cheat mode, but found that every single level in the game is most definitely possible to complete. I feel that this could be a real addictive game as well. If there's no major issues in the game for the beta testers, I can send the final masterpiece to Daniel Kahlin for tape mastering (As he's been doing a mega cool high speed tape loader system exclusively for Trance Sector. I shall be keeping my fingers crossed. :)

My next C64 project WILL be Amazon Tales, a co-op production by Alf Yngve for RGCD's 16KB cartridge game competition - and it won't be a SEUCK game this time round ;)

Scroll it the hard way

18th May 2012

Something more interesting to be added to Trance Sector. A 4-directional scrolling field. Well, that's what I have spent most of today's Trance Sector session with. I wanted to get the scrolling movement to move according to the direction the player uses with the joystick. I created a new counter which can check which value will indicate the direction for scrolling background field. Then I stored values of 0 - 3 into the scroll counter. Where 0 = Up, 1 = Down, 2 = Left, 3 = Right, then I added a routine that could check for what value the counter is and added subroutines, which would scroll the characters that formed the background field, according to direction. This took quite a lot of programming to get implemented into the game, but I still have plenty of memory of additional code, since sacrificing the logo to build a new title screen. (The logo will be used for the intro instead). My next task (Possibly tomorrow) will be to activate the shield for the player, for any time it hits a shield tile. (On later levels), then hyperspace (Warping) to a different area on the same level screen.

It's getting there ... :)

5th November 2011

Things are getting on pretty well with Woolly Jumper and I feel that I could be nearly finished with the 16KB CRT version of this fun game project. Well, estimated time for finishing the 16KB cartridge is probably between next week and 20th November 2011. I am dedicating myself to at least one hour to this project during my spare time all this week, as we are coming closer and closer to the deadline.

So then what has been happening today? Well, basically I have been concentrating on some minor bug fixing and also getting the enemies to roam across the screen with their new attack patterns. So how did I go around to working on those? It started with some experiments with sprites. Before I could build the sinus patterns, I had to work out the starting and ending position for where to put the enemy sinuses. To be able to do this, I did a little poke that would display a square sprite. Did a little maths to work out the: start and stop position of the sprite sinues for the top, middle, and bottom portions of the screen. These mainly took effect on the penguin ships, green alien saucers and chickens. The meanest enemy of them all were the pink bugs. The bugs have a different kind of behaviour compared to the three aliens (penguin, green saucer and space chickens) . The bugs shall also be appearing less frequently, compared to the other aliens.

After programming and storing the new sinus movements for each enemy, I restored the sprite/sprite collision and discovered a silly bug. For every second enemy shot, you could see an explosion appear again after the death animation had finished. That was one heck of a daft mistake I discovered today. To to fix that problem, I added a routine that switched off the enemy dead mode, so that the enemy is offset. I also made it so that the enemies don't appear on the screen, or move in a Y-axis if they are supposed to be offset - and it worked.

The last thing I did today was added a little ending to the game, for after the final level was complete. It was something too basic, but because of size restrictions, I was unable to do a very good ending - but the full game will of course have a better ending than what I did for this version.

The hobby project continues through to December after the .CRT version's finished!

Get ready for take off

29th October 2011

Arrrrgh! 1 month to go. Woolly Jumper's deadline is coming near, otherwise it won't make it to the compo on time. I have to be quick, but spare time has been cut even more due to my full time job. Actually to be honest, I will not be under pressure to get this game finished, as there isn't really much to be done.

Shaun has got back to me about how the game should be improved. For a start off, he thought that it would be miles better if I removed the colour washing routine over the status bar. So the first thing done earlier on this week was to remove that score. I made it yellow, but after yesterday's email. A yellow status bar looked very odd. So I changed the status bar to white. The second niggly thing was the way the sheep was dying. The speed of the sheep bouncing off the platform falling straight into the water looked very odd. So I slowed down the speed slightly, so that it looked less daft. :)

Shaun also mentioned to me about the enemy formations. Although I worked quite hard on making a variety of enemy formations, it turns out that those formations do not suit the game at all. Therefore it would have been better if I just let the enemies fly across the screen, but I will need Shaun's help to do a quick enemy formation for each group of enemies during the game. Oh ... hang on .... I just got an email from him to illustrate how the enemies should move. I guess I didn't need to use SEUCK again then :)

While I was waiting for Shaun's reponse, I decided to work on the level complete sequence in which the player enters the rocket, and then the rocket takes off with the sheep inside. Unfortunately I found it to be impossible to have the player's face appear in the rocket, as the player sprite overlaps the rocket's sprite. However to solve this problem, I just removed the player sheep's sprite after the rocket picks the sheep up. Then the rocket takes off again. I also added the animation at the bottom of the rocket where the flames are burning from underneath the rocket. The animation was pretty smooth and looked great on the rocket. It would have been great to have the sheep peeping through the rocket window, but the only solution which I can think of to this little problem would be to have two more sprites that build the left/right part of the rocket with the sheep inside. This will be up to Shaun.

Tomorrow after my 6am-2pm shift at a Distribution Centre I might rework on the enemy movement patterns as illustrated by Shaun's rough examples. Now I think I shall have a spot of gaming :)