zfvesoljc

Use a network library, i.e. enet, which works on udp protocol but also supports reliable packets. That way you can send important messages as reliable (and ordered) and state changes like position, rotation as unreliable messages (spam like, multiple times per seconds). I wouldn't use size as a message descriptor, just use header ID for that.

Hm... Thank you.
That does have a point, but I wonder where I could create tasks to make use of at least 2 cores. Resource loading doesn't happen every frame.

Where ever you have N items to update, ie: 200 particle effects can be split into 4 tasks, where each one can update 50 particle effects.

As mentioned, a good way is to pull current state from the input devices once per frame and do logic based on that. However, usually only current state is not enough, for example if you are reading raw input or analog values from gamepad. Here, keeping an input state from previous frame(s) with time stamps can help a lot. Based on previous states one can determine how the value changed (slow vs fast) you can even manually catch double clicks (press).

A very trivial way to get the number of necessary bits to store a value at compile time:

template<unsigned int N> struct number_of_bits
{
	static const unsigned int value = 1 + number_of_bits<(N >> 1)>::value;
};

template<> struct number_of_bits<0>
{
	static const unsigned int value = 0;
};

Use:

int bits = number_of_bits<42>::value;

It's not very generic or error-safe, but it works under normal circumstances at least. Add whatever error-checking you feel is necessary, or modify to suite you needs.

Thank you!

HDD/RAM space is not a problem these days

Who said anything about storage? Believe it or not, there are still some parts of the world where network bandwidth is not abundant.

but you could use one bit flag to tell whether to read a full byte or 4bits

I'm not sure how this would help me. I want to save minimum number of bits required. It could be 2, 4, 7 or even 23. I just wanted to know, if anybody had a quick idea how to get number of minimum bits required based on some max value (at compile time).

Quit wasting your time on the triviality and work on making more/better code. Realistically you're likely to add more enum values over time; leave room for them.

I asked a specific question, trivial or not. And I can waste my time any way I want.

Firstly, let’s say you have mapped a key to an action. B to jump.
But now you are in water. Remap the key to “swim”? Keep the key on “Jump” but add code to check if you are in water during a jump?

well, to avoid such problems, you can still give a more generic action name, like fire1, fire2, action1, action2, if you have clear action definitions that is

For a final game, best way is to pre-bake the mesh and load in place the entire thing (header, index buffer, vertex buffer, even shaders and textures).

Could you please specify what you mean by:

explicitly instantiate a Test<int> in the .cpp file

?

all template code (function implementations for example) must go into header

why not serialize with xml? It's human readable, editable and there are some nice free xml libraries out there than can be used. I've used tiny xml before, haven't found any serious issues with it.


just a hint, if you have bitwise flags in an attribute, don't save the attribute as a value, save each flag on it's own. It can save you a lot of trouble

enum EAttr {
  aActive = 1,
  aVisible = 2,
  aMagic = 4,
};

int attr;
// DONT
xml.Write( "attr", attr );
// DO
xml.Write( "active", attr & aActive );
xml.Write( "visible", attr & aVisible );
xml.Write( "magic", attr & aMagic );

Similarly, we have implemented a particle system like mentioned above: effect, list of emitters and particles for each emitter. Effect is basically a render object and emitter holder. An emitter as the name implies, defines where and how are particles created. A particle is a point in space with direction velocity, color, texture info, etc...

Both emitter data and particle data have a bunch of evaluators (line/curve editor), which are driven with emitter/particle life, ie: size, color, alpha, velocity, gravity, etc... To get better re-usability, we've added "instance data", so that some specific options are not set (locked) on data, but there where data is used (ie: when emitter data is linked under effect data, an emitter instance data slot is created, under which the emitter data is linked).

Biggest problem we reached was when we tried to create fireworks effect - where a "particle" is also an emitter. We had to add the concept of child emitters. On a particle data we define a new emitter data link, and it's "active evaluator". This defines when the child emitter will be active in accordance to particle life. This way we can nest as much as wanted, but for sanity, memory and performance reasons the depth is limited to 3.

Each emitter can also hold various engine objects like lights, flares, sounds, etc... whose properties can be also evaluated (ie: light color, intensity and range).

The editor is written with inhouse UI (sadly ), and the system is job friendly.


edit: current biggest wish by designers is ability to animate particle movement, so they can create fancy movement like spiral, tornado, etc.. we are probably just going to import animation keyframes from an external tool (ie: maya), and interpolate particle movement based on that. note, that this will be just the "base" particle position, something like:
newpos += animationdelta + (velocity * dt)
so that you can still modify the particle movement even if particle movement is animated

Am I on the right track, or there is improvement to it I can make.

Don't hard code it, create a data driven system, so you can write state machine data (states, actions/transitions, conditions) in a data file, so you can edit the state machine without code rebuilding.