Why I Write Games in C • Hacker News Board

Re: Why I Write Games in C

#221

Post by cLeEOGPw » Sat, Jan 09, 2016, 8:59 PM UTC

loup-vaillant wrote: post #181

cLeEOGPw wrote: post #95

I see one of the core reasons C is chosen over C++ is the speed of compilation. My question would be, to what extent is compilation speed relevant? What time differences are we talking about? I agree that every second counts, and I understand that fast compilation just feels good to work with for a hobby project, but what serious relevancy it has? At least the way I do it is divide program (a game for example) into s…

Most C++ projects I have worked with, regardless of their size, had re-compilation times that routinely exceeded 20, sometimes 30 seconds. There are various reasons for this, among which uncontrolled use of templates and nested header inclusions where a forward declaration would have sufficed. C, with its simpler grammar and the absence of template, tend to re-compile under 5seconds even for sizeable projects.

So, roughly speaking, you can expect for a difference in the order of tens of seconds. But my question was, how relevant is this? At least in my experience, and I have worked with projects that took up to 50 minutes to fully recompile (before we moved to newer ms compiler) when taking all dlls, the full recompilation is rarely required. Sometimes you have to recompile project, which can take minute or so, but most often you do incremental compilations that barely takes a second. So for me it's hard to imagine compile time having considerable impact on delivery. Most of the time is used while reading the code and thinking how to solve a problem, not typing the keyboard and waiting for compilation to finish. And I would argue that properly written C++ can greatly improve the biggest part of work - reading and understanding the code. I admit that properly written code is not a given etc., but for personal project you can write however you want. In the end it's probably more personal prefference and how confortable you feel rather than strict rational choice. I think both C and C++ are very close calls, especially considering all the other choices there are.

Re: Why I Write Games in C

#222

Post by chipsy » Sat, Jan 09, 2016, 9:00 PM UTC

chii wrote: post #131

fennecfoxen wrote: post #103

Earlier quoted context omitted.

> their own private code framework that is too complicated for anyone else to make use of Well, to be fair, games are one place where code reuse and maintenance by third parties is less likely to be needed. The real sadness is when you get corporate websites, technology platforms, and the like that decide they need their own framework to make their own set of tradeoffs, and do a mediocre job of it, and end up with a…

> Well, to be fair, games are one place where code reuse and maintenance by third parties is less likely to be needed. i feel like this is somehow perpetuated like folklore, but there shouldn't be any reason why game code should be inherently less reusable than other areas of software development. For example, code that deal with geometry data shouldn't really be any different for games, or code that deal with settin…

The framework level stuff is definitely reusable. Anything that involves rendering or collision touches on design decisions and thus impacts engine reuse. The off-the-shelf systems do conventional designs and workflows well, basically. But you go around them as soon as you want to explore in depth, no matter how big or configurable the engine is.

This leads to a situation where copy-paste at the start of the project may be the best way to reuse good stuff. Otherwise too many assumptions change. If you try to make it a parametric problem, you usually just find out you introduced accidental coupling later.

Re: Why I Write Games in C

#223

Post by davexunit » Sat, Jan 09, 2016, 9:01 PM UTC

weavejester wrote: post #123

Are GC pauses really significant? I can understand there being problems if you have to churn through gigabytes of world data, but the author's games don't appear to be on that scale.

Like in any program written in any language, you want to minimize allocation. People love to play the garbage collector blame game.

Re: Why I Write Games in C

#224

Post by krapp » Sat, Jan 09, 2016, 9:02 PM UTC

loup-vaillant wrote: post #183

ivanca wrote: post #39

Earlier 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.

Try and implement http://jonathanwhiting.com/games/knossu/ with Unity. My guess is, the author would have taken more time learning Unity than implementing this game.

For that to be a valid comparison, you would have to compare the learning curve for Unity to the amount of time it took him to learn how to implement the original.

Re: Why I Write Games in C

#225

Post by krapp » Sat, Jan 09, 2016, 9:05 PM UTC

Grishnakh wrote: post #133

raverbashing wrote: post #6

I 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++…

Better yet, avoid STL altogether and use Qt. It makes C++ very manageable and uncomplicated.

In my opinion, with which many will probably disagree, there's nothing wrong with using STL containers in moderation if you approach it right. std::vector is good enough and fast enough in most cases if you reserve space and are judicious with allocations.

Re: Why I Write Games in C

#226

Post by bluecalm » Sat, Jan 09, 2016, 9:09 PM UTC

pcwalton wrote: post #191

Tistel wrote: post #151

