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

Writing a game engine in pure C: The Graphic Initialization

prdeving.wordpress.com

Post reply on HN
Print view View original

81–90 of 129 posts

Re: Writing a game engine in pure C: The Graphic Initialization

#81

Post by munchbunny »

agentultra wrote: post #8

Starting with state management in the first post is a different approach I wouldn't normally expect. That being said I don't know what it is but I prefer writing games in C. I experiment with higher level languages and use them for rapid prototyping. However, and maybe its simply nostalgia, I always come back to C. And it's not even my favorite language by a long shot. For practically everything else, save for system…

I'm not really a fan of C for games just due to exploding complexity the moment game logic enters the picture. While the language is fairly clean, I find that it gets messy really quickly once the number of structs and functions starts to take off, and then I end up flipping things over to a reduced set of C++ features.

Re: Writing a game engine in pure C: The Graphic Initialization

#82

Post by nocman »

edoo wrote: post #62
dang wrote: post #41

Earlier quoted context omitted.

That crosses into personal attack, which we ban people for, and name-calling, which the site guidelines ask you not to do. Would you mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the spirit of this site more to heart? If you know more than others, the thing to do here is not to put others down, but to offer some of what you know, so we all can learn. Or you can ask about why they did X ra…

Maybe you guys can host my 'hello world' article. Blunt criticism rarely damages people. It often drives them to succeed. There are a lot of stories about the best of the best in their fields were shot down at some point in their life. Many assume the criticizers lacked insight, whereas more likely it was the criticism that drove them to their potential. There is little more damaging in today's world than to cheer on…

"It would require you to be a competent programmer though." is not blunt criticism. It is simply unkind and unnecessary. You can be blunt without being nasty.

While I do sometimes think reactions on HN could use a little "lighten up already", I agree with 'dang' here. You definitely crossed the line in this case.

Re: Writing a game engine in pure C: The Graphic Initialization

#83

Post by munificent »

makz wrote: post #72
munificent wrote: post #48

As a tutorial series, I think using plain C is a cool approach and will help illuminate what's going on under the hood and what parts of the engine are really essential. But if you yourself want to write your own game with just you or a small team of like-minded people, I would highly encourage using C++. As long as you don't have too many cooks arguing about which C++ features to throw into the pot, you can pick a s…

I’d like to know which book is that.

http://craftinginterpreters.com/

Re: Writing a game engine in pure C: The Graphic Initialization

#85

Post by haberman »

munificent wrote: post #61
pavlov wrote: post #50

Earlier quoted context omitted.

”...it's mostly a matter of choosing which better C you want.” For a beginner that can make things more difficult: in addition to the actual thing you want to learn, you need to first become a capable curator of language features from the past 35 years. JavaScript today has the same problem: you can’t just start writing a web app because two lines into a tutorial you’ll be barraged with “So this is actually an ES2017…

This is such a great observation. It makes me wonder if this can be solved technically by published curated language subsets. Racket does this by supporting a bunch of different dialects, specifically to make it easier to teach [0]. One good do something similar for other languages. Step one is probably just writing a doc that says "Here's a standard subset of C++ we call Blah. These are the features it uses and thes…

> It makes me wonder if this can be solved technically by published curated language subsets.

I'm biased, but I generally find the Google C++ Style Guide to be a good curation of C++: https://google.github.io/styleguide/cppguide.html

I generally stick to it in all projects I write. The only exception is that in a few cases I'll use features that are disallowed in Google C++ primarily for historical reasons, most notably exceptions: https://google.github.io/styleguide/cppguide.html#Exceptions

Re: Writing a game engine in pure C: The Graphic Initialization

#86

Post by [deleted] »

weberc2 wrote: post #58
buba wrote: post #55

Earlier quoted context omitted.

yep, I choose C89 for this project because there's no Object/Prototype/Class/overloaded bullshit, you get what you wrote and no more, i think it's easier to understand than any other high level language where you have to use obscure things by design. Actually, this tutorial is not just about "building a game engine in C89", it's more about learning the concepts behind game engines, the language and the code is just i…

