🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: comp.sys.ibm.pc.games.strategic
29 messages
29 total messages Started by Jim Fri, 07 May 2010 21:45
Civ5 Steam and preoder bonus
#715820
Author: Jim
Date: Fri, 07 May 2010 21:45
3 lines
1492 bytes
http://www.shacknews.com/onearticle.x/63665
Digital Deluxe Edition gets the Babylon civ and preorderers get Cradle of 
Civilization Map Pack: Mesopotamia.
Civ V - It better not be slow and based on Python, Ruby or other crap languages
#715821
Author: Martin Wallinson
Date: Wed, 12 May 2010 04:25
23 lines
2434 bytes
When I bought Civ IV, it was the first worthy successor to the
original Civ, but I had to wait many years after purchasing to play it
due to the shitty Python language implementation.  Slow as molasses on
the PC I had at the time (I dont mean animation speeds, I mean AI
calculations).

Fortunately I now have a very fast PC to play it on, but of course
Python and most other open source langs sucks cocks at multithreading
so it does not take full advantage of it.  It's more than fast enough
to play.

But the real lesson I learned is that 4.5 years later, I can get the
whole thing with all expansion packs for 10 bucks off Steam. So I'm
not preordering.  In fact, I will watch reviews first and if it does
not perform on a par with other games (most of which are WAY more
computationally demanding) on my machine, I will simply continue on
with Civ IV for another few years, and play Civ V when hardware
catches up with slow shitty script kiddie code.

Hey Sid if you don't want to code in a real language, farm it out to
someone who will.  Just playing the design role of the game you'll do
well enough.  
Re: Civ V - It better not be slow and based on Python, Ruby or other crap languages
#715822
Author: Tim Skirvin
Date: Wed, 12 May 2010 06:30
11 lines
1563 bytes
Martin Wallinson <mwal2362@gmail.com> writes:

> [...] but of course Python and most other open source langs sucks cocks
> at multithreading so it does not take full advantage of it.

        *snicker*  This is going to be a fun flamewar.

                           - Tim Skirvin (tskirvin@killfile.org)
-- 
http://wiki.killfile.org/           Skirv's Homepage <FISH>< <*>
http://wiki.killfile.org/personal/history/       Skirv's History 
Re: Civ V - It better not be slow and based on Python, Ruby or other crap languages
#715823
Author: MetalGuru
Date: Wed, 12 May 2010 09:31
11 lines
1809 bytes
"Tim Skirvin" <tskirvin@killfile.org> wrote
> Martin Wallinson <mwal2362@gmail.com> writes:
>
>> but of course Python and most other open source langs sucks cocks
>> at multithreading so it does not take full advantage of it.
>
>  *snicker*  This is going to be a fun flamewar.

Wait until he gets a load of Armageddon Empires or Solium Infernum from 
Cryptic Comet - darn things were done with Macromedia Director or some crap 
like that.  Both great game designs, but awful everything else. 
Re: Civ V - It better not be slow and based on Python, Ruby or other crap languages
#715831
Author: Stuffed Crust
Date: Wed, 12 May 2010 14:42
13 lines
1636 bytes
Martin Wallinson <mwal2362@gmail.com> wrote:
> Hey Sid if you don't want to code in a real language, farm it out to
> someone who will.  Just playing the design role of the game you'll do
> well enough.  

Yaeh, Sid had better not use C++ the next time around.  Look where that got him 
with Civ4.

 - Solomon
-- 
Solomon Peachy        		       pizza at shaftnet dot org	 
Melbourne, FL                          ^^ (mail/jabber/gtalk) ^^
Quidquid latine dictum sit, altum viditur.
Re: Civ V - It better not be slow and based on Python, Ruby or other crap languages
#715830
Author: gumby
Date: Wed, 12 May 2010 16:53
6 lines
1477 bytes
On 11/05/2010 9:25 PM, Martin Wallinson wrote:
>
> When I bought Civ IV, it was the first worthy successor to the
> original Civ,

BS, CivII was a very good game and worthy successor.
Re: Civ V - It better not be slow and based on Python, Ruby or other crap languages
#715832
Author: Martin Wallinson
Date: Wed, 12 May 2010 23:14
14 lines
1748 bytes
On 12 May 2010 14:42:14 GMT, Stuffed Crust <pizza@spam.shaftnet.org>
wrote:

