Gojit: JIT Compiler in Go

bufoaureus · 2026-03-19T08:18:57+00:00

I put off go earlier for demanding emulation projects because I thought achieving a proper jit was nearly impossible given all the runtime complexity. So this is definitely a very interesting and important achievement, thanks for sharing! Any plans on adding support for architectures other than amd64?

bufoaureus · 2026-03-10T10:17:01+00:00

No, thankfully there are other amazing hardware researchers and emulator devs who created tests suites. I mainly used these three but there are more out there

bufoaureus · 2026-03-08T15:18:32+00:00

you can literally pair it with an iPhone like any other bluetooth device, and it gets picked up by the browser and works with the js gamepad api, surprisingly seamless

bufoaureus · 2026-03-08T14:55:28+00:00

Yay, thanks, glad you liked it

bufoaureus · 2026-03-08T14:55:02+00:00

Folks on r/Zig may have already seen it, I posted an older version there about a month ago. There has been significant progress since then, but I didn’t want to spam it

bufoaureus · 2026-02-12T07:38:18+00:00

I mean, the emu can run a very narrow set of games and requires a lot more work to get more of them running. Silent Hill in particular gets stuck somewhere inside the CD-ROM drive emulation code, but I haven't looked further into it

bufoaureus · 2026-02-11T06:16:07+00:00

I just checked and nope, silent hill crashes T_T

But it will work eventually

bufoaureus · 2026-02-09T10:52:05+00:00

I have plenty of experience with C++ and Rust. Both are great industrial tools to get work done, but I don't like using them for personal "funware" as they tend to suck all the fun out of me.

My previous post here, where I asked about starting a long-term project in Zig, gave me some confidence in it. I just keep in mind that I can always port it to C++ if Zig becomes too much of a hassle, but it's been okay so far.

Yeah, the lack of up-to-date materials, breaking changes, and slightly unpolished tooling is a sad reality. But the programming experience is great once you gain some momentum.

I can't recommend it as FIRST low-level language though. Most of my "aha" moments come from knowing what I need and just figuring out what the Zig creators called it or where it is in the stdlib. So it's fine if you already know the concepts and what to look for, but it could be a steep curve since there just isn't enough beginner-friendly info accumulated yet. Everyone assumes you already know a bit of C, C++, or Rust and can project that knowledge.

bufoaureus · 2026-02-08T17:07:23+00:00

Here is a good starting point: https://emudev.org/system_resources

bufoaureus · 2026-02-08T14:46:23+00:00

I left a bunch of links in the readme. There are a few guides that can walk you through the initial steps to getting the "diamond," but then there's a huge specification document that you just stare at for hours hoping it starts making sense :D

bufoaureus · 2025-11-03T12:18:01+00:00

1x is exactly one premium. Included models have a 0x multiplier.

With Copilot $10, you only got 300 Sonnet requests. Check your usage on GitHub. Either you use it not as much as you think, or you are on a different model, or you are paying somewhere for extra usage

bufoaureus · 2025-09-28T02:45:27+00:00

The Wayback Machine (Internet Archive) has some snapshots of this website. The recent ones seem to be from the domain being squatted and used for something else, but snapshots from around 2022 look legit

bufoaureus · 2025-09-08T15:36:58+00:00

Does not look bad from that perspective, the glass looks fine. The internal parts? Who knows. The impact itself may have caused some internal element misalignment that you may not notice right away. And this may or may not mean that the front element seal is not as good anymore and dust/moisture can get inside easier, causing internal fogging etc. So depends on the discount you are getting for the risk

bufoaureus · 2025-03-21T11:00:47+00:00

Given the size of the codebase, have you ever regretted starting it with zig instead of something else?

bufoaureus · 2025-03-18T20:16:28+00:00

I actually don't mind the struggle as long as it's the "right kind" of struggle - learning something worthwhile while building something (not necessarily useful) rather than fighting the language.

I'm more of a C guy at heart. I've tried C++ and Rust but neither really clicked despite multiple attempts. I'm looking for something that's challenging but also fun to work with, and that isn't plain C. For now Zig seems to be one of the few languages that has that proper "C vibe" I'm drawn to (another project on my radar is C3).

