Lutger wrote:
> Bill Baxter wrote:
>  > With a tight schedule, a good strategy is to not waste time optimizing
> 
>> any one particular thing until you *know* it is a bottleneck.  Game developers tend to be pretty ruthless in applying this principle.  For the Civ4 SDK, something that will only be used directly by a tiny fraction of Civ4 users, there's just not a lot of bottom line justification for putting resources there, when compared to say fixing a crash bug that 10% of players are likely to encounter.
>>
>> So yeh, that's why folks like the Civ team and the folks behind Eve Online are willing to go with Python.  For most things Python is fast enough, and gets the job done much more quickly than C++.  For the small fracton of the code where it's not fast enough, you can always re-write those bits in C and call it from Python.
>>
>> --bb
> 
> 
> Civilization 4 is structured in roughly 4 layers:
> 1. core engine build on gamebryo (C++) - closed source
> 2. core game logic (120K LoC, a C++ DLL) - open source
> 3. python scripting (game logic, ui, terrain generation, etc.)
> 4. xml data (static data)
> 
> The C++ SDK is layer 2, so this affects all users. I don't know where bottlenecks lie here, but I suspect it is in 1 or 2.
> 
> I'm not sure (nobody is as it hasn't happened yet), but I wouldn't be surprised that if these parts of a large game are written in D performance will go up instead of down, even if the D compiler doesn't optimize as well as a good C++ compiler. For this kind of application I can't believe a little slower floating point calculation will matter as much as ease of high level design and maintenance optimizations.

Just to be clear I don't think floating point performance is going  to make a lick of difference in a game like Civ4.  It's only going to even have a chance of being a factor in a game that does massive amounts of realistic physics and accurate 3D collision detection.  Hmm and 3D character animation -- that's pretty heavy on the fpu too.

--bb

Lutger wrote:
> But they are on a tight schedule too and it must be a complex ordeal. I image doing something like this in D saves so much time and complexity, that alone might enable developers to implement higher performance applications. For the most annoying problems with performance in the games I play are due to 'bugs' or design-level bottlenecks it seems, and they are usually patched some months after the release - if you're lucky.

That's something I discovered, too. While D's optimizer is not as good as some C++ optimizers, D source code is much more flexible than C++'s. Hence, it is much easier to adjust the algorithm for better speed.

And this is why D code is often able to outperform heavily micro-optimized C++.