>Martin Wallinson <mwal2362@gmail.com> wrote:
>> Hey Sid if you don't want to code in a real language, farm it out to
>> someone who will.  Just playing the design role of the game you'll do
>> well enough.  
>
>Yaeh, Sid had better not use C++ the next time around.  Look where that got him 
>with Civ4.

What a dipshit

http://civilization4.net/files/modding/PythonAPI/
Re: Civ V - It better not be slow and based on Python, Ruby or other crap languages
#715846
Author: David Lamb
Date: Wed, 12 May 2010 23:14
6 lines
1245 bytes
Martin Wallinson wrote:
> I had to wait many years after purchasing to play it
> due to the shitty Python language implementation.  

The core is C++.  Python was apparently used to make it easier for fans 
to mod the game.
Re: Civ V - It better not be slow and based on Python, Ruby or other crap languages
#715847
Author: Martin Wallinson
Date: Wed, 12 May 2010 23:17
14 lines
1948 bytes
On Wed, 12 May 2010 19:14:56 -0400, David Lamb <dalamb@cs.queensu.ca>
wrote:

>Martin Wallinson wrote:
>> I had to wait many years after purchasing to play it
>> due to the shitty Python language implementation.  
>
>The core is C++.  Python was apparently used to make it easier for fans 
>to mod the game.

C++ was used for graphcs rendering and what not, but obviously that's
not what's slow in the game (or I should say was on a typical PC 5
years ago).  The scripting language, which is where the AI and game
scenarios are created are in Python.
Re: Civ V - It better not be slow and based on Python, Ruby or other crap languages
#715848
Author: Stuffed Crust
Date: Wed, 12 May 2010 23:43
19 lines
2090 bytes
Martin Wallinson <mwal2362@gmail.com> wrote:
> C++ was used for graphcs rendering and what not, but obviously that's
> not what's slow in the game (or I should say was on a typical PC 5
> years ago).  The scripting language, which is where the AI and game
> scenarios are created are in Python.

The graphics rendering backend was, and still is, a huge performance hog.
Look up the "harkonnen" patch sometime; it vastly improved the game speed and 
memory use over time -- and all it did was act as a shim between D3D and the game.  
(The patch was largely co-opted by Firaxis fixing the underlying problems)

The other games Firaxis released that used the same graphics engine (Pirates and 
Railroads) also suffered from severe graphics-related slowdowns.

 - Solomon
-- 
Solomon Peachy        		       pizza at shaftnet dot org	 
Melbourne, FL                          ^^ (mail/jabber/gtalk) ^^
Quidquid latine dictum sit, altum viditur.
Re: Civ V - It better not be slow and based on Python, Ruby or other crap languages
#715849
Author: Martin Wallinson
Date: Wed, 12 May 2010 23:49
24 lines
2892 bytes
On 12 May 2010 23:43:35 GMT, Stuffed Crust <pizza@spam.shaftnet.org>
wrote:

>Martin Wallinson <mwal2362@gmail.com> wrote:
>> C++ was used for graphcs rendering and what not, but obviously that's
>> not what's slow in the game (or I should say was on a typical PC 5
>> years ago).  The scripting language, which is where the AI and game
>> scenarios are created are in Python.
>
>The graphics rendering backend was, and still is, a huge performance hog.
>Look up the "harkonnen" patch sometime; it vastly improved the game speed and 
>memory use over time -- and all it did was act as a shim between D3D and the game.  
>(The patch was largely co-opted by Firaxis fixing the underlying problems)
>
>The other games Firaxis released that used the same graphics engine (Pirates and 
>Railroads) also suffered from severe graphics-related slowdowns.

It's just another sign of shit development then.  There is nothing in
any of the Civ games that have ever been graphically demanding, even
by standards of when they first come out.  The just barely even
qualify as 3D.. Yet they always seem to want way more processing power
than is available at time of release.  Its like the developers put in
thread sleep pauses to make it look like the computer is doing some
hard thinking.
Re: Civ V - It better not be slow and based on Python, Ruby or other crap languages
#715833
Author: Stuffed Crust
Date: Wed, 12 May 2010 23:55
17 lines
1855 bytes
Martin Wallinson <mwal2362@gmail.com> wrote:
>>Yaeh, Sid had better not use C++ the next time around.  Look where that got him 
>>with Civ4.
> 
> What a dipshit
> 
> http://civilization4.net/files/modding/PythonAPI/

Yes, Civ4 has a pretty extensive Python API, but you've not demonstrated that's 
responsible for Civ4's abysmal performance, given that most of the game, including 
the core AI and game rules, is implemented in pure C++.

 - Solomon
