Map code

[daniel.santos]

This is a continuation of the discussion here https://forum.megaglest.org/index.php?topic=4018.msg24398#msg24398.  By "map code" I mean the code that deals with the map in general, not necessarily the map editor.

Hailstone proposed considering having the map code in a separate dll (shared library).  It's a bit funny, this seems to be a time that the build its self is undergoing a lot of changes.  Bork helped get pre-compiled headers working on linux and that should speed up compile times nicely, although there are still issues (discussed here).  The main thing I want is for code that is used in more than one place (i.e., the game and the map editor) to be in a shared location -- copy & paste is very bad!  It leads to one copy of the code being maintained while the other is forgotten about and then there's inconsistent behavior that leaves you baffled!

I'm thinking we probably don't need to make the map code it's own shared library, but rather make the "shared_lib" project a true shared library (.dll on windows, .so on linux) instead of a statically compiled library.  This would reduce the overall download size and allow the map editor to link in everything from the shared library also allowing us to have access to all of the rendering capability in shared_lib.  The same is true for the g3d viewer (which we haven't supported for quite some time, unfortunately).  Further exploration of this may reveal that we want to move portions of game/graphics/render.h/cpp into the shared_lib as well, but that's not something we should probably worry about too quickly.

So here is what I'm thinking (and it's related to the pre-compiled header topic).  I don't understand jam very well, much less Matthias' custom build system that's built on top of it.  I'm seriously considering making a motion to replace the current build system entirely with a standard autotools & make-based GNU-style build system.  I realize that it may be less powerful and flexible in many aspects (aspects of which I don't fully understand), but a lot of people know it and there's a LOT of ways to get support for it when one of us gets stumped (as I haven't been able to get a hold of Matthias).  We should be able to reuse most of the m4 macros (under mk/linux/mk/autoconf) and configure.ac, just exclude the mk/jam stuff and alter autogen.sh to make the standard configure for a make file.

But back to the topic on hand, what do you think? Make the shared library an actual shared library (dll/so)?

[Omega]

Very good idea. It will allow updates to the dll easily too, won't it?

[wciow]

Personally I would prefer Glest to be a single executable rather than a bunch of files. The only possible benefit I can see is that the "map library" could be replaced independantly of Glest.exe. 

[hailstone]

It's lots easier to support multiple apps if it's a dynamically linked library. That way we can add functionally to the map editor without copying and pasting large amounts of code for something like a 3D map preview. And it can be updated without requiring a new executable (depending on the changes) like you said.

[wciow]

From my very limited knowledge of coding, if I was going to built the 3D map maker that people keep talking about I would start with Glest.exe and work backwards stripping out the uneccesary parts and adding new functionality to edit the map in realtime (possibilty in a new library).

It would be really cool to see a Crysis style editor where you can switch between playing and editing in realtime 

[Omega]

You know, I've been thinking. Would it be better and time saving to keep the 2D layout of the map editor (I'm pretty used to it by now) and give it two things:

1. Use images instead of x's and dots. Such as a simple image of a tree for the tree.

2. Most importantly, a quick preview button. With one button, the map opens with a selected tileset. Almost like opening the map in a new game with no factions and a totally free camera (no zoom limits, ect;).

Much faster and easier than a 3D map editor, which is very complex I imagine and would not actually improve the quality of the maps in the game.

[hailstone]

I'm not so sure about the first one but the second one is what I intended to do.