 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] san rrcom> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
TC wrote:
> 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 ;-)
One year I got a computer game for my birthday.
Only thing is... no computer. The "screen" actually just projects a
repeating loop from a reel of film inside the machine. There's a control
to move your ship from side to side, but really it just moves the
viewpoint a bit. Enemies don't actually disappear when you shoot them,
but hitting them does make a small mechanical rev counter count up. (I
presume the machine has something like a music box pin barrel to tell it
where the enemies are.) And there's a difficulty level, which just
adjusts the power to the electric motor scrolling the film.
Yes. A 100% mechanical computer game. With better graphics than the
actual computers of the time, by the way. (And probably much cheaper and
less likely to get busted by small children!) But damn, the thing took 4
big, chunky batteries!
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Be aware that it actually works.
Yes, thank you Google for making the entire office think I'm playing
computer games just because I wanted to look up the command line
switches for msiexec. :-P
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 22.05.2010 07:01, schrieb Warp:
> 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.
...
> 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.
... and not to forget that back then, what little software code arcade
games had used to be stored in ROM, so just about the fastest persistent
memory you can get; even today, if you want to beat that speed of old
times with modern off-the-shelf equipment you'll need to grab some SSD,
at least when random accesses need to be made.
Also remember that those machines took some seconds to boot as well;
they just had the advantage that they were usually turned on already
when the user approached them.
Not to mention the lags between levels, which weren't only there to
inform the user about their progress, but also re-initialize a few
variables.
Now leave the arcade game behind, and in order to get some more coins to
feed to the machine, go to work at some place where you'd use some
/real/ computer.
You'd probably be glad that you didn't have to literally /carry/ your
input and output to and from the server room anymore, ever since a few
years ago you got your own CRT terminal, and therefore you'd be pretty
forgiving to the fact that the execution time of some programs would
still be measured in minutes or even hours.
Note that back in those days, mass storage I/O would be the biggest
bottleneck for most applications.
Now guess which computer subsystems have seen the smallest performance
increase since then...
Let's face it: Comparing 1980's arcade games with 2010's business
applications is like comparing apples with bananas.
Look at 1980's arcade games, and you'll notice that you see the very
same responsiveness in 2010's games (even the lag between levels is
virtually the same ;-)), except that the games have grown immensely in
complexity.
Look at 1980's business applications, and you'll notice that they, too,
have grown immensely in complexity - but even worse in responsiveness as
today's stuff.
Want to compare 1980's word processing with today's?
1980:
You'd type in your documents in a text-only terminal.
Fonts would be limited to those built into whatever printer you'd be
using; depending on the printing technology, often even the font size
would be fixed. Text decoration would usually be limited to bold,
italics and/or underlined.
To see what the document would really look like, you'd have to print it,
and walk to the printer room to get your draft printout. WYSIWYG? Heck,
the best you could even /dream/ of was a preview functionality that
showed you where that particular printer brand would insert line breaks.
If you found that a particularly long word would create particularly
ugly line breaks, you were lucky if your word processor featured soft
hyphens, so you could manually give hints where words could be broken.
(Not to forget that if you ran into problems, you'd search for the paper
manual (which must be /somewhere/ around here, 'cause I know I had it in
my hands a week ago...), and pray that the buzzwords you can think of
happen to be listed in the index.)
2010:
You type in your documents in your very own personal supercomputer
(which, by the way, is pretty bored 99% of the time).
You can choose between hundreds of more-or less exotic fully scalable
fonts (some even including a full set of glyphs for each and every
language you could possibly imagine), in plenty of more-or-less useful
variations: Bold, italics, underlined, double underlined,
strike-through, small caps, font color, background, borders...
To see what the document would look like, all you need to do is look at
the display as you type. Nowadays you even get WYSIWYG feedback while
pondering what font or text decoration to choose.
You don't even know what a soft hyphen is, because you never need them
anyway, as your word processor features a full dictionary to decide
where to break words /as you type/ - and check not only your spelling,
but even your grammar while you type (and bore your computer to death).
(Not to forget that if you run into problems and can't find anything
suitable in the inbuilt help index, you might try again with a full-text
search. Or even do a full-text search on a worldwide repository of
documentations, tutorials, user group discussions, public diaries and
what-have-you-not. On the fly. With sophisticated sorting of the results
by probable relevance.)
(And all the while your media player keeps pumping studio quality music
(CD quality? What the * is a CD?) out of the inbuilt HiFi Stereo amp
with integrated 10-band equalizer... and still your machine is mostly
busy with being bored...)
Poor responsiveness? Well, I don't think so.
Instead, I think there is some "maximum acceptable lag", which software
"fills out" by adding features and "richer" feedback while processing
and I/O speed increase. And I think that acceptable lag is even slowly
decreasing in business applications. (It has always been pretty low for
games as it seems.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 22 May 2010 08:06:33 +0100, Orchid XP v8 wrote:
> Darren New wrote:
>> Be aware that it actually works.
>
> Yes, thank you Google for making the entire office think I'm playing
> computer games just because I wanted to look up the command line
> switches for msiexec. :-P
There's a reason to have the sound turned off on work PCs. :-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
