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

71–80 of 303 posts

Re: Why I Write Games in C

#71

Post by majika »

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.

Re: Why I Write Games in C

#72

Post by enqk »

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

C++ when it is practiced in a "standard" way using the standard library and all the standard advices (such as using boost libraries whenever possible) employs a style of programming that generates a _lot_ of intermediary, supposedly zero-cost abstractions that the optimiser then have to work hard to remove.

This is why I say supposedly zero-cost because although your users may not pay for them, you as a developer will pay for them through either slow compilations or alternatively slow debug builds.

C++ can be a good tool if you have the right discipline, however the discipline is hard to follow if you bring a lot of dependencies in.

Re: Why I Write Games in C

#73

Post by eddieroger »

vardump wrote: post #45
AndyKelley wrote: post #18

Earlier quoted context omitted.

The author said that garbage collection and non-static-typing were problems. Last I checked Lua has both of those.

Yet Lua has been embedded in a large number of AAA games.

There's a difference between embedding and using a Lua engine in a game and writing the main game code in Lua. The more accurate question would be, "how many games are written in pure Lua?"

Re: Why I Write Games in C

#74

Post by shurcooL »

> The library support [in Go] for games is quite poor,

I'd like to know the author's familiarity of Go libraries. Perhaps he's unaware of what does exist and makes false claims, or perhaps he's saying accurate statements and just has really high standards.

I help maintain many of the Go libraries/wrappers for games, so I might be biased, but I'm happy with what is available. Almost more so than when I was using C++, because Go packages can be made go-gettable and very easy to include and distribute, unlike with C++.

I've also not hit GC problems so far, but arguably my games are just not demanding enough yet.

Re: Why I Write Games in C

#75

Post by vidarh »

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

I can't speak for the article writer of course, but the Python-like syntax / significant indentation would be a deal-breaker for me. I'd suffer through a lot to avoid that. And back when I used C a lot myself, I found that even more objectionable. I often care more about syntax than many other language features - with a good syntax you can sugar over a lot of other deficiencies, but a syntax you dislike will stare you in the face every moment you use the language.

Re: Why I Write Games in C

#76

Post by stonemetal »

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?

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.

Re: Why I Write Games in C

#77

Post by synthmeat »

shurcooL wrote: post #74

> The library support [in Go] for games is quite poor, I'd like to know the author's familiarity of Go libraries. Perhaps he's unaware of what does exist and makes false claims, or perhaps he's saying accurate statements and just has really high standards. I help maintain many of the Go libraries/wrappers for games, so I might be biased, but I'm happy with what is available. Almost more so than when I was using C++,…

I'd like to pick your brain in real-time, but, in a nutshell, how far do you think Go game ecosystem is from something like Corona, LibGDX, Haxe? Have SDL, OpenGL wrappers stabilized, are there native ports? Any frameworks that might be considered close to production-ready?

Re: Why I Write Games in C

#78

Post by dom96 »

vidarh wrote: post #75
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

I can't speak for the article writer of course, but the Python-like syntax / significant indentation would be a deal-breaker for me. I'd suffer through a lot to avoid that. And back when I used C a lot myself, I found that even more objectionable. I often care more about syntax than many other language features - with a good syntax you can sugar over a lot of other deficiencies, but a syntax you dislike will stare yo…

I am in some ways the same, but the other way around. I like Python-like syntax more than C-like syntax. But not to the same extreme as you, I wouldn't mind using a language with a C-like syntax.

What are your reasons for disliking Python-like syntax?

Re: Why I Write Games in C

#79

Post by vive-la-liberte »

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?

Re: Why I Write Games in C

#80

Post by adnzzzzZ »

lbenes wrote: post #29
nunodonato wrote: post #24

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

When using LÖVE you have to write a lot of stuff in pure Lua because LÖVE is a framework and not an engine. So, for instance, if you wanna do AI you have to write everything about it yourself (without calling any of LÖVE's functions because generally they won't help you with this task), and most people will do it in Lua only.
Post reply on HN