C++ compile and link time. I once worked on a PS3 game that had a 50 minute turnaround time (change code -> compile -> link -> load). No scripting either. The horror. It was because the company had home brewed a bunch of "optimizations" into the build process. On the up side it will force you to learn to live edit the game with the debugger to tweak and adjust. If its C++ and the programmers know the engineering KISS…

> I like the simplicity of C too. You can have a good mental model right down the CPU of what is going on. Not really, with compilers as sophisticated as they are and the spec as liberal with undefined behavior as it is. The C virtual machine that the spec defines is every bit as complex as any other virtual machine. > But these days given how fast CPUs are and how much more productive you can be in a high level lang…

>>Not really, with compilers as sophisticated as they are and the spec as liberal with undefined behavior as it is. The C virtual machine that the spec defines is every bit as complex as any other virtual machine.

Having some undefined behavior in your code is just a bug, it has nothing to do with being complicated or compiling to machine code. It's not nearly as complex, in fact there are many people who understand quite well what the code compiles to. You can read the assembly as well and understand it for big parts of the code (oh, it compiled it to that, vectorized this but didn't vectorized that etc.). Try guessing what Java compiles to. It's not even close to the same level of complexity.

>>I totally agree. In fact, I wouldn't use C even for projects where a GC isn't suitable, just because we have alternatives

The only serious alternative as of today is C++. Rust is a new untested language which no one wrote anything quite serious in yet and which offers a lot of trade-offs in exchange for being safer, everything else is slow as hell.

Re: Why I Write Games in C

#227

Post by lobster_johnson » Sat, Jan 09, 2016, 9:10 PM UTC

hellofunk wrote: post #144

crafn wrote: post #141

Earlier quoted context omitted.

When you drop the semantic silliness of C++, like having the container to take care of constructing, copying, moving, and destructing, not to mention exception safety, a basic implementation of a "templated" dynamic array implementation in C comes down to like 100 lines. Hash map will be a bit more, and is not so trivial to write. It's true that there should be no need to write these things yourself. The alternative…

Considering that vector, map, etc are widely used and expected features of software development, I would think that good libraries in C exist for these already, so you don't have to even write your own 100 lines. Are there any?

GLib (not to be confused with glibc) from the GNOME project has a wide range of functionality -- generic lists, hash tables, strings etc.: https://en.m.wikipedia.org/wiki/GLib

Qt, I believe, also comes with a bunch of "standard library" stuff unrelated to UIs.

Re: Why I Write Games in C

#228

Post by Mikeb85 » Sat, Jan 09, 2016, 9:16 PM UTC

He mentioned a bunch of languages, and I'm not sure why he doesn't look into something like Kotlin. It's the JVM so you get maturity and it's fast as hell (ran a few economics-related benchmarks on my machine, OpenJDK 8 beat both C++ and Fortran!), has great IDE support (Intellij IDEA - which will actually translate Java into Kotlin if you want to translate snippets), and it doesn't strong-arm you into an OO style. And of course Lwjgl 3 is written mostly in Kotlin.

If he liked Flash, I'm also surprised he didn't go with Haxe. It's fairly mature, is a very nice language (Swift looks like it was mostly ripped from Haxe), with OpenFL he gets the Flash API (but can also compile to native or JS), and of course Haxe also has other frameworks available, or can even be used with native frameworks quite easily.

Anyhow, as far as C goes, it's a decent enough choice. It's simple enough, if you don't mind writing helpers for various tasks and building your own libraries then why the hell not. I definitely prefer the typical C style of programming to the prevailing C++ style.

Re: Why I Write Games in C

#229

Post by kungfooman » Sat, Jan 09, 2016, 9:20 PM UTC

majika wrote: post #71

AndyKelley wrote: post #19

The 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…

My solution is to write Jinja templates of C source files: https://github.com/mcinglis/libarray Libarray (and my other C libraries; Libvec etc) have served me very well on a 20k LOC project. With ~150 source files, the entire project builds from fresh in 20 seconds on a i7-2620M. Rebuilds are super-fast; with proper Makefile specification, there's no need to rerender/recompile the templated files.

AGPL? Never. Ever.

Re: Why I Write Games in C

#230

Post by krat0sprakhar » Sat, Jan 09, 2016, 9:22 PM UTC

Mikeb85 wrote: post #228

He mentioned a bunch of languages, and I'm not sure why he doesn't look into something like Kotlin. It's the JVM so you get maturity and it's fast as hell (ran a few economics-related benchmarks on my machine, OpenJDK 8 beat both C++ and Fortran!), has great IDE support (Intellij IDEA - which will actually translate Java into Kotlin if you want to translate snippets), and it doesn't strong-arm you into an OO style. A…

I've been meaning to get into Kotlin and building a game sure sounds like fun. Are there any Kotlin specific game programming frameworks (or any other resources for that matter) that you'd recommend?