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

291–300 of 303 posts

Re: Why I Write Games in C

#291

Post by Jach »

loup-vaillant wrote: post #283
Jach wrote: post #271

Earlier quoted context omitted.

I'm looking forward to playing that next time I boot into Windows (couldn't get it to even create a window on my Linux machine after satisfying its dynamic dependencies (really old libpng for one), or even the Windows exe via Wine -- one of the perils of custom engine development) but I know Antichamber ( http://www.antichamber-game.com/ ), which has the similar concept of a non-Euclidean world, was built in Unreal.…

From the author of Knossu himself here http://jonathanwhiting.com/games/knossu/press.html > [Knossu is] an answer to the question: What can you do with a Doom style raycasting engine if you're tired of realism and shooting things? So it's a Ray caster. Which you can confirm by playing the game and looking up and down: the distortions are typical of a ray-caster. Too bad you're using an old GNU/Linux distribution. For…

My distro is current (Gentoo), I meant that the game required libpng 1.2 when libpng current is on the 1.6 branch. (Though apparently the 1.2 branch still receives security updates so maybe it's not as old as I thought.) On a whim I tried again by just copying a 32-bit libpng1.2 so from Penumbra, that actually made it work, but no sound plays. Ah well.

Re: Why I Write Games in C

#292

Post by mobiuscog »

gregmac wrote: post #277
jaked89 wrote: post #4

"C# ... does a lot to railroad a programmer into a strongly OOP style that I am opposed to". C# has functional capabilities as well. People write in it nowadays in a whole lot of different styles, including procedural, OO, functional, reactive. Yes, the average developer uses it in an OO style, but it can do a lot more.

His argument against OOP makes it sound to me more like he's using OOP design patterns he doesn't like: > I've spent most of my professional life working with classes and objects, but the more time I spend, the less I understand why you'd want to combine code and data so rigidly. I want to handle data as data and write the code that best fits a particular situation. To put it simply, I find when using DTOs to store d…

Exactly - After all, you don't put all your code in a single C file.

Using classes as simple modules - encapsulating a set of functionality - can still lead to a very procedural style without all of the extras.

Re: Why I Write Games in C

#293

Post by Rusky »

melted wrote: post #282
Rusky wrote: post #171

Earlier quoted context omitted.

That bug was almost a year before Rust 1.0 was released. At this point, Rust is being used in production outside of Servo- for example Dropbox is even using it for their core data storage code. It's certainly not as old-and-boring stable as C, but it's a lot closer than you'd think.

That doesn't inspire a ton of faith in Dropbox, TBH.

So which is it? It's impossible for anything new to be stable so Rust automatically reflects badly on Dropbox? Maybe take a look at how well Dropbox is doing and let that reflect on Rust.

Re: Why I Write Games in C

#294

Post by vidarh »

lobster_johnson wrote: post #231
vidarh wrote: post #118

Earlier quoted context omitted.

I want strong visual cues for the end of blocks most importantly. And I want the freedom to adjust indentation in ways that to me improve readability without consideration of whether or not it matches language expectations. But also because I've yet to work in any environment where broken indentation due to tools with different ideas about how to handle it has not been a regular occurrence - indentation is brittle.

I think Haskell gets whitespace-sensitive indentation right. It is a lot less strict than Python, and if you didn't know it was whitespace-based you wouldn't necessarily realize it. Thanks to the functional nature of the language, the "hanging block" problem you have in Python (where the lack of an explicit end construct has blocks indent but never "close") doesn't really exist.

I wouldn't know - I gave up on Haskell because of the cryptic syntax long before I got to the stage of hating on smaller syntactic details... I love a lot of concepts from functional programming, but I wish I could get them in a language with a syntax more like Ruby and very much less than Haskell.

Re: Why I Write Games in C

#295

Post by dottrap »

jokoon wrote: post #238

To me lambdas justifies using C++ while still coding in a C style. Although my wet dream would a C language with map, vector and other containers, a simpler build system (no more headers), more nice syntactic sugar, and an interactive mode... I'd gladly see a language that break C compatibility for this.

Swift might hit all your bullet points there. It breaks from C compatibility, but it has really impressive C bridging/interop.

Re: Why I Write Games in C

#296

Post by dottrap »

ksk wrote: post #212
cies wrote: 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…

Do you have any examples of AAA games (or even major indie ones) that use Rust or Haskell? Often I find that when people recommend a technology for game development, no professional game studios ever seem to use them. I'd love to be proven wrong though...

Posted elsewhere in this thread, John Carmack ported Wolfenstein 3D to Haskell as an experiment.

Re: Why I Write Games in C

#297

Post by loup-vaillant »

Jach wrote: post #291
loup-vaillant wrote: post #283

Earlier quoted context omitted.

From the author of Knossu himself here http://jonathanwhiting.com/games/knossu/press.html > [Knossu is] an answer to the question: What can you do with a Doom style raycasting engine if you're tired of realism and shooting things? So it's a Ray caster. Which you can confirm by playing the game and looking up and down: the distortions are typical of a ray-caster. Too bad you're using an old GNU/Linux distribution. For…

My distro is current (Gentoo), I meant that the game required libpng 1.2 when libpng current is on the 1.6 branch. (Though apparently the 1.2 branch still receives security updates so maybe it's not as old as I thought.) On a whim I tried again by just copying a 32-bit libpng1.2 so from Penumbra, that actually made it work, but no sound plays. Ah well.

Crap. Why does it even work on my system?

Re: Why I Write Games in C

#298

Post by fanf2 »

aleden wrote: post #248
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…

One can implement linked lists as you describe in a C++ fashion using multiple inheritance. The LLVM project has many examples of this using the ilist_node class [1], e.g. [2]. Between using preprocessor directives in C and multiple inheritance in C++ (comes with associated complexity in the resulting client code), I'd always pick the latter. [1] https://github.com/llvm-mirror/llvm/blob/release_37/include/... [2] htt…

How do you put an object on multiple different lists with this technique?

E.g. in FreeBSD an mbuf can be on two lists at once: http://svnweb.freebsd.org/base/head/sys/sys/mbuf.h?revision=...

Re: Why I Write Games in C

#299

Post by fanf2 »

pcwalton wrote: post #258
bluecalm wrote: post #226

Earlier quoted context omitted.

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

> Having some undefined behavior in your code is just a bug, it has nothing to do with being complicated or compiling to machine code. In theory, yes. In practice, all C/C++ programs have undefined behavior in them, so you have to understand what compilers do to really understand your code. > It's not nearly as complex, in fact there are many people who understand quite well what the code compiles to. Not true in my…

Re. undefined behaviour, this fairly definitive paper agrees that it has gone too far: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1637.pdf

Re: Why I Write Games in C

#300

Post by Grishnakh »

krapp wrote: post #225
Grishnakh wrote: post #133

Earlier quoted context omitted.

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.

Maybe, but personally I think STL syntax is horribly ugly and not easy to read or work with, whereas Qt (at least to me) is much easier to parse, in addition to offering a lot more functionality and flexibility. (Qt has a lot more container types, for instance.)
Post reply on HN