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

51–60 of 129 posts

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

#51

Post by dllthomas »

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

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

#52

Post by buba »

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…

Absolutely, i stick to C89 in this serie for clarity as you said, knowing what a game engine does under the hood is the only point here and C is a self explanatory language by design (even if it can be "tricky" sometimes), Im also doing tricky things with it (not that tricky anyways) like the method-like function pointers in the structures that can be "obscure" for those who only work with high level languages but i'm trying to explain everything with detail.

As i said previously, i'd never do a profesional game proyect (or even a hobby one to be sold) with C89, it takes lots of boilerplate and it feels like reinventing the wheel over and over. I'll have to code a hash map approach, a growing array (already did), a "garbage collector" in C89, things that you either don't need or have in the C++ Stdlib, so yep, you are absolutely right.

Also, i enjoy C :D

Maybe after this i could do the same with C++ macroprogramming

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

#53

Post by vernie »

obituary_latte wrote: post #22

Interested people may also be interested in Handmade Hero[0]. The game is being developed — from scratch, engine and all — in real-time and streamed by Casey Muratori. It’s cpp technically, but he uses very little and sticks to mostly C if I remember correctly. [0] https://handmadehero.org/

https://twitter.com/epyoncf/status/1123155254760038400

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

#54

Post by Impossible »

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…

Although multi-threaded engines are now standard, this model adds complexity and is overkill for most games beginners will make (and many commercial indie titles). There is also no reason not to start with a single threaded renderer and move to multi-threading in a later article. Right now it isn't even past creating a window...

Honestly, if you're going to be so critical you should suggest the tutorial should use Vulkan instead of OpenGL, but wait neither of those support all gaming platforms so you have to write a low level API wrapper for Metal and DirectX12 as well, then write a shader translator... Etc. The gap is large between a toy engine and a commercial engine, but there are a lot of fun games you can make with a toy.

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

#55

Post by buba »

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…

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 illustrative examples.

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

#56

Post by buba »

vernie wrote: post #53
obituary_latte wrote: post #22

Interested people may also be interested in Handmade Hero[0]. The game is being developed — from scratch, engine and all — in real-time and streamed by Casey Muratori. It’s cpp technically, but he uses very little and sticks to mostly C if I remember correctly. [0] https://handmadehero.org/

https://twitter.com/epyoncf/status/1123155254760038400

sad, but true

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

#57

Post by codesushi42 »

AlexMax wrote: post #29
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 have some recent experience with doing game programming in C and while I think the experience was overall positive, I'm not sure that I would do it again unless my aim was portability. I found that when my project grew to a certain size, I started running into many cases where I needed many implementations of some base type, the kind of pattern that lends itself well to classes and simple inheritance. This pattern…

>I needed many implementations of some base type, the kind of pattern that lends itself well to classes and simple inheritance.

Inheritance is an anti-pattern, you can accomplish the same with composition.

>you're going to need a dynamically allocating array or hashmap of a specific type, and your choices are either going to be void or some macro thing that makes your eyes cross.

I don't understand, why would you need a *void for a specific type? If you meant heterogeneous types, you can use a typedef union.

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

#58

Post by weberc2 »

buba wrote: post #55
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…

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 indexing, etc.

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

#59

Post by munificent »

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

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.

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

#60

Post by buba »

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…

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 all the flow without weird library stuff, maybe i'm wrong, dunno :(

Post reply on HN