CPU intensive game - need dual core support?

General discussions about the games by Egosoft including X-BTF, XT, X², X³: Reunion, X³: Terran Conflict and X³: Albion Prelude.

Moderator: Moderators for English X Forum

Jon Tetrino
Posts: 3206
Joined: Mon, 2. Aug 04, 22:27
x4

Post by Jon Tetrino » Fri, 18. Aug 06, 01:45

handy388 wrote:"AGEIA PhysX card "

that card sucks. It's a 299.99 card that SLOWS down your game.
Thats more likely because its a card designed for CAD/CAM and other similar programs...


...then again I could be wrong.

aka1nas
Posts: 1382
Joined: Thu, 7. Jul 05, 05:17
x3tc

Post by aka1nas » Fri, 18. Aug 06, 01:59

Lost Ark wrote:
handy388 wrote:"AGEIA PhysX card "

that card sucks. It's a 299.99 card that SLOWS down your game.
Thats more likely because its a card designed for CAD/CAM and other similar programs...


...then again I could be wrong.
No it is a gaming card. There is only one released game(GRAW) that supports it and the support was poorly tacked onto a game that already is using the HAVOK software physics engine for most of the effects. So they chose a very inefficient way to support the hardware. To make it worse, the hardware physics mode vastly increases the number of particles and objects in the game and there is no way to use hardware physics with the normal number of objects or software physics with the regular number of objects. So it is very difficult to actually benchmark performance with or without the hardware.

Jon Tetrino
Posts: 3206
Joined: Mon, 2. Aug 04, 22:27
x4

Post by Jon Tetrino » Fri, 18. Aug 06, 02:02

so its a waste of money for everyone.

Cycrow
Moderator (Script&Mod)
Moderator (Script&Mod)
Posts: 20572
Joined: Mon, 15. Nov 04, 00:26
x4

Post by Cycrow » Fri, 18. Aug 06, 03:08

it is right now, but u have to give it time for games to actaully come out that uses it properly.

Thats the problem with new technology, most ppl will only get it once its established, which makes it hard to establish it in the first place as companys arn't going to spend time and money producing a game for it that no one can actaully use.

but then the same thing happened with the original voodoo, most ppl laughed at the idea of having a GPU for games.

it only really took off once voodoo 2 was lauched

User avatar
Mophus
Posts: 121
Joined: Sun, 14. May 06, 23:29

Post by Mophus » Fri, 18. Aug 06, 05:00

Carl Sumner wrote:Technically, X3 is certainly multithreaded.
Running different threads at different times doesn't really count. ;)

I think Morrowind launched a new thread each time you loaded a game, so some people swore that, on their system, the game ran more than 32 threads. Well, yes, but not at the same time. :)

Run X3 on a multi-core system, and you won't see it use more than the equivalent of one core at the same time. The process might jump around a bit, as Windows manages other processes, but you'll never get two CPU-intensive X3 threads running at the same time.

Parallelising everything would be hard, of course, but I'm pretty sure they could offload all the OoS simulation to a secondary thread with very little work. Since the two simulations are already significantly different, I'm pretty sure they already have mechanisms in place to handle the "transfer" of entities between them, which should be SMP-safe.

P.S. - The Ageia card was not designed for CAD. Most professional CAD packages come with their own physics code, tightly integrated into the program. They can't afford to have 3rd party hardware produce slightly different results, screwing up all the simulation. Ageia's card is aimed mainly at games. Personally, I doubt physics cards will go very far. It's more likely that a physics processor will be added to graphics cards (a lot of the data about the 3D scene is shared by the graphics and physics engine, so it makes more sense to keep them close together). I have a feeling AMD and ATi might be working on a hybrid solution, possibly with Havok, and probably designed to run on HTX. We'll see.

- Mophus

ZaphodBeeblebrox
Posts: 1585
Joined: Mon, 10. Apr 06, 20:35
x4

Post by ZaphodBeeblebrox » Fri, 18. Aug 06, 12:41

As a programmer who has written very large multi-threaded applications, I can assure everybody that apart from some very trivial uses, it is not an easy thing to add to an existing program.

Scripting is very definitely NOT a candidate for this.

I agree with Mophus, to some extent, there are parts of the OOS computations that could be made to run in a separate thread, that doesn't mean it would be easy to do though. Making the operations thread safe and avoiding race conditions would take a great deal of analysis, and might not be worth the effort involved.

It is almost certainly not worth the effort for X3.
It was a woman who drove me to drink... you know I never went back and thanked her.

Don't try to outweird me, three-eyes. I get stranger things than you free with my breakfast cereal.

aka1nas
Posts: 1382
Joined: Thu, 7. Jul 05, 05:17
x3tc

Post by aka1nas » Fri, 18. Aug 06, 17:07

ZaphodBeeblebrox wrote:As a programmer who has written very large multi-threaded applications, I can assure everybody that apart from some very trivial uses, it is not an easy thing to add to an existing program.

Scripting is very definitely NOT a candidate for this.

I agree with Mophus, to some extent, there are parts of the OOS computations that could be made to run in a separate thread, that doesn't mean it would be easy to do though. Making the operations thread safe and avoiding race conditions would take a great deal of analysis, and might not be worth the effort involved.

