27 replies to this topic

[Tursi]

Hey guys. Just wanted to link to a little project I did with some spare time on the weekend.

Many years ago, in 1989, I started a little game on the TI-99/4A. At the time, it was my most ambitious project, a 2D vertical shooter with bosses and the works. It came out all right and I sold a couple copies on disk. (Oi, I just noticed that was 20 years ago now...)

The TI-99/4A shares the same video and sound chips as the ColecoVision. Recently, I found the source code, and went ahead and ported it to ColecoVision. It didn't take too long (mostly I was hindered by a lack of comments, very sloppy code, and a couple of bugs in my replacements for the TI's graphics functions). But it works, and I got a thrill out of seeing the same game up on another machine.

Seeing it up was a bit of a thrill, but seeing the many faults triggered a desire to improve, so over the next little while I'll go through and clean up the source, then improve on the game a bit to make it a little more solid. In the meantime, just wanted to share.

http://www.harmlessl.../onesoft.cgi?64

[Pixelboy]

I just tried it with blueMSX. It's quite nice, but rock hard. I keep mistaking the bigger white stars for enemy projectiles, and most of the time, when my ship blows up, I'm not even sure what it was that hit me. Seriously, I can't even last 10 seconds without exploding!  

[Tursi]

Heh, thanks.

In playing it for a bit myself, I do believe it's much harder than the TI version. The random number generator works, and everything /can/ come out, but this one tends to make the enemies fire more often, and makes shield power ups very rare (on the TI version I can usually get 2-3 shield powerups before the first boss.. here I almost never see them).

As much as it might be good to offer a challenge, I wonder if I should port the TI random number generator code and see how that tweaks the difficulty.

It'll be a little while before I can start making updates, anyway.

[newcoleco]

It looks and sounds very cool. How long did it takes to make this beta version?

[Tursi]

Since I already had full C code, just a few hours to write the support functions. There wasn't too much to this - screen and sprite access functions largely mapped nicely to the Coleco devkit (which is beautiful, btw). I had to replace the data file load with a simple VDP write (TI loads files to VDP RAM first, so that was convenient), and the win code was originally a separate program, I merged it into the one here.

I also RLE-compressed and embedded the title page, which was originally disk files as well, that enabled the whole thing to fit in 32k.

It took a few hours more to troubleshoot - this was accelerated when I dug out the original C99 manuals and found that the screen offsets were 1-based in his functions, not 0-based like I assumed. My original random number generator was broken and didn't limit the returned values, which caused some grief (shifted the wrong way), and I believe there was an overflow bug in the original code for the starfield that for some reason didn't cause problems on the TI, but did on the Coleco. Other than that it's the original code.

It's pretty poor code. All variables are global (the TI compiler was very inefficient with stack variables - this was for performance). They're also all 16-bit, since the TI used a 16-bit CPU. The code /itself/ is full of things that, today, I shake my head at and wonder what I was thinking. Lots to clean up anyway.

[newcoleco]

Nice.

Keep track of the modifications you had to do... I would like to know more about the differences between the two versions, and how you did deal with them.

Also, if you are talking about the devkit I'm doing right now to be used with sdcc, let me know of any error or problem you find in it. It's a beta version and I still have tons of other things to do at the same time. So, if you find a bug like a problem with the random functions, let me know, with a code example if possible.

[ScottHuggins]

Tursi-  plays so smooth and the controls are very solid. Boss stage?????  Sounds nice although I know I will never see it.... This game is hard!

Edited by ScottHuggins, Wed Aug 26, 2009 1:40 PM.

[Tursi]

newcoleco, on Tue Aug 25, 2009 8:19 PM, said:

Nice.

Keep track of the modifications you had to do... I would like to know more about the differences between the two versions, and how you did deal with them.

Also, if you are talking about the devkit I'm doing right now to be used with sdcc, let me know of any error or problem you find in it. It's a beta version and I still have tons of other things to do at the same time. So, if you find a bug like a problem with the random functions, let me know, with a code example if possible.

It looks like the devkit I'm using was released by Philipp Klaus Krause - I got it a long time ago and had to search. I checked your profile and I know I use (and have referred to the TI group a few times) your graphics editors! They are very nice.

The random number function was my own code, so my own bug there.

Other than that there are no serious differences. The TI uses a 9900 16-bit CPU, and c99 is intended to run from RAM expansion, so the stack has 6-8k available to it and globals live in the same 24k RAM bank as the code. ie: lots of RAM. That wasn't a problem for this game. I wondered about code size differences, but the sizes are comparable (SDCC version may be a bit smaller), and performance is good, though hard to compare directly.

