32 bit vs 64 bit and dx10 vs dx 11 limitations

I'm sure you won't need that much RAM for your standard-sized maps - they should run fine on commodity hardware. But if it's possible to heavily scale up the size of maps, the larger amounts of addressable memory should prove a great benefit for those wishing to play such gigantic maps. Civ4 very much ran into issues in the memory area on very large maps, rendering its de jure support for larger maps and more cities than Civ3 moot.

I'm glad to hear that 64-bit is official - somehow I missed that news for a whole month! If Civ5 does prove to be an excellent game, I just might have to upgrade to 6GB of RAM and XP 64-bit, perhaps even a better CPU for the most epic maps. The graphics I'm pretty indifferent to - running DX9 on DX10 hardware is more than good enough for me if the strategy element is good.

edit: I doubt there will be a requirement to have a 64-bit system to play really big maps, but if you don't have a 64-bit system and you try to play a Super-Amazingly-Enormous size map, you might well run into Memory Allocation Failures (MAFs) or the like, just as in Civ4. Graphics-settings-wise, you probably would be able to play with the highest settings on a Tiny map with 1.5 GB RAM if you wanted to and had a good enough graphics card.

I really don't see this as a legitimate use of memory. The entire game design (tiles, units, etc.) lends itself extremely well to the reuse of resources. Unless you're talking about allowing games with millions of tiles, you'd probably run into other limitations before 2GB of RAM would hold you back.

The PS3 gets away with 256MB of RAM, after all.
 
Check out this thread for links to the Firaxis/Intel presentation at GDC this year. They aren't allocating memory anymore :)

They specifically note that most machines will run Civ V better than they ran Civ IV.
 
I really don't see this as a legitimate use of memory. The entire game design (tiles, units, etc.) lends itself extremely well to the reuse of resources. Unless you're talking about allowing games with millions of tiles, you'd probably run into other limitations before 2GB of RAM would hold you back.

The PS3 gets away with 256MB of RAM, after all.

Comparing a Console to a PC is ridiculous, they are all identical except for the HDD volume, with the exact same processor (well, except for die shrink) and GPU they can be exploited to their maximum, something you can't do with PCs
 
If Civ V is specifically designed for 64-bit (in other words, requiring more than 2GB of RAM) it will be suicide for Firaxis. That will cut out a huge percentage of their customers. On the other hand, if the game is 64-bit capable but does not require all that much RAM there will be little benefit to it.

This is the dilemma of 64-bit. To get the greatest benefit out of it you need to find a way to use all that RAM. You also don't want to leave money on the table.

You will learn about the benefits of being able to adress and make use of more RAM as soon as the first modifications with bigger maps, more content, more units, more nations will be released by the modding community.

Therefore, providing a 64bit-version is a very reasonable thing.
 
maybe I'll finally be able to make use of all my 6gb RAM for once. I'll be using the 64 bit version.
 
The big thing about 64 bit for a game like Civ is the higher RAM support.

Civ IV couldn't use over 2GB of RAM. It will allow for bigger maps.
 
Time to show my ignorance :dunno:...because this has always confused me...

A Gigabyte is an enormous amount of storage and something about the calculation of how much storage a map should use doesn't make sense to me.

