rip-off

You're going to need to be much more specific.

I actually didn't see the part apart converting it to pointers.

... but the performance bit too

Pointers are not necessarily going to help performance. Indirection and dynamic allocation are usually recommended against when trying to optimise code (where possible).

Using any kind of shared mutable state is not going to play nice with multi-threading. Even if you fix initialisation problems, you still need to deal with the thread safety when accessing and modifying the state itself.

This is regardless of whether you expose such state as a global, a static value, a singleton, or even passing a reference.

While it would be possible to make this work, you probably have a design flaw if you want to make every entity aware of every other entity.  Why do you want to do this?

According to here, the error means: STATUS_INVALID_IMAGE_FORMAT. The "image" here refers to an executable or DLL file. Where did you get the DLL?

Helper functions will simplify even further:

void setNumber(TextWidget &widget, int number) {
    // As BitMaster says, this int/string conversion logic could be moved elsewhere
    std::stringstream stream;
    stream << number;
    widget.setText(stream.str());
}
 
// Later
setNumber(my_test, unit.attack_power);

Note how the standard library could allow such a conversion from std::string to const char *, but chooses not to. Conversion operators are hidden and can introduce subtle bugs. Providing an explicit str() method would be preferred.

One idea is to not fork a new process just to wait for input from a user. Simply using std::cin.get() should suffice:

 
void wait() {
    cout << "Press return key to continue...";
    cin.get();
}

Bonus: this code is completely cross platform, and actually does the same thing on all platforms (in contrast, pause and sleep 1 do not do the same thing).

There are lots of non-performance related improvements. Some of your variable names are very poor, "x" and "y" in particular. Your use of the first element of the "sum" array as two unrelated temporary values is very confusing.

Overall, the intent behind the program is not really shining through the code. It is difficult to assess it's correctness without knowing what is supposed to be happening.

Also consider having a single enumeration to represent the "tile type", and using that in both places. Make the type of Level::level and DrawEngine::map to be of this type.

You might also want to eliminate this problem by having the Level class encapsulate this information. The DrawEngine might take a Level reference/pointer, which it can use when drawing. The Character might query the level, rather than the DrawEngine, about whether a tile can be moved into. You could also invert some of the dependencies, so that game checks if the tile is free before moving the player.

In level.cpp you populate the map using [y][x], but in drawengine.cpp you test the map using [x][y].

The typical example used to illustrate the difficulty of not using braces is this:

if( foo )
    if( bar )
        actionA();
else
    actionB();

The indentation hints that the else is paired with the "foo" conditional, but the parser will ignore this and pairs it with "bar". Almost all professional style guides I've seen require braces for loops and conditionals.

Code is typically represented in text in popular programming languages. Placing it in an image is not a good idea, because we cannot easily copy and paste the code onto our computers and try it out.

You can use [code][/code] tags around your code, which will present it in a nice syntax highlighted box:

#include <iostream>
 
int main() {
    std::cout << "Just like this!" << std::endl;
}

Yup.

First of all, you cannot trust any identifier found in a packet, because the client might be spoofing*. The good news is that each client already has a unique identifier! The IP address and port number uniquely identify that connection. You can use this combination as a key to lookup a map data structure, or because the number of clients is not large you could use a linear search of a client array, too.

* Exceptions include something like a username and password, because the password is a shared secret that malicious users should not be capable of spoofing.

The OP did say:

settcpnodelay is done outside.

However, there doesn't appear to be an explicit flush() anywhere, I don't know if there is any buffering done by some of the intermediate classes.

I've been trying to not comment on this, but I think that the object serialization support in any of the large runtimes (JVM, CLR, etc) is not suitable for game networking. The overhead on the wire is typically large, the guarantees are typically a poor match for real-time updates, and it's much harder to figure out what's going on on the wire.

While very true, and pretty much a necessity for production games, I think that the default serialisation is an acceptable way to bootstrap such a game.

My gut instinct is that the overhead on the wire is probably not the root cause of the dramatic performance jump, provided the OP is not mistaken about the scope of the object being sent. On my system a simple object with a 5 x 6 naive matrix of native "int" (i.e. not packed into a single dimensional array, not Integer objects stored in a Collection) appears to be 247 bytes long, which is approximately twice as large as necessary.

I think the OP might better spend their time decoupling the game logic from the rendering first, and leave optimising the data transfer for later.

@OP: Does the Information class have any super classes, and if so do any of them have fields of non-primitive type? What is the type of your matrix?