I would do that for very general typedefs used anywhere or so in the code, which don't refer to types defined by you, and which aren't going to change much, but not for ALL typedefs you are going to define in the project. That would be unpractical:
- Editing a single line would trigger a complete recompilation of almost all source files. If your project starts growing, you are gonna feel this.
- The user would need to parse the enum file each time to find out if some specific typedef exists, rather than finding all right next to what he is using.
I would keep typedefs related to a specific class in the same file where that class is defined. You don't necessarily need to define them in class scope, do that when it improves readability and don't do that when it hinders readability. E.g. your typedef std::unique_ptr<SomeObject> would probably be better off in SomeObject.hpp.
In some cases, e.g. with template classes, which might have several associated typedefs, I like having an extra *Fwd.hpp (e.g. SomeObjectFwd.hpp) file to group them without needing to include the actual header if all I need is the type declaration.
Also consider employing "using" rather than typedefs, since it is more flexible.
Cheers!
Edit: removed some post duplication.

Hi!
Technically, it is be possible to write something like that, you can also find something on that line if you look around the internet. You can even compile c++ to javascript to run your application in a browser with Emscripten! In practice this is not really needed or wanted in most cases. A common runtime or a virtual machine would always imply some performance cost (you either need to interpret an intermediate byte code, or run it through a just-in-time compiler), which is kind of undesired for a performance oriented language. It is also relatively maneageble to compile c++ code to native binary code for virtually every platform in existence, as long as it is written keeping portability in mind.
Cheers!

I'd say, if you have published a game with your engine, it is good for what you need! It is true maybe that by using an established commercial enigne you might save some development time in the future, but on the other hand it looks you already have a good basis, you don't have to pay royalties, and you are not depending on somebody else's code for features and bug fixes, so I'd say go with it as long as it works!

Do I understand correctly that options is just a struct?
In that case the problem is probably here:
&options + (i * sizeof(int))
With this you are not adding 1 * sizeof(int) to the address given by &options, but you are adding i * + sizeof(int) * sizeof(whatever type options is). In other words, after the first iteration, you are copying your integers all over the place, except inside your struct.
It might work if you cast &options to a char*. In any case, I would strongly suggest to reconsider what you are doing. There are for sure better ways to initialize your structure (more readable and less bug-prone).
Cheers!

Hello!
Things to be aware of in my experience are:
- Write standard conformant code. You might need to use a different compiler on different platforms. C++ compilers may have their own extensions and features (e.g. pragmas) which might not work on others, or may be able to do clever things that other can't (e.g. the Microsoft compiler in my experience is sometimes less clever than GCC when it comes to template argument deduction, resulting in some code not compiling on msvc).
- Be aware of performance and availability of the c++ features you are using. Some more recent c++ features might not be supported on all compilers. Things like exception handling might be badly implemented and cause performance impacts on some compilers.
- Avoid calling platform specific code directly (e.g. windows api functions), since of course it will not work on other platforms.
- Graphics API are also platform specific. DirectX will only work under windows. OpenGL is more portable, but for mobile devices you will use GL ES, which is more constrained.
- If you use third party libraries, make sure that they are cross-platform and that they support all platforms that you are targeting.
- Pay attention to platform specific limitations. For example, on Android you will not write your own main, but you will write a library which will then be linked to the actuak executable. Another example, is that windows encodes unicode file names in the utf16 format, while linux in the utf8 format.
- If you just manage your project builds in an IDE, you might need to redefine the builds for platforms on which you can't use that specific IDE.
In general the following will help you writing platform independent code.
- Wrap third party, platform specific, and compiler specific code behind your own interfaces. In this way, you can swap things out or support new platforms without changing the code built on top. You just need to write a new implementation for your interfaces.
- Continuously test builds in all target platforms. This will let you notice problems immediately, when they can be fixed without too much effort.
- If possible, use a library that abstracts the underlying platforms for you. This will save you a lot of time. SDL is very good and widely used. GLFW is ok as a windowing only library, but you will need something else for mobile platforms. SFML is a c++ style library, but I feel it is a bit more limited than SDL. I am also working on my own c++ middleware library (https://github.com/DavideCorradiDev/houzi-game-engine), which is partly built on top of SDL, but it is not mature yet. :)
- Use a cross-platform build system, e.g. cmake. In this way you can manage builds for all target platforms in one place.
- Figure out early what platforms you want to support, or you might have to make large redesigns later.
- Figure out early what your game needs. Swapping from 2d to 3d graphics for example might not be a light undertaking. :)

Hello everyone!
Lately in my spare time I have been working on the Houzi library, a C++ multimedia library for 2D games. I did it mainly for fun and exercise, but it has grown to have a respectable amount of functionalities, so I thought I would share it with the community. I am still working on it to iron out some rough edges and add some much needed features, therefore the code is not yet in a stable state, and I would appreciate any feedback you can give to improve it. Here is the link to the GitHub repository:
https://github.com/DavideCorradiDev/houzi-game-engine
The library comprises seven separate modules:
- A core module providing some basic utilities, such as STL extensions, implementation of some concepts from the C++ core guidelines (e.g. span), a basic error handling framework, and so on.
- A mathematics module providing simple classes for matrices, vectors, rotations, and transforms.
- A system module abstracting window management and input for different OS (mostly a wrapper around SDL with some extras thrown in).
- An OpenGL and an OpenAL module, providing a thin layer of abstraction between these libraries and the rest of the code. This abstraction layer is used, for example, to provide simpler error checking, better type safety, abstraction between different library specifications (e.g. OpenGL vs GL ES), and so on.
- A graphics module, providing classes for easy sprite and text rendering.
- An audio module, providing classes for easy audio file loading and sound playing.
Thanks for any feedback!