The graphics functions in the original code were based on TI Extended BASIC, meaning we had calls like "hchar" (display and horizontally repeat a character), "sprite" (create and display a sprite with optional auto-motion), "joyst" (read the joystick), etc. I had to reproduce these functions (just read or write the appropriate area of VRAM for the most part). The sound list playback function I had to write and insert calls to (normally played by the TI console ROM).. this is pretty simple code that just loads sound lists from VDP memory. And the sprite automotion wasn't used by the game except during the ship explosion, so I just re-wrote that inline. Plus, as mentioned, replacing the disk load functions (title page and graphics data) with straight copies to VDP. The only real hack involved was moving the cheat codes from keyboard to Coleco keypad, the numbers are harder to remember than the original letters. (I'm teasing now).

Sorry it came out so difficult... I'll try to port the original random number function next week, that should tune it down a little. Even I have trouble getting to the first boss.

[Yurkie]

Quote

Sorry it came out so difficult... I'll try to port the original random number function next week, that should tune it down a little. Even I have trouble getting to the first boss.

Glad I am not the only one that thinks this is super difficult.

[ed1475]

A very fun game.  It's challenging but I did make it to the boss ship.

[Tursi]

I've published an updated version to my website -- this fixes the random number generator so that the difficulty is where it was originally meant to be, fixes a couple of small bugs, and reduces the firing rate of the weakest weapon. It also adds a nifty new title page, but none of the game graphics have been updated yet.

http://www.harmlessl.../onesoft.cgi?64

[Tursi]

Did post an update today.. I've put the main information (and screenshots) in the thread LS650 started: http://www.atariage....gopid__1892107

