Beginning Game Programming in C++ | Hacker News Reader

Beginning Game Programming in C++

lazyfoo.net

121 pointsmax_17 comments

https://handmadehero.org is a project that teaches how to write a game from scratch. He starts without even using OpenGL.

It's mostly C, but he does use the C++ compiler.

I guess the opposite of that (Without introducing editors) would be Cocos2d-x. You could still stay in C++ code-land but get everything out of the box (ECS, Memory management, scenes, etc)

I've been using cocos2d-x for a few months now to create my first game, and I am really impressed with it.

It would be great if lazyfoo had a changelog. Looks like it was last updated on 2016/2/15, but who knows what was updated? I mean I've been visiting lazyfoo since 10 years ago...

I hope someone will make a tutorial for using SDL with Vulkan.

> You should not be trying to use multithreaded optimization. Play with fire and you will get burned.

That's some poor encouragement there. They should be teaching how to do multithreading properly instead, or referring to such resources. May be using languages like Rust where multithreading is more sane will encourage using it more.

As I discovered to my misfortune recently, SDL2 is a nightmare of undefined behaviour when you start involving multiple threads, even if you're doing things in what naively would appear to be the correct way with locks and the like. Depending on your OS and GL backend, a bunch of stuff is thread local and will bomb out or just fail to do anything. In the end I ended up having to do everything SDL related, not just rendering, but including things like polling the keyboard and mouse, inside one thread, with mailboxes back to everywhere else. The documentation was pretty weak on explaining this, too.

Is there anything more multithreading friendly? What about alternatives, like GLFW[1]?

It's now integrated with Vulkan as well: http://www.glfw.org/docs/3.2/vulkan.html

[1]: https://github.com/glfw/glfw

http://www.glfw.org

I find this hard to believe. I've implemented multi-threaded rendering engines with OpenGL without too any major issues. As long as you aren't adding multiple threads to the main render loop, you shouldn't have these issues. Could you elaborate?

He's talking about multi-threading with SDL, not OpenGL.

This is with SDL overtop of OpenGL. I never had problems on Linux as long as I kept the rendering in its own thread, but on OSX I had more serious problems with SDL_PollEvent simply failing to do the right thing if not called from the main thread, if I recall.

A nitpick I had with SDL2 is the inability to render while the window is being resized. There is a rather awkward hack around this on Stack Overflow[1], which involves a callback function that has to call right into your custom rendering routine and "may run in a different thread!"[2].

[1]: http://stackoverflow.com/questions/7106586/keep-window-activ... [2]: https://wiki.libsdl.org/SDL_SetEventFilter

Modern drawing libraries are limited to single threaded drawing.

That's a classic one. I used to refer to this website for SDL related projects.

It's awesome that he's reworked them to stay up to date - I remember poring over the SDL 1.2 tutorials almost ten years ago. Also looks like the OpenGL page is updated as well - no more immediate-mode 1.0 stuff, like there still is in the Nehe tutorials that everyone used to use.

Here's the tutorials I used to learn game programming in C: http://bespin.org/~qz/pc-gpe/

.. 20 years ago :(

C++, not C :(

Thanks. Fixed.

Reply on news.ycombinator.com