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

71–80 of 129 posts

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

#71

Post by [deleted] »

weberc2 wrote: post #65
buba wrote: post #60

Earlier quoted context omitted.

yep, i said "get what you wrote" and it's true, if you want your iterations to not get out of range you have to do it yourself, if you want to make a dynamic array you have to do it yourself and if something is not working as expected means that you wrote something wrong, that's far from the opaque flexible behaivour on javascript, f.e. I meant that i think is easier to understand C than other languages cause you see…

Like I said, I wasn't commenting about out-of-range or those other things, I was commenting about the surprising undefined behaviors. :) JavaScript and many other HLLs have their criticisms, but they are generally far less surprising than C. In particular, there are languages like Rust and (to a lesser extent) Go which lack many of the dynamic runtime features of scripting/VM languages and behave very similarly to C,…

[deleted]

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

#72

Post by makz »

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…

I’d like to know which book is that.

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

#73

Post by bluedino »

LinuXY wrote: post #3

For more inspiration I'd check out the Quake engine source. It's quite the masterpiece. There's also been some modernization over the years by LordHavoc of the DarkPlaces engine https://icculus.org/twilight/darkplaces/ - I'm constantly impressed how well the HD remaster on DarkPlaces looks on modern 4k hardware.

The Wolf3D source is probably an even better start. Much simpler, the bad part is that it's 16-bit Borland C.

Andre Lamoth's DOS game programming books are a good read as well, he used 16-bit Microsoft C. Sprinklings of assembler in both.

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

#74

Post by davidscolgan »

This is super cool, well done OP! It looks like you've got some pretty in depth and interesting articles around the rest of your site too. Big props to you and everyone else who puts themselves out there and works to create something that helps others.

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

#75

Post by rzzzt »

mikepurvis wrote: post #68
rzzzt wrote: post #32

Earlier quoted context omitted.

y (I think the bit shifting and addition trick would still win over an IMUL.) Edit: also, wasn't there a way of (ab-)using LEA to do some of this?

It seems clang-7 agrees with you— it compiles the multiplication down to shl+add, so the perf is completely identical, see: http://quick-bench.com/CdxqB_qPD3VS5H7igB31FFoqLLo

But you are also right that it is not a huge difference :) In no-optimization mode, it keeps the imul in for Multiply. the result is 1.2477 vs. 1.2668, relative to Noop.

The site is really cool, thanks for pointing me to it!

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

#76

Post by [deleted] »

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…

[deleted]

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

#77

Post by nroah »

borgel wrote: post #63
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…

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?

If you want to know what a reasonable subset of C++ looks like don't hesitate to check out the source code for Doom 3.

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

#78

Post by [deleted] »

edoo wrote: post #62
dang wrote: post #41

Earlier quoted context omitted.

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

Maybe you guys can host my 'hello world' article. Blunt criticism rarely damages people. It often drives them to succeed. There are a lot of stories about the best of the best in their fields were shot down at some point in their life. Many assume the criticizers lacked insight, whereas more likely it was the criticism that drove them to their potential. There is little more damaging in today's world than to cheer on…

[deleted]

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

#79

Post by briansteffens »

borgel wrote: post #63
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…

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.

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

#80

Post by TillE »

Sir_Cmpwn wrote: post #19

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…

I gave up on SDL2 for graphics after looking at the code that would be necessary to apply the simplest OpenGL shader.

The alternative path for C++ is SFML, which has sensible abstractions for most of what you need.

Post reply on HN