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

111–120 of 129 posts

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

#111

Post by malkia »

malkia wrote: post #110

Right now I'm heavy into C++, especially C++17, but mostly due to the current project I'm working on (tools engineer @ gamedev) 20 years ago, my first project was being part of 4 people team porting Metal Gear Solid from PS1 (PSX) to PC. This is when I saw how good written "C" code could be done. Even if it had only japanese comments in the code (understandable). The pure and simple structure, where most of the funct…

e.g. "C" is still valid choice, if your data is well organized, known, and no additional heavy modifications are need - e.g. you don't change much - mostly load "pre-cooked " data, play it, keep few (okay dozen, maybe hundreth, even thousand) variables around and that's it.

Once you get to the point of needing various tweaks, modifications, changes, more advanced UI, etc. - you may need better suited language, because malloc/free won't cut it for you.

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

#112

Post by malkia »

haberman wrote: post #85
munificent wrote: post #61

Earlier quoted context omitted.

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…

> 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…

For our code base we avoid exceptions, except when due to awkard workarounds, or kludges mostly due to some API that's written in a way that you need to communicate with it with exceptions.

That to be said, even if you don't use exceptions in C++ - you must write exception safe code - e.g. as much as possible no manual "begin"/"end" but wrap things behind RAII, such that "end" is still called, in case of exception. Hence allocation through unique_ptr, shared_ptr, etc. is preferred over new/delete.

Because you never know the function you are calling whether deep down it won't throw an exception...

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

#113

Post by heinrich5991 »

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.

dtors that throw come with their own share of problems: If they do so while another exception is in flight (dtors are still called for objects when the stack is being unwound(?)), C++ crashes the process.

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

#114

Post by heinrich5991 »

dllthomas wrote: post #89
falcrist wrote: post #88

Earlier quoted context omitted.

As an embedded firmware developer, I really wish there was a way to outright disallow implicit type conversions in C source code. You'd have to exclude libraries, but I'm creating "typedef enum" to show what I'm doing AND help make sure I don't somehow screw it up. If all of those typedefs are interchangable with each other (and ints and chars), I lose out on part of the functionality.

To get nominal typing in C, wrap things in a struct. There shouldn't be any performance overhead (the generated code should often, if not always, be unchanged), and the boilerplate can be manageable (and you can unpack things locally when it starts to get too messy). See https://dlthomas.github.io/using-c-types-talk/slides/slides.... (... which I should really turn into a blog post or something)

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

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

#115

Post by justinmeiners »

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 is a fine language which many game/graphics developer prefer over C++. More features is not always better.

Here are some reasons to choose C: - longevity. The language never changes. C++ does a good job, but not as good as C.

- portability. It runs everywhere.

- readability. Its a simpler language to read and debug.

- size. You can have the whole language memorized, and know how to write it very well.

- prefer C community over the C++.

- avoiding pandoras box. Once you allow one C++ feature, its easy to add another.

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

#116

Post by justinmeiners »

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?

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

#117

Post by mhh__ »

lone_haxx0r wrote: post #106
mhh__ wrote: post #100

Earlier quoted context omitted.

What? Operating systems are big projects and the tools to write them safely (and open source) haven't existed for very long, so it's a question of manpower and effort not technology. C has almost no performance benefits these days, either, due to advances in compiler optimization; if anything it can be less as other languages can provide more static guarantees to the compiler to use when optimising. That network stac…

What do you propose? Replacing the system stack with Ada? Modern successors to C, such as Zig, and modern successors to C++, such as Rust, are still too young to be used for serious re-implementations of the lower layers.

Modern C++ would be a huge improvement to start with.

Rust is probably there, if under specified. D is definitely fine for writing operating systems (Question being whether to use druntime or not).

I know nothing about Zig, beyond having had a look and not being hugely impressed.

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

#118

Post by borgel »

briansteffens wrote: post #79
borgel wrote: post #63

Earlier quoted context omitted.

I'm a (primarily) C developer who would love to use C++ this way. I have some C++ experience but not enough to know which elements I should include or exclude. Or even how to begin effectively deciding that. Can you point to any resources I can use to learn?

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.

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

#120

Post by dllthomas »

heinrich5991 wrote: post #114
dllthomas wrote: post #89

Earlier quoted context omitted.

To get nominal typing in C, wrap things in a struct. There shouldn't be any performance overhead (the generated code should often, if not always, be unchanged), and the boilerplate can be manageable (and you can unpack things locally when it starts to get too messy). See https://dlthomas.github.io/using-c-types-talk/slides/slides.... (... which I should really turn into a blog post or something)

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.

Post reply on HN