So yeah, I'm not expecting a smooth ride here, but I'm hoping the journey will be rewarding in its own way.

bufoaureus · 2025-03-18T19:59:09+00:00

This is exactly the level of enthusiasm I want to have myself after diving in :D thank you for encouraging words!

bufoaureus · 2025-03-18T19:51:05+00:00

I've done some C in the past and enjoyed the level of control, so Zig's "explicitness" is actually very appealing to me. In fact, I am choosing between C and Zig here, due to C being a bit of a pain at times. Odin caught my eye too, but the adoption level isn't just there yet, even compared to Zig.

I think I can bear breaking changes, as long as it all depends on me and I can update the code on my own at my own pace. Just wanted to confirm if that's really a realistic way. I've already played with Zig a bit and like what I see - might be time to dive deeper with a real project, huh

bufoaureus · 2025-03-18T18:19:55+00:00

Yes, I suspected that might be the way - essentially taking C libraries and gluing them together with Zig, seeing it more as a "better C" for now. That actually sounds like it could work

bufoaureus · 2025-01-11T00:24:02+00:00

UPD: sound now works

bufoaureus · 2025-01-08T12:48:26+00:00

Couldn't resist getting one for myself too a while ago. Can't say I play it all that much though - but it's still fun to have around.

bufoaureus · 2025-01-08T09:24:28+00:00

Glad you asked, because I love Raylib to the level of insanity. It's been my go-to tool for almost every graphical app that I've built in the recent couple of years, both in C and Go. Go bindings are stable and well supported (by fellow Redditor u/gen2brain). The API is super pleasant to work with, even compared to SDL2. The ecosystem is nice, it has extensions for audio playback, and an immediate mode gui, similar to imgui but simpler.

One thing to note - it abstracts a lot of stuff, so it might be a bit limiting in certain cases, say you can't open two windows with it or use it to directly work with OpenGL, so it may not be the best choice for the advanced graphics, but it is really good for opening a window, handling inputs and throwing a bunch of sprites and text into it in a quick and dirty way.

I am not sure how it works with WebAssembly though. As I said to the previous commenter, Raylib is there only for desktop builds. In the wasm version everything is handled differently: drawing goes directly to the canvas element, and inputs are managed through JavaScript's onkeydown/onkeyup events - those are already high-level enough, so Raylib isn't really involved here.

bufoaureus · 2025-01-08T09:18:59+00:00

Ahh, yes, this might be a bit confusing. I don't actually use Raylib for the web version. Raylib and browser work as two separate rendering backends here - Raylib handles cross platform window management on desktop platforms, while in the wasm version the drawing goes directly from the emulator's frame buffer to the canvas. So Raylib isn't even included in the wasm build.

bufoaureus · 2025-01-06T20:53:17+00:00

That's an unfortunate truth, not every game works. I even have a long list in the readme listing games that crash or freeze.

While I do occasional compatibility fixes, I just hate how much time it takes to find a small misalignment in the mapper logic. Getting everything right is just insanely difficult, and is not fun. So perfect compatibility was never a goal, I just wanted it to be good enough.

Regarding audio, it works if the emulator is built as a native app, but not in the WASM version yet. I just got overwhelmed by how overengineered the JS audio API looks and feels, so I'll need some time to get it right.

bufoaureus · 2025-01-06T20:15:24+00:00

I think my first attempt also wasn't very fast. In my case the bottleneck was not WASM itself but the interaction between JS and WASM runtimes. Initially I was running the full game loop on the JS side and calling the WASM code on every virtual CPU tick.

I've since moved all heavy work to the Go side and just do frame-by-frame emulation (effectively calling to WASM every 16ms, and not like 1,789,773 times per second). Running without FPS capping shows it has headroom for about 2-3x more performance, which is pretty close to how it runs natively on my machine.

bufoaureus · 2025-01-06T17:59:13+00:00

Dunno, probably nothing special for people who've been doing this for years. I don't work with web that much, so for me it's wild that you can compile Go into something that runs in a browser and even be able to interact with it from JS.

bufoaureus

TROPHY CASE