3 ms·

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 co

by Luc 8y ago

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

beagle3 8y ago
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.
feintruled 8y ago
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-spectrum-screen-memory-layout.html 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!

by Luc 8y ago

beagle3 8y ago

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.

feintruled 8y ago

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-spectrum-screen-memory-layout.html 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!