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

121–129 of 129 posts

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

#121

Post by flukus »

borgel wrote: post #118
briansteffens wrote: post #79

Earlier quoted context omitted.

Speaking from my own very limited experience, I think C++ can be pretty nice if you basically write straight C but borrow from the C++ STL. Smart pointers (std::unique_ptr, std::shared_ptr, etc), collections (std::vector, std::unordered_map, std::set, std::stack, std::priority_queue), and stuff like std::tuple and std::optional really make C feel less clunky without getting too gross.

Ha, I was just thinking about where to find some STL-style collections earlier today and was lamenting not knowing having a great lib in mind. Thanks for the suggestion! Seems like a good place to start.

Glib (https://developer.gnome.org/glib/2.60/glib-Miscellaneous-Mac...) is a great STL like library for C. It's got the basic data structures, a good API and plenty of utilities. My favorite is g_autoptr (https://developer.gnome.org/glib/stable/glib-Miscellaneous-M...) for deterministic cleanup. There's enough to make C a reasonably pleasant scripting language.

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

#122

Post by Supersaiyan_IV »

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

I like your approach, mostly because it's bottom-up, and because this is an excellent opportunity to illustrate common pitfalls. Those pitfalls can be identified using sanitizers (-fsanitize=undefined,leak,address,thread etc). With the correct CI setup you'll have a safety net, where sanitizers provide precise motivations why one approach works, and another also works, but at risk of undefined behaviour.

I have no opinion on use of C89 instead of C++, since that's just an implementation detail. Also, for your purposes, it works to your advantage, since C is basically the white-box of C++.

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

#123

Post by agentultra »

justinmeiners wrote: post #116
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…

> Imperative programs are notoriously difficult to comprehend Which programs can most programmers read and understand?

Very few in their entirety I'm sure.

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

#124

Post by heinrich5991 »

dllthomas wrote: post #120
heinrich5991 wrote: post #114

Earlier quoted context omitted.

Some ABIs pass structs containing a single element differently (and in a less performant way) than primitive data types.

You should always be aware of the details of whatever platform you're targeting, to be sure. That said, can you name a few that work this way? If I've worked on such a platform, it's been a long while.

Apparently ARM64 does this for return values. I remembered the `#[repr(transparent)]` proposal that precisely tackled this problem for Rust: [RFC 1758](https://github.com/rust-lang/rfcs/blob/de0917dca549694fffbe3...).

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

#125

Post by Supersaiyan_IV »

jackhack wrote: post #46
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 pixel…

If that brought a tear to your eye, you might enjoy:

http://www.pouet.net/prod.php?which=53816 "Puls" by Řrřola, 256b, MS-Dos

Along with this interesting explanation https://meatfighter.com/puls/ of what's happening with the "binary-search" raytracing, lattice-effect, and tricks to make it fit in 256b.

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

#126

Post by NikkiA »

kevin_thibedeau wrote: post #91
haberman wrote: post #85

Earlier quoted context omitted.

> It makes me wonder if this can be solved technically by published curated language subsets. I'm biased, but I generally find the Google C++ Style Guide to be a good curation of C++: https://google.github.io/styleguide/cppguide.html I generally stick to it in all projects I write. The only exception is that in a few cases I'll use features that are disallowed in Google C++ primarily for historical reasons, most nota…

The problem with exception-less C++ is that new, delete, ctors, and dtors become timebombs when they fail in a way that would have generated an exception.

If new fails your program crashing is probably going to be the only outcome anyway, might as well fail from an unhandled exception.

And if you're putting things that can throw exceptions in your ctors or dtors you're probably already writing code that is a timebomb

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

#127

Post by edoo »

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

When I was younger my programs would start to fall apart after a few thousand lines. It took a LOT of practice, both writing programs from scratch and working on large programs that were correctly designed.

One thing to remember is the act of coding is a bit different from architecting a program. If you are unsure of how it is going to work it is probably not going to work and as your program grows in size will become unmanageable as you continually have to rewrite it to take things into account that you didn't plan on. It helps to become familiar with design patterns and to pseudocode the overall structure. Expressing your desired architecture into code is a big enough challenge without trying to do it at the same time.

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

#128

Post by Retra »

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…

Choosing a curated language subset is exactly the "how do I curate the language" problem being referred to. The solution is not to subset a language, but to refuse to superset it. Stop building DSLs and frameworks and domain-specific abstractions and just stick to a flexible core.

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

#129

Post by dllthomas »

heinrich5991 wrote: post #124
dllthomas wrote: post #120

Earlier quoted context omitted.

You should always be aware of the details of whatever platform you're targeting, to be sure. That said, can you name a few that work this way? If I've worked on such a platform, it's been a long while.

Apparently ARM64 does this for return values. I remembered the `#[repr(transparent)]` proposal that precisely tackled this problem for Rust: [RFC 1758]( https://github.com/rust-lang/rfcs/blob/de0917dca549694fffbe3... ).

Thanks, I'll dig in! Is this limited to floating point? That doesn't surprise me nearly as much.
Post reply on HN