Comment by crafn | Hacker News Reader

Comment by crafn | Hacker News Reader

Parent Full thread

There are some arguments to stick with C instead of a very C-like subset of C++. Off the top of my head:

- Recompiling and reloading parts of your game at run-time is quite easy in C. In C++ you have to make sure (at least) that nobody has pointers to vtables of the dll at the time of reload. This can be a bit tricky if you're using things like std::function in your dll code. Yes, you could be using a scripting language, but thinking how to match the semantics of a scripting language with your engine, where to draw the line, and then write the glue code is a lot more work than just reloading some plain C functions. And if you later decide this was a bad/worthless idea, reverting from dynamic C code to static is almost a no-op, whereas reverting back from scripts is dreadful.

- A quick & dirty reflection is easy when you don't have to deal with name mangling, templates, and overloading. Just some script scanning through your code and outputting elementary type info to .c file may be enough for things like real-time memory browser-editor for your whole engine. This can be very valuable when developing new engine features, as you can view and edit, and maybe draw even graphs of members you just added to some struct. Also useful for modifying game object data on the fly when debugging/creating levels.

(I too do my game programming in C)

To me it looks like it you would like to use plain C as scripting language for game logic code. Your arguments make sense there and the trade of looks reasonable.

However, it doesn't make necessarily sense put the restrictions across the complete source code of game, just because the game logic benefits from it.

Maybe, I don't know. This is just me trying to minimize the unnecessary pain and suffering while waiting for a better language to arrive. In that context arguing which bad solution is less worse seems somewhat pointless, and also depends on personal taste. I'll have to see this project through to know better.

C++ 14 is pretty awesome as a language.

Actually, swift, es6, C++ 14, C# come very close these days. in terms of language features.

In my experience, the runtime/build system/packaging/community become bigger factors when choosing between them than the language itself.

"real-time memory browser-editor for your whole engine."

Can you describe very briefly how you have the server set up? I've wanted to add this to my c hobby projects for a long time and would enjoy any tidbits of the practicalities involved.

Sure, although I don't have a separate server. Explanation here: http://pastebin.com/Nm6Qta4u

Very interesting approach, and pretty straight-forward as you said. Thanks for sharing that.

Have you considered letting the compiler produce DWARF-formatted debug information and using an existing DWARF library to handle the symbol to address mapping? I've had good success with this method for controlling embedded systems from a desktop PC, though not when the host and target are the same computer.

I started thinking about it, but quite fast decided to roll my own self-contained system. Not because it was an informed decision, but felt more fun :P

>Recompiling and reloading parts of your game at run-time is quite easy in C.

This is cool to hear. I've never done anything like this, but it almost sounds like REPL-driven development is a possibility in C?

Check out the first few episodes of Casey Muratori's Handmade Hero series where he implements an extremely simple hot code reloading system in C (actually C++, but he doesn't use almost any C++ features, certainly not vtables).

if you don't want to watch the video, here is a basic overview tldw; of the technique:

on every run of the game loop(usually every frame), reload a dynamically linked module (dll for windows, .so for linux), which contains the actual code you want to run every frame. The function you then invoke from the module must be passed the entire block of memory allocated for the game state. You then just recompile the dll/so module when you make a change, and the game would execute the new code on the next frame. Adding new data structures is OK as long as you don't mangle an existing data structure...but because a game can expect to work with a constant block of pre-allocated memory, this actually works fine most of the time...

I assume you'd be using techniques discussed here?

http://stackoverflow.com/questions/384121/creating-a-module-...

yes - but different OS have different ways to load dynamically linked modules, and the casey video only showed the windows method. But it's basically the same, just library calls differently named.

Really great feature. But it doesn't tell anything about the quality of the code.

Through out his complete series haven't seen any unittests for example.

So I my book. No unittests => crappy code.

His use of vtables is completely unrelated to the feature.

It's quite restricted still. For example changing datatypes during recompilation is problematic, at least if you don't destroy the instances before reloading, and re-instantiate afterwards. I don't bother to do that, because I see most of the value in things like tweaking game object logic repeatedly, which fits the restrictions nicely.

Reply on news.ycombinator.com