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.
The obvious solution would be to only allow https connections and the client validates the expected certificate is used. Obviously the client could still be manipulated to ignore the certificate check but it's a bit more involved than redirecting a DNS query.
The particular multiplication of a vector, defined in linear algebra, considers a vector of 2 dimensions nx1 or 1xn. And this multiplication operation thus runs in pattern of being complex . But you can validly define a multiplication operation to be not complex (as in GLSL or HLSL), and have a vector space. Making the multiplication of vectors comutative.
As the last time we talked about that: you can certainly add additional stuff (like operators) to a vector space. You might even be able to do more with it then (although the polite way in mathematics is to give it's proper name then), but that doesn't suddenly give all vector spaces that property.
Even so, if I remember correctly the last time that discussion came up you needed something like getting rid of a vector \(v\) on the right in an expression \(Av\) for a suitable matrix \(A\). Even if you have an inner product \(*: V \times V \rightarrow V\) that does not work: first, not every vector has an inverse element regarding \(*\). Second, even if you had the expression \(Ae\) (where \(e\) is the one-element regarding \(*\)), you cannot make the \(e\) vanish. It's the multiplicative neutral element for \(*\), not for (matrix, vector) multiplication. The result of \(Ae\) is a vector, not another matrix, definitely not \(A\) itself (except in the degenerate case of one-dimensional vector spaces).
You surely agree then that there are plenty of differences fired in also morphisms , transformations. Yes, the multiplication of matricies is not associative then, having multiplication of matricies undestood as F(L(D(v))) where F, L D are linear functions of v vector (linear functions can be multiplied to one function)
I have no clue what you are talking about. Function composition is always associative. You don't even need linear functions for that, it's a basic property. Changing the representation to \((F \circ L \circ D)(x)\) instead of matrices has no influence on that, you still have \((F \circ L) \circ D = F \circ (L \circ D)\).
In addition to what the posters above have already said, in your second example, your "crap" variable has undefined state after the std::move, so you should never use it again (it's safe to destroy, but otherwise you have no guarantees).
That is untrue. The object must be in an "unspecified but valid" state, not "undefined". You are for example allowed to call member function which have no specific preconditions. So calling std::vector::empty after a move is perfectly fine while std::vector::pop_back could or could not work. See also this discussion.
If TCP_NODELAY is not explicitly enabled (which is often disabled by default) your TCP implementation will not send data immediately and instead see if it can combine more data into a single packet. If that is indeed the case you are sending a packet every N frames (where N depends on your packet size and what timeout/size your TCP stack considers reasonable).
You do not have to load the content yourself. You can create an std::ifstream, open the file and then pass the stream to Json::Reader::parse.
You can also wrap a block of memory into an std::istringstream (or a custom stream) and pass it to Json::Reader::parse.
You can also create a custom stream which can load directly from a network source or your custom package format and pass it directly to Json::Reader::parse.
That's the nice thing about abstraction. A stream is just a source of data until it says it has no more data. Whether the data is coming from a file, the network or some other arcane source is irrelevant for the user of the stream.