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

91–100 of 129 posts

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

#91

Post by kevin_thibedeau »

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…

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.

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

#92

Post by kevin_thibedeau »

reikonomusha wrote: post #26
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…

Indirection, pointer casting, and the C standard library actually make things quite opaque in practice. Do you sbrk your own memory or use malloc? Malloc may not be as mysterious as GC, but it’s still a runtime-managed resource.

You can replace malloc with your own implementation. Just have a big static array to dole out bits of memory. The loader or startup code will prep it for you.

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

#93

Post by pjmlp »

TillE wrote: post #80
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.

SDL2 has much better support for Android though.

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

#94

Post by mhd »

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…

320x240 was one of the benefits, but the more important part was that it allowed you to use all the memory, double buffer, use split screens (for HUDs) etc. Addressing became more complicated, though. (And IIRC, Doom ran in 320x200 Mode X, for some design/monitor reasons)

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

#95

Post by kevin_thibedeau »

mhh__ wrote: post #70
Impossible wrote: post #49

Earlier quoted context omitted.

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

Ignoring the almost barbaric lack of abstraction in C, you could avoid a whole load of these bugs and make your customers not want your head on a spike at next to no cost by using a different language.

Nobody's complaining about the barbaric OS and network stack written in C. The safety nazis' bleating means little if they can't produce a viable alternative. Where are the high performance OSs written in Ada or whatever next big thing is?

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

#97

Post by edoo »

nocman wrote: post #82
edoo wrote: post #62

Earlier quoted context omitted.

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…

"It would require you to be a competent programmer though." is not blunt criticism. It is simply unkind and unnecessary. You can be blunt without being nasty. While I do sometimes think reactions on HN could use a little "lighten up already", I agree with 'dang' here. You definitely crossed the line in this case.

I reviewed the code and stand by my statement. The quality is firing worthy.

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

#98

Post by keldaris »

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.

I'm not sure why you were downvoted. I almost exclusively write exception-less C++ (compiling everything with "-fno-exceptions"), but correctly handling errors in constructors and destructors is absolutely an important concern. It's not hard to do, obviously, but it does require forethought and heavily encourages delegating complex logic to other parts of the code.

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

#99

Post by kvark »

Impossible wrote: post #54
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…

Although multi-threaded engines are now standard, this model adds complexity and is overkill for most games beginners will make (and many commercial indie titles). There is also no reason not to start with a single threaded renderer and move to multi-threading in a later article. Right now it isn't even past creating a window... Honestly, if you're going to be so critical you should suggest the tutorial should use Vu…

Good thing WebGPU native implementations are coming along to fill this role.

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

#100

Post by mhh__ »

kevin_thibedeau wrote: post #95
mhh__ wrote: post #70

Earlier quoted context omitted.

Ignoring the almost barbaric lack of abstraction in C, you could avoid a whole load of these bugs and make your customers not want your head on a spike at next to no cost by using a different language.

Nobody's complaining about the barbaric OS and network stack written in C. The safety nazis' bleating means little if they can't produce a viable alternative. Where are the high performance OSs written in Ada or whatever next big thing is?

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 stack written in C gave us heartbleed for example. If C arrays were bounds checked by default (e.g. they carry around their size), this could've been easily avoided at no runtime cost.

How can you honestly complain about people wanting more safety in software? If it's speed ("high performance") then you're probably implementing yourself in C (e.g. Bounds checking) something that is built in either at runtime or even statically as can be done in some cases.

Post reply on HN