After going over the code of the old Aliens game, I started reorganizing it a bit.
For this, I set up an emulator to “Print to a text file”, and then listed the program to the “printer”.
After some Copy-Pasting (and line number changing), I moved the lines that create the graphics to the end of the code. This way, the main loop ended up between the 10th and 30th line, instead of around the 80th to 100th. This already makes it faster because of the way the infamous GOTO command works.
While doing this, I noticed that I was initializing some variables that are never used, and that there was provision for up to 50 aliens in one level!
I don’t think that fixing that gave me any extra speed, but at least there is no waste of memory as before.
Then, for the hardest part.
The lines in main loop had to be rearranged to have all the graphics drawn in the graphics page that is not being displayed. Then, copy that page to the one in the screen, do the math, delete the sprites that are going to move in the first page, and loop back to drawing the sprites.
I think I kind of sorted that out in a decent way, but there might still be room for improvement.
Then came code compacting.
Again, in Notepad++, I started looking at lines that could be crammed into a single one.
430 COLOR 1
440 PMODE 4,1
460 PMODE 4,5:SCREEN 1,0
420 PR=1:COLOR1:PMODE 4,1:LINE(Q*8,Z*8)-(Q*8+8,Z*8+8),PSET,BF:PMODE 4,5:SCREEN 1,0:PLAY”O4;L8;C;L16O3BL32AL8GL16FL8ED”:S=S+25:RETURN
The risk here is that you may delete a line that is referenced in a GOTO or GOSUB, That is why I always keep a backup of “uncompacted” listing, in case I need to figure out where something used to be.
After all looks good, I take the file into a disk image using either IMGTOOL from MAME or with Toolsheed
With this, the program went from 132 lines to 100.
At this point, code was probably as neat and fast as I would get it without a major rewrite, and that was not the goal.
The flicker is, of course, gone. But sometimes, when more than 2 aliens move at the same time, you can tell that it is slowing down. Perhaps I should change it to have only one alien move in each cycle?
I’ll move on, make some minor changes to the look of the game, and then come back to that thought.
And for the last post of the weekend, my “Second Challenge”.
write a game that will run in any TRS-80 Color Computer, using the low-res graphics mode (64×32) and no more than 16 KB RAM.
A great way to save time, is to “clone” an existing game. That way, I don’t have to come up with the game mechanics, and I will already have a fair idea on what the graphics should look like.
And it turns out that there is one game, quite simple, that I used to play a lot many years ago, and that as far as I know, was never available in any computer.
A small handheld LCD game called “Hippo Teeth”
The Hippo has only 3 teeth, and a nasty worm is trying to eat them!
Your task, as a veterinarian dentist, is to kill the worms with your gas spray. Nut that is not so easy. The worm moves around a lot, and the Hippo’s tongue gets in the way….
As the gameplay is already set, I decided to test if I could do some decent graphics in the 64×32 mode. One of the difficulties, is that each 2×2 block can only have 1 color and black, a limitation similar to the one the ZX Spectrum has in the high res-mode.
Instead of trying to design the graphics using a regular “Paint like” program, I took advantage of the excellent online SG graphics editor at https://daftspaniel.neocities.org/tools/sgeditremix/
With this tool, it didn’t take that long to come out with what I believe is a decent design for the graphics.
There you have the Hippo with it’s big open mouth, the 3 teeth, the nasty orange worm, red tongue, “cyan” gas cloud, and the Doc.
Except for the Doc’s feet, everything else happens over a black background, making it easier to design the graphics and animate them.
I will save the Hippo’s picture as a ML file, and load it at the start of the game, perhaps even keeping a copy in another memory location, to make it easier to redraw it if needed.
I have to do some tests to see what is faster, if printing the semigraphic characters, or POKEing them. I guess print will be faster, as each “sprite” will use 3 commands, instead of 9-12 POKEs.
On a side note, something that caught my eye, is the way that the cyan color looks like. I would have sworn that it was a sky-blue like color, as it should be according to Wikipedia.
But my CoCo 3, and all the emulators I tested show the same greenish hue… well, not all. The original Java based “Mocha” emulator does show the color I remember from all those years ago…
I really don’t know what happened to that color that was perfect for bright skies or clean waters. Do you?
And I had to do it. Start with my 3rd Challenge.
So I went over my old BASIC programs looking for something interesting that could be part of this challenge. I have 10 full disks, and after 5, it seemed to me that I had more than enough games to keep me busy for the month.
Let’s see what I found…
Inspired by the movie “Aliens”, you are a space marine trying to rescue the alien’s victim in a maze of tunnels.
A Russian roulette simulation. Yeah, I guess I was kind of sick back then 🙂
You must try to catch the weird tentacled thing, avoiding the pac-man like chomper.
Inspired by (I believe) a ZX Spectrum game inspired by the “Airwolf” TV show.
A simple target shooting game.
Keep the missile on target to blow the tank before it blows you.
You are alone against 2 enemy fighters. At least that is better than 5 vs 2 as in the movie!
Shoot the enemy space fighter from your base’s turret before it fires on you.
You may have noticed that some of the names and text in the screenshots are in Spanish. Yes, that is my native language. I’m not really sure if I want to translate them.
What do you think?
Now is time to pick one, and start trying to figure out 30 year old code written by a 15 year old kid….
Como se habrán dado cuenta, este blog es cada vez mas retro.
Hoy les voy a presentar una pequeña parte de mi colección de retrocomputacion, aprovechando que por primera vez puedo tener una buena parte de la misma en exhibición, en vez de guardadas en cajas y cajones.
De izquierda a derecha, y de arriba a abajo:
CPUs: Intel 486 SX (40 Mhz), Intel 486 DX2 (66 Mhz), Citrix 486 DX2 (80 Mhz), AMD 486 DX4 (100 Mhz), Intel Pentium (133 Mhz), AMD K6-2 (450 Mhz)
Camara digital EZ-Mega cam (1 Mp)
Laptop AcerNote 730i 486SX / 4MB (Monocromatico)
Tarjetas de memoria: CF de 64 MB, SD de 32 MB, Micro SD
En esta foto hay algunos “invitados”. Limitándome al tema de hoy, tenemos:
Tarjetas PCMCIA para laptops: Wi-Fi Trendnet, Red D-Link, Memoria flash 8 MB.
Tarjetas de PC: “Super I/O” (Puertos serial, paralelo, controladora de discos IDE y diskette), Tarjeta de red 3-COM
Laptop IBM Thinkpad (Celeron 400 Mhz)
CD de Lotus SmartSuite 96
That is why, a few days ago, when feeling a bit bored and finding some time in my hands, I started another project. Let’s call it … “Trench of Death”
Just as “Furious Felines” was inspired by “Angry Birds”, “Trench of Death” draws from another modern classic, “Plants vs. Zombies”, but with a scenario changed from a garden to the Death Star.
I guess that everyone remembers the attack against the Death Star at the climax of the original Star Wars movie. The attacking ships have to go through a long, straight “trench” to get to their final target, while turbolasers and TIe fighters try to shoot them down.
In this game, you’ll have to set the defenses along the trench, to prevent the attacking crafts from reaching their target. The ships will be coming from a trench 10 cells long, were you can place guns at 3 sides.
Each gun will have different cost, a “time to build” and power ratings. After the player selects the type of gun to be installed, they will place it either on the sides of the trench, or at the end, meaning that the incoming crafts will be fired upon from the sides and the front.
I have already coded 10 types of gun turrets for defense, and 8 types of attacking crafts, and done some testing to evaluate the game balance.
So far, I don’t have much to show. I have coded the attacking craft movement routines, and tested it with a squadron of 8 ships. Speed seems to be acceptable even with fake routines added to represent the joystick input and gun firing routines.
Next up, allow the player to select a type of gun, and place it in one of the designated spots.
I hope I’ll be able to do it this weekend.
After the success(?) of Furious Felines I started thinking about which would be my next project.
For some time I considered a port of “Felines” to PC, or to mobile platforms. Perhaps, but not right now.
But that reminded me of another game I wrote years ago for the CoCo, “Submarine Hunter“.
I did port, or actually, create a much improved version for the PC platform in 2012.
The PC version has, of course, far better graphics, but also the gameplay was improved. (I hope).
I realized that a far better CoCo version is possible, and decided to get on with it. I’m almost sure that most of the code can be reused from either the original CoCo version or the PC port, and with that in mind, I started creating the graphics. I plan to manage the graphics as I did in “Furious Felines”, drawing all the graphics in an intro screen that will then be loaded from the main program. This makes it easier to update the graphics, and keeps the file with the program’s code smaller.
So, here is a preview.
After the last change, when the game is run, there is a few seconds delay while the screen is being loaded.
At first, I was just going to add a simple “Please wait, loading” message, but I couldn’t help myself.
While adding more graphics, I realized that the initial screen was taking longer and longer to draw. It’s not fun waiting for a minute or more while the game “loads”. But there is a solution for that.
I moved the code that draws the graphics and intro screen to a separate program. Then, using the code from HSAVE, saved the screen and color palette into 3 files.Now, the main game file, FELINES.BAS loads those files to display the intro screen, and then captures the in-game graphics (HGET) from there.
Now it takes less than half the time to finish the intro screen than before, and I can add as many graphics as I want without affecting loading time. The only drawback is that the files that make up the screen, – FELINES.PAL, FELINES.SC1, FELINES.SC2 – are quite big, +32 KiB total. The whole game is now almost 38 KiB. quite big, but still fits comfortably in any floppy disk
With just a few days left before the Annual “Last” Chicago CoCoFEST!, I had to get in gear. I had submitted a preview version of “Furious Felines” for the CoCo Coding Contest, but it was far from what I wanted the game to be.
First, I had to discard the idea of playing music while drawing the introduction screen. I had hoped to play a recognizable tune, playing one note after drawing each line in the cat’s graphics, but it slowed everything too much, and the music did not work fine.
The biggest change came when I decided that the game will allow you to, once you have finished all the levels, replay them, with a higher level of difficulty. To do that, I moved the levels data outside the program, to a data file. In this FELINES.LVL file I could store as many levels as I wanted, and could load and reload it as many times as I wanted. This worked out fine, and will allow me to create a level editor at some point.
Also, I added a random factor to the wind in each level, to give a better replayability (is that a word? Or what?), and a wind speed indicator at the top left of the screen.
With this changes, and 6 playable levels that could be replayed until the mouse escapes, version 1.0 of “Furious Felines was ready for the public unveiling.
Interpreted BASIC, in a 25 year old computer, is not fast. That is a fact.
Trying to improve the animation speed and reduce flicker, I did something I have never tried before. A look-up table of sorts.
The idea is simple. Calculate all the points in the cat’s trajectory while it jumps, and store them in a matrix. Then, animate the jump reading the graphic’s position from that matrix instead of calculate it while drawing the animation.
But I found two not totally unexpected problems.
- The calculations took about 5 seconds. During that time, the game had an ugly pause in the action.
- I found out that most of the flicker is actually because of the time it takes for BASIC to draw the graphics in the screen. Having no delay between the command that deletes the cat’s old position, and the one that draws the new one did actually create a flicker that was in some aspects nastier than before.
So, back to the old code.
The good thing is that it was not hard to implement at all, and I’m sure I will find another chance to use it.