Rebuilding parts of Civ4! Multithreading & 64bit memory access to increase Civ4's speed in large games?

for graphics you could ask tomekum
Click to expand...
Knowledge of modding the graphics is useful. That is at least knowledge of the file formats. And he's touched the L-System.
Or just use a modern engine
Click to expand...
It doesn't really matter. Write it all in raw GL/D3D11, or pick a graphics engine that loads quickly. Just draw bare meshes without lighting. A prototype doesn't need to be pretty. The difficult part is knowing what to draw. Plot building. Animate the NIF entities. The L-system. How is the coast put together. All these internal things that need to be figured out independently of graphics engine.

Somebody could start on this, without having the DLL running. Get this internal stuff figured out. Maybe get those NIFs loaded.

I might be crazy enough to get started with a TUI, but no way would I have time for full graphics as well.
 
<Nexus> said:
Oh, I love this sexy talk [pimp]

Yeah, Civ4 is probably one of the greatest thing holding me back from switching (or at least trying) to Linux. (I had to abandon Win7 recently and I still hate Win10)

With no programing skills I can only offer to help by beta testing (which I know is still far away) and I'm sure there are many others who would.
Click to expand...
Basic Wine runs Civ 4 pretty well, not to mention Steam's Proton thing. Though a native port even using vastly different graphics would greatly appeal to me...

Is the majority of the DLL game logic? Is there much Windows-specific stuff in there?
 
The most Windows specific thing is probably the assert dialog. And you've got things like wchar_t, __forceinline, maybe some of those stdio functions are MSVC specific.
 
snowern said:
It doesn't really matter. Write it all in raw GL/D3D11, or pick a graphics engine that loads quickly. Just draw bare meshes without lighting. A prototype doesn't need to be pretty. The difficult part is knowing what to draw. Plot building. Animate the NIF entities. The L-system. How is the coast put together. All these internal things that need to be figured out independently of graphics engine.

Somebody could start on this, without having the DLL running. Get this internal stuff figured out. Maybe get those NIFs loaded.
Click to expand...
Yeah the main issue is getting any modern engine to display the graphics. Everything else seems like it should be doable. Lots of "everything else" will not have to be clones of the civ4 engine and in fact a lot shouldn't be. Take for instance text. We should just make it support unicode by default rather than using the Microsoft page system.

snowern said:
The most Windows specific thing is probably the assert dialog. And you've got things like wchar_t, __forceinline, maybe some of those stdio functions are MSVC specific.
Click to expand...
Possibly DllExport too. I was told I did something, which isn't allowed under C++03 and Microsoft added it in some MSVC extension. However C++ added it in a later version, so stating what is specific to MSVC in vanilla is kind of an open question and it depends on which version of C++ the compiler is for. We do however have a fairly easy way to deal with it: if/when we have an engine, just compile the dll for linux and fix every single reported error. I suspect fixing what was allowed in C++03, but isn't in modern C++ is more of an issue and yet that's still minor compared to making a new engine.

One thing to point out is that when civ4 was written, there was two xml schema formats fighting to be "the best". One won and the other died and lost software support. This means we would likely have to write our own schema evaluation if we want to stick with existing schemas. That's less of a task compared to what it sounds like because this ancient xml schema system is fairly simple, at least the part used by vanilla.
 
We should just make it support unicode by default rather than using the Microsoft page system.
Click to expand...
One of those things I'd love to do. Rip out Cv(W)String. And wchar_t. *And use std::string for UTF-8.

I'm currently using TinyXML2. So, I'm basically plopping whatever codepage into wchar_t I assume. Will have to be corrected at some point.

But, wchar_t will have to stick around in some places for save file compatibility. Maybe as char16_t. Actually, definitely as char16_t, for Linux.
 
Last edited:
You must log in or register to reply here.
Top Bottom