Making a 3D modeler in C in a week

Update: Although, having a closer look at the scene, I see its pixel art, so I bet the author is snapping floating point positions to a pixel point to prevent sub pixel blurring.

Another small update: I was sure requestAnimationFrame was locked to 60fps, but I noticed on Chrome the other day it was 144hz, the full speed of my monitor.

Which is amusing :)

What if Ray the person was named after ray-tracing by his parents?

There are three different aspects here, each one can be done differently and all can be (and have been) mixed or ignored:

1. Set the video mode. You can either do that or not and use whatever the desktop is running at. You may want to change the video mode not just for resolution but for using a different refresh rate. Both native games (like, e.g. Quake source ports using SDL2) and Wine still do that (you can disable the modesetting in Wine via the registry so that games only see the desktop resolution as the only available one).

2. Create a fullscreen window. There are two ways to do that: either create a window that bypasses redirection ("redirection" here means that the window manager wont manage it, it has nothing to do with compositing - if a compositor is used - though some compositors also use it as a hint for that) and have it cover the entire desktop area (you may want to use randr to figure out the monitor area for multiple monitors) or alternatively use the fullscreen hint on the window and let the window manager handle this. Note that some window managers may not support this or have bugs with it.

3. Handle input. X11 provides an API to capture mouse and/or keyboard input, though strictly speaking this is not really required and TBH i do not see why games ever did that (i can only think of conflicts with other programs but i'd expect this to be something for the user to deal with). In any case, it is rare for games to do that these days. You can just handle input "normally" like any other program. You can provide a (by default disabled) option if you really want to though as the API for capturing is trivial.

For my last game engine i did #1 (with an option to use whatever the desktop resolution is) and #2 (using the fullscreen flag by default with the redirect flag as an alternative for window managers that had issues with the fullscreen flag) but i didn't bother with #3.

Some legacy apps (that is, games) react very badly when they're not in full control of their window sizing, priority, input and device polling, ecc.

WARNING unpaired | unescaped *'s !! :-)

grrr, markup

And if every C project takes this same philosophy to poor documentation, how exactly is a new person learning C supposed to build that common sense? Brushing off poor documentation with "you just need more experience" is not a valid response. The documentation for that function could be much more clearer without being much longer.

so, while the documentation could and should be more explicit than the single telegraphic line you quote, the function's behavior is fine, and detecting and trying to handle the null pointer would make its behavior worse and harder to debug (except on like an arduino or ms-dos or something)

not every c api description needs to be an introductory tutorial for c

Sure, but they don't carry that length information when being returned from a function.

Not in any sense that is actually useful to the programmer, at runtime at least. You cannot ask an array how big it is.

Pointers actually do have length information as well, otherwise free() would not work. But its the same deal with arrays - there is no way to access it outside of compile time constants, if those are even present.

This is 100% correct. The parent of the parent is confused (or is just using terminology incorrectly) as are the current siblings to my comment.

One post claims pointers carry length information so that free works. This has nothing to do with pointers, it has to do with the implementation of malloc and friends. It's only a promise of a successful malloc that you can free, nothing to do with the pointer other than it was returned by malloc. Pointers can point to all sorts of things, the only information they intrinsically have are the type of the object they point to and its address.

Two posts claim a function can return an array of bytes. This is impossible in C. You can't return an array of bytes. You can return a pointer that might point into a continuous sequence of bytes. You could also return a struct whose member is an array, but that's rarely done. When you return (or pass) what looks like an array syntactically, it is converted to a pointer to its first element.

Arrays, on the other hand, always carry length information via the sizeof operator. A special hand waving case would be you could define a pointer to an array (not a pointer to the first element of an array), so in effect the length is contained within the pointer type. E.g. char (*foo)[42] declared foo as a pointer to an array of char with length 42.

So that is pretty much worthless outside the current scope where they were declared.

You still have to get decent topology out of the modelling package, and marching cubes aren't going to give you that. If you have to retopologize your sculpted model by hand to make it viable for use in a rendering pipeline you might as well have just started with good topology in the first place and save yourself the time.

How do you rig an SDF for animation (eg. skeletal, for a humanoid figure)?

But I don’t think it’s true. Why do you say SDFs don’t have finite resolution? There are no infinite precision SDF implementations. Meshes as a concept have no resolution limits either, you could in theory store verts in infinite precision, but in practice people usually use floats. It is the same with SDFs. In practice, the resolution limits are identical - it’s whatever you can store in a 32 bit float. It’s extremely common with SDF ray marchers to have a much higher threshold than the smallest fp32 delta, so I would say in practice, meshes probably have higher resolution than SDFs most of the time. And whatever, because it never matters. Nobody is pushing either SDFs or meshes to their resolution limits, and nobody wants that because you get visible quantization artifacts with both meshes and SDFs when you come anywhere close to the resolution limits.

Edit: and the most significant evidence for this is in comparing all the CVEs for C/C++ vs. memory safe languages like C#/Java.

> I've worked at a couple shops that these issues hit like a ton of bricks.

What you're missing is that 99% those shops wouldn't have existed at all if they had tried to go the C/C++ route because their products just wouldn't have gotten to a viable state. What your experience shows is that working in memory safe languages is so much easier that even average or mediocre programmers can get a viable product.

Yep, I have multiple scars and gray hairs due to them.

I would agree that you can be faster than you'd think on problems that C is reasonably good for. This is a fairly small subset of problems though, where your original comment was phrased like a general statement for any sort of problem / general purpose programming. That's what I take issue with.

If you're going to do any kind of programming that depends on interfacing with the world, UTF, protobufs, even rendering to a screen as with this article, you're going to be pulling in those same sorts of dependencies that you denounce from all of those other languages.

> Whatever ownership issues you have in C, you'll have in most other GC languages as well.

I agree you have similar thread safety issues, the ownership issues I was referring to was for managing lifetimes leading to double-frees or leaks. Yes there are some idioms that almost work, but "almost work" is exactly the point, in GC'd languages they actually do just work.

I understand the appeal behind the economy of C but we just shouldn't pretend it's something that it's not.

Which is why the concept of thread-safe types exists. The documentation usually explicitly states if a particular container/service/anything else is safe to call from multiple threads concurrently or not, and the standard library goes to great lengths to either make the types that are expected to be used in multi-threaded scenarios thread-safe or to offer thread-safe alternatives (like ConcurrentDictionary<K, V>).

Worst case, most types are engineered in such a way that should thread-safety be violated, it would either lead to an exception or an invalid state but not to memory safety issues.

Ah!!! It's the Alanis Morrisette meaning of irony, not the dictionary one!