Earlier quoted context omitted.
The switch port required heroic levels of efforts though I recall.
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.
Porting my JavaScript game engine to C for no reason
61–70 of 139 posts
Re: Porting my JavaScript game engine to C for no reason
#62Earlier quoted context omitted.
> 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
#63Earlier quoted context omitted.
> 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
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.
Re: Porting my JavaScript game engine to C for no reason
#64Re: Porting my JavaScript game engine to C for no reason
#65Earlier quoted context omitted.
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
#66I 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.
Re: Porting my JavaScript game engine to C for no reason
#67> 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…
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
Re: Porting my JavaScript game engine to C for no reason
#68Re: Porting my JavaScript game engine to C for no reason
#69I 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.
Re: Porting my JavaScript game engine to C for no reason
#70The 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 af…
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.