-- 
Solomon Peachy        		       pizza at shaftnet dot org	 
Melbourne, FL                          ^^ (mail/jabber/gtalk) ^^
Quidquid latine dictum sit, altum viditur.
Re: Civ V - It better not be slow and based on Python, Ruby or other crap languages
#715850
Author: WDS
Date: Thu, 13 May 2010 00:31
28 lines
2963 bytes
On 5/12/2010 6:49 PM, Martin Wallinson wrote:
> On 12 May 2010 23:43:35 GMT, Stuffed Crust<pizza@spam.shaftnet.org>
> wrote:
>
>> Martin Wallinson<mwal2362@gmail.com>  wrote:
>>> C++ was used for graphcs rendering and what not, but obviously that's
>>> not what's slow in the game (or I should say was on a typical PC 5
>>> years ago).  The scripting language, which is where the AI and game
>>> scenarios are created are in Python.
>>
>> The graphics rendering backend was, and still is, a huge performance hog.
>> Look up the "harkonnen" patch sometime; it vastly improved the game speed and
>> memory use over time -- and all it did was act as a shim between D3D and the game.
>> (The patch was largely co-opted by Firaxis fixing the underlying problems)
>>
>> The other games Firaxis released that used the same graphics engine (Pirates and
>> Railroads) also suffered from severe graphics-related slowdowns.
>
> It's just another sign of shit development then.  There is nothing in
> any of the Civ games that have ever been graphically demanding, even
> by standards of when they first come out.  The just barely even
> qualify as 3D.. Yet they always seem to want way more processing power
> than is available at time of release.  Its like the developers put in
> thread sleep pauses to make it look like the computer is doing some
> hard thinking.

So what you are saying is you had no idea why Civ4 performed badly yet 
posted some made up crap about it anyway?  Smooth.
Re: Civ V - It better not be slow and based on Python, Ruby or other crap languages
#715851
Author: Martin Wallinson
Date: Thu, 13 May 2010 02:23
34 lines
3383 bytes
On Wed, 12 May 2010 19:31:40 -0500, WDS <Bill@seurer.net> wrote:

>On 5/12/2010 6:49 PM, Martin Wallinson wrote:
>> On 12 May 2010 23:43:35 GMT, Stuffed Crust<pizza@spam.shaftnet.org>
>> wrote:
>>
>>> Martin Wallinson<mwal2362@gmail.com>  wrote:
>>>> C++ was used for graphcs rendering and what not, but obviously that's
>>>> not what's slow in the game (or I should say was on a typical PC 5
>>>> years ago).  The scripting language, which is where the AI and game
>>>> scenarios are created are in Python.
>>>
>>> The graphics rendering backend was, and still is, a huge performance hog.
>>> Look up the "harkonnen" patch sometime; it vastly improved the game speed and
>>> memory use over time -- and all it did was act as a shim between D3D and the game.
>>> (The patch was largely co-opted by Firaxis fixing the underlying problems)
>>>
>>> The other games Firaxis released that used the same graphics engine (Pirates and
>>> Railroads) also suffered from severe graphics-related slowdowns.
>>
>> It's just another sign of shit development then.  There is nothing in
>> any of the Civ games that have ever been graphically demanding, even
>> by standards of when they first come out.  The just barely even
>> qualify as 3D.. Yet they always seem to want way more processing power
>> than is available at time of release.  Its like the developers put in
>> thread sleep pauses to make it look like the computer is doing some
>> hard thinking.
>
>So what you are saying is you had no idea why Civ4 performed badly yet 
>posted some made up crap about it anyway?  Smooth.

For those paying attention, there are two separate issues - speed of
AI and game flow (Python) and graphics (who knows). I understand and
spoke about one, someone else brought up the other you fuckin dolt.
Re: Civ V - It better not be slow and based on Python, Ruby or other crap languages
#715834
Author: Martin Wallinson
Date: Thu, 13 May 2010 02:25
19 lines
2313 bytes
On 12 May 2010 23:55:23 GMT, Stuffed Crust <pizza@spam.shaftnet.org>
wrote:

>Martin Wallinson <mwal2362@gmail.com> wrote:
>>>Yaeh, Sid had better not use C++ the next time around.  Look where that got him 
>>>with Civ4.
>> 
>> What a dipshit
>> 
>> http://civilization4.net/files/modding/PythonAPI/
>
>Yes, Civ4 has a pretty extensive Python API, but you've not demonstrated that's 
>responsible for Civ4's abysmal performance, given that most of the game, including 
>the core AI and game rules, is implemented in pure C++.

