C-Research said:
Not to be argumentative, but higher languages must generally be slower than C in algorithms, beginner reckless speculation, unless math based algorithm libraries are being used. As an extreme example, would not C# algorithms be usually slower than C ones? I understand that C++ is quite a bit better performing in almost all instances than C#.

Performance is two-fold: Machine performance + developer performance. We could write everything in assembly still, but modern software is so complex, we would never get done with it.
C++ is an extension of C, so in theory it does not have to be slower if you use it accordingly. There are also cases where C++ can be faster, because it gives compilers more options due to a higher level of abstraction.
Though, the question which is generally faster - C or C++, seems to lack a simple answer. Opinions and test cases vary.

But we can assume C++ should be faster than C#, and sometimes much faster. C# has garbage collection, which will add hidden costs no matter how well you know it.

C-Research said:
Where does C actually shine, in your view?

Simplicity. It's nice if you can keep an API in C.

But below such surface, you pay for simplicity with higher implementation complexity.
Personally i don't see anymore point to use it, but i still think it is better to learn C first, C++ on top of that.

C-Research said:
Not to be argumentative, but higher languages must generally be slower than C in algorithms, beginner reckless speculation, unless math based algorithm libraries are being used. As an extreme example, would not C# algorithms be usually slower than C ones? I understand that C++ is quite a bit better performing in almost all instances than C#.

Thats is absolutely objectively false. C and C++ can outperform languages C#, but only if you know what you are doing. If you are not, you are likely ending up with worse performance. Still, the difference in practice is rarely noticable eigther way, and there is even instances where C# can be faster due to JIT. Even so, you should choose your language primarily based on productivity and not raw achievable performance. C++ in particular is well suited for achieving all performance-goals you might have, so there really is no reason to use C in that regards in the gaming-landscape. Both languages share the paradigm of “you don't pay for what you don't use”, and both allow you a fine-grained control on performance-characteristics/algorithms where you need it, but C++ straight forward allows you to write the better abstractions, saving you tons of developement-time, especially when you learn modern C++ (11, 17 and 20).

C-Research said:
Where does C actually shine, in your view?

