How? Why? Does stuff perform so badly after 20 years?

[clark]

In my youth, I used to go to a sports shop, and buy unlabelled Amiga 500 game disk for £0.50

One of these games, was Gravity Force 2. 

 

In Gravity Force 2. You got heat seeking missles, per pixel collision, physics along with buoyancy, you had terrain deformation, you had 4 players playing at (what was in hindsight) responsive controls. A well aimed laser would slice through geometry and eventually ruin the ship you targetted.

 

Fast forward 20 years, to a time of dual core processors where even 4 logical cores is the norm, and literally 20000x the video capability of that Amiga 500+ system. 

 

Why does my performance suck so bad? I mean, even if you are perfectly clean and pay extra attention to memory allocation, If I implement the per pixel collision of that game, on a £1000+ PC in 2015, Simply having per-pixel collision (In Flash, Unity or JavaScript) at this level of detail, would destroy my framerates.

 

So what gives? How can a game so old, and with such limited computational power, be so limited in this age after such significant growth in the capability of all parts of a system?

 

I cannot understand this comparison. I see Mario and I see how it works, but GF2 was pure math and it performed at atleast 24fps because I cannot recall it being slow in my time (or on that video which may be emulated)

[AshleyScirra]

Well, I think if you wrote code as efficient as the original game, it would perform just as well. The question is what code are you running and why is that code slow? As you say, the hardware has come on massively. But also bear in mind some of the hardware demands have increased substantially too: the Amiga had a 640x256 screen with 6 bpp running at 25 Hz, which requires a video bandwidth of about 3 MB/sec, whereas 1080p 32bpp at 60 FPS has a video bandwidth of nearly 500 MB/sec. Add in layer or post-processing effects and you can end up with a multiple of that. Plus the Amiga probably didn't have to worry about the security problems raised by running untrusted code from random websites.

[JUL]

Even if your code was the exact js or AS3 equivalent of gravity force 2 the issue would remain the same.

 

I assume gravity force 2 was written in C or C++, maybe assembly.

Compare JS or AS3 with those regarding performances and see what you get.

 

Javascript and AS3 have something called the garbage collector, it facilitates coding but comes at a price.

But that alone doesn't explain the performance gap.

 

Those games were not running in a browser.

Compare the performances of your .swf in firefox and as a stand alone application for instance, you'll get the idea.

 

Not to mention that they were designed for a specific hardware.

[SolarJS]

You can get 60FPS with GF2, even in JS, but you have to carefully design your structures, look at memory allocation/GC and know how to do it. Think like a game designer with limited resources back then, optimize everything and (also helpful) if you can do so, use your own engine to keep control of speed and overhead. 

[tsphillips]

Having been programming for a long time, here's my two cents --

 

Computers started out as niche market products.  Over time computers have become mass media devices.  On the software development front there has been a massive shift to make things easy to program.  Easy development comes at a price.  When one turns over responsibility to third-party libraries, APIs, etc., then one loses the ability to optimize for a specific platform and exploit efficiencies available in the hardware.

 

It is still possible to make incredibly fast and efficient software -- you just have to roll up your sleeves and bypass the layers of encapsulation that stand between us and the hardware.

 

Tom

[SolarJS]

Totally agree with Tom!

[KyleNau]

Those old games use a lot of trickery beyond just being closer to the hardware. The old game developer's adage was "If it looks right, it is right". If the gravity or buoyancy looks and feels right then it's fine even if you aren't calculating it "properly". After all they weren't writing simulations, they were writing games.

 

Trim the number of calculations per frame mercilessly and fake everything you can get away with.

[BdR]

The big difference is that the Amiga game is compiled as an application and running directly on the hardware, while a typical JavaScript/Flash game runs within another application and is interpreted line by line.

 

Javascript code runs inside a browser and Flash runs in a runtime application within a browser (which I suspect is even worse in terms of performance). The browser or runtime are applications running on the OS, which makes calls to device drivers, which make calls to the BIOS. So there are more abstraction layers between the code and the hardware, and that is what makes it so slow. See diagram below, javascript and flash would be located even above the applications layer.

 

 

 

Having been programming for a long time, here's my two cents --

 

I agree, and with the many new big platforms in the last 10 years (windows, macos, iphone, android, windows phone, xbox etc.) I think there is now a trend in trying to make it easier to program for all of these platforms using one single tool or programming language. Html5/javascript may be one of those solutions, but like you say the downside is that it has more abstraction layers and that hurts overall performance.

 

//offtopic: btw a sports shop sure is an odd place to buy unlabelled Amiga 500 games..