Or is it 18/10?
Anyway, writing a brief closing post seemed to make sense, so here it is.
To start, it was fun!
Yes, some things did not work as I expected, and others where hard, but overall, I had a lot of fun working and playing with my old computers – and emulators when needed.
It was also interesting to look at all the other projects going around, although I will admit that I did not have much time to see how the other participants were doing.
My goal of having 3 challenges may have been a bit too much. Not that I had to run to finish either, but I had to leave my other hobbies and projects on the sidelines for the whole month.
The First Challenge was to get my old Acer 486 laptop and “to install a full DOS and software package, including some games, utilities and productivity software in it”
Unfortunately, the poor thing is more dead than alive now. I’ll try to figure out what went wrong with it, and see if it can be recovered.
The Seconds Challenge was “to write a game that will run in any CoCo, using the low-res graphics mode (64×32) and no more than 16 KB RAM.”
“Hippo Teeth” was actually easy to write. Not having to create the gameplay mechanics helped a lot. I will try to write a version that runs in a 4 KB tape based CoCo, and another with some extra features, not caring too much if it will run or not in a 16 KB machine.
And the Third Challenge was “to look through my old programs, find some that could use some cleanup, and try to update them.”
And did I find some!
I have 10 disk images worth of old programs, and just by looking in 3 of them, I’ve already found 8 games that I wanted to update.
For the RetroChallenge, I did “Aliens”, “Russian Roulette”, and “Super-Catch-it”
It was fun – and a bit scary – to go over my +30 year old code. I really want to go over the rest of the programs, perhaps 20-30, and create a nice set of not-so-bad new-old games.
Perhaps for the next Retrochallenge? Because I will be there for sure!
With just hours left in the Retrochallenge, I sat to add that 2nd “Chomper” to “Sup-Caz”.
Trying to keep the game as fast as possible, I thought that I could just draw the same “sprite” a second time, just switching the horizontal and vertical variables.
And it worked. I had to make a concession though.
The screen is 256×192. But, since I’m switching vertical and horizontal ones for the second Chomper, I can’t use the whole screen, since 240 can’t be used as a vertical coordinate. Therefore, I had to limit the screen to 192×192. This is not that bad, and leaves some empty space on the side if I ever want to have some kind of score display or whatever.
With this, the Remix was basically done.
I went ahead tweaking a few things. Like removing the timer used to end the game (it moved a single pixel, almost unnoticeable, across the screen) and just used the Chomper’s position as timer. Once it reaches the 14th line, the game is over.
Also made the show your score and pause whenever you catch a bug or are eaten, instead of only at the end of the game, and finally, if your score goes below 0 (you loose points when eaten by a Chomper), the game is over.
Of course, before calling it a day, I compacted the code the usual way, merging and renumbering lines, and removing spaces.
In the end, the game is not very challenging or fun the way it is. Just mildly entertaining, I would dare say.
But is probably the “ultimate” version of the original game.
If I ever decide to come back to this game, I will probably switch to the lower resolution (128×96), which will give me larger characters, and 4 screen pages. Then I could add some background with obstacles, some logic to the bug’s movement – like trying to stay away from the player or close to the Chompers, and an on-screen score display.
And again, I wonder why I didn’t do better back then. I guess I realized that the game was not that fun to play, and didn’t try too hard.
Here is the code for the original and Remix versions.
I guess this is it. I can say “Challenge #3, completed!”
So I sat to redo the graphics. The first thing I realized was that I still, after 30 years, don’t understand how the DRAW command really works when moving just one or 2 pixels. So I ended up using a lot of LINE and PSET, but that is all right. I also started using
since it is a lot shorter, not just to store, but also to type.
It was at that time that I noticed that my “bug” sprite was only 11 pixels high, and the player’s was 13…. No big deal, small redesign, with a little hat for the player.
Then, it was just a matter of using a “flag” variable – C in this case, to determine which of the 2 sprites for each character to PUT. If C=1 then C=0 and use one set of sprites, if not, then C=1 and use the other set.
IF C THEN PUT(X,Y)-(X+11,Y+11),P1,PSET:PUT(Y,X)-(Y+11,X+11),P1,PSET:C=0 ELSE PUT(X,Y)-(X+11,Y+11),P2,PSET:PUT(Y,X)-(Y+11,X+11),P2,PSET:C=1
And it looked quite good! But… the “Chomper”… the animation did not look good. Soooo I changed the movements to have the characters step 6 pixels at a time. Of course, that will make them take longer to go from one side of the screen to the other, but that is not a big deal.
But then, I discovered my lie.
The “reason” why I did the new graphics was so that all of them matched the movement grid size, 12×12, making collision detection a lot easier.
But now, the movement grid is 6×6!
Instead of the simple
IF H=X AND V=Y GOSUB 580
I had to go with
IF H>X-12 AND HY-12 AND V<Y+12 GOSUB 580
Well, the game was still reasonably fast. And since I noticed that the lone Chomper was not really much of a threat… why not add a second one?
I guess I shouldn’t…. After all, there are just 6 days left…
What the heck, I do consider challenge #3 achieved, with 2 Remixed games.
And my long term goal, beyond retrochallenge, is to remix over a dozen of games, so, the next one in the list is “Sup-Caza”. The name comes from “Super Cazalo”, translated roughly to “Super Catch-it”, with the original being a 32×16 resolution game with 1×1 blocks as characters.
After a quick look at the code, (1600 bytes), it was clear that I could use PCOPY to avoid screen flicker.
Here is the original routine to draw and clear the graphics.
274 FOR A=1 TO 100:NEXT A
275 COLOR 1
The wait loop in 274 is to keep the characters visible in the screen for at least some time. I would have assumed that by that time I knew to put all the math between drawing and erasing, but I guess I did not.
Anyway, with page flipping, a simple PCLS is more than enough to clear the graphics, and faster than drawing 3 background colored boxes on top of the characters.
The next thought was to use the variables to store the actual character position in the screen, instead of the positions in the grid and doing math in all the loops.
Then, as the sprites are not the same size, I adjusted their positions so they looked centered in the grid squares, instead of “hanging from the corner”. That is, H starts at 2 instead of at 0 to center the 9 pixels sprite in the 12 pixel grid square.
But, that broke collision detection, since now the player’s H would never match the monster’s X
There are 3 ways to fix this. Doing additional math, with is kind of a waste, use a grid and array to store position – for example, X going from 0 to 20 and storing the screen coordinates for each position in X(19), or redo graphics to make them all the same size, which will affect the look of the game, and probably take more time. Also… who knows if I can get all the characters fit nicely in 12×12?
I guess I could do a mock-up to see… OK this looks good… Damn! I am doing the new graphics
Welllllll, I hope it rains next weekend.
As I expected, finding the software was not difficult at all.
Thanks to a USB card reader that is old enough to have Win98 drivers, moving the disk images and ZIP files to my internet impaired P-III was easy.
I was also able to find in some old backup CDs a copy of “HD-COPY”, the “Cardware” program that I used back in the day. It still worked flawlessly, and in a matter of minutes, the disks started to fill.
Some that were not new came out with some bad sectors, but HD-COPY does auto-verify and can low level format the disks if needed. It also auto-detects sequences in the source file names (if you read DOS6-1.IMG and there is a DOS6-2.IMG it will load it automatically), and starts writing to a disk as soon as one is inserted.
Well, not much of an update. All the good floppies I have are ready to be loaded into the Acer.
Using HD-COPY was a nice trip down memory lane. I used to work in a bootleg software store back in the 90’s and I would usually spend hours making disks out of IMG files with it. Again, a great piece of software with many, many options, including the DMF 21-sector, 1.68 MB format that Microsoft used to deploy Windows 95.
Yes! “Hippo Teeth” is completed!
well, there wasn’t that much left to do, mostly, get the “play again” option working.
The simplest way to do this is, of course, to run the program again, which would be fine since I’m not keeping a high score.
But, as I mentioned before, the background image is being loaded as a file. If you are running an emulator, or using any hard drive solution, this is probably fine, but for a floppy disk system, or even worst, a tape one, a better solution had to be used.
It was then that I remembered that the (C)LOADM command accepts an additional parameter, offset. Using this, I could LOADM the background to the memory range 1537 – 2049, normally used for the high-res modes. Then, at any time, it was just a matter of copying the memory content from there to the 1024-1536 range to have it “loaded” in the visible text screen.
As simple as FOR A=1537 TO 2049:POKE A-513,PEEK(A):NEXT
Then, I needed to restore the vertical position of the worm to the original one. As this is stored in a 3×3 array (3 possible horizontal positions, 3 lines in the graphic) with values that are READ from a DATA statement, RESTORE was clearly an option. I decided to use it, and basically reinitialize the game, going back to the first lines used to set the game variables.
This saved the space that would have been needed to reset the variables somewhere else in the code (I’m still thinking about eventually making a 4 KB version). A CLEAR was needed to make sure all was reset, but also keeps me from implementing a high score or something similar.
Eventually, by rearranging the order in which the variables are initialized, I will probably be able to have a high score list, and some other nice things. I wonder if the game is worth it?
The next step was to tweak the sounds a bit. I have been using the SOUND command, and for a while, I thought about replacing it with PLAY, since I could use just one PLAY to play multiple SOUNDs, saving some space.
I was surprised to find that SOUND can produce higher pitched sounds than PLAY, and PLAY goes lower than SOUND. After going around for a while trying to find the equivalent PLAY to the SOUNDs I was using, I realized that in a CoCo with Extended BASIC (the one that has PLAY), I would have 16 KB as minimum, so saving a few bytes by using a command that would not be available in the 4 KB machines did not make much sense.
Just in case anyone is curious, The closest PLAY equivalent I got to SOUND 150,1:SOUND 100,1:SOUND 50,1 was PLAY”O3L16GC+O2A-“.
Finally, I started compacting the code the usual way. Merging multiple lines in one, removing spaces and remarks, etc. I went from 70 lines with 3825 characters (according to Notepad++), to 37 lines with 3309 characters. Not bad at all.
I kept a copy of the “uncompacted” code, as it will make it easier to work with it in the future.
Well, that is it. The game is ready!
As the gameplay has not changed at all from what is seen in the previous video, I will leave you with the game’s code, the background code, and a DSK file, ready to play.
Looks like I could say “It is finished¨. Of course, anyone who ever wrote a computer program knows that you are never finished, but, at least I can say that “Russian Roulette” has been properly “Remixed”.
As I mentioned before, there were only 2 tasks left. I tackled the sound first, and even when the results are not great – there is no way to generate noise from BASIC in the CoCo – I think that they are at least acceptable.
For the “Bang” sound, I changed the original PLAY”V30O2L32CF”, just 2 notes in the 2nd low octave, to V30O1L254T254ACDEFAV20ACDBV10FACD. That is 14 notes in the lowest octave, as short as possible, arranged in a somewhat random fashion to simulate noise. There is also a slight “fade-out” effect by changing the volume from V30 to V20 and finally to V10 while playing.
The “Click” went from PLAY”O5L64;12″ – a single high pitched note – to O5L96T4BABB. Not a great deal, but at least a bit better.
In the original, the sounds will only be played in one place in the code. But as I added computer “players” that can also Click and Bang, I used an alphanumeric variable to store the PLAY string, to save me from typing the whole Bang sound twice.
For the ending, I wanted to do something a little bit fancy, but without going crazy.
I thought about changing the color assigned to the palette entry for the background to do a kind of “fade out” effect, but in the end I went for a kind of wipe-out.
Using 2 FOR/NEXT loops to print spaces with a different background color than the one already on the screen was very simple, and I went to use 2 PRINT statements. One would go from top left to halfway down, and the other from bottom right to halfway up.
But something was not working. For whatever reason, I’ve always ended up with a space in the original background color on the top left.
Eventually, I realized that, regardless of what was PRINTed on the screen, an extra character with the cursor would be placed right after it. Therefore, when I was printing in the bottom right corner (39,23), that extra character would print in the next line, causing the whole text screen to scroll up. This, in turn moved the 2nd top line up (still in the original background color), and caused that “leftover” character.
Since the computer was actually printing 2 characters for each PRINT command, and I should not print on the last position, I changed the loop that tracks the horizontal position to use STEP 2, and to go only up to 38, ending up with this:
510 FOR V=0 TO 11:FOR X=0 TO 38 STEP 2:LOCATE 39-X,23-V:ATTR 0,0:PRINT” “;:LOCATE X,V:PRINT” “;:NEXT X,V
And finally, the simple trick of printing one character at a time for the final message.
520 LOCATE 6,10:FORX=1 TO 25:PRINTMID$(“You are the last survivor”,X,1);:FORL=1 TO 30:NEXT L,X
The reason I did not use the palette fading effect was that I thought to use it for the “death” screen.
In the original, I switched one of the low res screens, set a blue background, and then painted it red from top to bottom by drawing lines.
1130 WIDTH 32:PMODE 1,1:SCREEN 1,0:PCLS 3
1135 COLOR 4
1140 FOR A=0 TO 192 STEP 2:LINE(0,A)-(256,A),PSET
I guess I was trying to do something like a veil of blood falling over the player’s eyes…
Looking for colors that would work for a fade from the magenta background to red, I realized that there were not really too many. By changing the default background to a darker shade, I was able to get another one, which is kind of enough for the effect to work.
340 FOR A=1 TO 5:READ P:PALETTE 6,P:FOR W=1 TO 100:NEXTW,A
350 DATA 9,8,7,6,5
Well, that’s it. A second game remixed. I leave you with some screenshots and the listings for both, the original and remixed versions.
Ooooppsss! I just figured something out. More than a few times, when it’s the player’s turn, the game will just react as if a key had been pressed, and move on. This seems to be because any key pressed after the INKEY$ is stored in a buffer, and goes is used later. Adding an extra, bogus INKEY$ seems to have taken care of this.
95 A$=INKEY$:IF A$=”” GOTO 95
As I went back to rewrite what I had lost, at least I remembered most of what I had done. And is not as if it was a great coding challenge. It is quite a simple program.
One of the first things I did was to include multiple computer players. They are quite dumb and will just pull the trigger when their turn is up.
When the game starts, you are asked “How many opponents” from 1 to 5 will play with you.
Then, after you go first, a simple routine takes care of your rivals.
2010 FOR R=1 TO O:CLS:C=C+1:IF C>6 THEN C=1:B=RND(6)
2020 LOCATE 5,5:PRINT”Rival #”;R;” aims and …”
2025 FOR W=1 TO 1000:NEXT:IF CB THEN LOCATE 15,8:ATTR 2,7,B:PRINT”!-CLICK-!”;:ATTR 3,6:FOR W=1 TO 1000:NEXT:NEXT R
2050 IF C=B THEN PLAY”V30O2L32CF”:LOCATE 15,8:ATTR 3,3,U:PRINT”!!!BANG!!!”;:ATTR 3,6:DP=DP+1:C=0:B=RND(6):FOR W=1 TO 1000:NEXT:NEXT R
2090 LOCATE 0,8:PRINT:O=O-DP:DP=0
Having other players gives you the possibility of having a bit of strategy for the game. If the last 4 rivals “click” their shoots, you know that there is a good chance (2 in 6) that your chamber will have a bullet in it. Time to buy a spin, or aim for the floor.
I followed by modifying the “spin” and “aim” routines. Before, the program went back to wait for you to press any key. Now, after you decide to do either action, you shoot.
Finally, it was just a matter of translating and relocating the text.
After a few test runs to tweak and make sure all was OK in the game’s logic, I added a bit of flash when the gun fires. Nothing fancy, just
That makes the background color a light yellow, plays a short pause (does the same as an empty loop, but is far shorter in code), and then restores the original color to the background.
The last two things I want to add are a congratulations screen if you are the only survivor, and better gunshot noises. Probably something like what I used in “Minecamp”
But is already almost midnight. That will have to wait for tomorrow.
After finishing the “Aliens” Remix, the next game in my list of candidates for a remix may seem a bit odd.
It is probably quite clear, even without a translator at hand, that “Ruleta Rusa” is a simple text based “Russian Roulette” simulation – let’s not call it “game”.
When you run the program, you are told just “It is chamber #1”. When you press a key, it is either “!-CLICK-!” or…. “!!!BANG!!!”.
If you are still alive, then you are also told that you won an extra $10, and now have a total of $40.
But there are a few extra things that you should be told before starting.
You clearly start with $30, and besides making you… not rich, the money can be used to spin the gun’s cylinder – for a mere $40 -or to aim your shoot to the roof – for just $25.
Also, you can walk away at any time. But, if you do it too soon, the audience may feel cheated and shoot you in the back.
After playing the game a few times, the goals of the Remix were clear.
- Show you the available options!
- Change the colors (white text in light blue background, with a green-on-red “CLICK”)
- Add computer players who can get shoot too.
- Translate it to English.
I exported the code to a TXT file, and started editing in Notepad++.
After a while, I moved it to a disk image, and tested it in the “VCC” emulator. It was then that I noticed that text that was supposed to blink, did not blink at all!
Looks like it has been a defect in the emulator that I never noticed before.
So I moved to MAME, kept coding.
After a while, I decided to call it a night. I was, I guess, mostly done.
But when today I was about to start writing this entry, and loaded the disk image… the files had not been saved.
I’m 100% sure I told MAME to mount the disk as “Read – Write”, and even loaded and saved a few times while working. But all is gone now. Just the .BAS file that I wrote in Notepad++ remains.
I guess is back to the keyboard.
I was still going over whether to make the game for a 16 KB or 4 KB CoCo, when I realized that variables are taking quite a lot. And it is understandable, since basically all graphics are stored in alphanumeric variables. With almost 2 KB in variables, and over 2 KB in code… well, there is no room for it in a 4 KB machine.
Therefore, right now, I’m going for a 16 KB machine, with Extended Color Basic, and disk drive. Once I’m done, I’ll rework it for Standard Basic and tape.
Knowing that I had plenty of room, I started adding some nice things.
First, a simple welcome screen, with the hippo moving it’s tongue and blinking.
Then, I made the worm move up as the teeth are being eaten, to keep it “touching” them, by updating the variables that store the position where the worms is printed, every time that a tooth’s piece is eaten.
I’ve also included a not so good version of the game’s intro tune, and the constant “peek-peek-peek” sound, just as in the original game. Somehow, it does not seem that annoying to me. Perhaps because the game is short, or because I’m the one playing it. It will probably annoy the heck out of anyone around… 🙂
And finally, there is a “Game Over” screen, where you are asked if you want to play again. But… the option to play again does not work yet.
In order to go again, I will have to redraw the teeth. But they are not actually drawn in the game, they are part of the background that is loaded form a separate file. And I don’t want to load the file again and again every time that the game is replayed. I got something half figured out, that will (should) take very little additional code. I may try that tomorrow.
Here is a new video of the game.
In the “to-do” list, I have: 1) Improve the sounds and music 2) Get the “Play again” option to work, and 3) Compact the code.
Once everything is ready, I’ll try to get it to work in the more limited Standard Basic, and who knows, seems like porting it to other old micros (C64, Spectrum, etc) should not be that hard…
OK! This was fun!.
Then, yeah, I made it so that only one alien will move in each loop. This, of course speed up the game.
And then I realized that there was a lot of speed being wasted somewhere else.
You see, the aliens and the player are 8×8 sprites. And every time an alien moves, the H and V positions change by 8
350 IF Y*8V(A) AND PPOINT(H(A)+4,V(A)+12)=1 THEN V(A)=V(A)+8
370 IF X*8H(A) AND PPOINT(H(A)+12,V(A)+4)=1 THEN H(A)=H(A)+8
But, for whatever reason, the player’s X and Y change by one, and then the sprite is PUT in X*8, Y*8
140 IF PEEK(341)255 AND Y>0 THEN IF PPOINT(X*8+2,Y*8-6)=1 THEN Y=Y-1
150 IF PEEK(342)255 AND Y0 THEN IF PPOINT(X*8-6,Y*8+2)=1 THEN X=X-1
170 IF PEEK(344)255 AND X<31 THEN IF PPOINT(X*8+10,Y*8+2)=1 THEN X=X+1
This means that every time I PUT, and check for collision, slow multiplication has to be used.
By changing it to work as the aliens already did, everything is again a bit faster.
One of the changes I made caused the aliens not to be drawn until they move. It actually seemed kind of cool, so I left it like that.
And I think that the final change is that the difficulty level now influences how far away from the start is the victim going to be.
Wanting to see how much faster or slower the game was, I used the TIMER variable, which “tics” 60 times in a second. By setting it to 0 at the start of the loop, and printing it at the end, I could get a fairly decent idea of the game’s “framerate”.
The original took from 13 to 20 tics, while the new one took… between 8 and 20!
Success! Not only the game looks and plays a bit better, but it is also faster!
Let’s take a look at the remixed “Aliens”
I hope you like it, at least a bit.
And, in case you are curious, here is the source code for the Remix and for the Original versions.
Well, yesterday I spent a few hours coding the “Hippo Teeth” game, and I was surprised at how easy it all seemed to flow.
After saving the background image as a BIN file, that could be LOADM’d from the main program, I went ahead with creating and animating the “Sprites”.
The player’s controlled Doc can be in just 3 positions, one below each tooth. So I used a variable P to track those. As the graphic of the player is made up of 5 lines of 3 graphic characters each, I also use P$(5) to store the 5 strings. Then another array P(3,5) to store where each of the 5 strings should be printer for each of the 3 possible positions.
That is, when the player is in the 2nd position, I print P$(1) at P(2,1); P$(2) at P(2,2); P$(3) at P(2,3) and so on.
I did the same with the Worm and the Tongue, but for the Smoke, it was a bit more complicated, since it can be in located in a 3×4 grid.
Actually, my first problem was that the game was running too fast!
Each teeth has 40 “life points”, and I was subtracting one for every loop that the worm was under a specific tooth. I had to cut that down to 0.25 for each loop, which actually gives the teeth a life of 160 points.
I made a single change to the game play.
In the original, the tongue could move to “cover” the worm, and stood there, blocking your shoots, while the worm ate the tooth.
Now, if you shoot a “clean” tooth, the tongue may move to that position, leaving the worm open for a shoot.
So far, the game is taking 2570 bytes of memory, and I realized that I’m using some commands that are not in “standard” BASIC (STRING$, TIMER).
I will need to figure out if the game will target a 4 KB machine with tape, or a 16 KB one with Extended BASIC / Disk BASIC.
If I go for the 16 KB machine, I can make some extra animations, and with Extended BASIC, probably nicer sound.
Here is a video of the game after under 3 days of work, with sounds mostly as “placeholders”
And yes, I need to figure out why sometime the smoke cloud is not deleted…
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.
While I was at work, I managed to find some time to go over the code of the first game in my list, titled “Aliens II”.
By looking at the game, I found a few things that seemed easy to improve/fix.
There is a lot of flickering, and using page flipping should fix that.
The maze is not well designed, with lots of dead ends that tend to block the alien’s movement, and can force you to take very long paths to get to a particular place.
The time available to complete each level is just not enough in most cases, and finally, the text messages is horribly placed on the screen.
In the code, I found that the DATA for the graphics is on top of the code, instead of in a routine at the end.
Then, I realized that implementing page flipping to minimize flicker is not going to be that easy.
The game keeps the maze in one of the pages, copies it to the second, and draws the “sprites” there. In the next cycle, instead of erasing the sprites, the clean background is copied again from one page to the other.
This means that, in order to use the page flipping technique to eliminate the flicker, I will have to add the commands to delete the sprites from the old positions. This will make the game slower…
Moving on, I found this:
910 IF PEEK(344)255 THEN IF X<31 THENIF PPOINT(X*8+10,Y*8+2)=5 THEN X=X+1:GOSUB 1040:
And the line 1040 is just….
OK, then, first task, speed up the game.
Rearrange the code to bring the main loop as close to the top as possible, declare all variables at the game start, giving priority to the most used ones, find some numbers that are used a lot and change them to variables.
Then, the game’s look.
I decided not to change the graphics. They are quite …. bad, let’s face it. But I guess is part of the game’s personality. The only real change will be to get rid of the white color and change it for green. Fits better with the game idea. And of course, the text must be aligned better, not just dropped anywhere in the screen!
And finally, game play.
The maze needs a redesign. Not a major one, but it should be easier to go from one place to the other, for both, the player and the aliens.
And like I said, the time available is not enough.
Here is a video of the original gameplay.
And the sound! What was I thinking? I believe that i just took a part of the music from some demos in the CoCo’s manual.
Should that stay or should that go?
Well, I guess we’ll see… tomorrow?
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?
My First Challenge, as you may remember, is to fully load an AcerNote730i laptop, with software to match it’s manufacture date of 1995.
I guess I can divide it in three.
1) Choose the software,
2) Get the software, and
3) Load the software.
Even if the computer is from 1995, Windows 95 is clearly out of the question.
Windows 3.1 should not be a problem, perhaps with the computer booting to DOS, and loading Windows manually when needed.
X-Tree was one of my favorite programs back in the day, and it will find its way in there.
Norton Utilities, or at least Norton Disk Doctor should also be there.
Other programs that I used back in the day were Quattro Pro, Arj, Compushow…
Some games must also be there. Maniac Mansion, Master of Orion and Doom seem like a good way to start.
Getting the software should not be that hard. I still have copies of some of the one I was using back in the 90’s, and sites like “Vetusware” make it relatively easy to find almost anything from that time period.
The real challenge will be to get the software into the computer. As I mentioned before, it has no PCMCIA slot, nor network card. That leaves only the serial port and the floppy drive.
I do have a P-III with a floppy drive, and I could get the software to it from either a CD or a CF card reader. But I have not used the floppy drive in years…
And to use the serial port, I will fist need to get a terminal program into the laptop, so I would still need to use the floppy drive for that.
Well, I guess my next step will be to test that floppy drive, the few disks I still have around, and perhaps try to get a few more from somewhere. Let’s see how it goes.
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….
OK, not that they were going to reject me or anything like that, but the last 2 times I tried to participate in the RetroChallenge, something got in the way. (The last time was a trip to the US that allowed me to go to my 2nd “CoCoFest”, so I can’t complaint about that one).
At least, this time I’m writing the first blog post, and that is much more that I managed before.
I decided to take 3 challenges, 2 of which have been in my mind for quite a while, and I will try to write individual posts for each.
The first one is related to an old laptop a friend gave me for free some 10 years ago. An AcerNote730i (486SX,4 MB RAM)
It was clearly designed from the start to be a limited machine, as it has almost no expansion options. Just a parallel port, serial port, VGA, PS port and a floppy drive. No PCMCIA slot or network card.
The hard drive was clean except for some leftover DOS files (From a Windows 95 boot disk).
Eventually, I got to install “Maniac Mansion“, but never gave it the attention it deserves.
Then, the First Challenge is to install a full DOS and software package, including some games, utilities and productivity software in it.
The second challenge came to mind after writing a couple of games for my Tandy Color Computer 3.
I realized that I was always using the high-res modes, full 128 KB memory, and requiring a floppy disk (real or emulated).
But I had nothing that would run in the old Color Computer 1 or 2.
So, my Second Challenge, is to write a game that will run in any CoCo, using the low-res graphics mode (64×32) and no more than 16 KB RAM.
The third challenge is somewhat related to the second.
Not long ago, loaded all the programs I wrote in BASIC from 1985-ish to around 1995 and created disk images with them, to play them in emulators or in my real CoCo using the SuperIDE card.
A few weeks ago, while optimizing one of my latest programs, I realized that I could probably improve some of my old ones, creating perhaps a “Director cut” or “Remix” version of them.
Therefore, my Third Challenge is to look through my old programs, find some that could use some cleanup, and try to update them.
Well, maybe I’ve overextended myself…. Time will tell. I have 30 days and counting.
6 years ago, I started to write “Furious Felines”, and 6 months later, it became the most complex game I had written to that date.
It has quite nice high resolution graphics (320×192), the graphics and levels are loaded from individual files, making it easier to maintain, and allowing me to go past some of the memory limitations of BASIC, and people seemed to like it.
I did like it too, but there were some things that I’ve always thought could be improved.
The “wind” was the one that I really did not like, and some of the graphics, specially the trampoline onto which the cats jump, were kind of…. off.
A few weeks ago, I finally made up my mind and starting re-coding it.
And then I could not stop.
I changed the way the wind works, then cleaned up the code, and then added new features, and then improved some sounds, and then improved some graphics, and then… STOP!
If I kept going, instead of version 1.1 it would be 2.0! (And I have plans for a 2.0)
Here is what I finally decided to change / update / add:
Used to be part of the level, loaded into VV, and then modified this way:
It will then affect the cat’s horizontal position by H=H+VV+0.1+LO*0.5
Now, it simply is initialized as VV=RND(3)+1 and then used as H=H+VV+LO
A lot simpler, and always an integer.
Enhanced some graphics.
Since I was redoing the way the wind works, I changed the indicator, from simple “>” characters to actually DRAWn arrow shapes.
The spring onto which always looked to ugly. I’m not sure if it looks any more like a spring as it did before, but at least I gave it some “shading” and color.
In the background, I added a second type of window for the buildings in the background, simply by adding a black cross on top of some of them.
And now there are stars in the sky!
And then… I said to myself: “What the heck, I’ll do it.” and added a change in the gameplay.
I added a new element. A piece of cheese that the mouse will try to steal. This will give the game a sort of time limit, and put some pressure on the player to catch the mouse as soon possible.
Now the mouse had to be able to chew trough the walls. To do this, I just draw a black vertical line ahead of the mouse when it collides with a wall and is pointing to the cheese. This effectively “eats away” a small part of the wall.
By making this change, most of the levels of the original game had to be changed. Just dropping the cheese anywhere would not make it a good level, so I went ahead and updated most of them. As I was at it, I added another 2 levels, for a total of 8. (It is still quite easy to edit the levels file to change them or create new ones)
This, of course, required testing and retesting all levels to make sure they were winnable, even in the second round when the wind is stronger, and also tweaking the screens where the score is shown to make room for the higher scores that are now possible.
With this changes, the game became “Furious Felines 2, Save the cheese”
At this point, the game was almost ready.
The flickering in the cat’s graphics as they flew across the screen annoyed me at some point – it is mostly created by the time the computer needs to draw the cat on the screen – and with the help of the great CoCo community, it got mostly under control.
Finally, I changed a bit the intro’s music – which can be skipped, most of the times, by pressing any key – and added a not very neat way to change the color palette to make it look as it should in a TV or RGB monitor.
Well that should be it.
You can download the game from my CoCo website, where there is some information on how the game works, and how to tweak the levels. There is also a manual, in printable and a PDF versions.
If you try it, please let me know what you think of it.
Todavía me acuerdo de la primera vez que instale Windows 95.
Cuando mi pobre 386 termino de cargar, pasé un buen rato mirando las opciones de colores, configuración, y después… creando iconos para mis juegos de DOS. El hecho es que en 1995 no había muchos juegos interesantes para Windows.
Para 1998, las cosas habían cambiado bastante, y gracias a DirectX, prácticamente todos los juegos salían directamente para Windows.
Así que, cuando tuve Windows 98 (2a. edición!) pronto, llego el momento de instalar, no solo el US Navy Fighters, sino también algunos de mis juegos favoritos de todos los tiempos y otros clásicos.
US Navy Fighters 97:
Advanced Dungeons and Dragons rules:
No One Lives Forever:
Blood 2: The Chosen:
European Air Warrior:
Heroes of Might and Magic III
Ahora, a jugar!
Habíamos quedado con Windows 98 instalado, pero con grandes problemas de los drivers (controladores, para los fanáticos del Español).
Video de 640×480 con 16 colores, sin sonido, sin tarjeta de red… Y se podría pensar que conseguir los drivers para una computadora que tiene 15 años seria bastante complicado…
Pero no. El sitio web de Dell tiene todo lo que se necesita, incluso para modelos mucho mas viejos. Gracias Dell!
Así que, descargue los archivos desde mi PC moderno, los copie a un disco USB, y…. nada.
En estos días uno esta tan acostumbrado a cosas que funcionan, que me había olvidado por completo que Windows 98 no reconoce discos USB a menos que se instale un driver, que no tenia como instalar.
La alternativa era usar un CD. Pero… ¿Cuantos de ustedes tienen CDs vírgenes por allí? Yo tampoco.
Por un momento pensé en moverla hasta donde llegara un cable de red, y conectarla a Internet, pero entre los drivers que necesitaba estaba el de la tarjeta de red. Ya me veía saliendo a buscar CDs vírgenes, cuando me acorde de unos CDs que me salvaron la vida.
“Puppy”es una distribución de Linux que no necesita instalase en el disco, y esta diseñada para PCs con recursos limitados. ¿Podría funcionar en un PC tan limitado?. Si, definitivamente si.
Desde Linux, solo necesite entrar (lentamente) al sitio de Dell, descargar los archivos correctos, y guardarlos en el disco de Windows. En realidad no fue tan fácil. Incluso Puppy Linux se complico con la poca memoria, tratando de usar todo el OS desde RAM. Cuando ya tenia el driver de la tarjeta de red pronto, pensé en seguir la descarga desde Windows. No. Internet Explorer 5 no tiene ni idea de que hacer con una pagina moderna (no es que Internet Explorer 10 u 11 se manejen mucho mejor), asi que, reiniciar en Linux de nuevo, y terminar de bajar los drivers.
Pero finalmente, valió la pena.
Hace unos días me econtré queriendo jugar a uno de los simuladores de vuelo que, para mi, marco una época.
Pero, como era de esperarse, Windows 7 no es lo mejor para un juego de la época de Windows 95.
Pero decidí que eso no me iba a impedir jugar USNF97 como se debe.
Y para eso, el “Proyecto Windows 98”.
Tengo una Dell Optiplex 150, que salio de fabrica con Windows 98 (aunque ahora tiene Windows XP).
Es una Pentium III de 1 Ghz, que con 256 MB de RAM y un disco de 30 GB resulta un poco demasiado para un PC de 1999, pero me puede hacer mas fáciles las cosas.
El primer paso, es reparticionar y formatear el disco. Windows XP usa el formato NTFS, y Windows 98 no puede instalarse en el.
Luego de reencontrarme con mi viejo CD de rescate (EBCD), FDISK y FORMAT se encargaron de dejarme con un C:\ utilizable.
El siguiente paso es copiar los archivos de instalación de Windows desde el CD al C:\WIN98. Si bien posible instalar directamente desde el CD, hacerlo desde el disco duro es mas rápido y confiable.
Al ejecutar “Instalar”, el programa primero hace algunas pruebas del sistema (básicamente, un scandisk), y cambia a modo gráfico para comenzar la instalación en si.
Entre las opciones interesantes, que nunca vi en uso, está la de instalar un “Servidor de acceso telefónico a redes”, que permitiría al la computadora funcionar como una especie de servidor web para conexiones por módem de discado. Aprovechando que el espacio en el disco sobra, instale prácticamente todo lo que se me ofrecía.
Luego de algunos minutos, y un par de reinicios, Windows 98 me daba la bienvenida… con una pantalla horrible de 16 colores.
Parece que tener esta Dell pronta para juegos va a tomar un poco mas de esfuerzo…
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.
A few weeks ago I was bored and stuck with a PC were I couldn’t run my 8 bit emulators. I then decided to go for QB64 and start on a project that had been running around my head for quite a while.
I’ve always wanted to write an adventure game, something like the classics from LucasArts, or Zork. And I had realized that writing an “engine” would probably be no more difficult than a stand alone game, with the advantage that creating new games would be much easier.
So I started working on what is now “eSage” (for ‘extremely simple adventures game engine’)
It turned out to be far easier than expected, and that led me to keep adding new features, to the point where I had to write a manual, because I couldn’t remember all the commands I had implemented.
The system is quite simple. Each game is divided in “Steps”, in which you are given options that will take you to other Steps, not unlike those “create your own adventure” books.
Each Step has a background image and sound, as many additional images and text as you want, with a list of options that determine to which Steps you can jump to, and the score that you get for choosing that option.
I eventually added support for multiple fonts and colors, random jumps, and a few other features.
It is still not finished, but I think that any improvements that I add from now on will not break the scripts from current games. In short, this means that if you create a game now, and I update the engine, your game will still work.
Here is a sample script:
Number of steps,5
text You are the new Captain of the USS Enterprise/H180/V5/C030444
text and have been ordered to patrol/H385/V6/C030444
text the Romulan Neutral Zone/H350/V8/C030444
Option Helm, set a course/3/10
Option No way, that is dangerous. Helm set a course for Risa/2/0
text While “relaxing” in Risa, you get a VD!/H250/V9/C400004
text Your career in Starfleet is ruined!/H280/V10/C400004
text Sir! A Bird of Prey decloaking on the starboard bow!//H280/V10/C400004/F2
Option Fire at will/4/3
Option Hail them/10/3
In a few days, I will be uploading the “runtime” program, eSage itself, and the manual, to http://www.hscomputadoras.com/HERMESOFT/hermesoft.html