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

11–20 of 129 posts

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

#11

Post by buba »

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…

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 fcked 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 scopes, garbage collectors or automatic weird typing.

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

#12

Post by buba »

thrower123 wrote: post #7
jandrese wrote: post #4

Seems like it is going to take a long time to get to a fully functional game if this is the second article and they're only just calling SDL_CreateWindow.

One post a week is about as fast as most people can go if they are into nuts-and-bolts technical topics and they are trying to juggle work and life and other demands on their time. That's about the best I could ever manage when I used to be blogging as I learned DirectX. And that was using C#, so you didn't have to boil the ocean and implement all your own fundamental data structures as you go (see the previous post…

Just want to explain how things works, i don't know if i'll ever finish this proyect, but if i don't i want the things i did explain crystal clear, i want every concept well presented so every single post in the serie can be a piece by its own and you can learn something. I'm now trying to write two articles a week but it's hard, coding C89 is not fast, there are a lot of cavities and undefined behaivours xD

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

#14

Post by gameswithgo »

jandrese wrote: post #4

Seems like it is going to take a long time to get to a fully functional game if this is the second article and they're only just calling SDL_CreateWindow.

such is life. that is the reality of making games without an engine.

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

#15

Post by mhh__ »

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

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…

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

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

#16

Post by buba »

mhh__ wrote: post #15
buba wrote: post #11

Earlier quoted context omitted.

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…

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

true, i'd never do a C89 game from scratch as a profesional project, but this is not a profesional project, it's more like a hobby-academic approach to the lower level of game engine design :D

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

#18

Post by kuon »

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 agree. I still use C a lot, but I often couple it with luajit for scripting.

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

#19

Post by Sir_Cmpwn »

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 support and text rendering, which you'd have to figure out separately with GLFW, but to each their own.

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

#20

Post by edoo »

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 should be running in async threads. It would require you to be a competent programmer though.

There are better SDL tutorials from the 90's.

Post reply on HN