Bullshit.  You need to demonstrate the core AI and game rules are in
C++ after Sid said years ago this was the design.  What's more, I just
read he is replacing Python with Lua due to shitty multithreaded
performance.  So it's for sure a $10 bargain bin game for me. 
Re: Civ V - It better not be slow and based on Python, Ruby or other crap languages
#715835
Author: Stuffed Crust
Date: Thu, 13 May 2010 03:11
17 lines
1918 bytes
Martin Wallinson <mwal2362@gmail.com> wrote:
> Bullshit.  You need to demonstrate the core AI and game rules are in
> C++ after Sid said years ago this was the design.  What's more, I just
> read he is replacing Python with Lua due to shitty multithreaded
> performance.  So it's for sure a $10 bargain bin game for me. 

I point you towards CvGameCoreDLL.dll, its associated (C++) source 
code, and the various projects over the years fixing game and AI bugs 
that touch little more than its source.
  
Q.E.D.

 - Solomon
-- 
Solomon Peachy        		       pizza at shaftnet dot org	 
Melbourne, FL                          ^^ (mail/jabber/gtalk) ^^
Quidquid latine dictum sit, altum viditur.
Re: Civ V - It better not be slow and based on Python, Ruby or other crap languages
#715836
Author: Martin Wallinson
Date: Thu, 13 May 2010 03:33
30 lines
2693 bytes
On 13 May 2010 03:11:47 GMT, Stuffed Crust <pizza@spam.shaftnet.org>
wrote:

>Martin Wallinson <mwal2362@gmail.com> wrote:
>> Bullshit.  You need to demonstrate the core AI and game rules are in
>> C++ after Sid said years ago this was the design.  What's more, I just
>> read he is replacing Python with Lua due to shitty multithreaded
>> performance.  So it's for sure a $10 bargain bin game for me. 
>
>I point you towards CvGameCoreDLL.dll, its associated (C++) source 
>code, and the various projects over the years fixing game and AI bugs 
>that touch little more than its source.

Last time I looked there were only a couple of hundred .cpp source
files (most of them only a few 4kb)  in the entire CvGameCoreDLL.dll.
It handles mostly user interface handling (graphics, as I said
before), raw data structures, initial map generation (can be modified
via Python and in many cases is), utilities, etc.

Most of the AI is scripted as Python, as I stated earlier.  

The total source files for the dll you mentioned comes to a few megs.

Take a look at the Python code assets.  Just the Python folder,
without including art and resources, is about 25 MB.


Point made.

Enjoy.
Re: Civ V - It better not be slow and based on Python, Ruby or other crap languages
#715837
Author: Stuffed Crust
Date: Thu, 13 May 2010 04:19
59 lines
3972 bytes
In article <65smu51opn1rm9657elnlu7ve17sqdkiqg@4ax.com> you wrote:
> Last time I looked there were only a couple of hundred .cpp source
> files (most of them only a few 4kb)  in the entire CvGameCoreDLL.dll.
> It handles mostly user interface handling (graphics, as I said
> before), raw data structures, initial map generation (can be modified
> via Python and in many cases is), utilities, etc.

I did say "Core AI" did I not?  The actual game rules, unit definitions, 
etc are specified in XML files.
 
> Most of the AI is scripted as Python, as I stated earlier.  
> Take a look at the Python code assets.  Just the Python folder,
> without including art and resources, is about 25 MB.

Some of it, yes, but not "most".  Map generation is pure python, as are 
nearly all of the interface screens.

Oh, and about 25 of the 26MB of python code in that directory are 
non-game python libraries, including 21M that encompasses the PyWX UI 
library.  So it seems that there's a lot more C++ code than Python code 
in Civ4.

> Point made.

...and what, pray tell, is your point?

Through all of this, all you've "demonstrated" is that Firaxis
created a disproportionately resource-intensive game that has some 
Python code in it -- Those facts were established years ago.

Other assertions of yours -- "shitty multithreaded performance" (at 
least compared to Lua) and blaming Civ4's use of Python for the game 
being a dog) aren't backed up at all, including your implication that 
this is why Firaxis is switching to Lua for Civ5.  (Incidentally, I 
can't find any primary sources specifing any reasons for the switch, 
just lots of guesswork)

