I would suggest that we have two methods CvGame::getMap(), and a new CvGame::getMapInternal() which takes an extra parameter saying which map to return. The first one calls the second with the param set to return the external (viewport) version. Before making ANY other changes bulk search-and-replace all internal uses of GetMap() [and GetMapINLINE()] with GetMapInternal(MAP_UNDERLYING) [make this unconditionally inline probably), so we wind up with just the external engine calling the original getMap().
Parallel Maps
- Thread starter LyTning94
- Start date
I would suggest that we have two methods CvGame::getMap(), and a new CvGame::getMapInternal() which takes an extra parameter saying which map to return. The first one calls the second with the param set to return the external (viewport) version. Before making ANY other changes bulk search-and-replace all internal uses of GetMap() [and GetMapINLINE()] with GetMapInternal(MAP_UNDERLYING) [make this unconditionally inline probably), so we wind up with just the external engine calling the original getMap().
Okay. I was hoping to avoid replacing all the calls to getMap(), but I don't see any other way around it, so this sounds good.
I should have time to start actively helping with this from next week if you like. Question is what would be the best way to do that? I can see a number of possibilities:
Let me know what you want to do...
- I just work on porting what you have to C2C, possibly doing more on it there, and then you can back-port. This seems a bit clumsy as we'd both be continually porting
- I could work directly with you on your codebase, then port to C2C as pieces of functionality become complete. Seems like a practical possibility, but the problem is how we avoid continually clashing with one another since you don't have a shared code repository available (do you?). If we go this way ideally you'd need to put your code on Sourceforge or some other shared repository so we could both work on it
- You could adopt the C2C DLL as your base, and we would add you as a DLL modder to our repository, and we both work on the functionality via the C2C DLL codebase. Obviously this one suits me, but it rather imposes on you. However, the C2C DLL does offer a ton of advantages you might want to consider (runs way faster than the original, espeically on larger maps, has a save format that allows games to be loaded across changes to the XML, are the two biggies)
Let me know what you want to do...
I have a question for either or you.
Back when this was being developed, LyTning and AIAndy came to the conclusion that it was impossible to make maps of different sizes using the Civ engine. With the new large map-viewport setup, would it be possible to, while having the viewport remain of a constant size, allow the underlying logical maps to be different sizes for the purpose of the actual gameplay? That would make things much better for the Mars and Moon multi-maps, among other things.
Back when this was being developed, LyTning and AIAndy came to the conclusion that it was impossible to make maps of different sizes using the Civ engine. With the new large map-viewport setup, would it be possible to, while having the viewport remain of a constant size, allow the underlying logical maps to be different sizes for the purpose of the actual gameplay? That would make things much better for the Mars and Moon multi-maps, among other things.
Yes. I'm not even suer that the conclusion that you cabnot vary map size is correct. To the game engine a map change pretty much looks like a load of a game (which can change map size), but for certain the size of the underlying map can change.
I think option 2 would work the best at the moment. I don't have a shared repository set up as of yet, but I should be able to set one up in the next few days (once I figure out how).
I may be interested in merging with C2C at some point--I haven't really looked into it much--but I think it would be better to keep vanilla BTS as the base for the mod, so it will be easier for users to port to their own mods.
I tried a lot of different things, and from what I can gather the only way to load a different sized map into the engine is to reload the engine itself: i.e. start or load a whole new game. I did put a little workaround into the mod, so that subsequent maps can be smaller than the original map. The extra plots on the smaller map are set so that they can't be moved into or revealed. The only major problem with this is that it disallows wrapping.
With this said, the underlying maps should be able to be different sizes either by using this method or by somehow predefining the viewports so the engine only sees a map of the same size.
Yeh, the restriction is that all viewports must be the same size then. Not the end of the world. Best thing would be to make the viewport size a BUG option I think, so that users can set it appropriately for their hardware
Edit - oh wait, you don't have BUG as part of your mod. I guess a global define then (and I'll migrate it to a bug option when I port to C2C). Let me know when you get set up on some shared repository (Sourceforge or whatever) and what aspect you'd like me to work on/experiment with.
Will do.
j_mie6
Deity
wow!!! I was just thinking that for my medieval mod instead of a wide map I could have a switched map for the americas. Of course I will have to do some work on this myself, for example actually moving units betweens maps (creating CyUnit/CvUnit in the next map and killing the previous one) by placing them on a tile on the west /east of map and pressing a travel python button. Will make a button on the interface (like next to the mini map) to swap to the other map (provided it is discovered). And the AI will have to be event style to create them on the other world.
Though I have a question... Will the other map freeze while you play the current map? I'm not sure how this will actually affect me, if the player is in the americas they would want to swap every turn anyway (and the end turn button will have to be linked somehow to end both turns, or the swap world button glows greens when a move needs to be made there...)
But atleast I have a base for my own work!!!
Thanks for this mod, will experience when the time comes
Jamie
Though I have a question... Will the other map freeze while you play the current map? I'm not sure how this will actually affect me, if the player is in the americas they would want to swap every turn anyway (and the end turn button will have to be linked somehow to end both turns, or the swap world button glows greens when a move needs to be made there...)
But atleast I have a base for my own work!!!
Thanks for this mod, will experience when the time comes
Jamie
Androrc the Orc
Emperor
Absolutely awesome! 
Originally I intended for the map to freeze, like you said, when you aren't playing it, and then to pick up where you left off upon return. But after thinking about it some more, it actually makes more sense to treat the other maps almost as colonies, controlled by some sort of governor system, on turns where you don't play them.
About switching between maps, I think I'm going to make it an XML option whether to switch between them at will (via a button on the interface) or to switch automatically on an event. This way each mod can use what suits it best.
Sir Spanky
Chieftain
- Joined
- Jun 22, 2009
- Messages
- 76
I was just thinking about something like this the other day but My idea was far more complex...
I wanted to have the original map squares to become regions and when entered they would open up there own map... so in theory even though you started 10 tiles from someone you are actually 10 maps away... makes the game much larger and a memory hog but that was my idea...
wishing you luck on this mod!
I wanted to have the original map squares to become regions and when entered they would open up there own map... so in theory even though you started 10 tiles from someone you are actually 10 maps away... makes the game much larger and a memory hog but that was my idea...
wishing you luck on this mod!
This would be very possible to do. In fact, I'm already working on something similar. Civilization Tactical Combat (see my sig) lets you resolve combat on a tactical battle map, which is essentially the battle plot zoomed in.
Expanding this to every tile would, like you said, make the game much larger. However, it wouldn't have to be a memory hog because A) the zoomed in maps would be a lot smaller than a normal map, and B) if there aren't any units currently on a tile, there would be no need to store that tile's map in memory. You could deallocate it, and then reallocate it whenever a unit moves there. Of course the major disadvantage to something like this is the time necessary to switch between maps. If you're doing it frequently, it could become very annoying.
That is essentially what Koshling is planning for C2C's Multi-Map implementation. It actually helps the memory somewhat, as the main Civ engine is very inefficent with graphics and the DLL can be highly optimized to use memory well.
daddyorion
Chieftain
- Joined
- Aug 28, 2008
- Messages
- 4
I yhope this mod works out well! I enjoy playing the C2C mod and the FF+ Mod, it takes me back to Civ2 TOT sifi mod, open a new tech and a new map is available. The C2C mod has all these future techs but no place to go with them. Lets get some place to go with it: space, Nona, Mars, Alpha Centari, Vega, or don't care, lets just gtet there.
I just wanted to drop by and mention that when I was much younger, I used to watch my dad and brother play Civ 2. They would occasionally try to describe the game to me, and when they told me about the space race victory, I thought it was the coolest thing ever that you could build a civilization from the ground up and then do it all over again on another planet; it wasn't until many years later that I actually played the Civ games and was crushed to find out that it doesn't work that way.
So basically what you did here is a giant leap towards achieving a childhood dream that I've nurtured for about 15 years now.
I actually made a mod in civ2 (Test of Times) where there were 4 maps : Normal, underwater (for subs) the sky (for planes) and the moon. It was doable because of a fantasy mod/scenario that was included.
Ok. Fairly major update just pushed to the SVN (parallel maps svn is at svn://svn.code.sf.net/p/parallelmaps/code/trunk for read access):
Viewports initial implementation complete.
This work leverages a lot of the multimap underpinnings (multimaps themselves are not yet complete however) to provide virtual maps which are viewports (windows if you like) into the underlying map (or maps once we have multimaps fully working).
The idea behind this is to increase (potentially significantly) the scalability of maps in Civ, since as far as the game engine is concerned the map is just the size of the viewport (graphically that is - the AI and so on still see the full map), so only graphical assets needed for that area are loaded (which should hopefully lead to very significant memory savings on large maps).
Each map can have one or more viewports associated with it (current demo just surfaces one, but the API supports an arbitrary number). At any one time, one of the viewports is the current viewport, and the current viewport of the current map is what get displayed. Obviously a UI is needed for switching/creating viewports, or at least moving the current one around wthin the larger underlying map. Long term my vision is to have a new advisor-like UI screen which gives an overview of viewports, which you define freely (so imagine having viewports for different theatres of war - say europe, north america, etc. on an earth map). You will have the ability to name viewports and switch between them by name, or of seeing them as outline overlays on a larger map of the entire planet and selecting by clicking.
In the current version I have seconded the military advisor to provide control over viewports. This works as follows:
If you want to try it out, grab the current contents of the 'assets' folder from the SVN and set it up within a test mod folder ('parallel maps' say). To just test out the viewports you'll need to make two changes to the XML (which I've left set up by default as multimaps ON, viewports OFF, so that it doesn't disturb Lytning's work on the multimaps). In Assets/xml is a file called 'ParallelMaps_GlobalDefines.xml'. This contains:
To get viewports without mutlimaps (which is basically what more or less works now) set ENABLE_MULTIMAPS to 0, and ENABLE_VIEWPORTS to 1. The viewport size settings can also be changed as you see fit, but see notes below.
Notes:
A good way to get a feel for it is to just start a new game with debug mode (chipotle) enabled, reveal the entire world (ctrl-Z), and then switch around, possibly adding a few units in in far flung places using world-builder so you can see how it behaves with units not all on the current viewport.
My next steps will be:
Viewports initial implementation complete.
This work leverages a lot of the multimap underpinnings (multimaps themselves are not yet complete however) to provide virtual maps which are viewports (windows if you like) into the underlying map (or maps once we have multimaps fully working).
The idea behind this is to increase (potentially significantly) the scalability of maps in Civ, since as far as the game engine is concerned the map is just the size of the viewport (graphically that is - the AI and so on still see the full map), so only graphical assets needed for that area are loaded (which should hopefully lead to very significant memory savings on large maps).
Each map can have one or more viewports associated with it (current demo just surfaces one, but the API supports an arbitrary number). At any one time, one of the viewports is the current viewport, and the current viewport of the current map is what get displayed. Obviously a UI is needed for switching/creating viewports, or at least moving the current one around wthin the larger underlying map. Long term my vision is to have a new advisor-like UI screen which gives an overview of viewports, which you define freely (so imagine having viewports for different theatres of war - say europe, north america, etc. on an earth map). You will have the ability to name viewports and switch between them by name, or of seeing them as outline overlays on a larger map of the entire planet and selecting by clicking.
In the current version I have seconded the military advisor to provide control over viewports. This works as follows:
- At game load (or new game start) the viewport will center on the initially active unit
- When you go into the military advisor the minimap there (the map in the advisor is just an instance of the minimap) will show the entire underlying map [not just the current viewport]. This is anyway necessary really, or else it would only tell you about that part of your military that happened to be within the current viewport, which is unlikely to be what you want
- Clicking on the map in the military advisor will set the main map viewing there (as it did before), and if that click was outside the current viewport it will also move the viewport to center on the point you clicked
If you want to try it out, grab the current contents of the 'assets' folder from the SVN and set it up within a test mod folder ('parallel maps' say). To just test out the viewports you'll need to make two changes to the XML (which I've left set up by default as multimaps ON, viewports OFF, so that it doesn't disturb Lytning's work on the multimaps). In Assets/xml is a file called 'ParallelMaps_GlobalDefines.xml'. This contains:
Code:
<?xml version="1.0"?>
<!-- Global Defines -->
<Civ4Defines xmlns="x-schema:CIV4GlobalDefinesSchema.xml">
<Define>
<DefineName>ENABLE_MULTIMAPS</DefineName>
<iDefineIntVal>1</iDefineIntVal>
</Define>
<Define>
<DefineName>ENABLE_VIEWPORTS</DefineName>
<iDefineIntVal>0</iDefineIntVal>
</Define>
<Define>
<DefineName>VIEWPORT_SIZE_X</DefineName>
<iDefineIntVal>50</iDefineIntVal>
</Define>
<Define>
<DefineName>VIEWPORT_SIZE_Y</DefineName>
<iDefineIntVal>50</iDefineIntVal>
</Define>
</Civ4Defines>To get viewports without mutlimaps (which is basically what more or less works now) set ENABLE_MULTIMAPS to 0, and ENABLE_VIEWPORTS to 1. The viewport size settings can also be changed as you see fit, but see notes below.
Notes:
- The switch into and out of the military advisor involves a virtual map switch, in order to change what the minimap used in the advisor displays. It thus takes the same amount of time (essentually) as a map switch does. This time is proportional to the area of the viewport, so smaller viewports result in faster switching. The 50 X 50 I have in the default XML is about 2 seconds for me, but your mileage may vary
- There are some bugs I'm still fighting the game engine over - occassionally (it's a bi erratic and I'v greatly redcued it, but not yet entirely eliminated it) you'll see the selected unit's selection highlight and/or its flag displace itself by a few tiles from the unit on switching back into the main map from the advisor. Clicking the unit (or clicking another one then back to it) resolves it, so it's just cosmetic (annoying though)
- Exiting the advisor by pressing escape does not work correctly right now. I still nee to fix that. Exiting by clicking the minimap or by pressing the 'Exit' button both should work ok
- Not really a viewports issue (more a multimap issue), but the settings you select for map script and map size are currently ignored, and are read from the MapInfos.xml file instead. The model for this will need to integrate better with the UI selectable map options, but that'll happen further down the road
- I have tweaked the selection group order for units (the order in which they select as you move them) to minimize viewport switching. It will cycle trhoguh tegh units that are in the current viewport first, and after there are none left there which require moving, will automatically select one not in the current viewport, and re-center the viewport there
A good way to get a feel for it is to just start a new game with debug mode (chipotle) enabled, reveal the entire world (ctrl-Z), and then switch around, possibly adding a few units in in far flung places using world-builder so you can see how it behaves with units not all on the current viewport.
My next steps will be:
- Fix the escape-to-exit-advisor bug
- Port what is done so far to C2C
- Make some memory usage measurements using mature save games from C2C on very large maps (GEM), to (hopefully) validate the memory savings
- Help Lytning as required with the other aspects of multimaps
j_mie6
Deity
uh..... wow
Similar threads