New graphics, new boss dynamic (you have to shoot through them to get the engines), enemies aim better and won't shoot backwards, lots of tuning. The biggest change was I was able to convert a lot of the variables from 16-bit ints to 8-bit chars -- 16-bit was the TI's native word size so it made some things easier to stick with that, but SDCC's Z80 16-bit code is pretty nasty, so going to 8 bit saves a lot of code space (and I would presume also CPU time)... this plus cleaning up the data file and consolidating some code freed enough space for the new boss graphics, and there's still about 6k free (which I hope to use for music, though there's still a bit of new code to write to make the bosses move more smoothly). I'd also like to improve the background, but depending on time and space (no pun intended) I might settle for just making the stars less prominent and removing the big one (since even 20 years ago people noted that they sometimes thought it was an enemy bullet!)

Homepage: http://www.harmlessl.../onesoft.cgi?64

[rpgcollector]

Very fun game. I would buy this on a cart!

[Tursi]

As posted in the other thread, I did another update to this.

The biggest change tonight was that I wanted to give the player more shots, and that meant I had to re-arrange the sprites some. The original code was all magic numbers, so I came up with tables of what sprites, characters, etc, were used for what (actually did that last release), and used that to create defines for the various objects. Once I had the defines in place and working, I could trivially move things around.

I worried all the extra sprites would cost in terms of CPU, and they did a little, but I think I was able to compensate - it was worst on the boss checking against the background characters, so I reduced the size of that test a bit to make up for it.

I also fixed the game glitching when you died during a boss battle - after you died, the boss would explode, and off you'd go. The game uses a single flag variable with various random numbers, and some of the gameplay changes I'd previously made caused the wrong value to be stashed in there. That's definately a system that needs evaluation for improvement, and if it gets in the way again, I'll do that.

Also, when you are killed, the game remembers which sprite killed you, and leaves it on the screen so you can see it.

I'm finding it interesting to work on this code again - not my first C code but very close to it. Looks like I won't make the 20 year anniversary of first starting it, but 2010 is right in the middle of twenty years after first start (1989) and first release (1991), so I should be good for that. heh. It's interesting to look back 20 years and see how I coded things. I know some of my decisions were prompted by a low memory, inefficient compiler, and some by the editor itself, but others - like all the code being in one file, all variables being global, the coding style and some of the algorithms - definately speak to inexperience.

Anyway, carrying on!

http://www.harmlessl.../onesoft.cgi?64

[newcoleco]

My best try for a game footage of this game. I can't wait to try the next updated version.

[Tursi]

newcoleco, on Mon Dec 28, 2009 7:05 PM, said:

My best try for a game footage of this game. I can't wait to try the next updated version.

Thanks for posting! Very kind of you to do that! (Though, note the last word in the title is "Acer", not "Ace".. I've been asking unsuccessfully to have the other thread here corrected, too... otherwise it sounds like a derivative of Space Ace, which it is not.)

The comments are interesting to read too... of course, the music will be replaced - there's a reason I didn't go start a band with my composition skills (though even today, I don't mind the Game Over music ).

The comment about lack of score is an interesting one - it was a major complaint back when I released this on the TI, one that, at the time, I simply shrugged and apologized for, I was out of characters in the character set, so I couldn't have the score onscreen, and practically out of memory, so I didn't feel I could do a between-stages score. In fact, the 'game over' characters were simply 7 spare characters in the character set.

Back then, I didn't realize I could separate the sprite and the background character patterns... doing so here made plenty of room. Not to mention, of course, I could have used VDP RAM more. But that's the difference between starting out and twenty years later.

When I got back into the source code, I was surprised to see that there IS a score variable, and it's appropriately updated. It remains to be seen whether it wraps too easily or not (being just 16 bit), but I'll get it onscreen eventually.

[Tursi]

I posted a big update tonight - I've been working on the game off and on over the year. I only recently noticed that it has been nearly a year.

http://www.harmlessl.../onesoft.cgi?64

Quite a lot of little tweaks that were fun to do. I'm still playing with the weapons systems, but I think I came up with a power-up scheme (not implemented yet) that I like, which will be a little more Raiden-like, rather than just swapping weapons as today.

I had fun with some animation enhancement. The mines now have flashing lights at their tips -- to do this I used the one unused enemy sprite. Every game frame it cycles to the next enemy in the table. If that enemy is a mine, it overlays it, if not, it is offscreen. The effect is that each mine gets blinking lights.

Bosses by far saw the most enhancement. The boss explosions do a little macross-inpired animation now instead of being static, which makes it more interesting to look at. Beyond that, the tricky part is that they move smoothly horizontally, rather than per character.

Smoothly here means with 2 pixel resolution. They accelerate per level - meaning the last two bosses are moving per character anyway for the most part. The way it's done is pretty simple -- there are 4 character pattern tables loaded into the VDP. When the boss graphics are decompressed, they are shifted two pixels into each pattern table. When we are moving the boss, then, we just change the pattern table appropriately for a free shift of up to 6 pixels. When it actually changes character position, then we redraw.

I was worried about the damage patterns when the boss is shot. This updated data is shifted in real time and all tables are updated. Luckily, it appears to keep up.

The real problem was the loading phase. It takes a notable amount of time to pre-shift all the boss graphics, and I don't have space to keep them all loaded. A 'BOSS APPROACHING' phase was added to cover this up. During this time, the player's ship is centered, and enemies are made to leave the screen. In the background, the boss graphics are being pre-shifted. When it's done, then the boss can arrive.

I was also able to remove a lot of old, messy code, and fix up a lot of silly functions. I removed all the hard-coded delays I found, and replaced them with VDP timing loops. Also, many of the original functions were from the TI's c99 graphics library, which attempted to emulate Extended BASIC. As a result, pretty much everything was 1-based instead of 0-based. I did away with that. I also wrote my own code for most of the hardware access for better control of the system, since a lot of it is just as good inline.

I was also able to use the above tweaks to take control of the framerate. Due to somewhat unpredictable code paths (and those hard-coded delay loops), the code's performance varied a lot. It's now fairly solid. I ran the game at 20fps so that I could divide the workload among 3 different tasks, every 60th of a second.

The vblank handling uses my technique (dissed elsewhere) of masking VDP interrupts until you are ready to process them. This eliminates the need for a variable to check whether a VDP interrupt happened when you were not ready for it (not to mention all the code needed to set and later check it). This is the way TI programmers have handled it for 30 years now -- with the exception that the 9900 has a CPU instruction for it, and so on the Coleco we have to use a two byte sequence to the VDP register. This is slightly racey so does require some consideration about timing... but so does accessing the VDP anytime outside of the interrupt on the Coleco with interrupts left enabled, so I don't feel too bad.

Hope you enjoy! It's shaping up to closer to what it should have been twenty years ago!

[Yurkie]

Tursi, on Wed Dec 15, 2010 1:45 AM, said:

I posted a big update tonight - I've been working on the game off and on over the year. I only recently noticed that it has been nearly a year.

http://www.harmlessl.../onesoft.cgi?64

Quite a lot of little tweaks that were fun to do. I'm still playing with the weapons systems, but I think I came up with a power-up scheme (not implemented yet) that I like, which will be a little more Raiden-like, rather than just swapping weapons as today.

I had fun with some animation enhancement. The mines now have flashing lights at their tips -- to do this I used the one unused enemy sprite. Every game frame it cycles to the next enemy in the table. If that enemy is a mine, it overlays it, if not, it is offscreen. The effect is that each mine gets blinking lights.

Bosses by far saw the most enhancement. The boss explosions do a little macross-inpired animation now instead of being static, which makes it more interesting to look at. Beyond that, the tricky part is that they move smoothly horizontally, rather than per character.

Smoothly here means with 2 pixel resolution. They accelerate per level - meaning the last two bosses are moving per character anyway for the most part. The way it's done is pretty simple -- there are 4 character pattern tables loaded into the VDP. When the boss graphics are decompressed, they are shifted two pixels into each pattern table. When we are moving the boss, then, we just change the pattern table appropriately for a free shift of up to 6 pixels. When it actually changes character position, then we redraw.

I was worried about the damage patterns when the boss is shot. This updated data is shifted in real time and all tables are updated. Luckily, it appears to keep up.

The real problem was the loading phase. It takes a notable amount of time to pre-shift all the boss graphics, and I don't have space to keep them all loaded. A 'BOSS APPROACHING' phase was added to cover this up. During this time, the player's ship is centered, and enemies are made to leave the screen. In the background, the boss graphics are being pre-shifted. When it's done, then the boss can arrive.

I was also able to remove a lot of old, messy code, and fix up a lot of silly functions. I removed all the hard-coded delays I found, and replaced them with VDP timing loops. Also, many of the original functions were from the TI's c99 graphics library, which attempted to emulate Extended BASIC. As a result, pretty much everything was 1-based instead of 0-based. I did away with that. I also wrote my own code for most of the hardware access for better control of the system, since a lot of it is just as good inline.

I was also able to use the above tweaks to take control of the framerate. Due to somewhat unpredictable code paths (and those hard-coded delay loops), the code's performance varied a lot. It's now fairly solid. I ran the game at 20fps so that I could divide the workload among 3 different tasks, every 60th of a second.

The vblank handling uses my technique (dissed elsewhere) of masking VDP interrupts until you are ready to process them. This eliminates the need for a variable to check whether a VDP interrupt happened when you were not ready for it (not to mention all the code needed to set and later check it). This is the way TI programmers have handled it for 30 years now -- with the exception that the 9900 has a CPU instruction for it, and so on the Coleco we have to use a two byte sequence to the VDP register. This is slightly racey so does require some consideration about timing... but so does accessing the VDP anytime outside of the interrupt on the Coleco with interrupts left enabled, so I don't feel too bad.

Hope you enjoy! It's shaping up to closer to what it should have been twenty years ago!

Looks nice, but I think you should get rid of the stars, or atleast the big ones that go by. They look like shots coming at the players ship. All the sprites being smaller so there is more screen space to move would be a plus too. Just my opinion.

[Tursi]

Are you sure you're playing the right version? The big stars were removed ages ago. Only the medium and small are left - they're smaller, differently shaped, and differently colored to enemy shots. I disagree on the sprite sizes, but appreciate the input!

[Yurkie]

Tursi, on Sat Dec 18, 2010 4:10 PM, said:

Are you sure you're playing the right version? The big stars were removed ages ago. Only the medium and small are left - they're smaller, differently shaped, and differently colored to enemy shots. I disagree on the sprite sizes, but appreciate the input!

Sorry it is the medium stars. I do appreciate you sharing your work and visuals are very nice for a ColecoVision.

[NIAD]

Yurkie, on Sun Dec 19, 2010 10:07 AM, said:

Tursi, on Sat Dec 18, 2010 4:10 PM, said:

Are you sure you're playing the right version? The big stars were removed ages ago. Only the medium and small are left - they're smaller, differently shaped, and differently colored to enemy shots. I disagree on the sprite sizes, but appreciate the input!

Sorry it is the medium stars. I do appreciate you sharing your work and visuals are very nice for a ColecoVision.

I actually like the oversized ships and all, different from what almost every other shoot'em-up game uses. Although the difficulty, in my opinion, is off the charts. I thought Scott Huggins' games were tough, but SSA is crazy hard.

[Tursi]

Really? hehe.. I guess I've been playing it on and off for better than 10 years, so I have some experience. That said, there are two pending updates that will affect difficulty, one is one final tweak to the weapons systems, the other is to replace the enemy randomness with patterns. That will at least make it possible to learn the stages instead of being /pure/ twitch.

My main issue right now is finding ROM space.. each feature is a bit of an optimization game. But I have some other tricks up my sleeve yet.

[Tursi]

As posted in the other thread, I released an update of the game after dumping a few more hours into it today. Most of it was small cleanup, but I took to heart the difficulty complaints, and you can now select a difficulty level. I'm thinking that you will have to play the original difficulty (now Skill 3) to get the best ending, but for now that is moot as there's only one ending.

From a programming perspective, there's not much to note except that I was able to optimize away enough old code to get a net zero change in code size for the newly added features. Besides difficulty - the main gameplay difference is that the power ups cycle through all three options now - Shield, 3-Way and Pulse cannon. Not sure whether Shield should be included in the rotation?

There was a problem where no player collisions were tested during the 'Boss approaching' phase (which was only a pain when you wanted a power up that was onscreen). I had to rework a little of the old game structure, but I got that cleaned up and working as part of the mainline code now.

I removed the medium size stars, so all stars are just points now. Hopefully that will end the confusion. I don't really want to remove them.

Also added a collision sprite to the bosses so you can't (easily) sit on top of them to shoot their engines out. If you know where to sit, yes, you can still do it, but it's a little more dangerous than it used to be. I'm okay with this, I like tricky cheats.

Also made the ship red since the one on the title page is. I'm not sure if I like that, but I've been looking at the white ship for 12 years, so I guess I need time to get used to it.

Not done yet by any means.. mostly I need to get the new weapons system and enemy patterns in, the rest will be tuning and polish.

http://www.harmlessl.../onesoft.cgi?64

[Yurkie]

Tursi, on Sun Jan 9, 2011 4:53 AM, said:

As posted in the other thread, I released an update of the game after dumping a few more hours into it today. Most of it was small cleanup, but I took to heart the difficulty complaints, and you can now select a difficulty level. I'm thinking that you will have to play the original difficulty (now Skill 3) to get the best ending, but for now that is moot as there's only one ending.

From a programming perspective, there's not much to note except that I was able to optimize away enough old code to get a net zero change in code size for the newly added features. Besides difficulty - the main gameplay difference is that the power ups cycle through all three options now - Shield, 3-Way and Pulse cannon. Not sure whether Shield should be included in the rotation?

There was a problem where no player collisions were tested during the 'Boss approaching' phase (which was only a pain when you wanted a power up that was onscreen). I had to rework a little of the old game structure, but I got that cleaned up and working as part of the mainline code now.

I removed the medium size stars, so all stars are just points now. Hopefully that will end the confusion. I don't really want to remove them.

Also added a collision sprite to the bosses so you can't (easily) sit on top of them to shoot their engines out. If you know where to sit, yes, you can still do it, but it's a little more dangerous than it used to be. I'm okay with this, I like tricky cheats.

Also made the ship red since the one on the title page is. I'm not sure if I like that, but I've been looking at the white ship for 12 years, so I guess I need time to get used to it.

Not done yet by any means.. mostly I need to get the new weapons system and enemy patterns in, the rest will be tuning and polish.

http://www.harmlessl.../onesoft.cgi?64

First off... thank you very much for sharing this.

As is I saw 2 issues.

1. The moving stars destroy digits in the player score display.
2. the screen background is white for awhile when the boss first appears.

I love the power-ups!

I like this version much better. I still think the small moving stars and the background ones are a distraction. I think you should get rid of the moving stars and make the background ones blue like on the title screen.

With no moving foreground stars and discreet blue background stars, I could see myself being a big fan of this game. Would you please consider this change?

Perhaps make the change and post the 2 roms versions with a poll question and ask for feedback.

Again thank you for sharing your hard work.

[Tursi]

Thanks, Yurkie.

Yurkie, on Sun Jan 9, 2011 9:54 AM, said:

1. The moving stars destroy digits in the player score display.
2. the screen background is white for awhile when the boss first appears.

Hmm.. neither of those should happen. The stars check the background before drawing, and the screen color register is not touched during the game. I don't see these issues under BlueMSX. Naturally there could be a bug writing to VDP, but what are you running it under?

Quote

I love the power-ups!

Thanks. I might need to bounce them around a bit so that the cycling can stay longer on each one..?

Quote

I like this version much better. I still think the small moving stars and the background ones are a distraction. I think you should get rid of the moving stars and make the background ones blue like on the title screen.

To me that just seems like a step backwards. You're supposed to be moving, so something has to show that. I can try the blue stars but I can't remove the moving background altogether.

Quote

Perhaps make the change and post the 2 roms versions with a poll question and ask for feedback.

Thanks for the suggestion, but this is one concept I'm rather firm on. I want to add additional backgrounds if I have the memory, but it defeats the purpose of a "top down scroller" if the background isn't moving.

.. and d'oh. The boss cockpit sprite is supposed to be invisible. Oh well, now people can learn where it is, and I probably won't move it, much.