[Ramble Warning]Not sure if this is going anywhere so no devblog yet, this is mostly just about a particular oldschool artistic canvas.
Made out a quick and dirty mem save/load so I can start to draw things in my retro terminal.
The "terminal" emulates OEM (Code Pg. 437) VGA font. Character raster w/ 16 color FG/BG (CGA/EGA/VGA) palette & "color corrected" scanline emulation (compensates for "dimming" effect of adding dark scanlines to images).
On original CGA/EGA/VGA hardware you can only have 8 background colors (0-7) by default. BG 8-15 would be "blink mode" w/ BG colors 0-7. However, you can disable the blink option by writing to the device port and thereby enable all 16 colors for the text backgrounds. (I made a 16BG-COL.COM program to do this & set the config at startup via AUTOEXEC.BAT once upon a time). My "emulation" targets this 16 bg color configuration, even if it was rarely used back in the day. I can create blink-emulation by manually changing the raster data if desired, and assets can artificially limit themselves to 8 BG colors if so desired, so I should still be able to support the display of classic BBS era ANSI Art.
To smoke test this "old-school" gamedev platform I'm trying to come up with a simplistic game concept that uses BBS era graphics, minimalistic SFX & (mod file style) music. Was inspired by some of the cute skull-themes from Blocktronics. Here's one from b7 2014 Worlds Longest ANSI scroller, for example:
An 80x25 text window requires the skulls to be quite small even for a simple stacking game. I'm sure I can work in some more emotive juices with simple animations and more ANSI art, perhaps some cut-scenes. These are the smallest recognizable skulls I could pull off. Maybe I can scroll the play window a bit allowing me to make bigger skulls.
Note how the scanlines soften the edges of the pixel graphics, greatly reducing jaggies? That's a lot closer to how pixel art seemed, back in my day anyway. There's a bit of horizontal bleed as an electron gun naturally causes on CRT displays. Could use a bit more bleed to one direction than the other, but i was trying to make it fast enough for HTML5 fallbacks too. The terminal is a cross platform executable, but logic can easily be ported to the web.
Note how the colors bleed horizontally across the upscaled "pixel" boundaries.
(not really the best examples, but maybe I'll make a more detailed post in the tech forum)
I always want a scanline option in a game when I see crisp "neo-retro" crunchy indie-pixel graphics. Perhaps I'll port the shader to WebGL to make an "add scanlines" webpage so pixel artist can drop in pixel art images (no upload required) and view it with various scanline settings. (probably already exists somewhere, meh) If anyone's interested, I could have a prototype "scan-line preview" webpage made during break time.
The scanline effect I've produced here is a very simple and fast upscale filter. I could improve it, but it's already loads more warm and cozy than crisp pixels, IMO (your nostalgia may vary). Even in HTML5 Canvas I can reproduce the effect with not too terrible performance hit per frame.
The Blocktronics scroller mentioned above, in case anyone's interested:
Consider the fact that many of these ANSI artists have loved the canvas of 16 color 80x25 VGA text mode for decades, and yet still have incredibly limited (honestly, crappy) tools. With my project(s) I plan to give the struggling ANSI art scene a much needed shot in the arm via a toolset upgrade, and perhaps bring back the commission market for their nostalgic retro art...
I've enjoyed the
Rexpaint tool that
Cogmind's Josh Ge brings to the table, but we can do MUCH better than this for the limited 16 color VGA mode, and IMO ANSI artists deserve awesome tools.
---
Note that I said "color corrected" scanlines - Adding scanlines will inevitably darken the brightest colors in your game art, but you can compensate for much of the dimming (or all of it if you don't mind not having scanlines in very high intensity colors, see also: additive bloom filter). I (re)used an AI to generate the appropriate compensation table to use when in scanline mode.
My original use of this AI was to correct the dithering problem: Almost ALL dithering algorithms are just plain wrong, sorry, they are; And that's a prime reason that hand dithered pixel art looks so much nicer than algorithmic dithering: Because eyeballs are looking at what comes out of the screen to set the pixels by hand. When a simple software algorithm says 50% gray solid = 50% white & black dither, it is mathematically correct, but optically very wrong depending on the display medium.
Human eyes, the "pinhole effect" / diffraction, humidity and other effects naturally scatter pixels of light, thus a 25% white, 75% black dither coming from an additive light source should not be considered the same as a solid gray that is 25% intensity.
Note: PNG's gamma correction was a flawed attempt to reproduce the visuals of a creator's screen on a consumer's monitor, but the CSS colors weren't gamma corrected to match so gamma corrected PNGs didn't match webpage colors -- AND, PNG's gamma "correction" algorithm typically screws up careful dithering work in images due to the wildly different intensity curve of dithering vs solid colors.
If you back away from the screen the green squares to the left in the image above should seem fairly close in intensity, even though the solid green is 32.1% and the dither is LESS THAN a 25% dither: 25% shade block = (22.2% * fg color) thanks to the black line between cells in ye ol' VGA font -- but we're approximating it using a solid region of 32.1% green. Let's do a bit of simple math. CGA's Low intensity green is approx 170/255 #00AA00 or 66.4% green. 22.2% of 66.4% is 14.7%, and yet we approximate the visual color by using a solid green of 32.1% (the math is pretty damn wrong, right?) Even when corrected to the SRGB palette (which attempts to even out the greens somewhat) the dithering equations used in nearly all image processing tools gets the approximation wrong for on-screen displays (where most video games live).
The blurry images above are captures from the AI's camera at various stages of calibrating its optics. Too sharp and the bright pixels are clipped in the sensor producing too dark an average. Too blurry and the brighter dots cover too much of the sensor. I "matched" a few test patterns manually then allowed the AI to adjust her own gamma, color temp and focus until the outputs matched. Then I allowed the AI to run through all combinations of FG / BG colors and shade blocks, adjusting the solid colors so she could discover the best visible approximation.
Also, She locates the dithered / solid block pattern herself via edge detection on a sharply focused image:
Here is a sample of the results of AI color correction, an average of LCD, tablet & smartphone displays, but I could target any display.
Without correction the solid color is the average of the dithered pixels. If you take a few steps back or squint, it may be more apparent that those simple mathematics produce colors that are too dark. The AI corrected results attempt to match the visual appearance of the dithered colors given at typical screen viewing distance. View distance also affects gamma given the eye's focal length changes the spread of color on the color receptors (or CMOS chip in the case of our AI assistant). This gives a much better baseline and color curve information for algorithmic gradients and dithering.
I've started to throw together some color tools beginning with a quick and dirty Hue / Saturation / Lightness color picker, but the algos still need some work (WIP):
There are many color combinations representing a large selection of colors that do not currently exist, or have only rarely been used, in publicly available samplings of ANSI art... I've scanned them. From the scroller above it's evident that things look very "primary", or garish, but this needn't be the case (and isn't in some ANSI artworks). Most ANSI Art shading gradients tend to consist of only two of the 16 colors and utilize only the dither blocks to blend between them; However, the gamut can be expanded greatly via using non-obvious color dither combinations as halftones. This means the shading seen in ANSI art (and potentially other reduced palette pixel art) can be greatly improved simply by exposing the less intuitive color dither combinations to the artists in a better way. This is one of several toolset improvements I aim to bring to the ANSI Art medium.
[please forgive the rambling nature of this post. typically I rant & sperg to brainstorm, then clean up and split into a proper articles, but haven't the time today]
Developer
