Quick glance at the code, you pass parameters by value specially std::string, you do not use const anywhere including marking methods which do not change state of an object. Those two things would be give me the impression that you are a junior.
For me is, why would you do any kind of cheat prevention for a single player game? If I want to "cheat" myself, why make it harder for me? Maybe some parts of the game are too hard and I am not willing to spend some hours of getting better at that part. IOW, I am not competing with anybody else and I play games for my own enjoyment and not somebody else.
I have used cef toolkit (https://bitbucket.org/chromiumembedded/cef) before and with some good results (not the easiest library to work with). There also couple or so derived projects from it that may be better solution, do not remember from top of my head, but I'm sure google will find it for you.
Since you already using EU4, I would use Blueprints to at least a prototype. It seems that your project would fit well in BP and they are pretty powerful and you can do a lot. For any harder problems or performance issues, you can always step into C++.
My approach lately has been to use google proto buffers for saving and loading to and from disk, and then actually create sqlite db in memory to represent that data during run time, and rest of the system then deals only with that database. By using sqlite for data representation, it gave me quite bit of flexibility and it seems easier to deal with changes. In most case it usually only required small adjustment to query as the needs grew or changed. The actual conversion to and from proto buffers is contain only in one file. And to top it off, by using sqlite (mostly as intermediate format here), it allowed me to add more verification and validation by using sqlite language, like constraints, triggers, etc, so data become even more validate with almost no work on my end.
What about trying to log to a file and at various locations and bits of your program, it may generate large file. Other option is to build with pdb file even in release and then run it under debugger or attach debugger and hopefully when it crashes you may get "decent" stack.
Posted by DoctorGlow
on 30 October 2014 - 02:18 PM
Best way is to forget all the transforms and provide vertex position coordinates in projection space - that is, in range [-1.0, -1.0, 0.0, 1.0] to [1.0,1.0, 1.0, 1.0].
i think i can make that work by making a separate shader that does not have any world transforms, but i am re-using the same shader for many things, how can i set a world matrix to have no effect when it is used?
I think true tests for this would be to "eat your own dog food". IOW, try to make a game with this and see how well it works out, and I mean something more complicated, rather then simple pong or Tic-Tac-Toe. This should give you good insight into your project/library, how well it works, how much changes, custom code you had to do, etc. Once you finish, you can try another different game and then you end up with cool and useful samples code for your perspective customers.
I would try to log as much as I could to a file (flush it out or close the file after each write). Then when it hangs, reboot, and look over the log file. This may give you at least approximate area where it hags.