> 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 credit there!
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.
In game development this isn't true for better or worse. There is a lot of sunken cost mindset in games that we just go with what we have because we have already invested the time in it and we'll make it work by any means.
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
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 ;)
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).
I like this take, but you're saying something different I think, which is more along the lines of "Customers don't care about how the sausage is made".
You didn't polish a turd, you found something that could be valuable to someone and found a way to make it into a polished product, which is great.
But "You can't polish a turd" implies it's actually a turd and there's nothing valuable to be found or the necessary quality thresholds can't be met.
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.
Huh. Never would have guessed. I am sure there were many “fancy” effects in the game, but during my playthrough, it all felt like it would have been achievable on a SNES.
I am not familiar with either Rust or the Switch, so maybe you can enlighten me: why would a Rust game be challenging on the Switch?
As long as you have a good C ffi (which Rust has), shouldn't it be quite easy?
Or is the Switch more similar to Android/iPhone where you cannot (could not?) run native code directly but have to use a platform specific language like Java or Objective C?
AFAIK some (all?) console vendors require you to use the compiler toolchain from their SDK to compile your code. So unless the console SDK includes a Rust toolchain the only way is to somehow translate the Rust code to C or C++ and compile that with the SDK compiler.
Maybe if the console SDK toolchain is Clang based it would also work to go via LLVM bitcode instead of C/C++ though.
As flohofwoe pointed out, you are limited by the console vendor SDK, the compiler toolchains, and everything required to target their OS, linker, API, ABI,...
That switch port took a lot of effort as someone has already commented, it is absolutely not standard impact.js.
For the anecdote, everyone wanted a Switch version, but considering the technical limitation, the team replied with "Sorry but CrossCode will be coming to Switch when Hedgehags learn to fly." [1] When they finally got to do it [2], it came with an extra quest called "A switch in attitude", featuring, you guessed it, flying hedgehags.
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.
So to clarify: my suggested point of comparison was replacing QOI + 7Zip of GP with QOIR + zstd. QOIR already compresses better than QOI before the LZ4 pass, and zstd compresses faster than 7zip and often better. On top of that you can put zstd in the header option when streaming data on a browser so you don't need to increase the JS bundle or whatever if the use case is the web. So that's basically a guaranteed net improvement all around.
Second of all, the speed/compression trade-off with zstd can be tuned a lot. The "half as fast as LZ4" stat is for the fastest setting, but for the proposed comparison point of 7zip a slower setting with better compression ratio is likely perfectly fine.
Had to log in to my rarely-used HN account to mention that I had played Biolab Disaster over and over again years back but lost track of it and forgot the name. Kinda wild to find it again by sheer luck!
...in this specific project, the Emscripten SDK is used for the link step (while compilation to WASM is handled by the Zig compiler, both for the Zig and C sources).
The Emscripten linker enables the 'embedded Javascript' EM_JS magic used by the C headers, and it also does additional WASM optimizations via Binaryen, and creating the .html and .js shim file needed for running WASM in browsers.
It's also possible to create WASM apps running in browsers using only the Zig toolchain, but this requires solving those same problems in a different way.
Yes, but the point of the joke was to make the loop longer, while keeping it somehow logical. I wish I managed to insert Purescript, Elixir, Pony and ATS somehow.
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.
Not looked into the code, the correct way would be to move the particles engine into shader code, and the limit would be as much as the graphics card can take.
It appears that after all these years, not everyone has bought into shader programming mentality, which is quite understable as only proprietary APIs have good debugging tools for them.
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.)
Exactly. Detecting patterns that are typical for human coders and replacing them with stuff that uses the machine efficiently is what most compilers do, even for low-level languages like C. You write a typical `for` loop, the compiler recognizes it and unrolls it, and / or replaces it with a SIMD-based version with many iterations run per clock.
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 still limited by the user's internet bandwidth of course.
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.
Then the next question is why your asset formats require such heavy processing after loading. Normally you'd convert any data into custom engine formats in an offline step in the asset pipeline so that the files can be dumped directly into memory ready for the engine (and 3D API) to be used without an expensive deserialization process.
FWIW, POSIX style multithreading in WASM is supported everywhere for a while now again (it was disabled after Spectre/Meltdown) but is locked behind special COOP/COEP HTTP headers for security reasons (so you either need to be able to configure the web server to return those headers, or use a service worker to inject the headers on the client side.
It does, but the main speedup comes from using WebGL instead of Canvas2D. Sadly, Canvas2D is still as slow as it ever was and I really wonder why.
Years back I wrote a standalone Canvas2D implementation[1] that outperforms browsers by a lot. Sure, it's missing some features (e.g. text shadows), but I can't think of any reason for browser implementations needing to be _that_ slow.
Ah man, I'm still looking for a general canvas drop in replacement that would render using webgl or webgpu if supported. Closest I've found so far is pixi.js, but the rendering api is vastly different and documentation spotty, so it would take some doing to port things over. Plus no antialiasing it seems.
For things missing/hard in WebGL, is it performant enough to rely on the browser compositor to add a layer of text, or a layer of svg, over the WebGL?
I have some zig/wasm stuff working on canvas2D, but rendering things to bitmaps and adding them to canvas2d seems awfully slow, especially for animated svg.
I used to play X-Type all the time on iOS, it’s how I discovered Impact. I love web-based games but lately I’ve been tempted to write in C or C++. Did you notice dramatic gains in optimization porting Impact from JavaScript to C?
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.
Adobe had competing products mostly based on open standards. They shut down many active product lines and merged what was left into Adobe AIR, which didn't take off.
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.
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.
> 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.
I've been out of the space for about a decade, so I can't say how things have continued to evolve, but the only consistent antidote to fraud has been a trusted third party.
I spent a lot of my time back then pulling in metrics from third parties like Nielsen (who do traditional TV viewership numbers) as well as companies who specialized in "viewability". We could include that data in our real-time auction and bidders would adjust what they were willing to pay based on the reputation of the ad opportunity. At least that's the theory. In practice there was so much indirection and reselling that it was hard to say what was true.
As far as the technical answer: it's a game of cat-and-mouse but we found some interesting metrics we could dig in on. One was that fps of a video hidden behind another element on the page would have a drastically different rendered fps than one in the foreground. That would be different between browsers (and browser versions) but the viewability vendors would find all those quirks, measure, and analyze to give us a normalized score. For a hefty fee, of course.
Percent In View = Area of the Intersection of the Ad and the Viewport / Area of the Ad
You would get the area of the ad using getBoundingClientRect, and the area of the viewport using window.innerWidth and window.innerHeight.
It was not possible to do this if the ad was within a hostile iframe (cross origin iframe) so you needed to use a third party source for this information like SafeFrame.
All of this was greatly simplified when Intersection Observer was officially supported by modern browsers.
"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 much as the other way around but that's speculative
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.
... 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
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...)
ohhh I love your use of UNION to create a polymorphic-type ENTITY data structure. Nice work and design.
I still love futzing around in C...It was the original langauge I learned and God did I struggle with it for years. Like the OP mentioned, C is awesome because its such a concise language but you can go as deep as you like with it.
Thanks for all your efforts and the writeup...the game has a throwback Commander Keen-type vibe to it and I loved that franchise for a minute back in Carmack's pre-3D days.
Remember I was working on an impact.js game 10 years ago. Just can't seem to find the source code! First time I hired a guy to create some graphics. Very inspiring gaming platform.
> high_impact is not a “library”, but rather a framework. It's an empty scaffold, that you can fill. You write your business logic inside the framework.
I normally phrase this in a much more negative way: a "framework" is simply a "library" that does not place nice with others. It's good to hear a sensible positive phrasing for once.
I studied Software Engineering, but never quite grasped the difference between a Library and a Framework until I started my first job developing with Web Objects.
It is a joy to use such a rich and well thought out Framework that really does do 99% of everything you need. Adding in your own stuff is about the easiest development I've ever done, and it just works. It was magic, and I miss using it.
My ideal framework is a library or set of cooperating libraries on the inside, with as little framework as possible.
e.g. Qt is a framework. Qt "calls you". But you can run the QPainter code without starting the Qt event loop or thinking too hard about QObjects. You should ideally be able to use the event loop without buying into signals and slots, though it won't be as ergonomic.
It's not always possible, it's not always worth it, but everything else being equal, I'd rather have no framework at all.
(For game engines I understand why a little framework is necessary - When you're talking about compiling to a weirdo platform like phones or consoles, the engine must also be involved in your build process and sometimes even libc shit. So you can't just make a Win32 exe that is a PlayStation game.)
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.
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 <Audio> 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 :]
I loved Impact and paid for it back in the day, though I never ended up finishing the project I was working on. Did you ever throw the source for "Impact2" up anywhere? What's missing from it being releaseable?
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.
138 comments
[ 2.8 ms ] story [ 216 ms ] threadCross 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 credit there!
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
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.
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.
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 ;)
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).
You didn't polish a turd, you found something that could be valuable to someone and found a way to make it into a polished product, which is great.
But "You can't polish a turd" implies it's actually a turd and there's nothing valuable to be found or the necessary quality thresholds can't be met.
You absolutely can. Mythbusters proved it.
https://youtu.be/yiJ9fy1qSFI
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.
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 <canvas> 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.
See https://news.ycombinator.com/item?id=41155807
Even Rust is going to be heroic levels until console vendors decide it is an acceptable language to be made available on their devkits.
As long as you have a good C ffi (which Rust has), shouldn't it be quite easy?
Or is the Switch more similar to Android/iPhone where you cannot (could not?) run native code directly but have to use a platform specific language like Java or Objective C?
Maybe if the console SDK toolchain is Clang based it would also work to go via LLVM bitcode instead of C/C++ though.
For the anecdote, everyone wanted a Switch version, but considering the technical limitation, the team replied with "Sorry but CrossCode will be coming to Switch when Hedgehags learn to fly." [1] When they finally got to do it [2], it came with an extra quest called "A switch in attitude", featuring, you guessed it, flying hedgehags.
[1] https://www.radicalfishgames.com/?p=6581 [2] https://www.radicalfishgames.com/?p=6668
Out of respect for your player's battery life, perhaps :)
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.
[0] https://nigeltao.github.io/blog/2022/qoir.html
[1] https://github.com/nigeltao/qoir
Second of all, the speed/compression trade-off with zstd can be tuned a lot. The "half as fast as LZ4" stat is for the fastest setting, but for the proposed comparison point of 7zip a slower setting with better compression ratio is likely perfectly fine.
[0] https://github.com/facebook/zstd/tree/dev?tab=readme-ov-file...
j/k :D
https://floooh.github.io/pacman.zig/pacman.html
The Git repo is here:
https://github.com/floooh/pacman.zig
...in this specific project, the Emscripten SDK is used for the link step (while compilation to WASM is handled by the Zig compiler, both for the Zig and C sources).
The Emscripten linker enables the 'embedded Javascript' EM_JS magic used by the C headers, and it also does additional WASM optimizations via Binaryen, and creating the .html and .js shim file needed for running WASM in browsers.
It's also possible to create WASM apps running in browsers using only the Zig toolchain, but this requires solving those same problems in a different way.
e.g. https://killedbyapixel.github.io/LittleJS/examples/stress/
It appears that after all these years, not everyone has bought into shader programming mentality, which is quite understable as only proprietary APIs have good debugging tools for them.
Could this take place at compile time?
FWIW, POSIX style multithreading in WASM is supported everywhere for a while now again (it was disabled after Spectre/Meltdown) but is locked behind special COOP/COEP HTTP headers for security reasons (so you either need to be able to configure the web server to return those headers, or use a service worker to inject the headers on the client side.
Years back I wrote a standalone Canvas2D implementation[1] that outperforms browsers by a lot. Sure, it's missing some features (e.g. text shadows), but I can't think of any reason for browser implementations needing to be _that_ slow.
[1] https://github.com/phoboslab/Ejecta
The game looks cool.
From what I recall, what killed Flash wasn't iOS, but rather the acquisition of Macromedia by Adobe.
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.
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.
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.
I spent a lot of my time back then pulling in metrics from third parties like Nielsen (who do traditional TV viewership numbers) as well as companies who specialized in "viewability". We could include that data in our real-time auction and bidders would adjust what they were willing to pay based on the reputation of the ad opportunity. At least that's the theory. In practice there was so much indirection and reselling that it was hard to say what was true.
As far as the technical answer: it's a game of cat-and-mouse but we found some interesting metrics we could dig in on. One was that fps of a video hidden behind another element on the page would have a drastically different rendered fps than one in the foreground. That would be different between browsers (and browser versions) but the viewability vendors would find all those quirks, measure, and analyze to give us a normalized score. For a hefty fee, of course.
Here is the formula for viewability:
Percent In View = Area of the Intersection of the Ad and the Viewport / Area of the Ad
You would get the area of the ad using getBoundingClientRect, and the area of the viewport using window.innerWidth and window.innerHeight.
It was not possible to do this if the ad was within a hostile iframe (cross origin iframe) so you needed to use a third party source for this information like SafeFrame.
All of this was greatly simplified when Intersection Observer was officially supported by modern browsers.
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 much as the other way around but that's speculative
The game looks slick af btw,
https://en.m.wikipedia.org/wiki/ECMAScript_version_history#4...
https://phoboslab.org/high_impact/biolab/
FYI - in non-fullscreen mode, on my Mac / Chrome, the bottom of the viewport is cut off. So can only play in fullscreen.
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...)
I still love futzing around in C...It was the original langauge I learned and God did I struggle with it for years. Like the OP mentioned, C is awesome because its such a concise language but you can go as deep as you like with it.
Thanks for all your efforts and the writeup...the game has a throwback Commander Keen-type vibe to it and I loved that franchise for a minute back in Carmack's pre-3D days.
I normally phrase this in a much more negative way: a "framework" is simply a "library" that does not place nice with others. It's good to hear a sensible positive phrasing for once.
It is a joy to use such a rich and well thought out Framework that really does do 99% of everything you need. Adding in your own stuff is about the easiest development I've ever done, and it just works. It was magic, and I miss using it.
My ideal framework is a library or set of cooperating libraries on the inside, with as little framework as possible.
e.g. Qt is a framework. Qt "calls you". But you can run the QPainter code without starting the Qt event loop or thinking too hard about QObjects. You should ideally be able to use the event loop without buying into signals and slots, though it won't be as ergonomic.
It's not always possible, it's not always worth it, but everything else being equal, I'd rather have no framework at all.
(For game engines I understand why a little framework is necessary - When you're talking about compiling to a weirdo platform like phones or consoles, the engine must also be involved in your build process and sometimes even libc shit. So you can't just make a Win32 exe that is a PlayStation game.)
Are there new engines that are far better?
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 <Audio> 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]
Any chance you're going to release it, even if its incomplete?
(or mrubyc)
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.