Awesome looking results. As far as I understand it's a "3D" shader in the sense that it looks 3D but it's a prerendered 2D normal map which is then lit using the resulting world space normal.
It's not that different from "real 3d" renderers. Especially in deferred rendering pipelines the rasterizer creates a bunch of buffers for depth map, normal map, color, etc but main shaders are running on those 2d buffers. That's the beauty of it parts operating with 3d triangles are kept simple simple and the expensive lighting shaders run once on flat 2d images with 0 overdraw. The shaders don't care whether normal map buffer came from 3d geometry which was rasterized just now, prerendered some time ago or the mix of 2. And even in forward rendering pipelines the fragment shader is operating on implicit 2d pixels created by vertex shaders and rasterizer from "real 3d" data.
The way I look at it if the input and math in the shader is working with 3d vectors its a 3d shader. Whether there is also a 3d rasterizer is a separate question.
Modern 3d games are exploiting it in many different ways. Prerendering a 3D model from multiple views might sound like cheating but use of imposters is a real technique used by proper 3d engines.
Unfortunately, the 2D imposter mode has pretty significant difficulties with arbitrarily rotated 3D. The GBDK imposter rotation demo needs a 256k cart just to handle 64 rotation frames in a circle for a single object. Expanding that out to fully 3D views and rotations gets quite prohibitive.
Haven't tried downloading RGDBS to compile this yet. However, suspect the final file is probably similar, and pushing the upper limits on GB cart sizes.
It's not that different from how some creative Mac games were doing 3d lighting on 2d textures prior to 3d accelerated hardware being available. The neat part here is that it runs on a Gameboy Colour.
And another practical observation is that not many people have Lobsters account or even heard about it due to that (way less than people who heard about HN). Their "solution" is to make newcomers beg for invites in some chat. Guess what would a motivated malicious actor would do any times required and a regular internet user won't bother? Yeah, that.
I think this is the inevitable reality for future FOSS. Github will be degraded, but any real development will be moved behind closed doors and invite only walls.
It was an issue with the main JPEGXL library being unmaintained and possibly open for security flaws. Some people got together and wrote a new one in Rust which then became an acceptable choice for a secure browser.
Windows has PIX for Windows, PIX is the name of the GPU debugging since Xbox 360. The Windows version is similar but it relies on debug layers that need to be GPU specific which is usually handled automatically. Although because of that it’s not as deep as the console version but it lets you get by. Most people use RenderDoc on supported platforms though (Linux and Windows). It supports most APIs you can find on these platforms.
With projects like this competing against well known massive competitors (eg. the browser JS engines), not seeing their main competitors in a benchmark is a massive red flag to me: https://boajs.dev/benchmarks
Not seeing V8, SpiderMonkey JavaScriptCore is very strange...
Personally, I'm more impressed with https://github.com/Hans-Halverson/brimstone - it is faster, nearly just as full featured (almost full ES2025) and last but not least, a single person project.
Yeah! I found out about Brimstone just the other day! Its definitely interesting! One optimization that they have that Boa needs to implement is ropes for our string type :)
Well, it is, because V8 is definitely an embeddable JS engine. For many people they might want to make a choice between V8 and Boa and for them the performance numbers are important information!
People who need an extremely high performance JavaScript engine, where the extra performance is worth using an engine that's hard to embed, has an unstable API, and an absolutely massive unwieldy Google-style C++ code base with all the pain that entails, plus a JIT and all the limitations that entails, JITed V8 is the right choice.
People who just want to run JavaScript code where performance isn't such a big concern would prefer something like Boa (or the other engines listed on the comparison benchmark page).
Both have their uses, and their use case is almost entirely non-overlapping. You wouldn't choose Boa for a competitive web browser engine or as the runtime for your back-end server software. You would consider it for a plug-in system, or maybe a game's scripting system.
I'm not saying that there would be no value in having benchmarks which compare the JITless, easily embeddable JS interpreters against JITed, hard-to-embed browser-quality JS engines like V8 and SpiderMonkey. I'm just saying that those engines aren't really Boa's competitors, certainly not its "main competitors"; it's a different kind of thing that serves a different need.
It isn't, v8 will have anywhere between 2-1000x performance depending on the exact code it's jitting. Boa absolutely destroys v8 here though:
use boa_engine::{Context, Source, JsResult};
fn main() -> JsResult<()> {
let js_code = r#"
let two = 1 + 1;
let definitely_not_four = two + "2";
definitely_not_four
"#;
// Instantiate the execution context
let mut context = Context::default();
// Parse the source code
let result = context.eval(Source::from_bytes(js_code))?;
println!("{}", result.display());
Ok(())
}
Huh, I just noticed thanks to this that the comment needs to be updated in the example lol it should probably say "Parse and evaluate the source code".
Is it though? V8 and spider monkey both have jits so performance numbers of the form “wow V8 is vastly faster than any of these other ones!” (similarly for sm). Does that really have any value?
From a quick glance, it's a very simply a premade wav file which has all letters A to Z with 0.15s for each. The final wav is just a concatenation of all of letters from the text, and a silence of each unknown character/space. It doesn't support numbers but could easily be extended beyond what's in the demo. Very clever.
I was going to say the same
thing. It was nice as their native save format could still be opened anywhere.
But you did need to remember to export if you didn't want the extra fields increasing the file size. I remember finding fireworks pngs on web pages many times back then.
If you play Fortnite right now (until Friday June 7th). You can speak in realtime to Darth Vader, he replies in his voice and in character, he knows who’s playing (the name of the character skin). The technology is here, and used in production of major games. It’ll be a big tide sooner than what people expect.
Here are the frames: https://github.com/nukep/gbshader/tree/main/sequences/gbspin...
reply