You've also "demonstrated' that you have an irrational dislike of Python 
(and to a lesser extent, "open-source languages" -- which is a pretty 
meaningless phrase; do you mean "open-source implemntations of 
programming languages" or "open-source runtimes" or "open-source 
software" or what?) 

Meanwhile, I've demonstrated that there were (and still are) huge
performance problems stemming solely from pure C++ parts of the game, 
and as such, one can't blame Python for all of Civ4's woes.  I've also 
demonstrated that there's more C++ code than Python code in the game, 
and that the game core and core AI are also pure C++ code.

> Enjoy.

Oh, but I do.  Thanks!

 - Solomon [I've written Python, Lua and C++, and can debate their 
            relative merits/weaknesses.  Can you say the same?]
-- 
Solomon Peachy        		       pizza at shaftnet dot org	 
Melbourne, FL                          ^^ (mail/jabber/gtalk) ^^
Quidquid latine dictum sit, altum viditur.
Re: Civ V - It better not be slow and based on Python, Ruby or other crap languages
#715852
Author: Jim
Date: Thu, 13 May 2010 06:51
13 lines
2667 bytes
"Martin Wallinson" <mwal2362@gmail.com> wrote in message 
news:6jomu5pvm60dcdlbt2sopn92vjbchm10jp@4ax.com...
> For those paying attention, there are two separate issues - speed of
> AI and game flow (Python) and graphics (who knows). I understand and
> spoke about one, someone else brought up the other you fuckin dolt.
The GameBryo engine is a pig IMO.  If you played Oblivion when it came out 
you'd probably agree.  But thats only a small part of problem.
A lot of calculations do happen every turn.  The game checks trade routes 
for each city and has add culture to every tile in the cities radius and 
check who owns it.  And since we longer have a retarded AI that takes up 
more time.
The turns on Civ3 got ridiculously long if you played a full huge map and 
that's a much simplier game with no Python. 
Re: Civ V - It better not be slow and based on Python, Ruby or other crap languages
#715838
Author: Martin Wallinson
Date: Thu, 13 May 2010 11:56
118 lines
7313 bytes
On 13 May 2010 04:19:45 GMT, Stuffed Crust <pizza@spam.shaftnet.org>
wrote:

>In article <65smu51opn1rm9657elnlu7ve17sqdkiqg@4ax.com> you wrote:
>> Last time I looked there were only a couple of hundred .cpp source
>> files (most of them only a few 4kb)  in the entire CvGameCoreDLL.dll.
>> It handles mostly user interface handling (graphics, as I said
>> before), raw data structures, initial map generation (can be modified
>> via Python and in many cases is), utilities, etc.
>
>I did say "Core AI" did I not?  The actual game rules, unit definitions, 
>etc are specified in XML files.

The problem is one of nomenclature and the fact that you're using the
word "core", which is part of the dll name, seemingly to build a case
that more actual AI code is in C++ than in Python, which is not the
case.  The real "core" is zeros and ones, and is the operating system
itself.

>> Most of the AI is scripted as Python, as I stated earlier.  
>> Take a look at the Python code assets.  Just the Python folder,
>> without including art and resources, is about 25 MB.
>
>Some of it, yes, but not "most".  Map generation is pure python, as are 
>nearly all of the interface screens.
>
>Oh, and about 25 of the 26MB of python code in that directory are 
>non-game python libraries, including 21M that encompasses the PyWX UI 
>library.  So it seems that there's a lot more C++ code than Python code 
>in Civ4.
>> Point made.
>
>...and what, pray tell, is your point?

The point of the original thread is in the subject line.  The point of
subthreads and tangents created by others are defined by them.  My
current point, for purposes of the tangent you created, is that the
choice of Python for AI is a bad idea.  I never said that inefficient
C++ coding does not also contribute to performance issues in the game,
only that choice of language for the scripting engine was a bad one
with regard to performance.


>Other assertions of yours -- "shitty multithreaded performance" (at 
>least compared to Lua) and blaming Civ4's use of Python for the game 
>being a dog) aren't backed up at all, including your implication that 
>this is why Firaxis is switching to Lua for Civ5.  (Incidentally, I 
>can't find any primary sources specifing any reasons for the switch, 
>just lots of guesswork)

There is no such thing as guesswork in internet debates anymore, only
laziness.  You're a mere search engine away from enlightenment.  The
act of fact research has been democratized over the past decade or so,
such that no reasonable person expects others to search the web for
them everytime they have questions or seek substatiation for things.

