Fun idea, open source for maximum learning value, seemingly flawless execution, vanity-free and clear writeup—what a lovely contribution to the world. I feel privileged just seeing things like this.
Porting my JavaScript game engine to C for no reason
71–80 of 139 posts
Re: Porting my JavaScript game engine to C for no reason
#72Somewhat related. Your QOI lossless file format coupled with 7Zip outperfoms lossless PNG. Amazing work!
BMP coupled with 7Zip would outperform too (probably by a bigger margin). It just boils down to gzip vs gzip-replacement compressor.
Not to mention the part where adding compressors like this somewhat defeats the purpose of using a simple format like QOI (although at least zstd is faster than gzip, let alone 7zip).
But if we're modifying things like that, then they might as well make use of Nigel Tao's improved QOIR format, and replace the LZ4 compressor it uses with zstd. That's probably faster and likely compresses better than QOI.
Re: Porting my JavaScript game engine to C for no reason
#73Earlier 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.
> You can't polish a turd
Of course you can. Not really sure why this still is tossed about. You just get a shiny turd with a lot less stink. I've made a career of taking people's turds and turning them into things they can now monetize (think old shitty video tape content prepped to be monetized with streaming).
Re: Porting my JavaScript game engine to C for no reason
#74Looks 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?
Re: Porting my JavaScript game engine to C for no reason
#75Earlier quoted context omitted.
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 af…
> to trigger the impression pixel I've always wondered how ad companies verify the ad is actually being displayed. Can you explain this in more detail? I imagine it has to be somewhat "bulletproof" since money is involved.
> I imagine it has to be somewhat "bulletproof" since money is involved.
The GP comment pretty much shows how bulletproof it wasn't, it isn't, it never will be. You also have bad actors in the space that will load ads under other ads so that the same page load continues to generate impressions. The space behaves as if there is no incentive to be honest.
Re: Porting my JavaScript game engine to C for no reason
#76Earlier quoted context omitted.
Even PSP had Flash, and it was fairly decent. I wonder how much effort and money Sony put into that.
Flash had numerous issues. The processing power available (especially on a PSP) is more than enough to be “good”, the problem with flash _performance_ is the power usage while achieving that perf. Even on laptops flash was a significant battery life drain whenever it was running, having it on all websites would kill battery life while browsing on a phone.
Yeah it did. I'm just sad that it took down ActionScript with it. IMO this is the language Javascript should have been.
Re: Porting my JavaScript game engine to C for no reason
#77dude is an OG!
Re: Porting my JavaScript game engine to C for no reason
#78Would love to have a ruby binfing.
Re: Porting my JavaScript game engine to C for no reason
#79Looks 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 pixel graphics wasn't possible, so images are scaled at load time pixel by pixel[1]. Resizing the canvas after the initial load wasn't possible with this. Reading pixels from an image was a total shit show too, when Apple decided to internally double the Canvas2D resolution for their “retina” devices, yet still reporting the un-doubled resolution[2].
- vendor prefixes EVERYWHERE. Remember those? Fun times. Impact had it's own mechanism to automatically resolve the canonical name[3]
- JS had no classes, so classes are implemented using some trickery[4]
- JS had no modules, so modules are implemented using some trickery[5]
- WebAudio wasn't a thing, so Impact used which was never meant for low latency playback or multiple channels[6] and generally was extremely buggy[7]. WebAudio was supported in later Impact versions, but it's hacked in there. WebAudioContext unlocking however is not implemented correctly, because back then most browsers didn't need unlocking and there was no "official" mechanism for it (the canonical way now is ctx.resume() in a click handler). Also, browser vendors couldn't get their shit together so Impact needed to handle loading sounds in different formats. Oh wait, Apple _still_ does not fully support Vorbis or Opus 14 years later.
- WebGL wasn't a thing, so Impact used the Canvas2d API for rendering, which is _still_ magnitudes slower than WebGL.
- Touch input wasn't standardized and mobile support in general was an afterthought.
- I made some (in hindsight) weird choices like extending Number, Array and Object. Fun fact: Function.bind or Array.indexOf wasn't supported by all browsers, so Impact has polyfills for these.
- Weltmeister (the editor) is a big piece of spaghetti, because I didn't know what I was doing.
Of course all of these shortcomings are fixable. I actually have the source for “Impact2” doing all that with a completely new editor and bells and whistles. It was very close to release but I just couldn't push it over the finish line. I felt bad about this for a long time. I guess high_impact is my attempt for redemption :]
[1] https://github.com/phoboslab/Impact/blob/master/lib/impact/i...
[2] https://phoboslab.org/log/2012/09/drawing-pixels-is-hard
[3] https://github.com/phoboslab/Impact/blob/master/lib/impact/i...
[4] https://github.com/phoboslab/Impact/blob/master/lib/impact/i...
[5] https://github.com/phoboslab/Impact/blob/master/lib/impact/i...
[6] https://phoboslab.org/log/2011/03/multiple-channels-for-html...
[7] https://phoboslab.org/log/2011/03/the-state-of-html5-audio
Re: Porting my JavaScript game engine to C for no reason
#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.