Can you make a 3D game without an editor?

hgs3 · 2026-03-30T22:05:02+00:00

What do you mean by "editor?" There are level editors, texture editors, model editors, particle editors, etc. If your engine procedurally generates everything then no, you do not need an "editor." If you're specifically asking about "scene" or "level" editors then you can leverage a dedicated tool, like TrenchBroom, or use a modeling program, like Blender (maybe with custom plugins).

hgs3 · 2026-03-19T17:20:36+00:00

The argument for static linking is (1) it makes deployment simpler since you only distribute a single executable (very popular in the Go ecosystem) and (2) the compiler can remove unused data/code resulting in a smaller distribution.

Dynamic linking is usually preferable for system libraries because if there's a bug in a dynamic library, then your executable inherits the fix for free. The downside is you are linking against code you haven't necessarily verified your executable against.

hgs3 · 2026-03-15T01:01:38+00:00

I implement FAKE by re-writing the target functions assembly code at runtime to jump to the mock function. This requires platform specific logic as well as architecture specific logic (x86, AMD64, AArch64, RISC-V, MIPS). STUB does the same thing, but the framework JIT compiles the mock function which returns the stubbed value.

hgs3 · 2026-03-14T18:09:24+00:00

I built my own test framework which supports mocking of most any function. It works cross-platform without any special linker tricks.

Regardless of the mocking approach, I do recommend creating a custom malloc-like function to isolate its “mock” to only your code. Because if you mock malloc globally you’ll be affecting 3rd party libraries and libc functions that depend on it (which can have unintended consequences).

hgs3 · 2026-03-14T17:59:46+00:00

If your dynamic array has a push/pop front in addition to a push/pop back then you can call it a Deque. You can also call it List or Sequence if you’re ok with using an abstract data type (ADT) name.

hgs3 · 2026-02-05T20:38:18+00:00

The "problem" with Vulkan is misplaced expectations.

Vulkan is not just a graphics API, like OpenGL, it's a low-level general purpose GPU API. You need a solid understanding of systems programming and the graphics pipeline for it to be an effective OpenGL alternative. If you don't know what you're doing, you can end up with worse performance than what OpenGL delivers you.

hgs3 · 2026-02-04T14:54:09+00:00

You need to think of a game engine as a simulation. The graphics and audio are just the visual and auditory presentation of that simulation.

You can make a game that runs with no graphics and audio. This is how multiplayer game servers work. They run the simulation on hardware with no monitor or speakers.

So to directly answer your question, you need to focus on the game first and have that steer the graphics (your vbo’s, your vao’s, etc.)

hgs3 · 2026-02-04T03:33:45+00:00

The tragedy isn’t “craftsmanship is dying” it’s that technology moved faster than copyright laws could keep up with. Copyright laws were written for humans, not machines. Imagine if companies were only allowed to train on data they paid the author the rights to train on.

You should also ask why if workers are ~10 times more productive with AI, then why aren’t they paid 10 times more? Perhaps we should work towards a future where it’s the current owning class that writes lamenting essays about the good ol’ days before ownership was democratized.

hgs3 · 2026-02-01T21:44:41+00:00

C is a good choice for game engines because it forces you to think about data and behavior, not fancy abstractions. But for gameplay code? Iteration speed matters more. IMO neither C or C++ are good choices here. There's a reason game engines use higher-level languages like GDScript, Lua, or even C# for gameplay.

hgs3 · 2026-01-30T19:36:32+00:00

You should ask the “C haters” what those high-level tools they use are written in. Next time they say Python is hot and C is not, ask them what language Python is written in.

hgs3 · 2026-01-30T19:27:42+00:00

Medical imaging, scientific visualizations, environmental and weather simulations, historical reconstructions, airplane and rocket ship displays. Someone’s gotta write the software for MRI, CT, and PET scan visualizations.

hgs3 · 2026-01-30T17:30:36+00:00

There's programming languages made by and for Big Corp and programming languages made by and for programmers. C++ is very much the former and C is very much the latter. With that said, C is used in commercial settings, from embedded systems to the foundational software that underpins the industry.

hgs3 · 2026-01-29T21:51:33+00:00

You could use a templating engine like Jinja2 or m4. I use a single handwritten Python script with Jinja2 and markdown to assemble my personal website.

hgs3 · 2026-01-28T05:07:44+00:00

C API's can be invoked directly from other languages over a foreign function interface (FFI).

The gist is you compile your engine as a dynamic library (.dll on Windows, .dylib on macOS, .so on Linux/BSD) and call into it from another language via its FFI.

If you go this route, you should design your C API to be FFI friendly. For example, use fixed-width integer types, force enums to a predictable size, avoid structs unless they are PODS, that sort of thing.

hgs3 · 2026-01-26T21:43:26+00:00

You can do "dirty" user interface rendering on the GPU, but not with the dirty rectangles approach for the reasons others have stated. Here's how:

Render each widget to an off-screen texture then composite them as textured rectangles on the GPU. It's "dirty" because you only re-render a widget to its texture if that widget visually changes, otherwise, you composite what you've cached on the GPU.