>You've also "demonstrated' that you have an irrational dislike of Python 
>(and to a lesser extent, "open-source languages" -- which is a pretty 
>meaningless phrase; do you mean "open-source implemntations of 
>programming languages" or "open-source runtimes" or "open-source 
>software" or what?) 

I don't have a dislike of Python or even have any personal issues with
the lower echelon of programmers who seem to favor open source
practices, I just dislike when they are used to accomplish any task
that calls for good performance.

>Meanwhile, I've demonstrated that there were (and still are) huge
>performance problems stemming solely from pure C++ parts of the game, 

No you haven't.  You just provided the name of a dll.  To demonstrate
that Civ is slow because of C++ instead of Python, which is the point
you obviously really want to make here, you would need to do some code
profiling on both and provide source code analytics indicating where
the bottleneck is, and document your findings thoroughly so that your
profiling can be replicated easily by others and your statements of
conjecture confirmed.  I don't see you going to any trouble to do
this, you are simply stating your opinion and that it's better than
mine. 

>and as such, one can't blame Python for all of Civ4's woes.  I've also 
>demonstrated that there's more C++ code than Python code in the game, 
>and that the game core and core AI are also pure C++ code.

You haven't demonstrated anything, you simply stated your opinion
again, bringing up the topic of XML this time.  I specifically
excluded the XML files from my original code size metrics because they
simply contain data and not any programming logic.

You then went on to include the size of the Python libraries into the
equation to try to make your case that there is more C++ in the game
than Python.... but you failed to realize that the Python libraries
are not the intellectual property of Sid Meier, he didn't create them,
and so they cannot be considered Civilization IV code.  What's more,
without realizing it, by mentioning the Python libraries as being a
possible source of the bottleneck, you have unwittingly confirmed what
I have been saying all along, which is Python is a slow shit language
an inappropriate for use in games (or other apps) in scenarios where
performance an issue.

>> Enjoy.
>
>Oh, but I do.  Thanks!

Ignorance is bliss I guess.

> - Solomon [I've written Python, Lua and C++, and can debate their 
>            relative merits/weaknesses.  Can you say the same?]

Of course I can, but I'm also smart enough to know this isn't the
forum for doing that.

I'm off to the beach for a few days, I will have laptop with me and
might check back on this one, but in the meantime I'd like to thank
you for confirming everything I've said, even if you didn't realize
you did it.

Cheers
Re: Civ V - It better not be slow and based on Python, Ruby or other crap languages
#715839
Author: Stuffed Crust
Date: Thu, 13 May 2010 12:49
36 lines
3187 bytes
Martin Wallinson <mwal2362@gmail.com> wrote:
> There is no such thing as guesswork in internet debates anymore, only
> laziness.  You're a mere search engine away from enlightenment.  The
> act of fact research has been democratized over the past decade or so,
> such that no reasonable person expects others to search the web for
> them everytime they have questions or seek substatiation for things.

Silly rabbit, didn't your mommy teach you that the one making the 
assertion is the one who has to cough up the supporting evidence for 
someting they state as fact?

But okay, I'll do your work for you.  The closest I've found is a 
second-hand report that "some Civ5 developer at PAX East" said that 
Firaxis switched to Lua, with no further details.  *Every other* 
reference I found to this (I stopped after the first two pages of 
search results using multiple queries) was just just further speculation 
or repeating the original (now third-hand) report.  No attributable 
quotes from Civ developers or Firaxis, nothing.  Heck, even 
CIvFanatics.com (which religiously aggregates all info on Civ) doesn't 
have anything concrete either -- and their "confirmed feaures" page 
doesn't even list Lua, much less any reasons for switching.

One thing they do specifically mention is that Civ5 will be heavily 
multi-threaded, with the impication (easily confirmed by looking at a 
CPU load graph) that Civ4 wasn't threaded at all.

I've done my reasearch -- apparently, you haven't.

Subsequently, I'll spare the rest of your (still-unsupported) drivel 
and go do something productive. 

 - Solomon 
-- 
Solomon Peachy        		       pizza at shaftnet dot org	 
Melbourne, FL                          ^^ (mail/jabber/gtalk) ^^
Quidquid latine dictum sit, altum viditur.
Re: Civ V - It better not be slow and based on Python, Ruby or other crap languages
#715824
Author: Tim Skirvin
Date: Thu, 13 May 2010 16:17
15 lines
1880 bytes
tskirvin@killfile.org (Tim Skirvin) writes:

> Martin Wallinson <mwal2362@gmail.com> writes:

>> [...] but of course Python and most other open source langs sucks cocks
>> at multithreading so it does not take full advantage of it.

>        *snicker*  This is going to be a fun flamewar.

        I wasn't disappointed.  Thanks, all!

                           - Tim Skirvin (tskirvin@killfile.org)
-- 
http://wiki.killfile.org/           Skirv's Homepage <FISH>< <*>
http://wiki.killfile.org/projects/              Skirv's Projects
Re: Civ V - It better not be slow and based on Python, Ruby or other crap languages
#715842
Author: David Lamb
Date: Thu, 13 May 2010 21:28
24 lines
2911 bytes
Martin Wallinson wrote:
> No you haven't.  You just provided the name of a dll.  To demonstrate
> that Civ is slow because of C++ instead of Python, which is the point
> you obviously really want to make here, you would need to do some code
> profiling on both and provide source code analytics indicating where
> the bottleneck is, and document your findings thoroughly so that your
> profiling can be replicated easily by others and your statements of
> conjecture confirmed.  I don't see you going to any trouble to do
> this, you are simply stating your opinion and that it's better than
> mine. 

Wait a minute -- *he* has to provide data for his claim about C++, 
whereas *you* don't have to do so for your claim about Python?

> You haven't demonstrated anything, you simply stated your opinion
> again, bringing up the topic of XML this time.  I specifically
> excluded the XML files from my original code size metrics because they
> simply contain data and not any programming logic.

Distinguishing "data" from "code" is naive. The Python "code" is "data" 
for a Python language interpreter.  Quite a bit of that XML is similarly 
"data" governing how the core AI logic should work for individual 
leaders.  In the Bad Old Days somebody would have written it as code 
instead of writing an interpreter for more easily-modified "data".
Re: Civ V - It better not be slow and based on Python, Ruby or other crap languages
#715825
Author: Stuffed Crust
Date: Thu, 13 May 2010 21:50
13 lines
1657 bytes
Tim Skirvin <tskirvin@killfile.org> wrote:
>>        *snicker*  This is going to be a fun flamewar.
>        I wasn't disappointed.  Thanks, all!

It's been a welcome distraction from the day job -- For which I'm 
currently hacking some new features into a rather large C++/Boost/Python 
codebase that (among other things) does a lot of graphics manipulation.

 - Solomon
-- 
Solomon Peachy        		       pizza at shaftnet dot org	 
Melbourne, FL                          ^^ (mail/jabber/gtalk) ^^
Quidquid latine dictum sit, altum viditur.
Re: Civ V - It better not be slow and based on Python, Ruby or other crap languages
#715853
Author: Martin Wallinson
Date: Fri, 14 May 2010 01:16
31 lines
3397 bytes
On Thu, 13 May 2010 02:51:50 -0400, "Jim" <jim@wtf.invalid> wrote:

>The GameBryo engine is a pig IMO.  If you played Oblivion when it came out 
>you'd probably agree.  But thats only a small part of problem.

I did play Oblivion when it game out (on the same PC that I originally
had when I bought Civ IV), and I did crave better performance
(especially in outdoor environments) and never considered Oblivion a
top-notch performer, but the performance was good enough that I did
enjoy it for many hours.  I got a whole new rig a few months after I
finished Oblivion, and went back to some old saved games for some side
quest fun, and it was quite smooth by then, but still showed that it
wasn't as fast as some other engines.  But, for the time frame (spring
2006 I think), the eye candy in Oblivion was pretty good so it had a
little more excuse to be slow.

