Jump to content

  • Log In with Google      Sign In   
  • Create Account

rnlf

Member Since 03 Jul 2012
Offline Last Active Today, 02:30 AM

Posts I've Made

In Topic: Style preferences in for loop structure

25 August 2016 - 11:52 PM

i --> 0

 

I've never seen anyone write it like this, and in fact, without my morning coffee, it took me a few seconds to realize this is actually valid code and I had to put in extra effort to understand that it iterates over the same range. It's a neat trick, but I'm not sure it's really worth confusing other people who may read the code.


In Topic: C++ class properties initialization order on constructor?

22 August 2016 - 03:01 AM

Doesn't Microsoft's compiler warn you about such things? I know GCC and clang do...


In Topic: Some problems with ECS design

18 August 2016 - 09:20 AM

1. One way to do it is to not store pointers to your components, but IDs and having a second vector that maps IDs to pointers (or indices into your "actual" vector). This way you can shuffle objects around in the component storage vector without caring about the outside world, as long as you update the mapping vector.

 

This kind of design does not only protect you from pointers becoming invalid on resize, but also allows you to reorder objects in your vector to avoid empty spots, which is good for locality and therefore one step further towards a cache friendly architecture.

 

By using smaller indices than 32bit (do you really need more than 64k components of one kind?) you may be able to store your mapping in only 128k bytes and store 32 of them in a single cache line.

 

2. Using an unordered_map is often faster than a "normal" std::map, but it still uses dynamic allocations, since it is probably implemented using a list for each bucket. It touches less memory than a map, but it's still far from free. If you really want fast accesses and can find a way to do it, then limit the range of your keys and use a vector or array.


In Topic: Dependency Management in a Cross Platform, Multi Developer Environment

15 June 2016 - 03:43 AM

Including compiled libraries in a source repo has always lead to trouble somewhere down the road. Maybe you need different versions for similar platforms that have slightly different dependencies? (thinking of different Linux distros here).

 

I think the most practical way is to let developers install "well known" libraries from their OS's package manager and put less well known things as a submodule and have them compile along your own source.


In Topic: Is it bad to use macros such as __LINE__ or __DATE__?

05 April 2016 - 08:31 AM

__DATE__ and __TIME__ can make trouble if you need bit-by-bit reproducable builds. I would assume that is not true for games, but I've been working on projects where that was a hard requirement.


PARTNERS