Civilization IV is in GOG.com

[Thunderbrd]

And here I thought civ IV in it's entirety was programmed as single core code, how do you know it's not, or as you put it, that it's "well written"?

He means that some declarations of variables would cost more memory than necessary in a 64 bit environment. I doubt it would end up problematic as we need to overcome overflows more often than limit the data to eliminate waste, particularly if we're working in a less ram constrictive environment.

 

[Toffer90]

"Communication breakdown, it's always the same!" -Led zeppelin
^^

 

[Nightinggale]

He means that some declarations of variables would cost more memory than necessary in a 64 bit environment. I doubt it would end up problematic as we need to overcome overflows more often than limit the data to eliminate waste, particularly if we're working in a less ram constrictive environment.

I wasn't talking about memory usage and wasting memory. It might be a minor performance issue due to having less variables in the CPU cache, but that's about it. Modern optimization and modern CPU features will have a bigger impact on performance, which in turn will make the game run faster overall.

The problem is that people have been creative in order to save memory. For instance say we have 2 16 bit variables. If we need to store a point, it can be done by overwriting those as the pointer is 32 bit. Changing the compiler to make the pointers 64 bit will cause that code to overwrite the two 16 bit variables and whatever is in the next 32 bit. It's horrible coding practice, but is the main reason why moving from 32 to 64 bit won't always just work. If you need to use the same memory for multiple variables, use a union and you will avoid this problem.

 

[Thunderbrd]

The problem is that people have been creative in order to save memory. For instance say we have 2 16 bit variables. If we need to store a point, it can be done by overwriting those as the pointer is 32 bit. Changing the compiler to make the pointers 64 bit will cause that code to overwrite the two 16 bit variables and whatever is in the next 32 bit. It's horrible coding practice, but is the main reason why moving from 32 to 64 bit won't always just work. If you need to use the same memory for multiple variables, use a union and you will avoid this problem.

On this point I'm following you theoretically but can't think of a point in our current code that you would be referring to. Can you provide an existing coded example?

 

[Nightinggale]

On this point I'm following you theoretically but can't think of a point in our current code that you would be referring to. Can you provide an existing coded example?

I don't think the DLL has code like that at all. However that's not the same as the exe is free of such code and moving to 64 means all code has to be ready for 64 bit, including the exe. My main point is that good code can be compiled to 64 bit without issues, but it is possible to write code, which only works on 32 bit systems. As a result, moving to 64 bit can be anything from trivial to a major task and we can't assume anything about that for the exe, simply because we don't know the code.

 

[Thunderbrd]

I don't think the DLL has code like that at all. However that's not the same as the exe is free of such code and moving to 64 means all code has to be ready for 64 bit, including the exe. My main point is that good code can be compiled to 64 bit without issues, but it is possible to write code, which only works on 32 bit systems. As a result, moving to 64 bit can be anything from trivial to a major task and we can't assume anything about that for the exe, simply because we don't know the code.

Ah... got it. That's why it was hard to envision what you were explaining. Sadly all I know about coding is from examples in the DLL.