Writing a game engine in pure C: The Graphic Initialization • Hacker News Board

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

#61

Post by munificent » Wed, Jun 05, 2019, 6:29 PM UTC

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…

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 these are the ones it doesn't: ..."

Then you could add tooling so that it will warn you if you use a prohibited feature.

Of course, this just pushes the problem up a level: now a new user has to know which curated sublanguage to use. But that's arguably simpler than doing it on a per-feature basis. At least they can just order a combo instead of having to pick a la carte.

[0]: https://docs.racket-lang.org/drracket/languages.html

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

#62

Post by edoo » Wed, Jun 05, 2019, 6:30 PM UTC

dang wrote: post #41

edoo wrote: post #20

This is an awful SDL engine example. I've made rendering engines before. You should for example have a second windowless openGL context with its own thread so that you can be sending drawing commands at the same time you are updating GPU ram buffers. Generally the main thread is required to be handling input (due to cross platform requirements) and should only be doing that. Everything else including file loading sho…

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 someone who is obviously not living up to their potential.

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

#63

Post by borgel » Wed, Jun 05, 2019, 6:36 PM UTC

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'm a (primarily) C developer who would love to use C++ this way. I have some C++ experience but not enough to know which elements I should include or exclude. Or even how to begin effectively deciding that.

Can you point to any resources I can use to learn?

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

#64

Post by dllthomas » Wed, Jun 05, 2019, 6:38 PM UTC

munificent wrote: post #59

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".

Haha, yes. I've considered similar things before too. Part of the problem then is that working with any standard library functions is a huge pain. You have to manually "cast" back and forth all the time.

Any library that's not on board needs to be wrapped, for sure. Fortunately you can do it in just the prototypes if you keep things ABI compatible. It fits well with the practice of decorating functions with empty structs, which is always ABI compatible (... in C, with mainstream compilers. In C++ it is explicitly not ABI compatible, sadly).

It's extra important, in writing this kind of C, to pick a granularity of types such that they help you make the distinctions you need without drowning you in casts. And I'm not at all sure such a granularity always exists. It worked out very well on the (greenfield) project I built this way, though.

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

#65

Post by weberc2 » Wed, Jun 05, 2019, 6:38 PM UTC

buba wrote: post #60

weberc2 wrote: post #58

Earlier quoted context omitted.

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…

yep, i said "get what you wrote" and it's true, if you want your iterations to not get out of range you have to do it yourself, if you want to make a dynamic array you have to do it yourself and if something is not working as expected means that you wrote something wrong, that's far from the opaque flexible behaivour on javascript, f.e. I meant that i think is easier to understand C than other languages cause you see…

Like I said, I wasn't commenting about out-of-range or those other things, I was commenting about the surprising undefined behaviors. :) JavaScript and many other HLLs have their criticisms, but they are generally far less surprising than C. In particular, there are languages like Rust and (to a lesser extent) Go which lack many of the dynamic runtime features of scripting/VM languages and behave very similarly to C, but with far fewer footguns (e.g., no architectures with 9-bit chars!).

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

#66

Post by banachtarski » Wed, Jun 05, 2019, 6:43 PM UTC

enriquto wrote: post #21

Sir_Cmpwn wrote: post #19

Personally, I prefer GLFW over SDL: https://www.glfw.org/ GLFW just goes from zero to OpenGL context ASAP, plus input events. With SDL I found that their drawing primitives are too limiting for my needs, and if you want to do any custom drawing at all, you need to abandon their drawing primitives entirely and just write GL codel. At that point, GLFW makes more sense. SDL does have a few other nice things like audio s…

are there any concrete, tangible advantages of glfw over freeglut? I see the glut api as the paragon of usefulness and simple elegance, and I'm really curious how glfw can be any better than that.

There are plenty. Freeglut not being in active development for a while, AFAIK, will not support high-dpi devices (where the window resolution and surface resolution do not match), or newer drivers for different input devices. Freeglut locks you in to OpenGL instead of other rendering APIs. Getting multi-monitor setups up and running is harder. Joystick support is paltry to nonexistent.

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

#67

Post by binthere » Wed, Jun 05, 2019, 6:45 PM UTC

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…

Although this was mostly a decompiled project, I really appreciate the architecture and code style of https://github.com/OpenTTD/OpenTTD which seems to use OOP minimally and more c oriented code.

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

#68

Post by mikepurvis » Wed, Jun 05, 2019, 6:46 PM UTC

rzzzt wrote: post #32

mikepurvis wrote: post #9

Earlier quoted context omitted.

Oh man, the memories. It was such a revelation discovering how much faster it was to POKE pixels directly into memory in QB rather than use the PSET built-in. And then much of that knowledge was directly transferable to Turbo Pascal and later C. it really boggled the mind that it was possible to blt a sprite in rows rather than a pixel at a time, and under the hood, the computer was actually copying 4 bytes per instr…

y (I think the bit shifting and addition trick would still win over an IMUL.) Edit: also, wasn't there a way of (ab-)using LEA to do some of this?

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

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

#69

Post by BrS96bVxXBLzf5B » Wed, Jun 05, 2019, 6:50 PM UTC

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…

There are a few that people use! Here's a simple one with links to a few others: https://gist.github.com/bkaradzic/2e39896bc7d8c34e042b

And some people choose to use more comprehensive documentation, like Google's C++ style guide, at the cost of imposing more restrictions that are largely in place for corporation-specific reasons that smaller personal codebases don't necessarily need to regard.

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

#70

Post by mhh__ » Wed, Jun 05, 2019, 7:02 PM UTC

Impossible wrote: post #49

mhh__ wrote: post #15

Earlier quoted context omitted.

Perhaps, but C is unsafe both in terms of types and memory (Which has to be considered if choosing C for a project)

HN users tend to parrot the safety line a lot because most people are working on web applications that store somewhat important user data, so gaining access to a remote machine due to a buffer overrun issue is catastrophic, but in games, especially in single player games, safety is less of an issue or even a non-issue. With a multiplayer networked game, cheating, attacks on servers and attacks on other players client…

Ignoring the almost barbaric lack of abstraction in C, you could avoid a whole load of these bugs and make your customers not want your head on a spike at next to no cost by using a different language.