In general, you should prefer the standard library where possible. However, in this particular case your code will be more portable with sf::Clock, because some standard library implementations (e.g. those of Visual Studio) were known to not use high-precision timers in Chrono until a few years ago.
Alright, thanks. Less differences between game and level editor code, yay!
You should work with a C++ data structure that represents the JSON tree layout (which is very simple: arrays and objects=maps). I'm pretty sure good JSON libraries already come with that.
I use jsoncpp which has that, but I want to do this.
Suppose I have a class like this in C++
class Animation {
int frameTime;
int frameCount;
...
};
which looks like this in JSON:
{
"frameTime" : 100,
"frameCount" : 10
}
I output Json table (Json::Value in C++) to Qt table which then maps every field to Json::Value object, so when I change table value, corresponding Json::Value changes. But I also need to update corresponding C++ value. So I have to map Json::Value object to pointer to corresponding value, so when Json::Value changes, the variable value changes automatically. I already have some ideas how to implement this, but maybe there are easy ways to do this stuff.
I wouldn't stick to one dynamic library format (DLL) unless you actually need it. There are various options for inter-process communication, see here for a list of common ones. Network sockets are also a possibility.
But are game and editor actually running in parallel, in two applications, and they need to know each other?
Thanks, I'll check this out.
I want to have an instance of game running in Qt application. I can use code directly from my game project and then call functions from it, but I feel like this is a bad idea.
So, I need some other way to link editor and game engine code.
They, of course, need to communicate somehow. Suppose I click on some object. Level editor calls some function from game engine like this:
Entity* findEntity(sf::Vector& mousePos);
and now I get a pointer to entity and level editor can do pretty much everything with it, so if I decide to delete it, it does calls function from Game:
removeEntity(selectedEntity);
This would be trivial if I just #included some stuff from main code base, but I feel like game engine and level editor need to be separate somehow. (Hell, some devs write their editors in C# while the game engine is in C++, you can't do #include's in C# for code in C++, so you can't call it directly)