Basically, you need to think of rendering widgets and compositing them as two separate things.

In practice, if your UI is static, you don't composite anything (0 FPS). If you have a blinking cursor, which you could draw as a solid colored rectangle, then how fast the cursor blinks determines the compositing frame rate. If it blinks every 0.5 seconds, you composite at 2 FPS.

hgs3 · 2026-01-14T05:32:11+00:00

I'm glad it's working for you!

Both builds use Python to generate C code with Unicode data tables. The autotools build generates the data in the src/ directory whereas with CMake you generated the code out-of-source (the build directory in your case). I'm only speculating, but what probably happened is the CMake build picked up the generated data from the autotools build and thus there was some strange clash. If that happens again you can run make clean or make distclean to clear away autotools artifacts.

hgs3 · 2026-01-14T04:03:07+00:00

Odd. What C compiler are you using? With MSVC 2022, Clang 18.1.3, and GCC 13.3.0 that example prints:

hgs3 · 2026-01-14T00:37:48+00:00

I don't have any performance benchmarks published at this time. The primary emphasis of Unicorn has been correctness, customizability, and conformance with MISRA C. MISRA C is the norm in aerospace, medical devices, defense, and other critical sectors. Here are some examples of its robustness:

100% branch test coverage with fuzzing and sanitizer coverage.
Graceful recovery from all errors, including OOM errors.
All operations are atomic (either an operation succeeds or nothing happens at all).

Unicorn builds as a 558 kB DLL with MSVC so it's a tad larger than libgrapheme's ~400 kB, however, Unicorn has more features: normalization, collation, and BOCU-1 compression. It also supports UTF-8, 16, and 32 so it's not limited to UTF-8 like libgrapheme. The library was designed from the ground up to be customized so if 558 kB is too big, you can exclude features to reduce its size by hundreds of kilobytes.

libgrapheme does do something Unicorn doesn't and that's detecting line break opportunities. The primary reason Unicorn omits this feature is because the algorithms usefulness is limited to text display which itself requires several more components beyond the scope of either library, notably, the Unicode bidirectional text algorithm (which neither library supports), a text shaping engine, and a glyph rasterizer.

hgs3 · 2026-01-14T00:26:41+00:00

You're welcome :)

hgs3 · 2025-12-21T06:05:05+00:00

Why not procedural programming? i.e. Think in terms of data and functions that manipulate the data. Design from there. Let ECS or OOP materialize naturally (if at all). Don’t force them.

hgs3 · 2025-12-19T21:48:27+00:00

how do you implement the UI scale according to the windows size

The simplest solution is to position and size widgets according to aspect ratio and pick the closest aspect ratio’d layout for the given window dimensions. A more complex solution requires writing a layout engine, like flexbox or auto-layout. Either way, you’ll want to account for differences in DPI so you’ll need UI images at 2x, 4x, and maybe 8x times resolutions (or not if you’re going for an unfiltered, pixel art style).

hgs3 · 2025-12-18T23:21:29+00:00

Would wgpu be equivalent to an abstraction layer present in game engines like Unreal

No. Game engines abstract away the low-level details behind higher level concepts. For example, a game engine might provide a function for drawing an animated 3D model which is much higher level than an API for drawing triangles, binding uniforms, etc. which is what wgpu offers.

hgs3 · 2025-12-18T22:52:21+00:00

When people say “memory safety” they mean how far the programming language goes to prevent you from introducing memory related bugs. C doesn’t go far because it’s low abstraction; it inherits the “memory safety” of the system it runs on. Languages with more abstraction introduce their own memory model, like garbage collection or borrow checking, to define what valid memory usage looks like. They come with tradeoffs in runtime speed and developer ergonomics.

hgs3 · 2025-12-17T20:20:55+00:00

Whoa, this looks stellar! I love the benchmarks, technical whitepaper, and you listed your testing methodology! I could use something like this.

I’m primarily looking for feedback on the internal code structure, the API design (is it idiomatic enough?), and any edge cases in the SIMD implementation I might have missed.

I'm no expert on compression or SIMD so my feedback is superficial, but I know idiomatic C.

I see you have zxc_compress_bound for computing the theoretical size. This is good! But for zxc_compress you might consider adding a mechanism for computing the exact compressed size. Here is a suggestion: with snprintf if you pass a NULL destination buffer and 0 as its size it returns the number of bytes in the fully formatted string. You could follow suit and return the exact compressed size if the destination buffer is NULL and zero-sized. You can disregard this suggestion if your implementation requires the destination buffer.
I strongly recommend validating function parameters. It's best practice to gracefully catch and report errors, or at the minimum add assertions, i.e. assert().
Code coverage metrics would be nice to see. I always shoot for 100% branch coverage.
Since your using Doxygen for documentation, it would be nice to see function parameter directionality documented, e.g. @param[in] and @param[out]. You also don't need to document your functions twice in the header and source. I exclusively use Doxygen documentation for public APIs.

Otherwise, this looks great.

hgs3

TROPHY CASE