Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Porting my JavaScript game engine to C for no reason

phoboslab.org

Post reply on HN
Print view View original

51–60 of 139 posts

Re: Porting my JavaScript game engine to C for no reason

#51

Post by andai »

echelon wrote: post #38
flohofwoe wrote: post #20

Earlier quoted context omitted.

You don't need multithreading to get concurrent asset streaming, a completion callback or async-await-style code will work too (after all, that's how most Javascript web games load their assets "in the background"). Also, browsers typically restrict concurrent download streams to about 6 (the exact number is entirely up to the browser though) - so you can have at most 6 asset files 'in flight'. In the end you are sti…

None of that worked out of the box, and we also spent most of the loading time CPU bound, processing the individual assets after they arrived over the wire. That was a blocking, non-async operation.

>processing the individual assets after they arrived over the wire

Could this take place at compile time?

Re: Porting my JavaScript game engine to C for no reason

#52

Post by andai »

nine_k wrote: post #43
leeoniya wrote: post #16

Earlier quoted context omitted.

i'm actually quite curious how it would perform relative to the C version. the article shows 1000x particles, but LittleJS has demos with a couple orders of magnitude more than that at 60fps. e.g. https://killedbyapixel.github.io/LittleJS/examples/stress/

JS engines like V8 are very good at JIT and optimization based on actual profiling. If we talk about pure CPU modeling, I suspect a good JIT will soon enough produce machine code on par with best AOT compilers. (BTW the same should apply to JVM and CLR languages, and maybe even to LuaJIT to some extent.)

From my cursory reading of v8 blogs, most of its optimizations revolve around detecting patterns in JS objects and replacing them with C++ classes.

Re: Porting my JavaScript game engine to C for no reason

#53

Post by Modified3019 »

Version467 wrote: post #26
senkora wrote: post #3

> Many Web games were created with Impact [the game engine from the article] and it even served as the basis for some commercial cross-platform titles like Cross Code, Eliot Quest and my own Nintendo Wii-U game XType Plus. Cross Code is an excellent game. I knew that it used web tech and I was constantly amazed by how performant it was on the Nintendo Switch hardware. I would guess that this engine deserves some cred…

Thanks for the recommendation. Looks interesting and is currently on sale on steam, so I bought it.

One thing to note, is you don’t have to feel compelled to master every combat mechanic the game throws at you (which is a lot), you can just pick your favorites. A “fox with one trick vs a thousand” and all that.

I for example basically ignore the shield for the vast majority of the game, only doing some very basic usage for some bosses, but perfect counters could very well be your favorite thing.

Re: Porting my JavaScript game engine to C for no reason

#54

Post by phamilton »

mgaunard wrote: post #27

The history section does not feel quite accurate. From what I recall, what killed Flash wasn't iOS, but rather the acquisition of Macromedia by Adobe.

One of the final nails was the infamous Chrome 45 aka the Chromepocalypse in the video ad world.

Chrome 45, in the name of performance, defaulted to only loading flash from 3rd party domains after a "click to load". This was bad for ads for obvious reasons, but it was much much worse due to an implementation detail.

In order to get the page laid out properly, Chrome loaded the flash component and then suspended it after a single frame. From an ad perspective, that was enough to trigger the impression pixel, signifying that the ad had been shown and the advertiser should be billed. However, the ad was not shown and there was no way for the ad to detect it had been suspended. Just a nightmare. We (I led the effort at BrightRoll) had to shift a ton of ad auction behavior to special case Chrome 45 and it limited what kind of ads we could serve.

That was the inflection point away from flash for ads. While ad formats like VPAID supported JS/HTML5, they didn't start getting popular until after Chrome 45 was released.

Re: Porting my JavaScript game engine to C for no reason

#55

Post by andai »

I did 5 game jams this year, 4 of them in various WebAssembly languages (C++, Zig, Odin, Rust).

In the end I switched back to JS/TS, because I found way more benefit from minimizing layers of abstraction and translation (WS is set up so you are forced to interface with JS to actually do anything), more than the benefits of any language or library.

