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

121–130 of 139 posts

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

#121

Post by dgb23 »

I like the part about memory management. Arenas are so simple.

In the (toy) web server I'm writing I initially also started with arenas. However I quickly realized that I don't actually need to grow and shrink memory at all.

Currently I'm simply allocating the memory I need up front then slice it up into pieces for every module.

When we're programming, we often pretend like we could be needing arbitrary amounts of memory, but that's not necessarily the case.

Many things actually have very clear limits. For the rest one can often define them. And if you enumerate those, you know how much memory you will need.

It is fun to think about and define those limits up front. It builds a lot of confidence and promotes a healthy frugality.

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

#122

Post by Kiro »

cookiengineer wrote: post #90

Honestly I would never ever execute any code from this guy. He is the inventor/founder behind the coinhive crypto mining network. [1] This guy made billions illegally [2], and maintained the biggest ransomware crypto coin network for years, by offering the tools and SDKs to fund dozens of cyber war involved agencies across the planet. [3] I have no idea how he got away with it, because his name keeps appearing in lot…

I think Coinhive was really cool and a fantastic idea that was ruined by rogue actors. I love the thought of mining for 20 seconds to unlock reading an article instead of getting out your credit card or even paying with crypto. Completely anonymous payment with zero overhead.

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

#123

Post by tracker1 »

esprehn wrote: post #116
jdnxudbe wrote: post #101

Earlier quoted context omitted.

I might be missing something, but isn't the original Impact a JavaScript & browser based engine, thus it should run on Android in a simple Web view just fine?

Most of that repo appears to have been built in early 2013. Android WebView didn't switch to chromium until late 2013. Prior to that it was usually an older hacked up WebKit sometimes provided by the phone manufacturer with unreliable features.

I remember working on a QC app that used NFC and a webview right when I think the first Pixel phone came out, basically to track QC steps while expensive equipment went through a production line. Was a somewhat painful, but interesting experience. I'm not sure if I liked it more or less than dealing with Palm/Handspring development a few years before it.

It's funny, I actually forget some of the small, one-off things I've worked on over the years.

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

#124

Post by i80and »

dgb23 wrote: post #121

I like the part about memory management. Arenas are so simple. In the (toy) web server I'm writing I initially also started with arenas. However I quickly realized that I don't actually need to grow and shrink memory at all. Currently I'm simply allocating the memory I need up front then slice it up into pieces for every module. When we're programming, we often pretend like we could be needing arbitrary amounts of me…

The TigerBeetle database is built this way, and I kind of love the concept https://tigerbeetle.com/blog/a-database-without-dynamic-memo...

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

#125

Post by TillE »

dgb23 wrote: post #121

I like the part about memory management. Arenas are so simple. In the (toy) web server I'm writing I initially also started with arenas. However I quickly realized that I don't actually need to grow and shrink memory at all. Currently I'm simply allocating the memory I need up front then slice it up into pieces for every module. When we're programming, we often pretend like we could be needing arbitrary amounts of me…

Right, I'm always annoyed when people talk about how std::vector has terrible performance (especially for games), which it certainly does if you just start with an empty vector with no memory reserved and append a few thousand items.

But it is very frequently possible to find the actual maximum you will need, allocate that upfront, and everything's great.

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

#126

Post by unevencoconut »

phoboslab wrote: post #79
jonwinstanley wrote: post #74

Looks like it’s a great game engine. Why does the article state its near end of life? Are there new engines that are far better?

The original JavaScript engine “Impact” from 2010 is at the end of its life; the C rewrite “high_impact” is new and will (potentially) be around for as long as we have C compilers and some graphics API. The JavaScript engine had a lot of workarounds for things that are not necessary anymore and some things that just don't work that well with modern browsers. From the top of my head: - nearest neighbor scaling for pix…

I loved Impact. Now finding out you were working on an Impact2?!

Any chance you're going to release it, even if its incomplete?

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

#127

Post by robterrell »

jdnxudbe wrote: post #101
namuol wrote: post #87

I owe a lot of the most informative programming work I’ve done to Impact. Impact was so ahead of its time. Proud to say I was one of the 3000 license owners. One of the best purchases I’ve ever made. The only game I’ve ever really properly finished was made in Impact. I loved that the source code was part of the license, and even modified the engine and the editor to suit my needs. I was so inspired that I worked on…

I might be missing something, but isn't the original Impact a JavaScript & browser based engine, thus it should run on Android in a simple Web view just fine?

Ejecta was a project that implemented WebGL with JavaScript bindings -- basically everything you need for a web game without the DOM. It implemented enough of WebGL to run Impact-based games.

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

#128

Post by seba_dos1 »

msephton wrote: post #110
jdnxudbe wrote: post #101

Earlier quoted context omitted.

I might be missing something, but isn't the original Impact a JavaScript & browser based engine, thus it should run on Android in a simple Web view just fine?

I guess web views on Android weren't very capable 10–15 years ago?

They were quite capable, but there was no mechanism to update them without updating the whole OS, so they were usually quite outdated.

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

#129

Post by seba_dos1 »

pdpi wrote: post #63
make3 wrote: post #58

Earlier quoted context omitted.

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

I think we're in violent agreement. phoboslab was downplaying their own efforts by saying that the Cross Code team customised the Impact engine a bunch. My point was that no amount of customisation can turn a bad engine into a good one (you can't polish a turd), so phoboslab definitely deserves credit for building the base engine for Cross Code.

> no amount of customisation can turn a bad engine into a good one (you can't polish a turd)

At a risk of being off-topic and not contributing much to this particular conversation (as I doubt it's relevant to the point you're making), I'd like to note that I often actually find it preferable to "polish a turd" than to start from scratch. It's just much easier for my mind to start putting something that already exists into shape than to stop staring at a blank screen, and in turn it can save me a lot of time even if what I end up with is basically a ship of Theseus. Something something ADHD, I guess.

However, I'm perfectly aware this approach makes little sense anywhere you have to fight to justify the need to get rid of stuff that already "works" to your higher-ups ;)

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

#130

Post by 38 »

jraph wrote: post #100
38 wrote: post #80

> Except for SDL2, all libraries are bundled here (see the libs/ directory). https://github.com/phoboslab/high_impact#libraries-used yep. exactly why I dont use C anymore. the package management story is so bad/non existent, that the typical approach is to just vendor everything. no thanks.

Isn't the common approach to tell people to install packages from their distribution?

If that's the case, why are they vendored here?
Post reply on HN