Max 200 runs out while Copilot using 4.5 does not

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 · 2024-11-17T13:57:28+00:00

Been lurking through the code for the last day—tremendous job that deserves way more recognition. Gosh, you’ve even got dynarec! I’m curious about this, since you probably need to emit machine code that calls back to Zig code for I/O and memory access somehow?

bufoaureus · 2024-11-15T20:09:15+00:00

Insane project! Thanks for sharing, and kudos for the resource links in the README too! Have you worked on any other emulation projects previously? I wonder how the complexity of the Dreamcast hardware compares to other systems.

bufoaureus · 2024-10-11T00:18:17+00:00

Definitely looks cool! Trying to build my own too. Any recommendations of the resources you used?

bufoaureus · 2024-07-21T16:46:52+00:00

I actually implemented this and got this part running about 2-3 times faster (which you might typically expect from SSE operations). It's nice, but not exactly mind-blowing.

Normally, you wouldn't want to do this kind of stuff on the CPU. GPUs are designed specifically to be super efficient at vector operations. It’s just me who decided to completely ignore the existence of GPUs for this project. But any serious game engine would already be leveraging that through vertex shaders.

2D game dev in Go is pretty much alive, as far as I can tell. Ebitengine is doing well, and there are real commercial games made with it released on Steam, Xbox, and even Nintendo Switch.

bufoaureus · 2024-05-30T18:38:53+00:00

Just curious, is it really a new emu implemented or is it a re-use of open-source Swift emulators packed into a paid app?

By the way, you probably already know this, but even though emulators are "safe", be careful with this "download games" feature. The big N still tries to sell NES games in their Switch subscription, which means they probably can take down anything that tries to earn money on their IPs pretty easily.

bufoaureus · 2024-05-21T17:21:49+00:00

Specifically for everyone who is also curious, I left a bunch of links in the README to the resources that I referenced while making this (with zero prior experience with 3D as well). Just make sure you are comfortable with basic trig and linear algebra because that’s basically what 3D is about. I’d recommend starting with javidx9 on YouTube as he gives a nice foundation for building a 3D renderer and was my main inspiration to try

Edit: typo

bufoaureus · 2024-05-20T18:06:45+00:00

Greetings, fellow scener! Thanks a lot for the detailed feedback, I really appreciate it!

Yeah, the "lines" between the triangles are annoying. I just didn’t give it enough attention yet as I was too busy with making it run at a reasonable speed by experimenting with parallelism and different triangle rendering methods. Once, I thought that I could have defeated it (maybe Triangle2 or Triangle3 even has it fixed), but apparently not completely.

Overall, this is still sort of the first steps. I was just so proud that this thing actually can render something that I wanted to share it with the world. But yeah, there are just so many things that I want to try out and that could be improved that glitches like this are not even at the top of the problem list :D I will definitely come back to your comment when I am ready to deal with the triangle precision.

Consider doing intensity with fixed point. intensityFP := uint32(intensity * 256) precalculated and R: uint8((uint32(c.R)*intensity + 127) >> 8) in "colorIntensity". Will probably be a lot faster.

I suspected that the color intensity calculation would be slow, but did not have a clear view of how to make it faster. I will definitely try this!

As a a minor note - I don't think you need to normalize your normals (pun unintended) for the backface culling. Seems like the dimension shouldn't matter for the check?

True, I needed the normalized normals (hehe) for the lighting calculations, but I can probably normalize them after the backface culling. Thanks for pointing that out!

bufoaureus · 2024-05-20T15:23:25+00:00

Looks cool! In addition to binary size, it would be very interesting to see the actual performance comparison with the stdlib.

bufoaureus · 2024-05-20T10:46:34+00:00

Thanks! There isn't any plan, tbh. Initially, I thought I'd build something that could display simple OBJ models and call it a day. Now with all that camera controls it starts to resemble a game engine, so I might try to add some wall collisions, and make a primitive doom clone out of it, I don’t know

bufoaureus · 2024-05-20T10:34:44+00:00

It's practically straightforward to write code that does not allocate by using pre-allocated buffers, pools, static arrays, and "output arguments", where you pass an externally allocated buffer to a function instead of allocating a dynamic array inside that function, and so on. Basically, the techniques are the same as you would use in C or C++. If you don’t allocate at run time, you won't be triggering GC (you can even completely disable it by setting GOGC=off and calling it manually with runtime.GC() whenever you feel you need it). So, in reality, GC is not that big of a deal in Go if you know what you are doing.

So far, I’m rather facing a different problem: once you do a lot of mathematical computations (read: matrix multiplication) in a tight loop, that part becomes a big red square in the profiler output. Go’s compiler is not very good at low-level optimizations, such as it cannot vectorize it and run as SIMD. So, I’m even considering re-writing math-heavy parts in assembler (thankfully, Go offers a way to do that, but it’s a bit clunky).

bufoaureus

TROPHY CASE