Hacker News Reader

Comment by TuringTest | Hacker News Reader

Cool for learning to program games.

Development environments in the 80's and 90's were so simple that you had to program down to every pixel shown on the screen (well, maybe calling some line and sprite primitives for speed), so you only needed to learn a small mental model for programming, and everything above it was designed by you. Also, the primitive hardware and no expectations of portability meant that you only had to care about one or two combinations of platforms (maybe supporting a small range of graphics and sound cards).

This can help teach younger developers to understand the basic principles, and get a glimpse of how things are done below the surface of those modern do-it-all gaming engines.

View on HN

Sure, flat bitmap modes existed, but no game I ever worked on used them. Plus they weren't conceptually simple, either.

On PC there was Mode X, which was so convoluted that I'm grateful to have forgotten how it works.

Before that, on C64, you'd generally build the game background out of a redefined character set, but some of the color bits would be read from a different part of memory.

Setting a pixel in bitmap mode wasn't a walk in the park, either, due to the way the memory was laid out (8x8 blocks). Plus you'd have to write to screen memory this time to set the colors in each 8x8 block.

It was convoluted, is what I'm saying

Mode X was convoluted, and if you were serious about double buffering, whole screen pixel perfect scrolling, etc - you had to master it.

But if all you wanted to do was set pixels, VGA mode 13 (IIRC) really was just setting a value to (0xA0000+y * 320+x) ; Turbo Pascal even let you define an "array[0..199][0..319] of byte absolute $a000:0" and treat it as an array; If you manipulated a small enough part of the screen, it was reasonable to do "off screen rending" (poor man's double buffering) and use the CPU to copy onto the screen.

CGA/EGA/Hercules were slightly more complicated because of bit packing and other weird hardware constraints, but only slightly so. As were the flat bitmap modes of most machines at the time, true. But the built in BASICs more than made up for this, as far as beginners were concerned.

On the Apple ][, it was all of "HGR2 : PLOT 100, 100 : LINE 200,200" IIRC; On the spectrum, it was "PLOT 100, 100 : DRAW 100, 100"; on the BBC B (spiritual grandfather of the Raspberry Pi) it was "MODE 7 : LINE (100,100)-(200,200)"

C64 Basic was indeed spartan, but C64 did have a pixel addressable mode that was almost a walk in the park; CPU was limited, so 99.9% of games used the redefined-charset trick, which let them update only one 40x25 charmap instead of a much bigger pixel map (and ... it was actually perfectly matched to the game designs and other memory constraints of the time - your elements had to be repetitive due to lack of memory/cpu to do other things, and the charmap just constrained those repetition to start on an 8-pixel boundary).

I may remember a detail wrong in those examples - but basically, the C64 and VIC20 basics gave you little help; But the ZX Spectrum, Oric Atmos, IBM PC jr, Apple ][, Dragon 32/64, Elan, MSX and all other contemporaries made it extremely easy.

And on a ZX Spectrum display, the horizontal lines were not contiguous in memory - you would get the 1st line, then the 9th, then the 17th.. then after you got one third down the screen it would jump to the 2nd, then the 10th.. a right pain to program! Explains the weird loading screen effect, when the data would be loaded so slowly you could see it drawing in that odd pattern.

Example: http://whatnotandgobbleaduke.blogspot.com/2011/07/zx-spectru...

And the icing on the cake being the colour information was stored sequentially at the end on an 8x8 pixel block basis!

Actually, programming homebrew for the NES and SNES, I was surprised by how similar my experience was to learning OpenGL. You can't plot individual pixels on hardware like that, you have to fill CHR memory (like textures) and create arrays of sprite data (like triangles) to upload to the hardware accelerated unit of the console.

While it's totally true that you had to be very "close to the metal" in everything you do, I feel it's not that dissimilar from coding C and OpenGL today, in terms of the overall flow of your project.

Plus the fact that you can't directly write to VRAM at all times and have to wait for the corresponding access windows.

But it's also a big contributor to the general art style and gameplay limitations for which the games of that generation are known for.

However with a few tricks drawing vector like graphics is possible[1] (to some degree), even though it requires a huge amount of lookup tables to be anywhere near peforment :D

[1] https://gitlab.com/BonsaiDen/vectroid.gb

NES and SNES were not your general "development system of the 80s"; I'm quite sure GP was referring to the Apple, Oric, Acorn, BBC, Dragon, MSX, Tandy CoCo, Spectrum, Amiga and even PCg/PCjr/XT of the time.

Commodore's C64, PET and VIC20 were exceptional in how hard they made using graphics at the time from the included BASIC; But in general it was quite easy.

The Atari VCS2600 had an even weirder video setup: It had one line of video memory (a 1D canvas!), and it was up to the program to replace the contents of that line while the screen raster was flying back to the next line. And a few sprites to sweeten the deal.

Modern hardware still works much the same, writing bytes to hardware that handles graphics generation, albeit today's are vastly more complex and SIMD-oriented. The key difference is these consoles lacked a framebuffer; RAM at the time was very expensive.

Reply on news.ycombinator.com