C2C Graphics

No offense to DH, but yes i very much way more detailed terrain.

At the risk of being that guy, if less detailed terrain stops the game lagging in the middle stages, then let's go for it. We don't need a dozen other reasons for the game to lag, in addition to coding problems.
 
At the risk of being that guy, if less detailed terrain stops the game lagging in the middle stages, then let's go for it. We don't need a dozen other reasons for the game to lag, in addition to coding problems.
There isn't much VRAM to save here and I think the terrains should have a higher graphical quality than units/ improvement and buildings as they are always visible. The grass terrain graphic I uploaded a few posts ago is actually reduced in size from 1.5 MB to 940 KB compared to what C2C currently uses.

It is the models and unique textures to the immense amount of different units, improvements and buildings that should be optimized at the expense of detail.

100 Grass plots would probably only barely noticeable use more GPU resources than 1 grass plot; texture reuse scales well. while 2 stone spearman on two different tiles uses close to 2 times more GPU resources than 1 stone spearman due to the doubling of polygons on screen.
 
Fair enough then, I suppose.
 
100 Grass plots would probably only barely noticeable use more GPU resources than 1 grass plot; texture reuse scales well. while 2 stone spearman on two different tiles uses close to 2 times more GPU resources than 1 stone spearman due to the doubling of polygons on screen.

Then that seems to me for getting RID of quite a few units that Hydro put inplace, i dont like more than 1/2 of the early units anyways, also i see no use for them unless you play on any scale higher than Snail . . .
 
Then that seems to me for getting RID of quite a few units that Hydro put inplace, i dont like more than 1/2 of the early units anyways, also i see no use for them unless you play on any scale higher than Snail . . .
You misinterpret/overreact...
First off, the problem is not that bad, turn times and regular CPU dependent processes are not affected by models and textures already in use.
Having less units per era would only clear up some VRAM because there are less texture files loaded at the same time. There would still be the same amount of units on the map contributing to the total amount of polygons which is the main cause for map scrolling lag due to loading in these polygons.
Models are the main thing that is cleared from RAM through graphical paging; textures are mostly stored in VRAM which is probably not where our map-scroll lag bottleneck lies. Since RAM is used for regular processing the game stutters when the game loads in lots of models when scrolling the map. This is the small downside with graphical paging that is worth it due to saving a lot of RAM usage.

Secondly, most people have enough VRAM for the assets C2C uses today and with further optimizing of textures/models we are really inside what is acceptable.


I'm no expert so I might be wrong in some of the details, so take it with a bit of salt.

Edit: If you were thinking about the statement: "optimizing units at the expense of detail"; then it should be noted that this is what I did with most the units/animals I've remade; they have less polygons and smaller textures than what was.
 
Then that seems to me for getting RID of quite a few units that Hydro put inplace, i dont like more than 1/2 of the early units anyways, also i see no use for them unless you play on any scale higher than Snail . . .

Toffer is right about a lot. Though the 'scroll map bottleneck' is produced by our massively memory saving graphic tweak that Koshling put in place that's allowing many games to go a long ways beyond any need for multi-maps. Not exactly a bottleneck so to speak but a consequence of a much larger positive.

As for getting rid of units, there's another issue entirely. I'd be curious to discuss what units it is you'd like to suggest getting rid of as I see purpose behind most if not all units but I often see that purpose being less than perfectly utilized in the way the units are designed. I'm working on a pretty large unit review process so pinpointing what units people find useless and why could be useful.

Game time delays however primarily stem from inefficient AI. That has little to nothing to do with the amount of units that are defined. While it can have a lot to do with how many units are on the board, the really noticeable delays stem from the units that are struggling to figure out what they should do. Solving that would take some truly impressive programming skill. I don't think we have that skill on our team at this time. And very little we would try to do outside of that to improve things would likely be very successful at solving the issue but could well be successful at eroding a lot of the work we've done to enhance the game in general.
 
Figured out how to fix this old bug: 2015-10-12_00002.jpg

I first thought it was an issue with one of the heightmaps for hills but it turned out to be an interaction between river canyon heightmap interacting with the hills heightmap.

Rivers flattens out hills to create canyons, and the inland endpoint of rivers literary ripped the seams of the ground when hitting hills from certain sides.

This has bothered me a long time. I finally got enough when I today saw the elephant walking straight down into the hole with its face planted well underground and its tail pointing right up. :lol:


I think its best to not include this fix in v36 as I've no idea about the unforeseen implications of changing the river heightmap; it might be a more complex system than I realize.
 
What's the public opinion on these new lake shore textures?
2015-10-14_00001.jpg

Don't mind the odd symbols in the water; it's just something I use to orient where in a texture I need to make my changes from what I see in-game.

Other things:
Interesting tropical coast & sea interaction: 2015-10-14_00003.jpg
Looks like the inside of a crystal rock like an agate.

Deep coast has no beach, sharp transition from land to water 2015-10-14_00004.jpg
 
I think it looks fairly reasonable, yes.
 
I like the last one the best (for some reason looks like bluer water?
I went for strong colors for most water terrain due to your earlier comments on it. I personally like far less saturation in game colors but I can see the appeal of the opposite as well.

Good thing they are not mutually exclusive; all 3 of those pictures was taken on the same map without changing any textures or anything in the WB between the pictures.
Bad thing would be that it will be some time before maps are generated with the new deep coast that you like.
 
I went for strong colors for most water terrain due to your earlier comments on it. I personally like far less saturation in game colors but I can see the appeal of the opposite as well.

Good thing they are not mutually exclusive; all 3 of those pictures was taken on the same map without changing any textures or anything in the WB between the pictures.
Bad thing would be that it will be some time before maps are generated with the new deep coast that you like.

Yeah i like bluer stuff because it is more pleasant on the eyes, just like Microsoft usually has alot of BLUE themes and backgrounds that have them also.

But i believe if you look up water, it isnt really blue and either is the sky, but i might be wrong there, lol ..
 
Found a vanilla bug in terrain art define xml
This:
<TextureBlend10>2,0 6,90 10,0 14,90 18,0 22,90 26,0</TextureBlend10>
Should be like this:
<TextureBlend10>2,0 6,270 10,0 14,270 18,0 22,270 26,0</TextureBlend10>
For all water terrains.

It decides how much a texture partition should be rotated to fit with its surrounding terrains.
My changes to water textures enhanced the visibility of this bug. When you have two of the same water terrains in a diagonal and two Land terrains in the other diagonal one would see this bug as a bad fit between water and land in only one of the two combinations the diagonals can be in.
So I kept fixing it for one of them only to get the exact same bug when the land and water diagonals switched places. After having mirrored the relevant part of the texture 3 times I understood that something other than textures had to be wrong. lol.
 
in the 36 version the lake shore texture is all bugged and purple.

If you have a SVN copy, then more than likely you made changes on top of changes, and just need a NEW SVN copy is all, if just regular v36, then a bad copy and need a new d/l.
 
Top Bottom