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
Author: Jim
Date: Fri, 07 May 2010 21:45
Date: Fri, 07 May 2010 21:45
3 lines
1492 bytes
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
Author: Martin Wallinson
Date: Wed, 12 May 2010 04:25
Date: Wed, 12 May 2010 04:25
23 lines
2434 bytes
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
Author: Tim Skirvin
Date: Wed, 12 May 2010 06:30
Date: Wed, 12 May 2010 06:30
11 lines
1563 bytes
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
Author: MetalGuru
Date: Wed, 12 May 2010 09:31
Date: Wed, 12 May 2010 09:31
11 lines
1809 bytes
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
Author: Stuffed Crust
Date: Wed, 12 May 2010 14:42
Date: Wed, 12 May 2010 14:42
13 lines
1636 bytes
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
Author: gumby
Date: Wed, 12 May 2010 16:53
Date: Wed, 12 May 2010 16:53
6 lines
1477 bytes
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
Author: Martin Wallinson
Date: Wed, 12 May 2010 23:14
Date: Wed, 12 May 2010 23:14
14 lines
1748 bytes
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
Author: David Lamb
Date: Wed, 12 May 2010 23:14
Date: Wed, 12 May 2010 23:14
6 lines
1245 bytes
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
Author: Martin Wallinson
Date: Wed, 12 May 2010 23:17
Date: Wed, 12 May 2010 23:17
14 lines
1948 bytes
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
Author: Stuffed Crust
Date: Wed, 12 May 2010 23:43
Date: Wed, 12 May 2010 23:43
19 lines
2090 bytes
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
Author: Martin Wallinson
Date: Wed, 12 May 2010 23:49
Date: Wed, 12 May 2010 23:49
24 lines
2892 bytes
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
Author: Stuffed Crust
Date: Wed, 12 May 2010 23:55
Date: Wed, 12 May 2010 23:55
17 lines
1855 bytes
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
Author: WDS
Date: Thu, 13 May 2010 00:31
Date: Thu, 13 May 2010 00:31
28 lines
2963 bytes
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
Author: Martin Wallinson
Date: Thu, 13 May 2010 02:23
Date: Thu, 13 May 2010 02:23
34 lines
3383 bytes
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
Author: Martin Wallinson
Date: Thu, 13 May 2010 02:25
Date: Thu, 13 May 2010 02:25
19 lines
2313 bytes
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
Author: Stuffed Crust
Date: Thu, 13 May 2010 03:11
Date: Thu, 13 May 2010 03:11
17 lines
1918 bytes
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
Author: Martin Wallinson
Date: Thu, 13 May 2010 03:33
Date: Thu, 13 May 2010 03:33
30 lines
2693 bytes
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
Author: Stuffed Crust
Date: Thu, 13 May 2010 04:19
Date: Thu, 13 May 2010 04:19
59 lines
3972 bytes
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
Author: Jim
Date: Thu, 13 May 2010 06:51
Date: Thu, 13 May 2010 06:51
13 lines
2667 bytes
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
Author: Martin Wallinson
Date: Thu, 13 May 2010 11:56
Date: Thu, 13 May 2010 11:56
118 lines
7313 bytes
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
Author: Stuffed Crust
Date: Thu, 13 May 2010 12:49
Date: Thu, 13 May 2010 12:49
36 lines
3187 bytes
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
Author: Tim Skirvin
Date: Thu, 13 May 2010 16:17
Date: Thu, 13 May 2010 16:17
15 lines
1880 bytes
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
Author: David Lamb
Date: Thu, 13 May 2010 21:28
Date: Thu, 13 May 2010 21:28
24 lines
2911 bytes
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
Author: Stuffed Crust
Date: Thu, 13 May 2010 21:50
Date: Thu, 13 May 2010 21:50
13 lines
1657 bytes
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
Author: Martin Wallinson
Date: Fri, 14 May 2010 01:16
Date: Fri, 14 May 2010 01:16
31 lines
3397 bytes
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
Author: StuffedItUpHisCrust
Date: Fri, 14 May 2010 15:44
Date: Fri, 14 May 2010 15:44
15 lines
1766 bytes
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
Author: Tim Skirvin
Date: Fri, 14 May 2010 15:54
Date: Fri, 14 May 2010 15:54
32 lines
2901 bytes
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
Author: Martin Wallinson
Date: Fri, 14 May 2010 19:29
Date: Fri, 14 May 2010 19:29
14 lines
2110 bytes
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
Author: Stuffed Crust
Date: Mon, 17 May 2010 18:06
Date: Mon, 17 May 2010 18:06
27 lines
2591 bytes
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