(An exception might be something like Unity, due to the excellent featureset, but the IDE has become so slow it's unbearable...)

Re: Porting my JavaScript game engine to C for no reason

#56

Post by phamilton »

lelandfe wrote: post #30
mgaunard wrote: post #27

The history section does not feel quite accurate. From what I recall, what killed Flash wasn't iOS, but rather the acquisition of Macromedia by Adobe.

Flash game sites were still huge and popular after Adobe’s purchase, so clearly it did not kill it. If you mean something like that the acquisition started the death… that’s a hard position to argue against, since it’s subjective. Perhaps you’re right.

When flash started to fade for games, many developers moved over to adtech where their skills were still valued. Flash continued for a few years to power ads as well as shims around other videos that would collect data and even trigger secondary ad auctions.

Re: Porting my JavaScript game engine to C for no reason

#57

Post by [deleted] »

andai wrote: post #55

I did 5 game jams this year, 4 of them in various WebAssembly languages (C++, Zig, Odin, Rust). In the end I switched back to JS/TS, because I found way more benefit from minimizing layers of abstraction and translation (WS is set up so you are forced to interface with JS to actually do anything), more than the benefits of any language or library. (An exception might be something like Unity, due to the excellent feat…

[deleted]

Re: Porting my JavaScript game engine to C for no reason

#58

Post by make3 »

pdpi wrote: post #42
phoboslab wrote: post #10

Earlier quoted context omitted.

To be fair, they modified Impact _a lot_. In some of their development streams[1] you can see a heavily extended Weltmeister (Impact's level editor). Imho, that's fantastic! I love to see devs being able to adapt the engine for their particular game. Likewise, high_impact shouldn't be seen as a “feature-complete” game engine, but rather as a convenient starting point. [1] https://youtu.be/4lZfnM9Ubeo?t=3215

> To be fair, they modified Impact _a lot_. You can't polish a turd. There would've been no point in modifying the engine a bunch if you hadn't given them a useful base to work with.

that's just crazy bs, starting from open source code and adding specific features needed for a project is a very common strategy, doesn't mean at all that the tool wasn't good to begin with

Re: Porting my JavaScript game engine to C for no reason

#59

Post by fitsumbelay »

fitsumbelay wrote: post #29

"Thoughts on Flash" may just have saved the Web platform at its hour of greatest need, ie. creeping dominance of a single piece of software. I believe that somewhere in there was frustration with Adobe who seemed to abandon the MacOS platform support for Windows' much larger user base, eg. Mac versions were always behind Windows versions. Perhaps Jobs also may've felt that there would be no Adobe without Apple as muc…

... and the post has me poking around with C again. was always an ecmascript guy with a little Lingo in there from long ago, however I have an itch for all things low-resource and close to the metal (but not assembly lang close) and golfing my way towards somethings that encourage me to dig deeper

Re: Porting my JavaScript game engine to C for no reason

#60

Post by senkora »

Mindless2112 wrote: post #36
senkora wrote: post #3

> Many Web games were created with Impact [the game engine from the article] and it even served as the basis for some commercial cross-platform titles like Cross Code, Eliot Quest and my own Nintendo Wii-U game XType Plus. Cross Code is an excellent game. I knew that it used web tech and I was constantly amazed by how performant it was on the Nintendo Switch hardware. I would guess that this engine deserves some cred…

Here's a talk about how CrossCode was ported to Switch: https://www.youtube.com/watch?v=KfBzlzvt8RU

Really interesting watch, thanks for sharing!

So, if I understand correctly, this is roughly what he did:

1. Wrote a transpiler to convert the subset of Javascript used by CrossCode into a dialect of Haxe.

2. Selectively modified his version of Haxe in small ways to more closely match the semantics of Javascript, to make writing the transpiler easier.

3. Selectively re-wrote complicated parts of the Javascript code into Haxe directly, so that his transpiler didn't have to handle them.

4. Transpiled and other browser API calls into calls to his own pre-existing Kha framework for Haxe, which provided similar APIs.

5. Compiled the Haxe output into C++.

6. Compiled the C++ to native code.

Damn.

Post reply on HN