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…
Show HN: Crown – A flexible game engine written from scratch in C++
151–160 of 179 posts
Re: Show HN: Crown – A flexible game engine written from scratch in C++
#152Your use of `require` is incorrect.
Can you elaborate on this?
Re: Show HN: Crown – A flexible game engine written from scratch in C++
#153Earlier 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 :).
Search for "Bitsquid" and "Our Machinery": pure gold IMHO.
Re: Show HN: Crown – A flexible game engine written from scratch in C++
#154Earlier 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.
Re: Show HN: Crown – A flexible game engine written from scratch in C++
#155Earlier quoted context omitted.
Can you elaborate on this?
http://lua-users.org/lists/lua-l/2012-08/msg00302.html
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++
#156Earlier 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.
Re: Show HN: Crown – A flexible game engine written from scratch in C++
#157Earlier 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…
(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++
#158Earlier 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_...
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++
#159Earlier 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...
Re: Show HN: Crown – A flexible game engine written from scratch in C++
#160Earlier 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)?
#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).