EWClay

I've considered using inheritance within components, but always backed off from it, choosing to either use multiple components or to make the distinction in a data-driven way.

This is partly because it would require a more complex system to find components. As it is, I can look up components on an entity by type. But with inheritance I would have to check every component to see whether it might derive from the one I was looking for. Then there's the possibility of multiple components of the same base type - which one did I want? This type of confusion is exactly why I went for components over inheritance in the first place.

There's no reason for all those statics in Program. It can just be a class with normal members like any other.

There are many formats written out by modelling packages, and these are well documented with loaders available. Typically, because artists may make use of several of these on a game, they will be loaded to an intermediate format for processing. Granny 3D is one popular choice for that step, but very much not free.

After processing the mesh is written to another format, and there will be loaders for each platform the engine runs on, which may include Direct X. But that format will be very simple compared to the original, optimised for fast loading and designed to go straight to the GPU. Because every engine works differently, there is no common format for this final step.

That code is very branchy. Culling an AABB is literally two dot products and a couple of comparisons per plane. See here:

http://blog.makingartstudios.com/?p=155

Optimise later with SIMD if you need to, but more important is the data layout. Keep bounds data in a vector separate from everything else. Cull before rendering anything, writing out a list of objects to render.

Once you get above 10000 or so, consider some sort or hierarchy.

My favourite paper on this subject:

http://www.cs.columbia.edu/cg/rosi/

It explains what is required from a solution, how various methods fall short, and how to put together a method that works.

If theta is the angle between d and ab and n is the vector in the plane of d and ab and perpendicular to ab, then knowing the length of d from Pythagoras,

d = (ab cos(theta) / |ab| + n sin(theta)) * sqrt(ab.ab - 1)

And since sin(theta) = 1 / ab and cos(theta) = 1 / d

d = ab (1 - 1 / ab.ab) + n sqrt(1 - 1 / ab.ab)

n can be any normalised vector perpendicular to ab, so pick any vector, cross with ab and normalise.

It's a thing you generally need to do with templates.

Sometimes, if you know what the template parameters are going to be, you can instantiate the functions you need in the cpp file. Usually you don't know, and neither does the compiler until you use the template. At that point it needs the full definition.

This can slow down compilation times since many translation units end up instantiating the same template. There were plans to allow template definitions to live in the implementation file using the export keyword, but these were dropped. Another option is to include the definition but tell the compiler not to instantiate a particular use of a template using extern, and explicitly instantiate it somewhere else.

Move the player as normal. If the distance from the centre to the player is greater than the maximum permitted, move the player directly back towards the centre by the excess amount.

Angles and trig functions are not required. All you need is the vector from the centre to the player. There's also no need to mix the movement code and the collision code.

An example of this is the YAML-cpp library. When a YAML file is loaded, the elements are converted to variant types and stored in a nested tree structure. Using a library such as this as an intermediary makes it easy to load your argument list from a data file, then just pass the tree structure to your various factories to build components.

I've done something like this using JSON as the data format. An entity can be defined by a set of components, each with its own data, all stored in the same JSON object. The entire entity can then be constructed from the parsed object.

It is necessary to be able to create entities in code as well, since not all entities can be defined before the game starts. I don't see a problem with any of the above approaches.

I also hear that Usain Bolt is slow if you tie bricks to his feet...

Small values, including built-in types, will be returned in a register, which is faster than a reference because that would force a write to memory. For larger objects there is the return value optimisation (http://en.wikipedia.org/wiki/Return_value_optimization). And in cases where the RVO is impossible, if the class has a move constructor the copy can be avoided that way.

Basically you can return by value in most situations without penalty.

I didn't even mention Java. I'm just saying, if you use C++ without the standard library you are making life difficult for yourself.

 

Switching language is hardly an optimisation. Switching to a different container type is trivial in comparison.

@Alpha_ProgDes has it right; use what you know first. Learning another language "because it's probably got better performance", before you have anything published in the languages you're already good with, is premature optimization - and as we all know, premature optimization is bad.

And for what it's worth, I'd avoid C++ like the plague anyway. If you DO pick up C++, avoid the STL containers like the plague - their performance is absolutely abyssmal.

Talking about premature optimisation and then saying to avoid the standard library for performance reasons is a massive self-contradiction.

@Endurion, that solution is cool, the problem with it is that all the bounds checking (e.g. only check tiles X1,Y1-X2,Y2) is done at collision time (meaning it runs every single time). It is arguably more efficient to treat your colliding map tiles (not all map tiles collide with the player) just like enemies/bullets/etc, and have them use the same collision quadtree, which is only updated when something moves.

You only need to check objects against the static tiles when they move. Tiles in an array use less data than they would in a quad tree and look-ups are faster, so a dual approach should be a good one.

One way to avoid having a global for this is to use the Model-View-Controller pattern.

In this scheme the Map would not handle user input but would simply have a LoadMap(name) function. A controller class would handle the UI. You can store any UI state (such as input strings) in the controller class, and the Map would not need access because the controller would call the LoadMap() function.