>A lot of calculations do happen every turn.  The game checks trade routes 
>for each city and has add culture to every tile in the cities radius and 
>check who owns it.  And since we longer have a retarded AI that takes up 
>more time.
>The turns on Civ3 got ridiculously long if you played a full huge map and 
>that's a much simplier game with no Python. 

Well back in the days of the 386, the original Civ could bog down at
times, but on a large map with lots of stuff going on, the actual
calculations needed to get the job done (versus how many actual
calculations might be taking place behind the scenes) shouldn't be
much more in the newer versions of the game than the old.  The routes
are prettier and we have zooming and camera angles and such, but the
number of tiles, approximate distances and such should be about the
same.
Re: Civ V - It better not be slow and based on Python, Ruby or other crap languages
#715826
Author: StuffedItUpHisCrust
Date: Fri, 14 May 2010 15:44
15 lines
1766 bytes
Tim Skirvin <tskirvin@killfile.org> wrote:
>        *snicker*  This is going to be a fun flamewar.

I'm rather dissappointed -- first, there aren't enough people involved, 
and secondly, the originator has already resorted to name-calling and 
barely-veiled (and hilariously misdirected) blanket ethnic insults.  

Kids these days have no appreciation for the creativity that goes into a 
proper flame war.

 - Solomon
-- 
Solomon Peachy        		       pizza at shaftnet dot org	 
Melbourne, FL                          ^^ (mail/jabber/gtalk) ^^
Quidquid latine dictum sit, altum viditur.
Re: Civ V - It better not be slow and based on Python, Ruby or other crap languages
#715827
Author: Tim Skirvin
Date: Fri, 14 May 2010 15:54
32 lines
2901 bytes
StuffedItUpHisCrust <pizza@spam.shaftnet.org> writes:

