4 ms·
Apple ][s have pretty much dumb framebuffer graphics and plenty of games were written for those. Fairly sure the ZX Spectrum didn't have much in the way of dedi
by pvg 5y ago
Apple ][s have pretty much dumb framebuffer graphics and plenty of games were written for those. Fairly sure the ZX Spectrum didn't have much in the way of dedicated graphics hardware either.
- nicetryguy 5y agoTrue. 2600 sprites work like this too. "Specky" has a Z80 anyway. I can't imagine realistically targeting something like this or being nostalgic for that XOR'd sprite look. Most later machines had more / varied graphical capabilities, even the new Commander X16 which uses a 'c02 has it's own graphics processor and several formats.
- duskwuff 5y agoThe 2600 was a whole wacky world of its own. The system didn't actually have any native support for sprites or bitmapped graphics! The graphics chip was designed to implement games similar to Pong, and only natively supported drawing a few blocks of color; games which wanted to display more complex graphics (which is to say, almost all of them) had to abuse this hardware by modifying its registers on a per-scanline (or even an intra-scanline) basis.
- nicetryguy 5y agoRight, all you could do with the "player" objects was point them at a different byte every scanline, write the X value into the register, and it would paint the "1's" as "pixels" in that byte on that particular scanline with that X value. It was up to the programmer to multiplex them on a per scanline basis. No framebuffer whatsoever. Fun stuff!
- bitwize 5y agoThe Atari 2600 supported sprites: two "players", two "missiles", and one "ball", that could be moved freely over the low resolution playfield. However, their bitmaps were only one pixel high; you had to change them on each scanline in order to get taller images. Rectangular bitmap sprites may have debuted in consumer hardware with the TI-99/4 in 1979; the term "sprite" comes from the technical documentation for that computer.
- duskwuff 5y agoApple II graphics were fucking weird. It was a framebuffer, true -- but the framebuffer layout was not even remotely linear, as all of the system's video output modes were designed to piggyback on the "free" memory read operations performed by DRAM refresh. Colors were even stranger. This all added up to a system which was difficult to write high-performance graphics code for.
- tmoertel 5y agoIf you want to understand just how weird Apple II graphics were, a great introduction is Stephen Edwards's "Inside the Apple II" video: https://youtu.be/r1VlrJboDMw https://youtu.be/r1VlrJboDMw. It's just half an hour long but manages to explain the clever hacks that Woz employed to squeeze video and floppy-disk logic from inexpensive 1970s-era hardware. (It also explains the Apple II's switching power supply, which was novel at the time.)
- pvg 5y agoHeh yeah, I spent a silly amount of time writing my own bitblts for the thing as a kid. I think the //e version of one of the books mentioned in the video (Understanding the Apple ][) is where I first learned of vertical retrace/blank.
- pvg 5y agoIt's not linear but it's modulo-ish and lookup-table-able. The colour is definitely mildly weird too but again, I think part of it is that it looks so unfamiliar in hindsight. I don't think these things that had much of an impact on high-performance code compared to 'it's just a blob of memory and every single thing has to be done by the anemic CPU'.
- ddingus 5y agoThe 7 pixel per byte was the hard part. Color by bit position repeated every 2 bytes, or 14 pixels.
- 5y ago