Darren New <dne### [at] sanrrcom> wrote:
> http://prog21.dadgum.com/68.html

  I don't understand all this "30-year old computers were able to present
slick user interfaces fast and without delays, yet even today we are
expecting things to take time to load and interfaces to lag" mentality,
which doesn't seem to be exclusive to Andrew.

  30 years ago the games consisted of a few kilobytes of code which used
a few kilobytes of RAM (at most), and all the data were either
programmatically generated line graphics or a few kilobytes of pixel data
(if even that much). Sounds were algorithmically generated with routines of
the size of a few hundreds of bytes, using another few hundreds of bytes of
data. The graphics hardware (or sometimes the CPU) had to update a very
low-resolution screen with just a few colors (in 1980 you were lucky if you
got more than 16 colors in total), and the hardest part of doing that was
using bitmasks as kind of 1-bit alpha channels for sprites.

  Drawing the graphics and playing sounds was not the major problem back
then because there was very little to draw or play. Loading data wasn't
either, because there was very little to load. The majority of the work
went into optimizing the game logic so that the game wouldn't lag because
the CPU was so slow.

  Now contrast to what a modern game needs eg. on the iPad. The iPad has
a screen resolution of 1024x768 pixels, with millions of colors (think
about how small a 320x256 area looks there). Even 2D graphics need a lot
more work to be drawn, as the amount of data to be drawn is enormously
larger (larger graphics, more colors, at least 8-bit alpha channel) and
there's a lot more to draw (a typical modern 2D game often has many layers
of graphics). If you tasked that 1MHz CPU from 1980 to draw that much, it
would probably take a couple of days to draw one frame. This not to talk
about 3D games (one frame could probably take a few years).

  Heck, the 1MHz CPU would even be unable to handle that much data in the
first place because it would run out of address space. It just *can't* do
it *at all*, no matter what you tried. It just doesn't support it.

  Sound is multi-channeled CD-quality sampled data, often stored in mp3
format, decoded and streamed into the sound hardware in real-time, while
the rest of the game is running. If you were to decode mp3 data with that
1MHz CPU from 1980, it would probably take a few years to decode 1 minute
worth of a soundtrack. And without the CPU being able to do anything else.

  If you want the same "slick" feeling as in 1980, just use an emulator and
run the original game. Which btw, will probably take about 1% of the CPU
time. You could have a H.264 movie playing in the background for all you
care and the emulation speed wouldn't suffer.

-- 
                                                          - Warp

Post a reply to this message