Pages: [1] :: one page |
|
Author |
Thread Statistics | Show CCP posts - 0 post(s) |
Allen Ramses
Caldari Typo Corp
|
Posted - 2009.12.01 20:57:00 -
[1]
Hello, I have a few questions about the client as it is now.
First of all, is the client large address aware? If so, is there a way to increase the cache to utilize anything close to the 3GB allotted by the LAA bit flag without dumping the EVE directory into a ramdrive? If not, are there any plans to support an LAA executable?
I am also curious if the client is still limited to a single thread. I know getting threaded python to work correctly is nothing short of an endurance trial of divine intervention, so asking about the UI seems somewhat obvious. However, I'd like to know if the client itself is still limited to a single thread. If so, I don't see why I/O operations, audio rendering, video processing, and the networking layer can't have their own threads. If these don't have dedicated threads, are there any major obstacles that would prevent a practical method, or might it simply not be worth it? Is it being worked on or planned?
I'm no engineer, just curious . ____________________ CCP: Catering to the cowards of a cold, harsh universe since November, 2006. |
Haguu
Caldari School of Applied Knowledge
|
Posted - 2009.12.03 18:05:00 -
[2]
I am quite sure that at fanfest they were discussing a separate thread for Mooddoggie, the new Chrome ingame browser.
I think they said they had done some, perhaps small?, work on threads for Apocrapha and were doing some more for Dominion. But I did not get the sense that they had done as much as they would like for the world of eight core personal computers. But bad memory and wishful thinking means no guarantees on this.
|
Gehnster
Gallente Domini Umbrus
|
Posted - 2009.12.03 19:47:00 -
[3]
I don't know about you, but my eve client uses like 600mb of RAM. How big do your clients get?
Also.
http://en.wikipedia.org/wiki/Thread_%28computer_science%29
Threads are within processes. I assume you meant process because I would think the client uses a lot of threads.
|
Allen Ramses
Caldari Typo Corp
|
Posted - 2009.12.03 23:08:00 -
[4]
No, I mean threads.
Everything in EVE seems to wait until an operation is complete before it will begin the next one. Try to do ANYTHING in the EVE client while opening a window, changing a session, etc. All operations, including lower level ones, halt until the currently executed one is completed. You don't even have mouse control.
This would lead me to believe everything in EVE (aside from EVE voice, which is its own process) is still limited to a single linear thread. ____________________ CCP: Catering to the cowards of a cold, harsh universe since November, 2006. |
Amida Ta
German Mining and Manufacture Corp.
|
Posted - 2009.12.03 23:46:00 -
[5]
Originally by: Allen Ramses Hello, I have a few questions about the client as it is now.
First of all, is the client large address aware? If so, is there a way to increase the cache to utilize anything close to the 3GB allotted by the LAA bit flag without dumping the EVE directory into a ramdrive? If not, are there any plans to support an LAA executable?
I'm pretty sure it is not LAA. On the other hand LAA doesn't make much sense for the client. With 2GB they can load about half of the ENTIRE game resources into RAM at once, which for most of them doesn't even make sense.
Originally by: Allen Ramses
I am also curious if the client is still limited to a single thread. I know getting threaded python to work correctly is nothing short of an endurance trial of divine intervention, so asking about the UI seems somewhat obvious. However, I'd like to know if the client itself is still limited to a single thread. If so, I don't see why I/O operations, audio rendering, video processing, and the networking layer can't have
Yes it basically is still limited to a single thread. And basically you also named the reason: Python (imho a very bad choice by itself). They are using Stackless Python to try to circumvent the problem with being single threaded (CCP funds the development of stackless python). But as you already noticed it doesn't seem to work very good/help very much. The EVE-client hangs more than any other MMO game I know. BTW: Not the entire client is running in a single thread. Some things ARE threaded (mostly the stuff that is non-python like the new browser (which is in fact a completely seperate process). Voice is too, afaik.
Originally by: Allen Ramses their own threads. If these don't have dedicated threads, are there any major obstacles that would prevent a practical method, or might it simply not be worth it? Is it being worked on or planned?
I'm no engineer, just curious .
I don't know CCPs plans. But imho it is probably next to impossible to change. It seems that Python is the problem. And the client (and as it seems even the servers) contain a huge amount of Python code. So to prevent that you would likely have to develop an entirely new client from the ground up. _________________________ EveAI.Live - The EVE-Online API/class library for .Net, C# and VB.Net |
Hel O'Ween
Men On A Mission
|
Posted - 2009.12.04 00:10:00 -
[6]
Originally by: Allen Ramses Everything in EVE seems to wait until an operation is complete before it will begin the next one. Try to do ANYTHING in the EVE client while opening a window, changing a session, etc. All operations, including lower level ones, halt until the currently executed one is completed. You don't even have keyboard control.
My guess is that some of the "wait loops" you're describing have to do with client/server synchronization. Making certain tasks threaded/asynchronous would mean you/your client interacts with stuff/circumstances no longer in the state they're appear to be. Hence you follow the KISS motto and keep it synchronous (and therefore blocking) instead of trying to do all kind of signaling (and therefore introducing hard to catch bugs). -- EVEWalletAware - an offline wallet manager |
Sleepkevert
Amarr Rionnag Alba Triumvirate.
|
Posted - 2009.12.04 11:36:00 -
[7]
Edited by: Sleepkevert on 04/12/2009 11:37:01 Well, the loading of resources (textures, models, etc) is "dynamic" these days so I'm pretty sure that that is in another thread. As for large adress aware, it's the same as the x64 discussion. As mentioned above it just doesn't make sense since EVE will probably never use over 1gb of ram per client. _
Add your own line! |
Amida Ta
German Mining and Manufacture Corp.
|
Posted - 2009.12.04 14:18:00 -
[8]
Originally by: Sleepkevert Edited by: Sleepkevert on 04/12/2009 11:37:01 Well, the loading of resources (textures, models, etc) is "dynamic" these days so I'm pretty sure that that is in another thread. As for large adress aware, it's the same as the x64 discussion. As mentioned above it just doesn't make sense since EVE will probably never use over 1gb of ram per client.
I'm sure that resource loading is "dynamic" just about everywhere in games (because it makes sense). But I'm also pretty sure that in EVE resources are NOT loaded dynamically in background threads. And although the client doesn't use more RAM today I'm pretty sure (depending on how long Eve continues to exist) that it WILL need more than 2 and eventually 4GB of RAM. _________________________ EveAI.Live - The EVE-Online API/class library for .Net, C# and VB.Net |
Leebe
|
Posted - 2009.12.04 14:35:00 -
[9]
Edited by: Leebe on 04/12/2009 14:36:37 When you are curios why don't you use some free tools (like process explorer) to check how many threads the client is running ?
Using threads in a computer game is not an easy task... you can use threads for stuff like loading ressources, the audio subsystem, the ingame browser, the networking but the most heavy thing will stay the rendering which is always single threaded. (Better support for multithreaded rendering is a new DirectX 11 feature)
Keeping a seven years old engine up to date is a heavy task .. and for every feature it's a decision if it's worth to do. - How much work to do for adding feature X - What might break adding feature X vs. What do we gain by adding feature X
|
|
|
|
Pages: [1] :: one page |
First page | Previous page | Next page | Last page |