Everyone's talking about the music but I also love the dot rendering system you're using for terrain and plants! Very neat effect, simple but it's a nice style. I'd love to see a whole forest done like this, maybe a flowing river too.
Steve put the nail in the coffin but the downfall started and was primarily caused by Macromedia being purchased by Adobe, IMHO. All the problems of Flash were solvable had it continued to been driven by a team and leadership that understood and cared about product quality. IMO this is one of the clearest cases of tech acquisition making the world worse.
This is missing much, including that we've outsourced our manufacturing (and thus CO2 from manufacturing) but we still buy lots of stuff that requires intense manufacturing.
I've made https://sprig.land, a webgpu-based game engine and have plans to transpile the whole thing into a new visual scripting language I'm inventing but I'll eventually share it and do want to make games with it.
Roblox uses a heavily customized version of Lua, and in it they've fixed many of the pain points of Lua and JS. One example is their Lua allows value types/copy semantics, native number types like f32 / i32, and simd. These are important if you care about tracking performance carefully which I believe they do.
They use Lua heavily in Roblox so they've got a lot of tools and expertise in it, so I assume they see a lot of benefit to further standardizing their high level language.
I'm guessing they have some tooling to auto-translate typescript into Lua to massively speed up their porting. TypeScript has a very good compiler API for doing exactly this sort of thing and I've written a decent TypeScript <-> Python translation before.
This scares me. Lua is already pretty niche, they customized it, and it's getting transpiled to js or wasm. There are too many places for that to go wrong, problems will be hard to investigate, and it's added ramp-up time for new hires.
In general, any time you venture away from a platform's default language (Objective C, Swift, Java, Kotlin, JS), things get significantly more complicated.
Pretty sure these are very different phenomena both called "ubershaders". As far as I understand it, outside of Dolphin, when people say "ubershader" they mostly mean a large material shader that has branches and constants to handle all the material variants used in one game (e.g. wood door, metal shield, shiny forcefield). It's produced by the engine so it's under full control of the engine developers. This means instead of loading separate shaders for the wood door and metal shield you can just tweak pipeline parameters. It's a work around for the various overheads, like compilation, involved in creating specialized shaders.
But Dolphin's "Ubershader" is a different beast. It's about handling all the shader variants for _all_ Dolphin games (which are made in different engines) with one shader, and the variant parameters aren't passed as nice constants (data) but as shader programs (code) that need to be interpreted to be understood. It's more like a meta-shader that takes shaders as input and produces shaders as opposed to a "normal" ubershader which takes configuration to specialize it at runtime.
I think that's right anyway. I haven't worked directly with ubershaders in either variety and my knowledge comes from building my own hobby engine and 3D pipelines.
reply