I always had a fascination for Lander type games. In case you don´t know, it is a genre of game, one I would consider primordial, probably made more famous by the Atari Inc. 1979´s arcade Lunar Lander:
Landing is what you have to do, score points, do it again. It is real time visual and control game, side way viewed, rocket gravity simulation. Apart from the beautiful polygon visualization, you get a set of data on top, the ones on the right are redundant, more like a number visualization of the motions.
The genre is even older, graphic versions dating 73 on mainframes and text versions dating 69!
Here is what one text version is about, the game becomes turn based, every entry of fuel simulates a certain passage of time in block. Only vertical axis is considered.
Tell you the truth, I only met the arcade years later after its release, my first lander experience was probably some text version on a ZX81, than graphic ones on the TRS-80 Color computer (COCO)... and I can´t quite remember any, I thought them uninteresting :D
It was late 80s when I think I stumbled into a TRS-80 model III graphic version, this one here:
Bitmap based, quite a low resolution, but it has some very neat details. The mountains have textures and the game has a cool clean cut zoom where things get really big, fantastic! Like Art of Fighting or Samurai Shodown on the NEO GEO :D
But it wasn't the cinematography technique that got my love, no, it was well executed, probably one of the very "firsts", fits the genre, bigger sizes add to the precision this game requires to produce the tense feeling..
So what made me blink was quite different, the whole zoom and scrolling around awakened a feeling of curiosity towards exploration, like a kid checking out the world with a magnifier. But see, it was not quite about the zoom, but about finding a living and thriving world going on.
Well, I never found any... you sure have a share of more action and shooting versions out there but they don´t spark the explorer in me.
Let's venture fixing that and do a Lander type game on the COCO in Disk Extended Color Basic (DECB). Instead of the land > points > restart cycle, let's make it an open world, and when you land, something like an adventure type of game kicks in, this could push that exploration hit.
Before advancing the concept, I have to say that I have an opportunity to have it code list published on Jogos 80 magazine, an almost 20 years Brazilian retro game magazine. Super cool!
First the burocratics, there are 2:
- Deadline. It should be done by 4th of July.
- Print size. The game must fit ~19200 digits.
Graphics, that means we must choose a resolution. I´d be comfortable with text semigraphics 4 (SG4) because that is something I have been messing with for a few years now, but I suspect its resolution, 64x32, might not cut vertically enough to pass the feeling of gliding.
This is what the SG4 resolution is about, the screen is composed of stamps of characters and colored 2x2blocks, each containing black and a color. This means that this is actually 32x16 pixels... work those sub pixels may be tricky because the ship moves over all axis, but I do believe this very hard work would be in vain.
Here is a test. The minimum ship size is a 4x4 pixel square, exactly a stamp/block size.
Things are just too small, precision will suffer, it will affect the game's tension.
Here is a test. The minimum ship size is a 4x4 pixel square, exactly a stamp/block size.
Things are just too small, precision will suffer, it will affect the game's tension.
Landing is a vertical thing (not Wings of Fury, no), specially more vertical resolution is a must.
I mean, it could be done some other way, but I would have to, probably, mess with the core gameplay on the lander part, and I would like to keep this pure.
That leads to using graphic resolution on the lander part, keep the text SG4 for the adventure mode... it has text :D
While SG4 is on point, graphic res is something I haven't messed with for some 35 years maybe...
So this will require that some code tests be done prior to start the project.
So this will require that some code tests be done prior to start the project.
The tests are all about graphic techniques, speed and memory usage.
While landers are fine as a slow game, they are still action with constant precise per pixel motion.
First let's look at the so said graphic resolution. I could use one of 2 modes, PMODE 0 or PMODE 1.
Both are at 128x96 pixels. PMODE 0 has 2 colors, can be either black and white or some sort of green. PMODE 1 has 4 colors, you can use one of two unchangeable color palettes. Here some of them:
See those 2 color modes? Yeah, those palettes are going to be a challenge!
The screens also have a border, like the green one, on black and white, it is white and so on the purple colored one. I will drop the green and black one not shown here.
Any of these modes could work fine. It seems the black and white is just a little bit faster than the colored modes.
There are 3 standard ways to draw on these modes on DECB. Actually 4, you may POKE the screen memory address but I will skip those wizardry for I can't handle :D Also, while these screens are 128x96, their coordinate system inside DECB considers them 256x192, to move a pixel, move 2 coordinate units. It also starts at 0, so 0-255 x 0-191:
- PSET (X,Y,C) Draws a pixel at coords X and Y. C for color or skip it to use the foreground color. You can use PRESET(X,Y) to draw a background color pixel. This is a primal command. It is versatile and can be made to recreate all the other commands.
- LINE (X,Y)-(Z,W),PSET Draws a line from coord X and Y to coords Z and W. PSET is used for foreground color, PRESET for background color, you may also add ",B" or ",BF" after PSET for a box or a filled box.
- DRAW "BM10,10;U5;R15;D2" This is an interesting command, it executes what is on quotes as if it is a sub language specific for drawing vectors, like a digital Etch a Sketch. More on this later.
There is also an extra way of drawing stuff on screen, the commands GET and PUT. It works as a copy and paste, you first capture/memorize a square piece of the screen, then you go about stamping it.
GET (X,Y)-(W,Z),V,G This memorizes the square area between those coords. The V variable is a 2 dimension variable you declared before and it must contain the appropriate size to hold the amount of pixels intended to memorize. G is a option that deals with objects out of the byte/pixel position, we are going to use it because of the per pixel needed.
PUT (X,Y)-(W,Z),V,PSET This stamps the drawing stored on variable V on the told coords, the opposite corners must be apart the same size from the GET. PSET will stamp every pixel but you can use PRESET, OR, AND, NOT, each of these creates a different blending result.
Also, the color computer has no alpha, no transparency, when we say "erase" or "delete" it actually means to paint over with a defined background color.
So I made a bunch of programs to test drawing same stuff doing a measured motions using these techniques. Primary objective is speed, secondary is memory consumption and both these worries will accompany the rest of the project.
1 DIM TM,X,Y:Y=86 :REM VARIABLES
5 PMODE0,1:SCREEN1,1:PCLS :REM SET SCREEN
10 TM=TIMER :REM SET TIMER
20 LINE(X,Y)-(X,Y+14),PSET :REM LINE
30 X=X+2 :REM MOVE
40 IF X=256 THEN ?@481,TIMER-TM;:END :REM QUIT
50 GOTO 20
This is more or less what each test is about, this example, full of REMs, moves a 7 pixel vertical line right for a while and marks the time. The smaller the better.
Here are some of the results:
HORIZONTAL MOVEMENT 1 PIXEL TIME SIZE
PSET 111 144b
LINE 136 153b
DRAW 292 186b
GET/PUT 141 221b
If moving a single pixel is all that is needed, PSET will beat em all. Notice the huge time on the DRAW routine, mostly for doing string manipulation to alter coords. Check the size GET/PUT takes, a bunch more than PSET, that is because it has to declare a 2 dimension variable and because prior to stamping, you also have to draw the image to capture.
HORIZONTAL MOVEMENT 2 PIXEL TIME SIZE
PSET 151 -
LINE 151 -
GET/PUT 157 -
DRAW didn't seem to be going good here so I dropped it. Notice 2 pixels and they are pretty much on par! GET/PUT will still take more memory.
HORIZONTAL MOVEMENT 4 PIXEL TIME SIZE
PSET 232 -
LINE 152 -
GET/PUT 157 -
4 pixels horizontally arranged and PSET farts out of the speed race.
HORIZONTAL MOVEMENT 8 PIXEL TIME SIZE
LINE 166 -
GET/PUT 171 -
8 pixels now and going, but above this point the LINE command gets too specific, so only room for GET/PUT.
HORIZONTAL MOVEMENT 16 PIXEL TIME SIZE
GET/PUT 184 255b
Here is the speed one gets moving a 4x4 square. Not bad! Also, the size is not too different from the single 221b on the 1 pixel. Cool.
Hopefully I didn't err. To sum up what I could make out of the data:
If you need a single pixel drawn on a cycle, PSET is you man.
2 pixels and all techniques will be on par.
4 pixels and PSET farts out.
8 pixels and above than GET/PUT really rules them all, specially for being able to paste anything.
It is also important to remember that if GET/PUT operates within the boundaries of a byte, 8x8 pixels on screen I believe, it will move MUCH faster without that G option. Unfortunately it won't be useful here.
One BONUS is about those PSET, PRESET, AND, OR, NOT you can use on PUT:
PSET will stamp your memorized square sprite.
PRESET will stamp the square sprite as a solid background color.
AND will do some funky shit.
OR will do even more! In this case, the background color won't be stamped.
NOT will get what is on the square and flip it.
While these might not look like much at first, there is quite the hidden potential everywhere you sniff.
It is a bit tricky to figure the AND and OR out, but it is a start on testing them. Maybe look deeper into it on a future game. If you want to learn more about it, check the excellent OG Steve Strow's lesson on it here:
I believe it's safe to say we could draw the background stage with the DRAW command and try to perform the action with GET/PUT.
Time to get back to the game.