What helps me is to let some tool like Doxygen create the documentation for the code (even if it doesn't have any Doxgen markup attached), and make sure it produces a call graph for every function/method. That way one can easily see which code gets called why what other code and it is often useful to understanding the overall structure. There is no use in understanding the details of every function unless you need to get into the details to do you work on this specific piece of code.
This has been very useful to me when searching through a 20+ million LOC project with a 25 years history behind it, so there were several generations of engineers working on it.
The code itself looks correct to me. Very often, heap errors happen at a completely unrelated place and show only much later. Stuff like this is usually hard to debug, but Visual Studio should help you with that.
Consider using http://kripken.github.io/emscripten-site/ It allows you to compile C/C++ to JS, including OpenGL ES. With a few tricks you can make it compile for the Web and to a native executable. Also the Web-Version ist way faster than any JS you would come up with yourself.
Even the supply line idea is present in MoO, but by the time it would be needed to balance the game, it doesn't matter anymore.
In MoO, ships have a limited range, based on their fuel cell technology. If a ship is stranded too far away, it will automatically return to the closest colony (which doesn't make any sense, considering that it was limited by the fuel cells, but whatever). So if you the closest colony to your currently targetted system, your attack will be cancelled. Too bad, after a while you can research better and better fuel cells, resulting in Thorium Fuel Cells which provide infinite range. So while this again limits the expansion in the early game, it is useless in the end game.
I really wonder if all these things were added in that fashion to make for more challenging middle games and quick end games or if it was actually just a balancing error.
Maybe they decided it was not desirable to have a more balanced end game because the game would get too slow paced then. That's a really interesting question for me, as I never thought about similar game design issues yet...
Depends. If your output device is a local monitor, you usually need some kind of video adapter (you could also write your renderings to a file, networks stream, printer, ...).
But if you want it to be visible on the screen, you copy (or let the operating system copy) your prerendered image to the video memory. In that case, the only thing the video adapter does is to output the image data to the screen.
In hardware rendering, you do the same, the difference is that you don't first use the CPU to do the rendering work but some hardware accelerated mechanism. But the stuff that happens after rendering is exactly the same with the same hardware parts involved. That's why it's usually (or was at least at some point) called hardware accelerated rendering.
ferrous: Master of Orion has something similar and it didn't stop players from stacking up. In MoO, you have command points (not sure if that's what they're actually called), which are produced by certain buildings of which you could only have one per colony. Bigger ships require more command points. If use up more command points than you create, the maintenance costs of your fleets are increased quite a lot actually. But with just a few economically strong colonies you can counter the effect by producing trade goods.
I guess Microprose had the same idea about limiting the usable number of ships, but it didn't work. At least not in the way they intended. In the early stages of the game this is sometimes a limiting factor to the speed of fleet growth but in the long run, new technologies and economic tactics make it a useless trick. Maybe that was actually done intentionally as some fort of positive feedback mechanism to make games end in a reasonable time (even single player games can take up a whole day though).
In Master of Orion II (one of my favourite games btw), battles take place completely within one "galactic" turn. Also there are always option to destroy a small ship without it ever being able to do anything.
I always wondered if it was possible to change the rules in such a way, that battles are not concluded within a single galactic turn (with either one fleet completely destroyed or retreated), but instead have battles last for several galactic turns (stopping after a number of battle turns and continueing in the next galactic turn). Also switching the active player after a number of unit-turns instead of after he has used up all his units' turns could make battles more balanced. That way, it would be possible for either player to bring new ships into a battle, smaller ships could destroy bigger enemies even if the enemy has the advantage of the first turn.
Also, stronger area of effect weapons that can be placed on smaller ships could help. There's for example the Pulsar in MoO, or the Spatial Compressor. Having some of those be actually more powerfull (not only more efficient) against larger fleets could counter the huge-fleet-syndrome. The strength of those weapons could also be an effective measure to balance the game towards a certain maximum sensible fleet size.
I like the other suggestions about fleet being more stealthy if they are smaller very much. Small fleets could even be made to pass through planetary defences more easily and probably even start their combat between the defending fleet and the planet if they are very small (sneaked through the defending fleet), thus allowing them to drop ground troops faster and so winning the battle without actually defeating the defending fleet.
No, they are not deleted from the object file. The linker needs them to be available if a function from the same compilation unit needs them. They are just marked as local and are thus not available for other compilation units. You can check that with the tool 'nm' (i guess it is also available in mingw):
$ nm static.o
0000000000000000 t f
000000000000000b T g
0000000000000000 D x
0000000000000004 d y
This basically means that f and y are local to static.o (lower case t and d as symbol types), while g and x are accessible from other compilation units (upper case symbol types).
It might all be a bit different on Windows though, not sure what object format mingw uses, this is an example from Linux. Learning the format of object files is probably not a very useful task. First, you barely ever need that and second, there are libraries and tools available that can already do that for you.
It's also the "usual" way to write performance critical applications or libraries in Python. You first write them completely in Python, then you profile it and whichever part has the worst performance impact is rewritten in C and exported back to Python (basically without changing this part's interface).
If you already started with python, stick to it. Python is perfectly fine as a language and also specifically for game development.
Java is better for Android development, but for the PC, neither has any real advantage in the sense of deployment or availability. Most people have a Java VM installed, but Python can be packed pretty small and distributed with your game (py2exe even makes an executable file from it).
Python has good enough performance for everything you might want to do in the first years (and it will take years before you can think about making anything "big"). You will also be able to transfer all your python knowledge to Java later. Most experienced programmers can pick up a new programming language in a matter of days or weeks, because they know the concepts and only need to learn how to express them in the new language.
I suggest you stick with Python, learn how to program (which is easier in Python than in Java, imho) and once you really need it, switch to Java. But that will probably not be before the end of the year or so, if you really want to learn the concept correctly.
How could GLSL even have file includes? GLSL doesn't even know about source files. You would either need a feedback mechanism telling the host application which include file is needed or the host application would have to upload each and every file that might possibly be required by the current source file. To get that right, you would have to parse your GLSL source files anyway to find out which includes you need. It's only a small step towards handling the includes yourself from there.
Linking is a completely different story though, the system knows all symbols generated by its source files and does not need any two-way communication with the host application.
So, I think the way it is done is the only feasible one.