I'd like to improve the gfx code of wz2100. However gfx callbacks are spread throughout the whole source code. Thus I'd like to modernize codebase to ease future improvement. Using namespace and adding directory is a first step but I intend to use c++14 where applicable and replace some structure (vector affine) with glm counterpart. Is it OK for wz project? It will likely break compatibility with older compiler but I'm expecting better maintainability by using modern dev practice and standard structure.

There are some limitations, compiler-wise, as we need to be able to cross-compile to Windows, and compile on MacOSX. I don't know what those limits are, currently, though. What are the c++14 features that you would like to use?

The codebase is very convoluted, with lots of static globals everywhere. Turning them into classes would be a good idea. We try to incrementally clean up and improve this up as we go, and patches to assist in this would be welcome. Probably a good idea to discuss ideas before coding them, if they involve larger reorganizations.

I'd rather use c++14 feature supported by MSVC since it slightly lag behind other compiler in C++14 support (afaik clang and gcc do support c++14 completly).For instance std::make_unique is not available in c++11 but is in C++14 and constexpr behavior was slightly modified wrt const method.

A first step would be to move everything in a namespace ; I think "maths" "ui" "render" "sound" "network" "ai" namespaces would be a good starting point.I'm also thinking of removing vector/Affine and custom matrix in favor of the one in glm.

Is it OK to use directwrite on Windows? Quesoglc has a lot of dependencies and is strongly tied to opengl fixed function. On the other hand directwrite is gfx api agnostic which would make possible to use opengl 3+ and vulkan api while retaining support for right to left layout.

Pangs is also another option for Linux but I have no experience with it.