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.