Be aware that it actually works.
-- 
Darren New, San Diego CA, USA (PST)
    Ada - the programming language trying to avoid
    you literally shooting yourself in the foot.

Post a reply to this message

Darren New escreveu:
> Be aware that it actually works.

yeah, was just about to post it here!  rocks!  and it's seemingly 
javascript. :)

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

nemesis wrote:
> Darren New escreveu:
>> Be aware that it actually works.
> 
> yeah, was just about to post it here!  rocks!  and it's seemingly 
> javascript. :)

Just another "incredible times" I guess. When I was in college, that was a 
leading money maker, filling up an entire cabinet with pretty much cutting 
edge commercial hardware.

Now, we give it away free, for a day, for giggles.

-- 
Darren New, San Diego CA, USA (PST)
    Ada - the programming language trying to avoid
    you literally shooting yourself in the foot.

Post a reply to this message

Darren New escreveu:
> Be aware that it actually works.

BTW, here's the code if anyone's curious:

http://www.google.com/logos/js/pacman10-hp.2.js

good luck understanding it. :)

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

nemesis escreveu:
> Darren New escreveu:
>> Be aware that it actually works.
> 
> BTW, here's the code if anyone's curious:
> 
> http://www.google.com/logos/js/pacman10-hp.2.js
> 
> good luck understanding it. :)

also, it seems to rely on yet other Google js code as well as dealing 
with the initial Google page, which is itself generated from js code. 
Holy code indirection, Batman!

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

nemesis wrote:
> Darren New escreveu:
>> Be aware that it actually works.
> 
> BTW, here's the code if anyone's curious:
> 
> http://www.google.com/logos/js/pacman10-hp.2.js
> 
> good luck understanding it. :)

It even simulates the level 256 bug!

Also, clicking Insert coin twice makes it turn two-player. Use WASD to 
control Ms Pacman.

Post a reply to this message

> Just another "incredible times" I guess. When I was in college, that was a 
> leading money maker, filling up an entire cabinet with pretty much cutting 
> edge commercial hardware.
>
> Now, we give it away free, for a day, for giggles.

When I think back on the money I spend on "Asteroids"... or "Defender"... 
who remembers those games nowadays?

I remember spending $50 on a handheld version of "Space Invaders" (battery 
powered LED game). A lot of money back then. And then I spent even more on 
batteries ;-)

Post a reply to this message

TC wrote:
> When I think back on the money I spend on "Asteroids"... or "Defender"... 
> who remembers those games nowadays?

http://prog21.dadgum.com/68.html

-- 
Darren New, San Diego CA, USA (PST)
    Ada - the programming language trying to avoid
    you literally shooting yourself in the foot.

Post a reply to this message

Nicolas Alvarez wrote:
> 
> Also, clicking Insert coin twice makes it turn two-player. Use WASD to 
> control Ms Pacman.

Or a really difficult one-player.

Post a reply to this message

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