Thats more likely because its a card designed for CAD/CAM and other similar programs...handy388 wrote:"AGEIA PhysX card "
that card sucks. It's a 299.99 card that SLOWS down your game.
...then again I could be wrong.
Moderator: Moderators for English X Forum
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.Lost Ark wrote:Thats more likely because its a card designed for CAD/CAM and other similar programs...handy388 wrote:"AGEIA PhysX card "
that card sucks. It's a 299.99 card that SLOWS down your game.
...then again I could be wrong.
Running different threads at different times doesn't really count.Carl Sumner wrote:Technically, X3 is certainly multithreaded.
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 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.
Ummm when the speed is given for a dual core CPU, it is given PER CORE.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
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.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).
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.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
The thing is, we have reached the stage where we cannot improve a single CPU anymore, not without a radical improvement in technology. But we can add cores to existing chips. Intel are talking about 32 cores in one CPU in the next ten years. In fact, in the near future we are going to be seeing less powerful cores, not more powerful. The time to design a core rises geometricaly with its complexity, so by working with large numbers of simpler cores they will be able to design new CPUs much more rapidly. While you are correct in that there is some overhead in running a program on multiple cores, once we have efficient hardware designs and once developers have learned to code multithreaded applications quickly, we will see massive gains in overall performance.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
And so they didKindred Spirit wrote: ↑Thu, 12. Jan 06, 05:29Hopefully SMP/multicore support will be considered when they do X4
SMP forever! Dual-core SMP even
KS