I like C, but you definitely don’t “get what you wrote” in any meaningful way. You absolutely have to understand all sorts of nuance about undefined behavior, the size of primitives on various architectures, etc. I’m not advocating for C++, but pointing out that C is far more error prone and surprising than many HLLs. And this doesn’t touch on the regular error prone things about C, like memory management, array inde…

[deleted]

Re: Writing a game engine in pure C: The Graphic Initialization

#87

Post by mikepurvis »

rzzzt wrote: post #75
mikepurvis wrote: post #68

Earlier quoted context omitted.

It seems clang-7 agrees with you— it compiles the multiplication down to shl+add, so the perf is completely identical, see: http://quick-bench.com/CdxqB_qPD3VS5H7igB31FFoqLLo

But you are also right that it is not a huge difference :) In no-optimization mode, it keeps the imul in for Multiply. the result is 1.2477 vs. 1.2668, relative to Noop. The site is really cool, thanks for pointing me to it!

Interestingly, gcc-8 does some really weird stuff. Its version of Multiply is 1.4 times slower than its version of Shift, but according to the disassembly, the Shift implementation is actually using an imul, whereas the Multiply implementation is doing a lea/shl.

Re: Writing a game engine in pure C: The Graphic Initialization

#88

Post by falcrist »

dllthomas wrote: post #51
munificent wrote: post #48

As a tutorial series, I think using plain C is a cool approach and will help illuminate what's going on under the hood and what parts of the engine are really essential. But if you yourself want to write your own game with just you or a small team of like-minded people, I would highly encourage using C++. As long as you don't have too many cooks arguing about which C++ features to throw into the pot, you can pick a s…

> C++ has saner rules for implicit type conversions I say this partly in jest, but once I have wrapped all my primitives in structs C has a perfectly reasonable rule for implicit type conversions: "don't".

As an embedded firmware developer, I really wish there was a way to outright disallow implicit type conversions in C source code. You'd have to exclude libraries, but I'm creating "typedef enum" to show what I'm doing AND help make sure I don't somehow screw it up. If all of those typedefs are interchangable with each other (and ints and chars), I lose out on part of the functionality.

Re: Writing a game engine in pure C: The Graphic Initialization

#89

Post by dllthomas »

falcrist wrote: post #88
dllthomas wrote: post #51

Earlier quoted context omitted.

> C++ has saner rules for implicit type conversions I say this partly in jest, but once I have wrapped all my primitives in structs C has a perfectly reasonable rule for implicit type conversions: "don't".

As an embedded firmware developer, I really wish there was a way to outright disallow implicit type conversions in C source code. You'd have to exclude libraries, but I'm creating "typedef enum" to show what I'm doing AND help make sure I don't somehow screw it up. If all of those typedefs are interchangable with each other (and ints and chars), I lose out on part of the functionality.

To get nominal typing in C, wrap things in a struct. There shouldn't be any performance overhead (the generated code should often, if not always, be unchanged), and the boilerplate can be manageable (and you can unpack things locally when it starts to get too messy).

See https://dlthomas.github.io/using-c-types-talk/slides/slides.... (... which I should really turn into a blog post or something)

Re: Writing a game engine in pure C: The Graphic Initialization

#90

Post by georgeecollins »

pavlov wrote: post #50
munificent wrote: post #48

As a tutorial series, I think using plain C is a cool approach and will help illuminate what's going on under the hood and what parts of the engine are really essential. But if you yourself want to write your own game with just you or a small team of like-minded people, I would highly encourage using C++. As long as you don't have too many cooks arguing about which C++ features to throw into the pot, you can pick a s…

”...it's mostly a matter of choosing which better C you want.” For a beginner that can make things more difficult: in addition to the actual thing you want to learn, you need to first become a capable curator of language features from the past 35 years. JavaScript today has the same problem: you can’t just start writing a web app because two lines into a tutorial you’ll be barraged with “So this is actually an ES2017…

I was mentoring these kids writing some code in C++ and I saw they were using all this syntax and functionality that was familiar from other languages, but that I had no idea was in C++. You see I used to program on games in C++, but like twenty years ago. I have learned a lot of languages since then, and don't really have a reason to go back to C++ although I liked it fine as a language. But it is possible to write C++ now that is really alien to me.
Post reply on HN