> Tim Skirvin <tskirvin@killfile.org> wrote:
>>        *snicker*  This is going to be a fun flamewar.

> I'm rather dissappointed -- first, there aren't enough people involved, 
> and secondly, the originator has already resorted to name-calling and 
> barely-veiled (and hilariously misdirected) blanket ethnic insults.  

        Oh, sure, but we still had somebody show up and tell off the guy
that thinks he understands programming languages.  It wasn't just a "haha,
I'm going to troll somebody into a flamewar!" kind of fight; this was a
nice case where somebody shows up thinking he knows more than he actually
does, and gets yelled at for it.

        My first instinct was to get involved, but I'm more involved on
the sysadmin side of the programming world than I am with the actual
coding, so I wouldn't have helped that much.  I can point at plenty of
really impressive, high-performance python code (especially in life
sciences), but I wouldn't be able to defend it in depth.

        Mind, I do agree with his *general* sentiment, though I disagree
with the specifics.  The AI code in Civ IV seems somehow... un-profiled to
me.  It feels like the algorithms could be more tightened, and it could do
with a pass-through with Purify to find some of the memory leaks.  I would
love to see Civ IV 2.0, which would be dedicated to improving performance
rather than adding new features.  

                           - Tim Skirvin (tskirvin@killfile.org)
-- 
http://wiki.killfile.org/           Skirv's Homepage <FISH>< <*>
http://www.stanford.edu/~tskirvin/             Skirv's Work + CV
Re: Civ V - It better not be slow and based on Python, Ruby or other crap languages
#715829
Author: Martin Wallinson
Date: Fri, 14 May 2010 19:29
14 lines
2110 bytes
On 14 May 2010 15:44:22 GMT, StuffedItUpHisCrust
<pizza@spam.shaftnet.org> wrote:

>Tim Skirvin <tskirvin@killfile.org> wrote:
>>        *snicker*  This is going to be a fun flamewar.
>
>I'm rather dissappointed -- first, there aren't enough people involved, 
>and secondly, the originator has already resorted to name-calling and 
>barely-veiled (and hilariously misdirected) blanket ethnic insults.  

What is hilarious is your misinterpretation, and lack of awareness of
what was said in the first place (and then calling it "barely-veiled",
thereby again unwittingly insulting your own inability to see through
the "veil")..  Made my day.
Re: Civ V - It better not be slow and based on Python, Ruby or other crap languages
#715828
Author: Stuffed Crust
Date: Mon, 17 May 2010 18:06
27 lines
2591 bytes
Tim Skirvin <tskirvin@killfile.org> wrote:
>        Mind, I do agree with his *general* sentiment, though I disagree
> with the specifics.  The AI code in Civ IV seems somehow... un-profiled to
> me.  It feels like the algorithms could be more tightened, and it could do
> with a pass-through with Purify to find some of the memory leaks.  I would
> love to see Civ IV 2.0, which would be dedicated to improving performance
> rather than adding new features.  

My gut feeling is that the relatively poor performance of the game 
internals (ie non-graphics stuff) is due to how the game rules are 
loaded and interpreted.  All of the units, their relationships, leader 
behaivor, and other game rules are specified in XML tables, and as such 
need to be loaded and parsed into a form that the game core can work 
with.  I suspect that these rule structures are effectively 
re-interpreted each time instead of being "compiled" into native code 
using something loosely equivalent to a Just-in-Time compiler.  Of 
course, I could be completely wrong here..  

But no amount of optimization will change the fact that the game AI has 
exponentially more data to crunch and evaluate as time goes on -- with 
the inevitable slowdown that entails.

 - Solomon
-- 
Solomon Peachy        		       pizza at shaftnet dot org	 
Melbourne, FL                          ^^ (mail/jabber/gtalk) ^^
Quidquid latine dictum sit, altum viditur.
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads