First, about your questions: 1. I don't really see where ultramailman suggested multiple entity managers.
2. If you know you need only one, you could as well make it global. My experience however says you don't know until the project is actually done, so my advice would be to avoid that path. Either you pass it along with every call that needs it or your quadtree needs to store the shared state and pass it down to every sub-quadtree it creates as well.
3. A static data member is a global with a slightly different name.
I feel you have modeled that in a slightly weird way. In my mind there should only be one Quadtree per actual quadtree. A Quadtree has a root Node. A Node has up to four child Node instances. Either the Node instances should know which Quadtree they belong to (allowing them access to any shared state), or perhaps better the Node instances are pure data and the visitor function always knows in which quadtree it is, again allowing access to shared state.
The lambda itself will not allocate anything dynamically. If you store the lambda somewhere (for example an std::function<>) it might have to allocate memory (depending on the size of the lambda and std::function's implementation details). Note that if you transfer the lambda somewhere using a template, like
If that path is actually contained in the string, it is most likely wrong. You have to escape the backslash when you write the string in the source file (unless you can use one of the nifty string features in newer C++ versions) not in any string. Also note that a lot of Windows functions can deal with '/' instead of '\' as the path separator. Edit: To make it slightly clearer:
std::string test1 = "G:\\test.txt";
// test1 now contains the string "G:\test.txt"
std::string test2 = readFromMyFile();
// if test2 now contains "G:\\test.txt" then this is wrong for further file operations
Assumining the readFromMyFile function just does a straight forward read, the file (or similar source) has to contain a line like
Also, note that DeleteFile returns 0 if there is no error. If there is an error you need to call GetLastError to retrieve a more detailed error code.
It was probably a mistake to post a question like this in "For Beginners". While well-meaning I fear the posters so far did not get the actual question you are asking and go into details which I believe from your post you already know.
To answer that: Usually you should not need to add implementation files if you are already linking the static library. In fact, that will result in linker errors because there are two definitions of the same function. What exactly goes wrong in your case, I cannot say. One possible scenario is that the project you downloaded was initially intended to build its own 'libyaml-cppmd.lib' and link it directly. Maybe you broke that configuration. Maybe it was already broken when you downloaded it. Maybe it relies on having a specific environment variable set or a path added to the global linker settings. Maybe the dependency between targets just got broken.
The function resize() is equivalent to -- and sometimes implemented as, calling pop_back() a bunch of times. Reserve the space first. You have potentially just caused n reallocations to trigger, and potentially just triggered n! (n factorial) moves. Most standard library implementations use bigger buckets, but some of them only allocate in very small increments, a few memory-conscious implementations only increment by one by default.
First, I think you meant 'push_back', not 'pop_back'. And then, are you certain about that? I just checked the documentation and the promised complexity is 'linear in the difference between the current size and count', not 'amortized linear' as would be expected when using a bunch of push_backs.
The first way is to call glBufferData with a NULL pointer
is enough for basic orphaning, no buffer mapping required.
Second, as Spiro already mentioned, unless the data you are rendering can make good use of indiced calls it's just dead weight. If your indices are more or less (0, 1, 2, 3, ..., n) it's just an extra step of indirection without any benefit. Are you actually able to significantly reduce the number of vertices by using the indexed calls?
Yes the VBO is updated every frame, but I'm confused why this is being considered created every frame. The memory is already allocated for the VBO buffer and that memory size does not change. I'm just updating it
That in itself it part of a problem. Uploading new data into a buffer object usually forces the driver to artificially synchronize. One simple way to avoid that is by explicitly orphaning the old buffer as described here.
However, more and more projects have begun using CMake so it can't be that bad.
[...] Guess what, CMake's support for packaging Mac application bundles haven't been maintained in years.
I have a different story to tell. We needed Mac packages (obviously in a hurry) we could distribute to clients. With no real MacOS knowledge I was able to get some decent packaging going with CMake within a day or two (which included some bug fixing/compiler appeasement because the application was never built on Macs that way). Someone else then needed a bit more time get the automatic signing in. However, when all was said and done we could generate several individualized packages with a single make call.
I freely admit CMake is far from ideal, but my work project was developed on two different platforms (without CMake) by different people and getting all changes synchronized was annoying (to use a polite term). It's now built on four different platforms plus a fifth for some tools and background infrastructure (with CMake). Dealing with CMake is a tiny price to pay to avoid practically all of that platform chaos.
Personally, I'm using it for my hobby projects at home too. I'm having far more success getting CMake to generate decent custom build steps than I had with MSVC alone (easier to recycle and extend them as well). Also, I like not nailing myself down to one IDE/compiler. I have been breathing MSVCs nearly all my C++ career and it certainly made me pick up some annoying habits. Using a different compiler certainly made me realize a lot of them and improve.
I just checked Wikipedia for 'GDI' and the only valid reference points directly to the well-known and not really helpful Windows API. Googling for 'GDI' also finds only the above (and some completely different things). Additionally, I have personally never heard of using 'GDI' as a stand-in for just any abstraction of output devices. That is like talking about a Model T when you actually mean cars in general. It's bound to cause misunderstandings and ultimately annoys people when they finally understand what you really mean.
The trick is giving people what they need, not what they want.
Your mileage may vary but in my experience the people who are the loudest in game forums are also the ones least likely to have well thought out and reflected opinions. Of course that also depends on the game and actual community, for example a lot of the people over at the official Age of Wonders III forum are markedly distinct from what I'm used to in other games. I still wouldn't blindly implement any change suggested on those forums though, either.