Live data from Hacker News

Writing a game engine in pure C: The Graphic Initialization

prdeving.wordpress.com

21–30 of 129 posts

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

#21

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.

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

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

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

#24

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…

Yes but SDL supports mobile and consoles and with either one, you can get an OpenGL or vulkan context pretty easily. Audio is honestly the other big plus (do you really want to navigate windows audio driver handshakes or pulseaudio...).

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

#25

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.

I haven't used glfw, but from the docs it leaves you in control of the main loop, whereas glut takes that over and only offers you callbacks. When I used glut (many many years ago) that was sometimes annoying.

glfw doesn't seem to have a function to draw teapots though, which should really rule it out as a serious contender.

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

#26
post #11

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…

C gives you all control over your machine, there are no obscure libraries, grabage collector or unexpected stuff, if something doesn't work as expected you know you have f cked it up. I'm using C here cause 1st, i like it a lot, and 2nd, i think it's the clearest language out there, you can follow the code execution from start to end and "almost" know what's happening, it doesn't have function overloading, obscure sc…

Indirection, pointer casting, and the C standard library actually make things quite opaque in practice. Do you sbrk your own memory or use malloc? Malloc may not be as mysterious as GC, but it’s still a runtime-managed resource.

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

#27

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 remember writing a blog post years ago about how I enjoyed C and Clojure, apparently two extremes, equally.

My current conclusion is that we just enjoy problem solving within mental frameworks, and each language family gives unique mental frameworks that come with different challenges.

Now that I've slowed down life and am planning in years instead of weeks, I think I would absolutely enjoy (and I think my kids would too) making a new video game from scratch with SDL in C.

The only difficulty is, every time I try this, I keep running into weird issues that only I seem to be having and can't find a solution to online. For example, the last time I tried making a lemmings style game in C with SDL, I ran into weird framerate issues where for apparently no reason or pattern, it would go incredibly slow sometimes.

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

#29

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 is totally 100% possible to roll yourself in C, but requires a bunch of boilerplate each time and I found that every time the implementation came out slightly differently, or that I had to go back and rewrite a bunch of code because I needed one more layer of flexibility than I anticipated.

I also really wish templates were in the language. Maybe not to the C++ level of flexibility, but at some point, 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.

Also, build tools in 2019 are still kind of bad. I use CMake and try to do things "the right way", and I still run into trouble occasionally, mostly surrounding external dependencies and generation of files outside the scope of the C compiler. It's a shavable yak, but it's still a yak.

Still, the lack of mental overhead and the much faster compilation times compare favorably to C++. But if portability wasn't a goal, I'd seriously consider an alternative like D, Zig, or Nim next time.

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

#30

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/

Handmade Hero is an impressive endeavor, but by now it's got over 500 1-2h sessions. That's a lot for anyone to catch up on.

Have there been any efforts to write episode summaries/articles on the techniques he demonstrates?

Post reply on HN