emscripten

[retard]

Wed, 15 Dec 2010 13:18:16 -0500, Nick Sabalausky wrote:

> "Andrew Wiley" <debio264 at gmail.com> wrote in message
> news:mailman.1026.1292433894.21107.digitalmars-d at puremagic.com...
>> On Wed, Dec 15, 2010 at 9:37 AM, Adam D. Ruppe
>> <destructionator at gmail.com>wrote:
>>>
>>> And in those rare cases where you are doing a lot of client side work,
>>> it is so
>>> brutally slow that if you start piling other runtimes on top of it,
>>> you'll
>>> often
>>> be left with an unusable mess anyway!
>>
>>
>> Unless you're using the beta of the next IE, the beta of the next
>> Opera, or
>> the current version of Chrome, in which case you'd find that
>> client-side work is becoming more and more feasible. Now, it's not
>> there yet, but when a
>> C-ported-to-Java-compiled-to-Javascript version of Quake 2 can get
>> 30FPS in
>> Google Chrome, I start thinking that performance probably won't be
>> nearly as
>> bad as browsers move forward.
>>
>>
> A game that was designed to run on a 90-133MHz 16-24MB RAM machine (in
> *software* rendering mode), and was frequently able to get framerates in
> the hundreds on sub-500MHz machines (using hardware rendering - with the
> old, old, old 3dfx cards), manages to get *only* 30FPS in JS on a
> multi-GHz multi-core machine using what is clearly hardware rendering
> (on a modern graphics card), and I'm supposed to think that means JS is
> fast? If anything, that's *proof* of how horrid JS is - it turns a
> multi-GHz multi-core into a Pentium ~100MHz. What a joke!

Some points:

 - IIRC the game was further optimized since the first release. The 
requirements went down a bit. Especially the SIMD optimizations allowed 
much lower MHz requirements with software rendering. Nowadays the SIMD 
instructions give even better throughput.

 - Compilers have improved a lot. E.g. auto-vectorization. Requirements 
went down a bit again.

 - the Jake2 version also runs faster because of faster JVMs and better 
OpenGL libraries

 - OTOH resolutions have gone up... but if the game uses hardware 
accelerated opengl canvas, using Javascript instead of C doesn't have 
much effect

 - overall I think the CPU requirements have gone down even though higher 
resolution and expensive graphical effects are more common these days.

Indeed Quake II used to work very fast on Pentium II class hardware with 
Nvidia TNT cards. I think I got over 100 fps @ 1280x1024 over 10 years 
ago. Getting 30 FPS on average now IS a bad joke. The (graphics) hardware 
gets 100% faster every 12-18 months. Even if you make the game twice as 
fast as now, hardcore fps gamers wouldn't find the rate acceptable for 
modern network gaming. Hardcore fps gamers won't also play 13 yo games 
anymore.

I admit that JavaScript is getting faster and faster. However, at some 
point the language will hit the performance wall. Luajit is one of the 
fastest dynamic languages out there. It's still drastically slower than 
statically typed languages. It probably shows has fast JavaScript can 
possibly get in raw computational tasks.

This is all ok for "casual gaming", but if you only get 30 FPS when 
running a 13 yo game, it means you're 15-16 years behind the state of the 
art. OTOH slow software rendered flash applets were already used as a 
platform for casual gaming, HTML5 doesn't change the situation that much. 
Maybe the greatest difference is that HTML5 also runs quite fast on 
Linux. This HTML5 hype also helps them in marketing. After all, it's the 
same old shit in new package.

>> [HTML5, HTML5, HTML5, Chrome, HTML5, HTML5...]
> 
> Yea, *eventually* HTML5 will *improve* a few things...That hardly counts
> as "The web's not a shitty platform!".

It's just 15-16 years behind the state of the art. Not much!