BitMaster

For the issue at hand the choice between TCP and UDP are irrelevant, especially in any local test.

The triangle ABC is in CCW order in my first example (and would be rendered). The same triangle ABC is in CW order in my second example (and would be culled). The second example is the same situation as the first example, just viewed from the opposite direction. So the same triangle is visible or invisible depending on the view direction and that decision is made using the winding order of the triangle vertices projected into 2D.
On the other hand, the triangle CBA is in CW order in the first example and in CCW order in the second example.

Most renderers (that includes DirectX and OpenGL) expect a CCW face to be the front face and will simply cull backfaces. At least in OpenGL you can specify which winding is treated as the front face and how exactly to handle front- and backfaces.

Have you tried setTcpNoDelay?

Imagine you paint a triangle on a piece of paper, labeling the vertices A, B, C. Pick a thin paper and pen which is clearly visible from both sides. Looking at it from one side you would see something like this:

A
|\
| \
B--C

Like this, the triangle ABC is in counterclockwise order. Now move your head around the paper so you see it from the other side (alternatively, just flip it over).
What you see from this position (minus the flipped BC) is:

   A
  /|
 / |
C--B

The triangle ABC is now in clockwise order (and would be culled normally).

Those are rather significant disadvantages. As soon as you need to input even a bit of text (and be it only the player's name or naming a save) and might have to deal with non-(keyboard you are used to), it becomes a rather huge problem.

If a practice has several disadvantages AND is discouraged as not recommended by the API designer, then the question you should be asking is "Is there any really compelling reason to still do it?" instead of "Why should that stop me from using it?".

Honestly, I do not see any point of DirectInput for these cases. You need to handle Windows messages anyway, and you even have functions like GetKeyboardState to query the current state.

vector <int*> names; works, so then wouldn't you have a vector of structs or classes if the int* referred to the addresses in memory of different data structs?

For the reasons above having raw pointers to Rectanglee in the vector is generally not a good idea unless you have the experience to know what you are really doing (and if the OP is confused by a private copy constructor then he is definitely not there). Dropping all type safetype by forcing a cast from int* to Rectanglee* is much, much worse for absolutely no benefit. You lose all type safety and gain exactly nothing over the Rectanglee* implementation. You also have the option of walking well off into undefined behavior if you do not understand the casts between the involved pointers very well and depending on how your inheritance hierarchy looks. And you still have to allocate storage for the Rectanglee somewhere somehow for the pointers to point to.

Even setting those things aside, why would you store int* instead of Rectanglee*? If something like that has to be done (and I cannot imagine any reason out of the top of my head that is not done better by other methods), why not use at least void*?

That said, the obvious candidate to solve the issues is boost::shared_ptr. In C++11 either std::shared_ptr or std::unique_ptr would do the job. Of course if we had C++11 I would rather make the involved type movable and just stick them into containers normally (if possible).

The entry function is the function which is called by the runtime to start the actual program after runtime initialization has finished. For /SUBSYSTEM:Console the common signatures are

int main();
int main(int, char**);

See the standard (or Wikipedia if a standard is not at hand) for a complete list of what is allowed here, although MSVC allows a few non-standard extensions.

For /SUBSYSTEM:Windows the entry function must be

int CALLBACK WinMain(HINSTANCE, HINSTANCE, LPSTR, int);

Although it is possible to change the name of the entry function in MSVC, the signature still must be as expected.

That error is unlikely to be the only one. There will be errors above there telling you exactly which symbols are unresolved. Without knowing the symbols you cannot even be sure the problem is freeglut, it could be a dependency of freeglut or something else entirely you are not linking. Or you could be using /SUBSYSTEM:Windows in which case you need to change that or define WinMain as the entry point.

I'm unfamiliar with JavaSoundAudioClip but a quick look at the documentation did not suggest it holds any native resources that must be explicitly released. From your description you appear to be keeping all resources of previous levels around. Normally the VM would be able to free the memory itself but if you never allow anything to become unreachable, that is not possible.

Assuming your resources all reside in the Level instances, a quick fix would be to set level1 to null when you move over to level2, and so on. Of course a much cleaner solution would be a data-driven design where only one instance of Level is active and a new one is filled with data for the new level as needed.

One concrete of a file format that does something like this would be TIF:

Every TIFF begins with a 2-byte indicator of byte order: "II" for little-endian (aka "intel byte ordering", circa 1980) and "MM" for big-endian (aka "motorola byte ordering", circa 1980) byte ordering. The third byte represents the number 42 which happens to be the ASCII character "*", also represented by hexidecimal 2A, selected because this is the binary pattern 101010 and "for its deep philosophical significance". The 4th byte is represented by a 0, an ASCII "NULL". All words, double words, etc., in the TIFF file are assumed to be in the indicated byte order. The TIFF 6.0 specification says that compliant TIFF readers must support both byte orders (II and MM); writers may use either.

(source)

When I say "watermark" I don't refer to an obvious human visible watermark. There are ways to embed a watermark in an image that is not only completely invisible to the human eye but will also survive a lot of image modifications. Unless you are applying something like a really aggressive cartoon shader to an image the assumption that a digital watermark will still be found in your image is a rather safe one.

I didn't say it does not come with a price at a different place. If Java-new were just completely better without any negative side effect at another point everyone would be stopping to use C++ and start using Java (well, not really). The important point up there was that new being expensive is something related to C++ only. It comes with prices and benefits all over the place. Other languages, even if they have the exactly same looking new-keyword, do that differently and things come with different prices and benefits.

You need to check the page where the image is actually on and see how it is actually licensed there. You might not be allowed to use it, you might have to attribute the image to its creator or you might be able to freely use it (among many other possibilities). Stealing a John Doe's image from their blog or whatever website you are pilfering might never be noticed but unless you are complying with whatever license is outlined there (and if there is no explicit mention of a license I would assume you are not allowed to use them), you are still doing something wrong. And although the likelihood to get caught is small in such a situation, sometimes it happens and then your reputation will take a hit it does not need to take.

If it is some commercial endeavor from which you try to steal images then it is pretty safe to assume they will find out unless it never leaves your local hard disk. Any free samples you see will probably contain an invisible watermark which will not be easy to get rid off and some webcrawler somewhere will detect it.

A lot of this behaviour in C++ is implementation dependent but as a general rule in a nutshell:
- stack allocation requires incrementing a pointer by sizeof(WhatIWant)
- heap allocation requires synchronizing over all threads and walking some kind of list until a suitable chunk of memory is found, modifying the list accordingly, and returning the pointer.
Note that this applies to C++ only. On modern Java implementations for example, new is silly cheap. Also note that the Debug runtime of MSVC for example does a lot of extra work (like initializing the allocated memory with a special value and padding the allocated memory with another special value).

Also note that an optimizing compiler will probably be able to completely eliminate your passing function since it can detect that nothing in there has a side effect. I would not trust the benchmark as written. Either the compiler is not optimizing (in which case it's probably the default Debug configuration in case of MSVC and as such completely useless for any benchmark) or the function and containing loop was probably completely removed.

Setting aside I would not implement something that is already in the standard library, I would do the casting as the standard library does. Most importantly I would not do a C style cast. It loses all type safety for absolutely no reason.