no auto in C.
no standardized data structures.
no lambda.
no exceptions.
and C++ still compiles actually fast. at least on my machine.
Why I Write Games in C
51–60 of 303 posts
Re: Why I Write Games in C
#52Earlier quoted context omitted.
If you're going to write a TL;DR for others, you should at least read the article yourself, don't you think?
I did, it is so abstract to pretend you can do better that there is no way to discern. He didn't even mention "unity" in his post, thats just ridiculous in 2016, but yeah, keep down voting, your implementation of 2d graphics, sound, collision, physics, plugins, marketing, sprites, menus is gonna be so much better than hundreds of engineers at unity withing 10 years straight.
Unity is not a language. They do not discuss frameworks/gameengines. Fürther unity is basically C# and JavaScript, languages mentioned by the article.
Re: Why I Write Games in C
#53Delphi compiles extremely fast, is strongly typed, no GC, has templates, objects. Too bad Embarcadero positioning towards Enterprise with its relatively high pricing effectively derailed it as a mainstream language and killed its community.
Well, there is FreePascal and the Lazarus IDE which appears to have been built by rather enthusiastic fans of ObjectPascal and the Delphi IDE.
I tried to use it when I took over maintenance of a Delphi application developed in-house, because I had no prior experience with Delphi or Pascal. Both FreePascal and Delphi felt very, very similar to ObjectPascal and Delphi. Unfortunately, Lazarus crashed on me a lot both on Linux and OS X, so I gave up on it rather quickly. But it might work better on Windows.
Re: Why I Write Games in C
#54The thing I miss most in C when I don't cheat and use a couple C++ features is templates. Specifically, a dynamically sized List implementation that is type-generic. If you do this in pure C, you have to pick your poison: 1. preprocessor abuse 2. void * 3. multiple redundant implementations of the data structure Dynamically sized lists are used so often, that this tends to be a problem in almost every C project. I wo…
BAH!
4. The "intrusive" containers, but of course.
The one true way to do it in C.
For one, you can keep items in multiple containers, all being on equal footing. None of that typical C++ mess, when this list is a primary storage for items, and those maps are secondary indexes, all sprinkled evenly with iterators. Intrusive containers don't own items, they merely organize them, which is exactly the right way to go about it.
For two, the actual code for container operations is as abstract and on-point as it gets as it focuses solely on "weaving" items into and out of a container rather than on other things, like de/allocating supporting structures.
For three, you get no heap activity when adding/removing items to/from a container. This means that if you already have the items, you can always arrange them into a collection. This also eliminates a lot of error handling code, leading to a simpler code.
Obviously, this is not limited to just linked lists.
Re: Why I Write Games in C
#55Incidentally, all of his reasons that don't misrepresent C are all the same reasons I write games in JavaScript. Mostly, it's about speed of development, understanding, and platform compatability. Performance is good enough and almost always my fault when it isn't. I wish for a strictly typed language, but OP isn't using one, either. I've tried several of the transpilers and have generally found the workflow lacking…
Did you try Typescript? I'm curious what you thought of it for games if you tried it. I enjoyed using Cocos2D JavaScript bindings for cross-platform game development.
Re: Why I Write Games in C
#56Earlier quoted context omitted.
I did, it is so abstract to pretend you can do better that there is no way to discern. He didn't even mention "unity" in his post, thats just ridiculous in 2016, but yeah, keep down voting, your implementation of 2d graphics, sound, collision, physics, plugins, marketing, sprites, menus is gonna be so much better than hundreds of engineers at unity withing 10 years straight.
Unity games I've tried seem to stutter often. Any idea why? GC cycles?
With C and C++, you have to be careful you release resources yourself to avoid leaks. With GC languages (besides memory leaks from referencing objects you no longer care about) you have to be careful that you preallocate upfront a good portion of the objects you need and reuse them to avoid GC stutters.
Re: Why I Write Games in C
#57Earlier quoted context omitted.
there are plenty of games using pure Lua. www.love2d.org :)
No, Only the scripting is Lua. The engine is all in C++.[1] [1] https://bitbucket.org/rude/love/src/tip/src/
After all, that's kind of the point of Lua. Write all of the performance-critical / low-level stuff in C or C++, expose it to Lua, then orchestrate it from a Lua script. Lua's C API is very pleasant to use.
As a standalone scripting language, I found it rather awkward to use when compared to, say, Python or Perl. It was only when using it as an embedded scripting language (not on a game, though) that I could really see it shine.
Re: Why I Write Games in C
#58I understand the want for simplicity in C (and Go gets closer, but has its issues), however, it seems in the end it drags you down. Just having the C++ ability to have objects doing things is very helpful. But yeah, C++ has the ability to get very complicated But it's your choice to have "complicated C++". Limit yourself to some functionalities and it's much more manageable. Use basic STL and keep it simple (also C++…
There are some arguments to stick with C instead of a very C-like subset of C++. Off the top of my head:
- Recompiling and reloading parts of your game at run-time is quite easy in C. In C++ you have to make sure (at least) that nobody has pointers to vtables of the dll at the time of reload. This can be a bit tricky if you're using things like std::function in your dll code. Yes, you could be using a scripting language, but thinking how to match the semantics of a scripting language with your engine, where to draw the line, and then write the glue code is a lot more work than just reloading some plain C functions. And if you later decide this was a bad/worthless idea, reverting from dynamic C code to static is almost a no-op, whereas reverting back from scripts is dreadful.
- A quick & dirty reflection is easy when you don't have to deal with name mangling, templates, and overloading. Just some script scanning through your code and outputting elementary type info to .c file may be enough for things like real-time memory browser-editor for your whole engine. This can be very valuable when developing new engine features, as you can view and edit, and maybe draw even graphs of members you just added to some struct. Also useful for modifying game object data on the fly when debugging/creating levels.
(I too do my game programming in C)
Re: Why I Write Games in C
#59The thing I miss most in C when I don't cheat and use a couple C++ features is templates. Specifically, a dynamically sized List implementation that is type-generic. If you do this in pure C, you have to pick your poison: 1. preprocessor abuse 2. void * 3. multiple redundant implementations of the data structure Dynamically sized lists are used so often, that this tends to be a problem in almost every C project. I wo…
Macros are a reasonable way to solve this problem. A good example is BSD's sys/queue.h:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/sys/queue.h...
Re: Why I Write Games in C
#60Earlier quoted context omitted.
I did, it is so abstract to pretend you can do better that there is no way to discern. He didn't even mention "unity" in his post, thats just ridiculous in 2016, but yeah, keep down voting, your implementation of 2d graphics, sound, collision, physics, plugins, marketing, sprites, menus is gonna be so much better than hundreds of engineers at unity withing 10 years straight.
Unity is not a language. They do not discuss frameworks/gameengines. Fürther unity is basically C# and JavaScript, languages mentioned by the article.
No. First of all Unity doesn't use JavaScript, it is a proprietary language called UnityScript that barely resembles JavaScript.
Second, Im talking about the hundreds of tested possible compossibilities of the game you envisioned, regardless if you make it in ensambler or JavaScript. C# is just the language they choosed for their API (unity is written in c++ fwiw)