Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I Write Games in C

jonathanwhiting.com

Post reply on HN
Print view View original

81–90 of 303 posts

Re: Why I Write Games in C

#81

Post by dividuum »

zodiac wrote: post #67
abcd_f wrote: post #54

Earlier quoted context omitted.

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

What is an intrusive container?

The two other responses already described what intrusive containers are. Have a look at https://troydhanson.github.io/uthash/ to see an implementation of them that I personally like and use in my C projects. It's really simple to have a struct that is indexed by multiple keys by basically just adding two UT_hash_handle values to your struct and then using the uthash functions. On top of that, it's a really nice implementation that is completely self-contained in a single C header file.

Re: Why I Write Games in C

#82

Post by [deleted] »

stonemetal wrote: post #76
zodiac wrote: post #67

Earlier quoted context omitted.

What is an intrusive container?

It is a container that intrudes on your data structure. For example in a linked list the next pointer is inside your structure instead of your data structure being wrapped in a node type.

[deleted]

Re: Why I Write Games in C

#83

Post by dom96 »

vive-la-liberte wrote: post #79
dom96 wrote: post #66

How about Nim? [1] [2] To me it is in many ways a "nicer and safer C". Sure it's not as mature as C, but what is? What it does have going for it is portability (it compiles to C so it shares C's portability), a soft real-time GC which can be manually controlled [3], generics, AST macros and much more. 1: http://nim-lang.org 2: https://github.com/nim-lang/nim 3: http://nim-lang.org/docs/gc.html#realtime-support

Have you any code shared on GitHub so I may see some real life Nim?

Sure. There is lots of repos: https://github.com/trending?l=nimrod

Some highlights: Nimble package manager [1], Jester web framework [2], NES emulator [3], NimForum [4], SDL GUI library [5]

And if you want some smaller code examples: http://nim-by-example.github.io/, https://github.com/def-/nim-advent-of-code-2015, https://github.com/def-/nim-unsorted

1: https://github.com/nim-lang/nimble

2: https://github.com/dom96/jester

3: https://github.com/def-/nimes

4: https://github.com/nim-lang/nimforum

5: https://github.com/yglukhov/nimx

Re: Why I Write Games in C

#84

Post by sebcat »

Ace17 wrote: post #42

Simplicity of a programming language, and simplicity of programs written in it are two very different beasts. I understand funny things happening under the hood (garbage collection) might not look attractive ; However you can't require everything to be explicit and, at the same time, keep your programs simple/small. The more you want your code to be small, the more you're gonna need a programming environment (languag…

> The more you want your code to be small, the more you're gonna need a programming environment (language/API/runtime/framework) doing things for you under the hood. And there's nothing wrong about it!

Or have your code do one thing and only one thing, a single purpose, with clear, well defined interfaces and then compose things doing only one thing to a bigger thing that you can reason about more easily because the interfaces and processes are well-defined.

One thing I've seen too much of in my professional life is complex projects trying to do too much, with ill-defined roles and implicit, poorly documented interfaces.

Simplicity of a language works well as long as your projects are kept simple. You can build fairly complex solutions by composing multiple simple projects with well defined interfaces.

I think we agree that simplicity of a language works less well when the scope of a single project is too large and too arbitrarily defined.

Re: Why I Write Games in C

#85

Post by lmedinas »

je42 wrote: post #51

no auto in C. no standardized data structures. no lambda. no exceptions. and C++ still compiles actually fast. at least on my machine.

For years developers used C++ without most of these features and built great code. So this is not the problem of C. There are still lot's of great code done in C.

Re: Why I Write Games in C

#86

Post by holografix »

tl;dr overly comfortable, old school C developer is still worrying about the death of flash and hanging on to what he knows. Finds reason why he shouldn't step out of his comfortable zone.

Re: Why I Write Games in C

#87

Post by fsloth »

crafn wrote: post #58
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++…

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.

Re: Why I Write Games in C

#88

Post by fsloth »

holografix wrote: post #86

tl;dr overly comfortable, old school C developer is still worrying about the death of flash and hanging on to what he knows. Finds reason why he shouldn't step out of his comfortable zone.

Um, "fast compilation", "hotloading dll:s", "future proof" are all to me valid and non-trivial technical requirements. Also - there are better languages than c for lots of things but there is a class of problems (like efficient and correct numerial code) where c is as good as any language "in the same category" (unless one counts fortran)

Re: Why I Write Games in C

#89

Post by cies »

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 ways to reduce categories of bugs that can arise

For game dev't you'll find both have maintained bindings to SDL2.

Re: Why I Write Games in C

#90

Post by xixixao »

moron4hire wrote: post #62
seanwilson wrote: post #55

Earlier quoted context omitted.

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.

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.
Post reply on HN