Live data from Hacker News

Show HN: Crown – A flexible game engine written from scratch in C++

github.com

151–160 of 179 posts

Re: Show HN: Crown – A flexible game engine written from scratch in C++

#151
post #87
post #81

Earlier quoted context omitted.

Not all games need to be the next Crysis. If fact, the majority of them gets abandoned even before memory pressure starts to be a relevant issue. Even if Go isn't at the same level of D or Modula-3 in regards to memory management (heap, stack, global), it is already quite usable for many types of games.

Yeah, at some point it doesn't matter what language if the game is just game logic on a standard input and output layer that are already fast. Even high end engines like CryEngine often include a scripting layer in some higher level language like Lua that probably has GC, because it's nice to have for game logic that doesn't have the same constraints as other parts of the game. ( http://docs.cryengine.com/display/SDK…

Lua has a GC, but it's incremental and tunable. Video game scripting is actually one of the biggest use cases for Lua for that reason. Lua is also one of the fastest scripting languages, especially if you can get away with using LuaJIT.

Re: Show HN: Crown – A flexible game engine written from scratch in C++

#153

Earlier quoted context omitted.

I started with game engines well before I put this project on github in 2012.

Can you recommend any resources/books to learn game engine development? I would love to implement a mini one where I can rapidly prototype AR applications :).

Game Engine Architecture by Jason Gregory is a nice one.

Search for "Bitsquid" and "Our Machinery": pure gold IMHO.

Re: Show HN: Crown – A flexible game engine written from scratch in C++

#154
post #26

Earlier quoted context omitted.

Go is a bad choice for game with its unavoidable GC. And Rust is simply too complicated for a person wanting sane C++. D or Nim (or even C!) would make more sense.

Is there not a point where GC overhead becomes negligible? There have been production examples of Go maintaining sub-millisecond GC pauses with a multi-GB heap under a server workload. https://twitter.com/brianhatfield/status/804355831080751104 Surely there are better reasons to disregard Go for gamedev by now.

The vast majority of memory in a modern game stores data for the GPU. On a game console the game manages this data itself. If you ever want to ship on a console you better be sure Go can handle the memory visible from the GPU correctly e.g. keep the necessary alignment, ensure the GPU is not reading/writing the memory it's going to modify, do not charge address of anything, preserve layout of structures etc. I never used Go so I don't know if it already does this. But I would be considering these things way before I'd even started looking into performance.

Re: Show HN: Crown – A flexible game engine written from scratch in C++

#155

Earlier quoted context omitted.

Can you elaborate on this?

http://lua-users.org/lists/lua-l/2012-08/msg00302.html

All resource paths (.lua files are resources like any other) in Crown are unix-style and do not include the extension.

I have a custom loader that deals with it: https://github.com/dbartolini/crown/blob/master/src/lua/lua_...

Re: Show HN: Crown – A flexible game engine written from scratch in C++

#156
post #53

Earlier quoted context omitted.

> dynamic strings would be isolated to their own pool to avoid fragmenting the heap Strings have arbitrary sizes. How does pooling them together reduce fragmentation? Do they always come and go in groups?

I think it reduces fragmentation in the other pools, not the string pool.

Bingo. This helps restrict the fragmentation from dynamic strings to one pool of memory, allowing the others to remain nicely packed, aligned, etc (whatever your ideal for them is).

Re: Show HN: Crown – A flexible game engine written from scratch in C++

#157

Earlier quoted context omitted.

