I thought about how would those 8x8 tiles, originally black and white, handle artifact colors. As we can see, it is very hard to get tanks with the 2 pure colors. So what about a single color and some 3d?
Here is some testings:
So here are 4 frames for each single colored tank, tiles for the background and color ramped tiles for whatever FXs.
This is what they look, and is also the tile set file needed to run the code:
Finally, a Scene Maker to test the tile set in action:
Ops, updated the engine:
Code should be much easier to understand.
Randomicity on number of layer repetition (displayed on the lower right, when available).
Layer with tanks!
Got rid of the ugly fences.
The ugBasic UPDATED source code, files and COCO binaries are here:
Last month a new disease was found going on the country side. Those infected go berserk in an eating frenzy, sort of rabies they say. It transmits through the saliva and has a fast infection rate, person goes crazy in a matter of minutes. The good side is that these people won't be catching any planes, said the government, so it is contained, and while dangerous and with no cure, they end up dying of starvation some days later.
Last week all sorts of communications went down. Not that they didn't work, it was just that nobody sent or responded anything. Some days later, people stopped showing up in town, merchants stopped travelling. It was something to do with rumors of people disappearing or never coming back, even those who looked for them.
Early today a few military trucks showed up, they were in a shocking condition, the captain said that the region has been declared lost grounds, that the condition is serious and they will do their best to carry the ones with needs but everyone should follow them east right away, for the infected will reach the area in 4 hours.
Well, it is now 5 hours past that speech, most people went away. I fail to trust those who were leaving us to a sudden death if not for the supplies they ended up taking. I think they won´t blink to cannon fodder me should the need appears. I got a car outside with some fuel, food, supplies and a gun, I may do better on my own with the others.
This is a zombie survivor rogue-like game for the Color Computer. Not a complete project yet but an exercise in code size reduction and possible features to keep. The plan is to create a 10 line version for the competition of the same name. More about the compo here: https://www.homeputerium.de/
This proof of concept works inside Adobe Photoshop through an ACTION, a PAL file and a layered TIFF file. One works with the TIFF file on an specific layer in an area of 256x192 pixels located on the Double Dragon colored preview you see here (top left):
The top 2 screens starts empty, you draw on the left one using the 2 rows of pure colors right underneath it, the rows below are what they will become after processed. There is a total of 24 colors to be used.
Notice some are marked background black? Those produce specific dithers that might not combine with everything and must be used considering its tone and texture, a good example is the blue/red brick color, the third from the left, you don´t want bricks on the sky nor the clouds unless you are doing a cloud city ;)
The pallets on the low right have 18 colors, they skip the specific ones, and are arranged as an RGB sequence, 8 hues with 3 shades each for the left scheme and 4 hues with ~5 shades for the right one.
These ones are easy to work with and good grounds for converting existing stuff, like the Double Dragon II screen shot you see there. This 18 color pallete is very close in appearance to the dithered artifact colors, it is best used when you want to create something original. For conversions, you might want to work-shift those tones into a more general RGB space and do the back indexing.
So, on the left screen, you then have your image/art using a palette that is contained on the lower pallete rows. Press F5 to activate the ACTION and it creates a layer containing the preview (as we actually see on the above screen shot) and a black and white equivalent to send to the COCO.
---
Art wise, it helps to better understand the native colors and dithers, so here are the 24 indexed pure colors you are going to do your art with, analysed with the superb DawnBringer's tool.
Discard the diagrams that deals with the pure colors dithers, they won´t work and the coco artifact colors already have their own dithers. Keeping that in mind, next is the previewed artifact colors:
As you can see, some of the diagrams are very inspiring into what can be done and how things are going to mix/blend in. Finally, you have the black and white equivalent just for fun:
An interesting aspect on the black and white version is its usage on the alternate green set (no artifacts) or on a Dragon computer. If it needs to be compatible with the COCO, then if it uses these dithers, you may know what it will look like on the other side.
The system is now complete as its intended goal, a proof of concept prototype running inside Photoshop that helps creating PMODE4 artifact colors. Only proper documentation is missing now ;)
Since this works just fine (at least for me :) ), it might be worth looking into making a better system or an add-on to an open source tool. What would you recommend?
Update: Here is the image running on the real machine and tube TV, courtesy of Luciano Scharf.
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.
So it is a lander game with bits of adventure when landed, all graphic. 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.
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.
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 TIMESIZE
PSET 111 144b
LINE 136153b
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.
