Live data from Hacker News

Why I Write Games in C

jonathanwhiting.com

91–100 of 303 posts

Re: Why I Write Games in C

#91
post #5

> I would like to use [Go], but there are big roadblocks that prevent me. The stop-the-world garbage collection is a big pain for games, stopping the world is something you can't really afford to do. GC pauses in Go should not be a serious issue for games like the ones featured on the OP's site. The same general techniques used for high-performance manual memory management work fine in garbage-collected languages --…

>I would say the same for C, honestly.

Really? SDL is quite poor??? It has bindings in pretty much every language and I would guess is the most popular game library in existence, written in pure C. It is not a game engine but is an excellent library to build one with. It is so popular for this purpose that it has its own COLUMN in the Wikipdia table of game engines:

https://en.wikipedia.org/wiki/List_of_game_engines

Re: Why I Write Games in C

#92
post #89

Because he claims that reducing the possibility for bug is a main concern I feel two languages, in his nicely written write-up, are left out: Rust -- low-level like C, fast like C, more modern than C, specific ways to reduce categories of bugs (borrow checker), promotes a more functional way for programming Haskell -- not as low-level as C, but pretty fast (best possible performance was not his main concern), many wa…

How is the Haskell stability nowadays? Simon Peyton Jones joked at one point that Haskell is not meant for production from the point of view that they are tinkering with it constantly. At some point the Haskell landscape looked like the GHC core and an endless desert of abandoned projects (which imply strongly it's not as good towards the librarys purpose as some other language).

Re: Why I Write Games in C

#93
post #69
post #67

Earlier quoted context omitted.

What is an intrusive container?

A technique commonly used in C, for example in the Linux kernel. You embed "links" to other nodes in your structs, and find the struct from the link based on offsetof. Linux kernel uses linked lists and red-black trees this way. Probably other data structures too. Intrusive containers are cache friendly and typically require no dynamic allocations (in addition to allocating the data itself). See the link in the post…

Interesting. At first I thought you were claiming this technique made linked lists cache friendly. After looking at it, I have concluded you meant merely that the next and prev pointers are near your data. Am I understanding you correctly?

Re: Why I Write Games in C

#94
post #90

Earlier quoted context omitted.

Found it difficult to integrate with existing JS, such as THREE.js. Also found it difficult to create libraries (I make a RAD workflow for VR apps) that could be used in arbitrary JS projects; I want people to be able to drop my concatenated script into their page with a script tag and not have to worry sbout anything else. Also, early on I ran into quality issues with the 3rd party type mappings for popular librarie…

You should give Flow a try, seems it would fit your requirements from typing point of view. You'll see whether it'll be fast enough for you.

You will have to provide a link, because Googling revealed only a long-dead project with a Chinese website and an empty GitHub repo.

Re: Why I Write Games in C

#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 several projects and compile them into dll's, this way compilation time is drastically reduced and with a side benefit of clear separation of different parts of the program.

Re: Why I Write Games in C

#96
You don't really get rid of complexity by using a simple language. You just move the complexity into your own code.

Say if your language doesn't have dynamically sized containers, you will end up writing your own. You hack it so you can store different types in it. You have reinvented polymorphism. And then you need sort functions, and everything else that is missing from the language.

And it wont be simple any more. Probably slow and buggy too. But you are not alone. Everyone has their own private code framework that is too complicated for anyone else to make use of. If only there was some way to avoid this mess ...

Re: Why I Write Games in C

#97
post #5

> I would like to use [Go], but there are big roadblocks that prevent me. The stop-the-world garbage collection is a big pain for games, stopping the world is something you can't really afford to do. GC pauses in Go should not be a serious issue for games like the ones featured on the OP's site. The same general techniques used for high-performance manual memory management work fine in garbage-collected languages --…

>I would say the same for C, honestly. Really? SDL is quite poor??? It has bindings in pretty much every language and I would guess is the most popular game library in existence, written in pure C. It is not a game engine but is an excellent library to build one with. It is so popular for this purpose that it has its own COLUMN in the Wikipdia table of game engines: https://en.wikipedia.org/wiki/List_of_game_engines

Of course, a more or less 100% complete wrapper of SDL for Go exists, too, so SDL invalidates the original argument against Go if you're considering it for C.

Re: Why I Write Games in C

#98
post #5

> I would like to use [Go], but there are big roadblocks that prevent me. The stop-the-world garbage collection is a big pain for games, stopping the world is something you can't really afford to do. GC pauses in Go should not be a serious issue for games like the ones featured on the OP's site. The same general techniques used for high-performance manual memory management work fine in garbage-collected languages --…

>I would say the same for C, honestly. Really? SDL is quite poor??? It has bindings in pretty much every language and I would guess is the most popular game library in existence, written in pure C. It is not a game engine but is an excellent library to build one with. It is so popular for this purpose that it has its own COLUMN in the Wikipdia table of game engines: https://en.wikipedia.org/wiki/List_of_game_engines

Another nice library is SFML[1], which has bindings for C and several other languages (including OCaml).

[1]: http://www.sfml-dev.org/

Re: Why I Write Games in C

#99
post #90

Earlier quoted context omitted.

You should give Flow a try, seems it would fit your requirements from typing point of view. You'll see whether it'll be fast enough for you.

You will have to provide a link, because Googling revealed only a long-dead project with a Chinese website and an empty GitHub repo.

flowtype.org

Re: Why I Write Games in C

#100
post #87
post #58

Earlier quoted context omitted.

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

"real-time memory browser-editor for your whole engine." Can you describe very briefly how you have the server set up? I've wanted to add this to my c hobby projects for a long time and would enjoy any tidbits of the practicalities involved.

Sure, although I don't have a separate server. Explanation here: http://pastebin.com/Nm6Qta4u
Post reply on HN