Azurian
The Azurian
Yes I'll do the Art and Pedia
C2C SVN Changelog
- Thread starter Dancing Hoskuld
- Start date
Faustmouse
Deity
- Joined
- Jan 31, 2012
- Messages
- 3,524
Thanks!
New Buildings
Liquid Metals Foundry
Shockwave Engine Factory
Microgenerator Factory
Nanogenerator Factory
Novus Refinery
Superstrong Alloy Foundry
Antigrav Generator Factory
Cybernetic Chloroplast Factory
Neuroinduction Field
Genetica Apparel Shop
Holographica Apparel Shop
Cybernetica Apparel Shop
Neon Boutique
Bioluminescent Boutique
Photosynthesis Boutique
Dattoo Parlor
Genetica Salon
Cybernetica Salon
New Buildings
Liquid Metals Foundry
Shockwave Engine Factory
Microgenerator Factory
Nanogenerator Factory
Novus Refinery
Superstrong Alloy Foundry
Antigrav Generator Factory
Cybernetic Chloroplast Factory
Neuroinduction Field
Genetica Apparel Shop
Holographica Apparel Shop
Cybernetica Apparel Shop
Neon Boutique
Bioluminescent Boutique
Photosynthesis Boutique
Dattoo Parlor
Genetica Salon
Cybernetica Salon
strategyonly
C2C Supreme Commander
Turned down the volume of the Tech Tracking, it was scaring alot of people when they are playing it was so loud, LOL
added missing artdefines schema for Buffalo Hump, thx Koshling
added missing artdefines schema for Buffalo Hump, thx Koshling
Hydromancerx
C2C Modder
Updates
- Applied the new resources to Gravity Traps, Metamateral Walls, Superstrong Alloy Walls, Megastrong Allow Walls and Anti-Matter Battery.
- Applied the new resources to Gravity Traps, Metamateral Walls, Superstrong Alloy Walls, Megastrong Allow Walls and Anti-Matter Battery.
Hydromancerx
C2C Modder
Updates
- Fixed an error in Fautmouses files that was causing the pedia to cut off at Lime Orchards. It was apparently a missing S in BOPNUS_WARES_METAMATERALS resource.
- Fixed an error in Fautmouses files that was causing the pedia to cut off at Lime Orchards. It was apparently a missing S in BOPNUS_WARES_METAMATERALS resource.
Just pushed to SVN (6059):
After some experimentation I discovered that most of the (graphical) memory usage on large, well-revealed maps is down to feature/route/river/improvement display (without these many more plots are identical to one another, and the game engine does seem to optimize that case). Obviously it's of no use to just not display those things, but I have been able to turn them on and off dynamically on a plot by plot basis. Coupling that with some rules about which plots need to show them (i.e.- those you can see on your screen pretty much, since they do not impact the minimap) I have been able to get a very large memory reduction (depending on exact settings MORE saving than you typically get with viewports).
For the test game I was measuring on (industrial era large map, all explored, 20 or so civs) process memory usage dropped from almost exactly 2G (previous SVN) to roughly 1.4G (new version).
There is NO functional compromise to gameplay as there is with viewports (so the entire map is always visible, things will auto-center on events, etc.) - the only cost is a slight delay rendering the terrain details when you scroll or minimap-click to a different part of the map (much faster than a viewport switch). This can be mitigated by judicious settings (see below).
The rules it uses to display terrain details or not bother to, are set by two integer parameters, currently defined in assets/xml/A_New_Dawn_GlobalDefines.xml, as follows:
GRAPHICAL_DETAIL_PAGE_IN_RANGE - the range (from the center of the screen, in plots) for which tiles will be rendered in full detail
GRAPHICAL_DETAIL_PAGE_OUT_RANGE - the range (from the center of the screen, in plots) for which previously fully-detailed plots will revert back to the un-detailed form (that just shows the base terrain and hills/mountains).
The latter should always be at least as much as the former.
The values currently set in the SVN are 256 for both. Since this is larger than any possible map dimensions the effect is to fully render the details of all plots, effectivelty disabling the mechanism by default.
If you want to turn it on and try it out, set them to much lower values (at a res of 1600X1050 I found 8 and 15 worked well). Smaller values will result in greater memory saving. The guidelines for setting the values are:
GRAPHICAL_DETAIL_PAGE_IN_RANGE should normally be enough to cover the entire screen - so enough that twice the value is the entire horizontal size at the resolution you play at, when scrolled out to just before the view goes into 'obscured by clouds mode'. If it's that big then all plots you can see should always render at full detail.
GRAPHICAL_DETAIL_PAGE_OUT_RANGE should normally be a bit bigger - the idea here is that if you are working in a small area (say managing your core cities, or working on an invasion of some smaller landmass) then as you make small movements to scroll the map around that limited area, you don't want the scrolling to stutter as the game is forced to re-render plots at the edge of the 'page_in' boundary - making the page_out boundary larger achieves this by not paging them out until you move the view significantly further away.
I strongly encourage anyone who has been forced to use viewports due to memory constraints, to try this new system and feedback to me on any bugs, or other weaknesses you find. GEM players should typically NOT need viewports if using this system with the kind of setting I suggest above (8,15)
- New approach to memory reduction, largely removing the need to use viewports
After some experimentation I discovered that most of the (graphical) memory usage on large, well-revealed maps is down to feature/route/river/improvement display (without these many more plots are identical to one another, and the game engine does seem to optimize that case). Obviously it's of no use to just not display those things, but I have been able to turn them on and off dynamically on a plot by plot basis. Coupling that with some rules about which plots need to show them (i.e.- those you can see on your screen pretty much, since they do not impact the minimap) I have been able to get a very large memory reduction (depending on exact settings MORE saving than you typically get with viewports).
For the test game I was measuring on (industrial era large map, all explored, 20 or so civs) process memory usage dropped from almost exactly 2G (previous SVN) to roughly 1.4G (new version).
There is NO functional compromise to gameplay as there is with viewports (so the entire map is always visible, things will auto-center on events, etc.) - the only cost is a slight delay rendering the terrain details when you scroll or minimap-click to a different part of the map (much faster than a viewport switch). This can be mitigated by judicious settings (see below).
The rules it uses to display terrain details or not bother to, are set by two integer parameters, currently defined in assets/xml/A_New_Dawn_GlobalDefines.xml, as follows:
GRAPHICAL_DETAIL_PAGE_IN_RANGE - the range (from the center of the screen, in plots) for which tiles will be rendered in full detail
GRAPHICAL_DETAIL_PAGE_OUT_RANGE - the range (from the center of the screen, in plots) for which previously fully-detailed plots will revert back to the un-detailed form (that just shows the base terrain and hills/mountains).
The latter should always be at least as much as the former.
The values currently set in the SVN are 256 for both. Since this is larger than any possible map dimensions the effect is to fully render the details of all plots, effectivelty disabling the mechanism by default.
If you want to turn it on and try it out, set them to much lower values (at a res of 1600X1050 I found 8 and 15 worked well). Smaller values will result in greater memory saving. The guidelines for setting the values are:
GRAPHICAL_DETAIL_PAGE_IN_RANGE should normally be enough to cover the entire screen - so enough that twice the value is the entire horizontal size at the resolution you play at, when scrolled out to just before the view goes into 'obscured by clouds mode'. If it's that big then all plots you can see should always render at full detail.
GRAPHICAL_DETAIL_PAGE_OUT_RANGE should normally be a bit bigger - the idea here is that if you are working in a small area (say managing your core cities, or working on an invasion of some smaller landmass) then as you make small movements to scroll the map around that limited area, you don't want the scrolling to stutter as the game is forced to re-render plots at the edge of the 'page_in' boundary - making the page_out boundary larger achieves this by not paging them out until you move the view significantly further away.
I strongly encourage anyone who has been forced to use viewports due to memory constraints, to try this new system and feedback to me on any bugs, or other weaknesses you find. GEM players should typically NOT need viewports if using this system with the kind of setting I suggest above (8,15)
Faustmouse
Deity
- Joined
- Jan 31, 2012
- Messages
- 3,524
Yes, I intend to once Ive had feedback from testing. It's not impossible that testing will reveal some gotcha that renders it inoperable, so I felt it was premature to expose it to people other than a few testers yet.
strategyonly
C2C Supreme Commander
Fixed SUPERSTRONG_ALLOY_FOUNDRY
was
BONUS_WARES_TITANIUM
fixed to
BONUS_WARE_TITANIUM
was
BONUS_WARES_TITANIUM
fixed to
BONUS_WARE_TITANIUM
Il Principe
Prince
Does this stack with viewports? Like using 8/15 like you suggested for your new trick, and a viewport of like.. 80x80 or 100x100 togehter for the real big maps?
would that make sense or is the memory used on base terrain outside your new 15 range radius so insignificant that stacking a viewport on top of that is pointless?
For most purposes it replaces viewports. There will be SOME gain from using them together as you suggest, but 90% of the gain will come from the new technique alone. I don;t recommend combining them unless you find you need to (which I very much doubt unless you have a really extreme case)
Just pushed to SVN (6062):
I have also re-organized the general options page a little to make things a bit clearer, and added an over-riding 'enable' checkbox for the paging of graphics. This allows me to set the default ranges to sensible values (8,15), so that most users can just use the checkbox to turn it on/off, and not have to worry about tuning the values.
Note - it also reacts to changes dynamically. It does not require a restart for them to take effect as viewport changes do.
- Fixed loss of plot yields (if displayed) on map scrolling when using paged graphics
- Moved config of paged graphics into the BUG options
I have also re-organized the general options page a little to make things a bit clearer, and added an over-riding 'enable' checkbox for the paging of graphics. This allows me to set the default ranges to sensible values (8,15), so that most users can just use the checkbox to turn it on/off, and not have to worry about tuning the values.
Note - it also reacts to changes dynamically. It does not require a restart for them to take effect as viewport changes do.
JosEPh_II
TBS WarLord
+1
JosEPh
With SVN updates on graphics paging every unit currently on screen redraws when I select any unit. If there is enemy units around they also produce sound which usually played when enemy unit becomes visible. And these effects occur many times during enemy turn (I have 'minimize AI turns' switched off). Very annoying.
All that happens even when 'Enable graphics paging' switch is turned off.
All that happens even when 'Enable graphics paging' switch is turned off.
Which SVN we you last using (if you recall) before this started happening? Can you think of anything that might be unusual aout your setup? It seems especially strange that it happens regardless of whether paging is on or off. Also hard to see why clicking a unit (that is already in view) should cause anything. I presume viewports are off?
The audio aspect cold easily be something I missed through, as I don't play with game sound on (so ill see if I can reproduce that tomorrow).
If you have a save that reliably reproduces this behaviour could you post it please, together with details of any settings you think might be relevant, including the resolution you have the game set to (and whether its windowed or full screen).
With SVN 6058 all is fine. For now I reverted changes from revisions 6059 and 6062 in my local copy and there is no redrawing. I play in windowed mod with custom resolution 1750x1000. Other than that can't think of anything unusual. Will try fullscreen (1920x1080) and post savegame later.
Did you try the version that had the mechanism in, but without the BUG settings (ie - the version that was all mediated via global defines)? If so did that version exhibit this behavior?
What map size are you using? Does it wrap horizontally? Vertically?
