Posted by BitMaster
on 14 November 2014 - 02:27 AM
Is it possible you are linking other libraries which link to the debug runtime when you build release (or the inverse)? Alternatively, is your project somehow set up weirdly? The problems you appear to be having seem to be general library linking problems with C++ with respect to the runtime, nothing specific with Boost. If a program links to both the Debug and Release runtime (as that warning suggests), things are most likely going to go to hell somewhere.
Maybe your preprocessor definitions don't match what you are actually building? Usually MSVC should deal with that, but if you added preprocessor symbols by hand things might get wonky. In that case try disabling Boost's automatic linking and link the correct library by hand or better yet, start from a clean workspace.
Do you have a minimum sample project which shows the problem?
Posted by BitMaster
on 12 November 2014 - 02:18 AM
Again, the pros do not use RTTI and exception handling, even if it's only in debug builds. If you want to ignore the collective wisdom of all the top developers in the industry, you do so at your own peril.
Just for the record, the primary reason I downvoted this is your abrasive personality in this thread and some other places I noticed you recently. An attitude like "I'm awesome, so every turd I drop is pure gold and you do not need anything else" really bugs me.
Now, moving on, especially after reading frob's post the impression I get this is solely about console considerations. To be honest, I'm getting rather tired of stuff being only valid for consoles ruining people's day on non-console systems and I'm talking both about the actual programming as well as unnecessarily limiting gameplay decisions.
Yes, there is a lot of money to be made on consoles. But consoles also cover only a very limited selection of genres and as it happens, aroundish 99% of what gets published on consoles is of no to little interest to me. What does interest me hardly ever makes it to consoles, because the average console audience is not very interested in it, because the people interested in the genre are less likely to have a console and because playing these kinds of games with a controller is not very optimal. I don't want to go into ideological battles here, so let's just say there is a market outside of consoles sufficiently large to make a decent living from. That's one part of the argument.
The other part is, unless you are part of a big studio, you will never write on consoles (at least not in C++ where a decision of "RTTI" or "no RTTI" could actually be made). Yes, consoles are very different beasts with specific requirements. But should I ever work on one I will have to read a lot of documentation and best-practice guidelines about it anyway (much of it is usually hidden by NDAs before I actually work on one), not to mention the studio's own coding guidelines. I would expect from any decent programmer to be able to modify their coding behavior depending on constraints like this. In my mind, if "we don't have RTTI on this platform" is too much for people to handle, they are really not people who should be working on the project. This forum is called "General Programming". It's not called "Console Programming", there are specialized places for that (usually inaccessible to the public because of the aforementioned NDAs and stuff). I would have no problem with people contributing additional information from their own experience how something is extremely inadvisable from their own console experience. But what I read very frequently is people taking their console experience and steamrolling it over normal (game) development. There is a a whole ecosystem of non-console game development out there. Your profits are not measured in hundreds of million of dollars, but neither are your costs. Also, you can actually work on the platforms involved without jumping through very expensive and often unreachable hoops. Completely ignoring this reeks to me as ignorance at best and actual malignancy at worst.
This will always print out 4. If your platform cannot support 4 byte ints it will at least refuse to compile instead of doing something creative.
That said, it's a bad idea. If the assets are on the user's computer, they have access to them. What they do with them in private is really their own problem and if they do something unwanted publicly you do have legal means at your hand. Besides, doing wonky things with your assets is more likely to cause yourself problems later on than inconvenience a skilled attacker. If you still want to hide your assets, I'd rather change the file extension or pack the resources into some archive format (that actually has benefits apart from the elusive idea of hiding them).
Posted by BitMaster
on 11 November 2014 - 01:12 AM
Then why did you feel the need to downvote me? The huge advantage of boost::polymorphic_downcast is that it verifies the type in debug builds (always a good idea to assert things which should be true there) and is a static_cast in non-debug builds.
Posted by BitMaster
on 10 November 2014 - 07:11 AM
I'm seeing here lots of mentions of MinGW without much acknowledging of MinGW-w64. This is important because vanilla MinGW is stuck in the pre-XP era and won't even be able to build a lot stuff made for Windows XP (and I hope you don't need DirectX because getting that to work is close to impossible), not to mention how SDL2 doesn't even work properly on it (I had to disable threading before I could get MinGW-w64 set up). Seriously, code should start including checks for vanilla MinGW and throw out an #error when detected (I just added that yesterday to my game).
Out of interest, what exactly are you referring to here? I have used both the original MinGW and its alternative (definitely in a post-XP era) and never encountered any problems like that (although I never tried DirectX with it). The biggest problem vanilla MinGW has in my opinion is the slower flow of features (as in MinGW was stuck at gcc 4.7.x when 4.8.x was already available for the other MinGWs).
One problem with all MinGWs is the issue of std::thread in C++11. Either you have to live without them (not a severe problem, especially if you use Boost anyway) or you get the standard library with POSIX threads (which works but makes the whole standard library on Windows slower than it could be). However, this seems to be a problem soon to be in the past, apparently the upcoming release at MinGW builds at least will have an implementation using native Windows thread primitives.
The biggest problem I always had was that a lot of libraries assume you'll be using Visual Studio on Windows, period, even if they use GCC on Linux instead. That's kind of ironic since MinGW(-w64) is basically half of each of those (Windows API but GCC toolchain). But yeah, enjoy messing with makefiles and such when you stumble upon one of those. I think the situation improved over time but still, take that into account. Though every time I see somebody defending Visual Studio over MinGW it's because of the IDE (I don't have any issues with using Code::Blocks but then again I don't use most of the advanced features either...)
With the libraries I wanted to use, the worst I had to do was use msys and fall back to the *nix build system. So far, that has worked even for the more annoying libraries and all it does it adding the constant cost of setting up msys once.
My Python is a bit sketchy but I would assume "comp = comp()" is a really bad idea. It creates a local variable 'comp' and then tries to initialize it by calling itself as a function in an uninitialized state.
Every time I see a "realtime" thread, one moronic wannabe just shows up trying to make the OP feel as stupid as possible. It is incredibly obvious that the OP is a beginner, and doesn't need actual realtime input.
Correcting misconceptions of a beginner is a very important step, especially because such misconceptions can make researching your own answer extremely difficult because the keywords you use are not the keywords which will be helpful. I did not see what tonemgub wrote as something to make someone feel stupid.
If you link the static version of GLEW (that is, glew32s.lib), you need to define GLEW_STATIC before including the header.
Also, I'm not sure about the prebuilt libraries with MinGW. Oftentimes projects will only supply prebuilt MSVC binaries for Windows. Personally I just build libraries (like GLEW) myself to avoid any such problems. It should be trivial for GLEW, especially if your MinGW comes with msys.
Your up-vector (the third parameter) must not be collinear with your forward vector (target - eye). It should be (0, 0, 1) or one of the many other possibilities. If you modify just one of the coordinates you did, glm::lookAt can orthogonalize the whole thing but that is mathematically impossible like you wrote it.
The L just means it's a long constant instead of an integer constant.
That said, I do not think you can solve the problem with cURL. cURL needs to resolve a DNS. It has to ask the operating system to do that, and Windows will lie as much as the user wants to with just a hosts entry.
Sik_the_hedgehog: I don't think just any https will do. You need to validate (with the public key contained in your client) that the server uses the exact matching private key.