As I see it there are three categories of objects that will typically scale with the map size: tiles, units and cities, (perhaps the # of civs will affect this too, but I vaguely recall that civ related arrays always have 18 slots so maybe there is no variation)

In Civ4, a tile will have state like terrain type, river existence, tile improvements, turns to chop, turns to cottage growth, isIrrigated, culture (per Civ), a list of units present (a vector?), visual state such as which tile graphic to show, etc. Seriously how much data can this be? 1000 bytes seems like it should be a very high estimate...but at that level a huge Terra map (about 15,000 tiles) uses only 15Mb for tile related state.
Similar estimates for city and unit state turn out equally low totals, 50Mb total feels like a high number based on a rough estimate of state.

Obviously the OS and Civ4's exe/dll and global state take up additional memory; however, even accounting for those, I'm still left with an estimate for RAM use that is more than an order of magnitude lower than reality...So...what is using all the RAM???

My understanding of how 3d graphics stresses memory use is where I suspect I am missing something. (I'm struggling with the fact that a console, for example, only has 512Mb RAM total (core+gfx) but manages 'pretty good' 3d graphics.) Is there some graphical state data that chews up the RAM such as caching of each tile's graphics?...but isn't that what the Gfx card memory is for?

I don't like being ignorant :( can anyone help me understand this?
Thanks.
 
Time to show my ignorance :dunno:...because this has always confused me...<snip>

Indeed, this is an interesting topic.

It always baffles me when you enter the age of map trading in Civ4 (playing on real big [modified] maps), you are trading maps and in the same moment the game almost collapses - especially when the human player acquires new maps.

To me it looks like there is something like "nation-specific" maps, which of course wouldn't make any sense at all.

But maybe we have some guys here who have explored the secrets of map-related RAM-usage and will enlighten us?
 
Comparing a Console to a PC is ridiculous, they are all identical except for the HDD volume, with the exact same processor (well, except for die shrink) and GPU they can be exploited to their maximum, something you can't do with PCs

How is it not comparable? Consoles are largely made up of PC parts. There are a lot of programming techniques that can be applied to any platform. A lot of game engines run on all console platforms including the PC. One such example of a super memory efficient technology that works on all platforms is Megatexturing. With Megatexturing you can take advantage of massive multi-gigabyte textures for nearly infinite detail while using around 14MB of texture memory.
 
Can a modder tell me if a mod for the 64 bit version will work on the 32 bit version? Or will all the mods still be done for the 32 bit version?
 
We don't know everything about modding Civ5 clearly, but if the mod is just XML/LUA then it is unlikely to be dependent on processor architecture.
However if it includes DLL changes similar to those possible in Civ4 then the DLL may have to be built twice, once for 32-bit and once for 64-bit.
In most cases, assuming all the necessary files are provided for both targets, this will be a simple case of recompiling for a new target env.

How this will work in terms of distributing the mod is anyone's guess!
 
Time to show my ignorance :dunno:...because this has always confused me...

A Gigabyte is an enormous amount of storage and something about the calculation of how much storage a map should use doesn't make sense to me.

As I see it there are three categories of objects that will typically scale with the map size: tiles, units and cities, (perhaps the # of civs will affect this too, but I vaguely recall that civ related arrays always have 18 slots so maybe there is no variation)

In Civ4, a tile will have state like terrain type, river existence, tile improvements, turns to chop, turns to cottage growth, isIrrigated, culture (per Civ), a list of units present (a vector?), visual state such as which tile graphic to show, etc. Seriously how much data can this be? 1000 bytes seems like it should be a very high estimate...but at that level a huge Terra map (about 15,000 tiles) uses only 15Mb for tile related state.
Similar estimates for city and unit state turn out equally low totals, 50Mb total feels like a high number based on a rough estimate of state.

Obviously the OS and Civ4's exe/dll and global state take up additional memory; however, even accounting for those, I'm still left with an estimate for RAM use that is more than an order of magnitude lower than reality...So...what is using all the RAM???

My understanding of how 3d graphics stresses memory use is where I suspect I am missing something. (I'm struggling with the fact that a console, for example, only has 512Mb RAM total (core+gfx) but manages 'pretty good' 3d graphics.) Is there some graphical state data that chews up the RAM such as caching of each tile's graphics?...but isn't that what the Gfx card memory is for?

I don't like being ignorant :( can anyone help me understand this?
Thanks.
In Civ IV what happens is the processes use RAM (normally not that much) and the system stops using the RAM when it finishes, but in some places it forgets to release this memory, so that RAM stays in use, the more things you have the more possible places this happen, so the bigger it is the faster it runs out of RAM
How is it not comparable? Consoles are largely made up of PC parts. There are a lot of programming techniques that can be applied to any platform. A lot of game engines run on all console platforms including the PC. One such example of a super memory efficient technology that works on all platforms is Megatexturing. With Megatexturing you can take advantage of massive multi-gigabyte textures for nearly infinite detail while using around 14MB of texture memory.
every architecture is different and has it's strengths and weaknesses, in the consoles case they all use PPC architecture giving them different strengths and weaknesses, when the transfer games to console or vice-versa they recompile it. Console CPUs&#8800;PC CPUs
 
In Civ IV what happens is the processes use RAM (normally not that much) and the system stops using the RAM when it finishes, but in some places it forgets to release this memory, so that RAM stays in use, the more things you have the more possible places this happen, so the bigger it is the faster it runs out of RAM

every architecture is different and has it's strengths and weaknesses, in the consoles case they all use PPC architecture giving them different strengths and weaknesses, when the transfer games to console or vice-versa they recompile it. Console CPUs&#8800;PC CPUs

Non-sequitur. The CPU architecture has nothing to do with having good or bad coding practices. Intel-based CPUs are every bit as capable of having memory efficient games as PPCs.
 
In Civ IV what happens is the processes use RAM (normally not that much) and the system stops using the RAM when it finishes, but in some places it forgets to release this memory, so that RAM stays in use, the more things you have the more possible places this happen, so the bigger it is the faster it runs out of RAM
Yeah I'm aware of this and it explains the creep that occurs as the game is played
but the initial game load is about 200Mb to the start menu and a further 500Mb to a total of 700Mb when starting a game on a huge Terra Map. This is before there are any units or cities etc.
It's that 500Mb which grows to 1500Mb+ late game, when you initially load the game before the memory leaks get to work, that I am curious about.
 
Yeah I'm aware of this and it explains the creep that occurs as the game is played
but the initial game load is about 200Mb to the start menu and a further 500Mb to a total of 700Mb when starting a game on a huge Terra Map. This is before there are any units or cities etc.
It's that 500Mb which grows to 1500Mb+ late game, when you initially load the game before the memory leaks get to work, that I am curious about.

It's a simple example of the over-reliance and misuse of object-oriented frameworks and high-level scripting languages. Data structures that would seem to require very small amounts of memory get blown way out of proportion when every little piece of data is made into an object. Large amounts of unnecessary highly general code bloats everything up.

To make a tight, efficient game you need to spend a lot of time thinking about how to reuse memory and how to structure your data as efficiently as possible and defer loading of resources until absolutely necessary. This is something few PC developers care about enough to devote the necessary time.
 
In this day and age it is the time factor. Less time spent = more profit.

Consoles also represent proprietary effeciency. Everything is streamlined for one company's use and the bugs are hopefully worked out of the system before it goes to market as opposed to a PC that has a zillion flavors.
 
To make a tight, efficient game you need to spend a lot of time thinking about how to reuse memory and how to structure your data as efficiently as possible and defer loading of resources until absolutely necessary. This is something few PC developers care about enough to devote the necessary time.

This is something virtually nobody cares about. I'm a sophomore CS major and memory management hasn't even been mentioned, except in explaining why destructors are needed when pointers are used. What is stressed is reusing code, which is why everything is made into an object.
 
This is something virtually nobody cares about. I'm a sophomore CS major and memory management hasn't even been mentioned, except in explaining why destructors are needed when pointers are used. What is stressed is reusing code, which is why everything is made into an object.

And garbage game engines (like gamebryo) are the result.
 
This is something virtually nobody cares about. I'm a sophomore CS major and memory management hasn't even been mentioned, except in explaining why destructors are needed when pointers are used. What is stressed is reusing code, which is why everything is made into an object.

As with most things there is a balance to be struck. The pendulum will eventually swing back the other way.

When I first started coding (370 Assembler) the IBM mainframe had an address space limit of 16Mb (basically per process) and the system I worked on could support thousands of connected terminals (3270 Screens, ATMs and other more esoteric devices) processing hundreds of isolated transactions per second.
Memory management was a huge component of getting that to happen.
 
It's a simple example of the over-reliance and misuse of object-oriented frameworks and high-level scripting languages. Data structures that would seem to require very small amounts of memory get blown way out of proportion when every little piece of data is made into an object. Large amounts of unnecessary highly general code bloats everything up.

To make a tight, efficient game you need to spend a lot of time thinking about how to reuse memory and how to structure your data as efficiently as possible and defer loading of resources until absolutely necessary. This is something few PC developers care about enough to devote the necessary time.

And that's exactly why console games flourish
 
Back
Top Bottom