It is almost certainly not worth the effort for X3.
I'll agree that it is probably not economical for X3 for them to reprogram the engine. However, if you look at the way the game works, there would be very little race conditions if you divide up things at the sector level. Sectors are already self-contained and the only time data is shared is when a ship jumps into sector. OOS Sector Data is already not displayed in real time so no loss there. This is basically just message passing between objects to think about it abstractly. To be honest, it doesn't matter if it takes microseconds or 10 seconds for a ship to appear in another sector after it passes through a jumpgate.

ZaphodBeeblebrox
Posts: 1585
Joined: Mon, 10. Apr 06, 20:35
x4

Post by ZaphodBeeblebrox » Fri, 18. Aug 06, 17:59

Which sounds ok until the player starts looking at sectors from the Universe Map. I can assure you that trying to update graphics from separate threads can cause a lot of problems.

One method, is to ensure that graphics updates always run in the same thread. Therefore you need some means of signalling, (or other synchronisation methods) for when background threads have completed their calculations and the graphics thread can now use the data to do its updates.

Edit:

Yet more problems arise when the player selects a ship from the sector map and gives it orders that will change its course.
It was a woman who drove me to drink... you know I never went back and thanked her.

Don't try to outweird me, three-eyes. I get stranger things than you free with my breakfast cereal.

Zakalwe
Posts: 217
Joined: Sun, 22. Feb 04, 13:52
x3tc

Post by Zakalwe » Fri, 18. Aug 06, 19:28

OOS update doesn't need to be at a high frequency, right now it's soemthing like one in 3? seconds. I cannot see a real problem with synchronisation. But then i am not a programmer...

In any case seperating OOS wouldn't help much as most CPU usage is used for IS, whatever other people say. Even i have my >>60fps when seeing only starfield in a not busy sector and i haven't got the high-end CPU. It get's slow when there are objects on the screen (I can blame my TI, other players can't).
Zepto Nox A15 - P8400, 4GB 800MHz DDR2, Nvidia 9650GT 512MB DDR3, WSXGA, 200GB SATA 7200rpm, Blu-ray, Vista Business UK 64-bit

Jon Tetrino
Posts: 3206
Joined: Mon, 2. Aug 04, 22:27
x4

Post by Jon Tetrino » Fri, 18. Aug 06, 20:16

Ok, I went and toyed around with my friends Core 2 Duo rig (he tends to experiment) and after using a resource managment software, we managed to get X3 running on both cores.

When I find the software I'll post a link.

Martin Logan
Posts: 1463
Joined: Sun, 26. Sep 04, 10:42
x3

i dont think they should

Post by Martin Logan » Fri, 18. Aug 06, 20:35

the way i see it that transferring data between two cpus would require some power as well i think it would be better to improve one cpu then simply putting two slower cpus together of course its just my opnion but i think transferring data between two cpus just takes too much power away in the first place

Jon Tetrino
Posts: 3206
Joined: Mon, 2. Aug 04, 22:27
x4

Re: i dont think they should

Post by Jon Tetrino » Fri, 18. Aug 06, 21:25

Martin Logan wrote:the way i see it that transferring data between two cpus would require some power as well i think it would be better to improve one cpu then simply putting two slower cpus together of course its just my opnion but i think transferring data between two cpus just takes too much power away in the first place
Ummm when the speed is given for a dual core CPU, it is given PER CORE.

so a 2.6Ghz Core 2 Duo has 2.6Ghz per core of processing power, and there is very little if any power taken away fromt he two cores running together.

snyderm
Posts: 297
Joined: Wed, 1. Mar 06, 21:09
x3

Post by snyderm » Fri, 18. Aug 06, 21:30

Edited for quality content.

There was none.

Sorry for the spam.
Last edited by snyderm on Fri, 18. Aug 06, 22:06, edited 1 time in total.

Cycrow
Moderator (Script&Mod)
Moderator (Script&Mod)
Posts: 20572
Joined: Mon, 15. Nov 04, 00:26
x4

Post by Cycrow » Fri, 18. Aug 06, 22:00

Zakalwe wrote:OOS update doesn't need to be at a high frequency, right now it's soemthing like one in 3? seconds. I cannot see a real problem with synchronisation. But then i am not a programmer...

In any case seperating OOS wouldn't help much as most CPU usage is used for IS, whatever other people say. Even i have my >>60fps when seeing only starfield in a not busy sector and i haven't got the high-end CPU. It get's slow when there are objects on the screen (I can blame my TI, other players can't).
Just so you know, game engines generally update as fast as they render, ie, if you ur running at 60fps, then the game will update 60 times a second.

slightly more than every 3 seconds ;)

Carl Sumner
Posts: 5112
Joined: Mon, 23. Feb 04, 02:28
x4

Post by Carl Sumner » Sat, 19. Aug 06, 01:55

Cycrow wrote:Just so you know, game engines generally update as fast as they render, ie, if you ur running at 60fps, then the game will update 60 times a second.

slightly more than every 3 seconds ;)
That's a different kind of update. Actually each thread can have it's own cycle rate, usually limited to allow other threads some processing time.

Plus, if there are locally controlled thread systems, each thread controller kernal will have it's own cycle rate depending on the load. In X3 the script processor seems to be a locally controlled, cooperatively scheduled, thread system.
:)

As far as the talk about protecting access to hardware or global variables from thread collisions, the Windows API provides several tools for this, built in. The programmers just have to use them. :wink:
Tinker

"If engineers built buildings the way programmers write programs, the first woodpecker that came along would destroy civilization!"

Locked

Return to “X Trilogy Universe”