Generally speaking many C++ game engines avoid the STL stuff and reimplement their own more predictable containers, often with custom allocation schemes. The engine at the last game company i worked at, for example, had its own containers and memory allocator and allowed you to define the allocation category and pool per allocator and per object class (so, e.g., dynamic strings would be isolated to their own pool to…

> Generally speaking many C++ game engines avoid the STL stuff and reimplement their own more predictable containers This seems a little like cargo cultism. I wonder if any of these shops regularly measure the performance of their custom containers and compare with the standard library on a modern optimizing compiler and make a reasoned judgment that it's still currently worth the trade-offs to stick with their own s…

You might also do this to improve debuggability and unoptimised build performance. The VC++ stdlib is particularly bad, as its authors have gone down the ultra-DRY rabbit hole even for simple stuff - a pain to step through, and it relies entirely on the optimizer doing its thing.

(libstdc++'s vector looks sensible in this respect - a good decision on their part. Haven't looked at any other aspects of it though.)

At one point the contents of vectors were often inconvenient to examine in just about every debugger, because you'd have to type out some infeasibly long expression to get at them, "vec._Mybase._Myval._Myptr[0]", that kind of thing, which you could also fix by writing your own container and simply calling your pointer field something like "p". (Same goes for smart pointers.) Luckily this is much improved in the latest Visual Studio but it may still be an issue elsewhere.

Re: Show HN: Crown – A flexible game engine written from scratch in C++

#158

Earlier quoted context omitted.

http://lua-users.org/lists/lua-l/2012-08/msg00302.html

All resource paths (.lua files are resources like any other) in Crown are unix-style and do not include the extension. I have a custom loader that deals with it: https://github.com/dbartolini/crown/blob/master/src/lua/lua_...

I would recommend that you extend `package.loaders` instead. You risk breaking expected `require` functionality. Then you get the benefits of both!!

https://www.lua.org/manual/5.1/manual.html#pdf-package.loade...

Re: Show HN: Crown – A flexible game engine written from scratch in C++

#159

Earlier quoted context omitted.

All resource paths (.lua files are resources like any other) in Crown are unix-style and do not include the extension. I have a custom loader that deals with it: https://github.com/dbartolini/crown/blob/master/src/lua/lua_...

I would recommend that you extend `package.loaders` instead. You risk breaking expected `require` functionality. Then you get the benefits of both!! https://www.lua.org/manual/5.1/manual.html#pdf-package.loade...

I already do so: https://github.com/dbartolini/crown/blob/master/src/lua/lua_...

Re: Show HN: Crown – A flexible game engine written from scratch in C++

#160

Earlier quoted context omitted.

I felt the same way dipping my toes in C++ for a few years. C99 is definitely my preferred language. But when in Rome...

I'm kind of curious about doing this more often, but it's the lack of clean collections that puts me off. What do you do regarding collections? (Dynamic arrays, hashmaps)?

Indeed collections are a stinky bit, but fortunately they are not the majority of the code. Generally i either do a "list of pointers" (for example http://runtimeterror.com/rep/engine/artifact/0a8bb29493c782f... from my own C engine) or i define `DECLARE_LIST(type)` and `IMPLEMENT_LIST(type)` macros which declares types and functions for handling those (note that with the word list "list" in both cases i mean a conceptual list of items, not the data structure, in practice it isn't a linked list but a vector). The latter can be faster, more flexible (e.g. you can specify how the comparisons are done so that you can use == for simple stuff, strcmp for strings, memcmp for structs or custom calls for more complex structures) and more type safe but on the other hand it can be very annoying to write, debug and extend which is why i rarely do it. Another way is to use an include trick where you do something like

    #define TYPE int
    #include "list_template.h"
    #undef TYPE
with `list_template.h` using TYPE wherever a data type would be needed and defining inline (C99) and/or static (C89) functions so that they can be redefined in multiple files (or have a dedicated C file that includes the above header with all data types and an additional macro that enables the implementation). This is basically sort of implementing templates in C.

The void pointer approach is the simplest and most macro free (despite me using macros here, i'm a bit macro happy sometimes :-P) but at the same time you are limited to pointers. In practice i've found that most of the time this is enough, which is why i still haven't replaced that yet. But there are cases where i'd prefer to be able to have a list of structs instead of pointers to structs, both because it is simpler (no need to define a custom free function) and faster (less indirections), so i'll most likely replace that code with another approach (most likely the macro that defines the types, not the include header).

But if there is a single feature i'd like to see from C++ to C that would be templates, even if they are single depth. I don't even care about classes or the other stuff (classes are nice to have, but not necessary as long as the compiler can figure out that the template parameters to structs and functions with the same name refer to the same type when used together).

Post reply on HN