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

41–50 of 129 posts

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

#41

Post by dang »

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 rather than Y. Perhaps they also know quite a bit, and chose X for an interesting reason.

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

#42

Post by buba »

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…

good thing this is not an SDL tutorial xD

i'll address that things when needed but the project has like 500 lines, don't think that momment is now, to be honest...

Anyways, thanks for your support, lovely fellow

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

#43

Post by mikedelfino »

AceJohnny2 wrote: post #30
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/

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?

There is an excelent episode guide at https://hero.handmade.network/

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

#44

Post by buba »

yellowarchangel wrote: post #40

This is moreso "how to start using SDL2". These tutorials exist and are really well thought out here: https://lazyfoo.net/tutorials/SDL/

this is not about SDL, it's just an easy way to open a window, import assets, handle events and reproduce sound.

Would you like to see a tutorial about how to do that in c89 compatible with windows, mac, Gnu/linux, consoles, etc? it'd take half million lines and 3 years.

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

#46

Post by jackhack »

mhd wrote: post #2

Reading the title my mind immediately went to mov ax, 13h int 10h I'm old.

Brought a smile to my face. I see this as a shibboleth for the oldschool coders.

For those missing the joke, that's the assembly language commands to switch to VGA mode from DOS. Set AX register to 13 hex and call interrupt 10. That gives us VGA graphics mode 320x200 pixels! Related: In the 1990s Michael Abrash via Dr. Dobbs Magazine, introduced the world to "Mode X" @ 320x240, which had the advantage of square pixels. That series of articles was responsible for my long-standing subscriptions to Dr Dobbs Journal.

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

#47

Post by buba »

ensiferum wrote: post #45

Theres also wdk which can give you open gl es/desktop context and and this is separate from window creation so you can also create a context for headless rendering. Supports window and linux. https://github.com/ensisoft/wdk/blob/master/sample/triangle....

uh, interesting....

C++ tho, but i could port it, i'll give it a glance

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

#48

Post by munificent »

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 subset of C++ that isn't much more complex than C (which is already more complex than most realize) and you'll get a much cleaner, safer language. C++ has saner rules for implicit type conversions, namespaces, overloading, and a cleaner notation for dynamic allocation. Those alone make it a sufficiently "better C" to be worth using in my book.

Going farther, even if you don't like "object-oriented programming", I think classes offer modularity and encapsulation features that make them worth using, even if you never once write the keyword "virtual" or use subclassing. (Fun fact: the first version of C++ did not have virtual methods!)

I like C and enjoy programming in it, which I've done for over 20 years. I've written a successful open source project in it and am writing a book that uses C as one of the implementation languages. Even so, I generally only use straight C if I'm writing a library that I want C users to be able to consume. Otherwise, I think C++ contains any number of "better C"'s within it, and it's mostly a matter of choosing which better C you want.

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

#49

Post by Impossible »

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)

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 clients are a concern, but in a game that is entirely or mostly single player the worst outcome of unsafe code is that it crashes to desktop.

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

#50

Post by pavlov »

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 ES2017b.71 feature that we’re enabling using babel-ts-flooginator, therefore you also need TypeScript and that means you need to...”

C feels clunky today, but writing more code in exchange for not having to curate the language can be helpful for learning.

Post reply on HN