IMHO, C's main use-case is for platforms where no other language is supported (or, C++ is not supported), mainly embedded systems I'd say. Also its a huge deal easier to write cross-platform-binary compatible C-libraries as well as DLLs (you're essentially forced to use a c-interface for achieving those goals even when developing a c++-app).

The OS cross-platform issue is one of the main reasons why I have been focused on C. C99 is very simple to deploy cross-platform.

Another aspect is that I am trying to use as much Open Source things as possible or, worst case, practical. Supporting Open Source communities is a value judgement rather than a productivity issue for me.

As for productivity, I find learning C++ to be getting in my way. Too much time spent learning C++ with the software, tools, libraries, and the gigantic learning curve which it seems to be, does not appeal to me. Another issue is that when I use VS, I find it sucking me down the path to abandoning Open Source. Same reason why I do not like to use 3ds Max.

I have already used and written some C++ code and see the potential need in game development for me, but I am trying to avoid it.

For above reasons, I am looking at CMake, mingw 32/64, and some header-only programming. When I reach a point of wanting to make really big game code, this is going to be a problem, but I do not see any alternatives which suit my values and my strengths.

@C-Research It sounds like you have made up your mind on using C for this. I think your reasoning behind it is quite arbitrary and not that well thought through. Your reasoning was probably sound 15-20 years ago but programming languages have evolved so much since then. If you decide to look for alternatives I would suggest Rust as an option. It seems to fit your requirements except that you would have to spend time to learn it.

Good luck!

Apart from game engines, I would like to find a list of popular libraries for game GUI menu, ingame stat display, etc. A few game developers use IMGui in their games, but mostly it is used in the studio for tool and engine software GUI, for example.

C-Research said:
I would like to find a list of popular libraries for game GUI menu, ingame stat display, etc.

I'm agreeing with Fleabay's answer earlier: They don't.

User interfaces in games typically don't require what GUI systems are designed for. Sure they have some menus and popups, but they're rarely the comprehensive GUI systems. Some UI-heavy games with tons of heavy dialog, menuing systems, inventory systems, and lots of scrolling, layering, and other GUI-style work exists, but even they don't typically use GUI-style systems.

HUD systems tend to be integrated with the graphics and display systems in games for performance reasons. Modern graphics are built around rendering point clouds and working with megatextures. Typical GUI systems use lots of tiny boxes, text fields, sprites, glyphs, and little images, which can completely destroy rendering performance unless they are pre-composited and carefully rendered in GPU-friendly ways. Even in the major engines they are tricky to get right without graphics performance plummeting.

C-Research said:

Not to be argumentative, but higher languages must generally be slower than C in algorithms, beginner reckless speculation, unless math based algorithm libraries are being used. As an extreme example, would not C# algorithms be usually slower than C ones? I understand that C++ is quite a bit better performing in almost all instances than C#.

That's an overgeneralization. Specific languages (or rather specific implementations of those languages) have specific performance characteristics. In general, you want a strong optimizing compiler for good performance. The low-level nature of C is a double-edged sword: it can generate relatively efficient code just by directly translating the source code, but it also limits some of the more aggressive optimizations that compilers for other languages routinely perform.

C++ and C are roughly the same for equivalent code. C++ has zero-cost abstractions that allow you to write more high-level code with the same performance. C++ code tends to use a lot more inline functions, which is very good for performance, but you can do the same in C.

It sounds as though you have experienced the difference in C and C++ algorithm performance.

Where does C actually shine, in your view?

Tasks that are inherently low-level. Reusable libraries that are by nature connected to specific data structures, e.g. file loading and data compression. Libraries that can be reused from many different high-level languages.

a light breeze said:
Tasks that are inherently low-level. Reusable libraries that are by nature connected to specific data structures, e.g. file loading and data compression. Libraries that can be reused from many different high-level languages.

None of that is unique to C. In most languages it ranges from trivial to pretty easy to create those. You need to mark them with a proper annotation for the language to build a language-agnostic interface, but they all work just fine.

Using C++ in C isn't difficult. The common C pattern, such as the file interfaces that take a FILE* object as the first parameter, are exactly identical to C++ interfaces which take the object structure as the first parameter. The pattern of create/use/destroy like fopen(), fread(), fclose(), is exactly identical to the non-name-mangled C++ interfaces for a constructor, usage functions, and destructor. The interface is the same. That's how they were initially written in the 1980s. The only difficulty in modern code is that the C++ language will mangle the names to encode parameters and other details, the actual interfaces remain the same.

C-Research said:

As for productivity, I find learning C++ to be getting in my way. Too much time spent learning C++ with the software, tools, libraries, and the gigantic learning curve which it seems to be, does not appeal to me. Another issue is that when I use VS, I find it sucking me down the path to abandoning Open Source. Same reason why I do not like to use 3ds Max.

I have already used and written some C++ code and see the potential need in game development for me, but I am trying to avoid it.

For above reasons, I am looking at CMake, mingw 32/64, and some header-only programming. When I reach a point of wanting to make really big game code, this is going to be a problem, but I do not see any alternatives which suit my values and my strengths.

I just use C++ as “C with Classes”. I use only the class, new and delete features of C++. For me, as opposed to using raw C, this provides the benefit of having a much easier time organizing and developing large code bases, while at the same time having the simplicity and few abstractions of the C language. C API's work well with this approach, and you can even wrap sets of API functions into their own classes.

frob said:

a light breeze said:
Tasks that are inherently low-level. Reusable libraries that are by nature connected to specific data structures, e.g. file loading and data compression. Libraries that can be reused from many different high-level languages.

None of that is unique to C. In most languages it ranges from trivial to pretty easy to create those. You need to mark them with a proper annotation for the language to build a language-agnostic interface, but they all work just fine.

Not unique, no. I would use C++ in preference to C pretty much everywhere, and wrap it in a C interface if necessary. But C is not an outright bad choice for these tasks, and C certainly beats interpreted languages (including JIT languages) and garbage-collected languages for writing language-agnostic libraries.