| Pages: [1] 2 3 :: one page |
|
|
| Author |
Thread Statistics | Show CCP posts - 0 post(s) |
Janya Rykayn
   |
Posted - 2007.01.02 13:29:00 -
[1]
Edited by: Janya Rykayn on 02/01/2007 13:32:33
One of the more unpleasant aspects of Eve gameplay is lag. Nobody would dispute that, least of all the devs.
One of the most unpleasant aspects of lag is the fact that it's not just the "perceived ticks" that lag, but the interface itself. In other words, I am unable to move windows. I'm unable to check item stats windows or do anything. I can't rotate the (frozen) camera and watch all the pretty eyecandy while I wait for the motion to resume.
If this one single thing could be corrected-- if the interface movement could be decoupled from network lags-- the entire gameplay experience would improve dramatically and the experienced lag would be vastly reduced for the end user.
In fact, if you were manipulating windows or looking at info screens during the lag, you might not even notice the hitch. But the fact that your windows freezes, that the entire application hitches, rubs the lag in your face and makes it impossible to ignore.
There is no reason why the entire client should freeze during lags. It makes no sense for the client UI to be locked while server communications are happening, especially since much of the game is written in a supposedly thread-friendly version of Python.
I respectfully urge the devs to read and consider this. If any further explanation is needed as to what I'm talking about, I'll be happy to provide it.
Thanks also for such an amazingly engrossing game as Eve.
|
Daygore Aracnus
|
Posted - 2007.01.02 14:39:00 -
[2]
i would love to be able to open the market and carry on playing lol
crew idea
skill calulator in game |
Janya Rykayn
|
Posted - 2007.01.02 15:57:00 -
[3]
That's a great example of what I'm talking about. Why, when downloading market information, should I be unable to move the EVE window while it's downloading? I'm able to do this in far more network-intensive applications, and the presentation layer should be decoupled from the network layer, so why is this not the case?
The Eve structure and backend are amazing. The client is, and has always been, rather terrible in many ways. The fact that the UI becomes unresponsive during network lag is symptomatic of that; it's just sloppy coding.
|
Niaski Zalani
Infinitus Odium
|
Posted - 2007.01.04 00:01:00 -
[4]
 Originally by: Janya Rykayn
That's a great example of what I'm talking about. Why, when downloading market information, should I be unable to move the EVE window while it's downloading? I'm able to do this in far more network-intensive applications, and the presentation layer should be decoupled from the network layer, so why is this not the case?
The Eve structure and backend are amazing. The client is, and has always been, rather terrible in many ways. The fact that the UI becomes unresponsive during network lag is symptomatic of that; it's just sloppy coding.
It's more an issue of the UI being damn lazy with it's drawing, and damn inefficient at it too. The network layer in EVE is decoupled from the UI, it's threaded, with a bunch of callbacks to update window contents whenever new data comes in. Just that the window part of the UI is crud. Which, if I recall correctly, has been somewhat acknowledged by the devs, which is why they're doing new UI stuff in the graphics update thing. Or so I heard.
yarr. |
Seruph
|
Posted - 2007.01.10 06:58:00 -
[5]
Its in Python isn't it? If so, then theres your problem right there. Please lets not have a UI that takes 3 and a half hours to garbage collect and is incapable of rendering a 700k text document in real time. Try loading a 700k text document in the IGB then viewing source. I recommend you grab lunch.
What I would like to see is, instead of DirectX Fullscreen mode, at least having an option for the "Maximized" mode that ShiftWindow, EVE Launcher, and all those other programs use. The one thing they lack is removing the window decorations so that special themes don't make the fonts blurry and so that the window decorations don't stick out onto second monitors. It could then be possible to decouple the UI from the viewport so we could still have our UI elements without having to have the viewport open. Chat in EVE without having to have it using up all that screen space would be a plus and have the added bonus of not stalling the whole game when you try to do something weird with the IGB.
At any rate, running all that python dribble in a separate thread from the rendering with some clever message passing would improve the game play experience immensely. Maybe add some preemption to python's scheduler so you didn't have to wait for a UI task to complete before updating other UI elements. That way searching the market wouldn't make it impossible to chat or interact with other ui elements.
|
Tareen Kashaar
eXin Alliance
|
Posted - 2007.01.12 14:54:00 -
[6]
/signed
Nothing to add really... I hope the UI gets a LOT of love in the next engine.
---
WTS: Forum Signatures, 30mil a piece. Evemail me!
|
Solbright
|
Posted - 2007.01.15 05:36:00 -
[7]
Yep, the network is already decoupled. The problem is more upfront in the client with the 2D renderer in particular and, I suspect, excessive object thrashing in general.
Lag is not the problem here. Major client stutter only kicks you in the face after the network packets have arrived and it needs to be displayed, at which point the above slow code single mindedly hogs the CPU to produce the updated display.
One change in this area with the Revalations patch that I noticed - CCP changed the overview's method of updating the item distances so that they are redrawn only one at a time instead of all at once. Nice improvement imho.
|
GeekWarrior
Gallente
e X i l e
|
Posted - 2007.01.20 03:30:00 -
[8]
/signed, I've been complaining about this forever.
-----------------------------
EVE Addict, creator of the EVE Online Forms Greasemonkey Script \o/ |
Valandril
Caldari
Resurrection
R i s e
|
Posted - 2007.01.20 11:23:00 -
[9]
Yes, i'm signed into it, its very very bad when 40 man fleet jumps on your 50man fleet and they start decloaking.
1 person decloak - screenlag
next person - screenlag and before everyone load, u can get poped.
-----------------
Flamedrone II belonging to Valandril perfectly strikes you, wrecking your topic. |
Za Po
Caldari
|
Posted - 2007.01.24 15:19:00 -
[10]
When I change a market order, after ten seconds or so, the wallet window refreshes. This freezes the interface for about 4 seconds.
Until now, I assumed that this is because the game is requesting full order info, which might reasonably take 4 seconds to get from the network, and because of bad threading this freezes the interface.
But some people here are saying that the client is already well decoupled, and that the issue is with the UI thread itself.
So, are you telling me that the client actually takes four freakin' seconds to build a list of 250 items, of which only 30 or so are shown, and for which the data to display has already been fetched?!? 
If this is true, well, I definitely hope they are really looking into it (as in: throwing the library away). That's worse than your average Windows list by orders of magnitude. Python being bad, not that I'm an expert on python, isn't enough to justify this. Hell, I have written programs that can compile from C++ code, start and fill a 2500-elements list in less than four seconds.
In fact, it's so ridiculously bad that I am hard pressed to believe it. Is there any proof that the client isn't simply waiting on the network?
|
|
|
Solbright
|
Posted - 2007.01.24 20:57:00 -
[11]
Ya, that's exactly what is being said. Also, this has been one of Eve's enduring features.
As for proof, I guess not, but the 6 second part of your write-up I'd put down to lag so that only leaves stutter for the remaining 4 seconds. And it should be possible to show the network activity for that market/wallet update had completed at the end of the 6 seconds.
|
Tesal
|
Posted - 2007.03.09 04:50:00 -
[12]
That explains a lot. I average about 2 sales a minute for my salvage purchasing operation, sometimes as many as 6 a minute. Except for Jita, I purchase region wide for the most part. No wonder I am so sluggish. LOL.
This is one of the real drawbacks to a real commodities market on Eve. If the lag was under control the prices would go up for sellers because people could buy and sell region wide easily. Buyers could also rely on a more even price.
One thing that may help is some kind of aggregation skill that could be learned where you could transfer items remotely more easily, or perhaps a pay service of some kind.
|
Shimakaze
The Intergalactic Federation
Knights Of Syndicate
|
Posted - 2007.03.09 06:09:00 -
[13]
There's also significant lag whenever I open up the Browse view of the Market in addition to the client-freeze when the Market is loading the list of orders. I suspect that for every category that is expanded in the Browse tree, the client fetches from the server the availability of every item within the category (since an item isn't listed in the tree if there are no orders available in the specified range), and this is done every time the Browse view is opened. For some reason, the client freezes the UI while waiting for this data. It's either that, or the code to display a tree is horribly inefficient. The more categories expanded the longer the UI stays frozen it seems. So every now and then I go through the long list of opened categories in the Market to minimize them, or force myself to contract a category as soon as I'm done with it. As a partial solution, could we at least have a button somewhere that would collapse the entire browse tree?
-------------
|
Solbright
|
Posted - 2007.03.30 09:09:00 -
[14]
I just run the market test again and result has changed for the better. :) Not sure which patch made the improvement but I can regularly bring up, say, the Spaceship Command skills for browsing and they now almost have no stutter at all. Compared to earlier tests, that had a massive seconds long stutter, this is a nice improvement.
I guess CCP are doing some tweaking but it's got a long way to go still to fix things like fleet engagements.
|
Aragonis
Heroic Legion
|
Posted - 2007.03.30 09:23:00 -
[15]
I think the problem with the market loading is generating all the treeview objects and parsing the data into the Groups tab.
Something really needs to be done about this problem.
---
|
Oblom
Minmatar
Sebiestor tribe
|
Posted - 2007.03.30 13:11:00 -
[16]
Decoupled you say? I see 5 threads there and 4 of them belong to audio. That leaves one thread for the game. Of course, it's possible to make something like this work as a single task using some kind of internal scheduler, but it's not practical. So I think it's plain obvious that the whole thing just waits dead frozen for server requests to complete while you listening to the music.
|
Tar om
Minmatar
Octavian Vanguard
RAZOR Alliance
|
Posted - 2007.03.30 16:41:00 -
[17]
The music which every PvPer switches off within 30 seconds of his first podkilling....
--
We are the Octavian Vanguard www.octavianvanguard.net
"The belief in the possibility of a short decisive war appears to be one of the most ancient and dangerous of human illusions." |
Oblom
Minmatar
Sebiestor tribe
|
Posted - 2007.03.30 18:44:00 -
[18]
All I wanted to say is that only thing that don't freeze is music  Because it runs in a separate task.
|
Xianthar
STK Scientific
Rule of Three
|
Posted - 2007.03.30 20:18:00 -
[19]
Originally by: Seruph
Its in Python isn't it? If so, then theres your problem right there. Please lets not have a UI that takes 3 and a half hours to garbage collect and is incapable of rendering a 700k text document in real time. Try loading a 700k text document in the IGB then viewing source. I recommend you grab lunch.
What I would like to see is, instead of DirectX Fullscreen mode, at least having an option for the "Maximized" mode that ShiftWindow, EVE Launcher, and all those other programs use. The one thing they lack is removing the window decorations so that special themes don't make the fonts blurry and so that the window decorations don't stick out onto second monitors. It could then be possible to decouple the UI from the viewport so we could still have our UI elements without having to have the viewport open. Chat in EVE without having to have it using up all that screen space would be a plus and have the added bonus of not stalling the whole game when you try to do something weird with the IGB.
At any rate, running all that python dribble in a separate thread from the rendering with some clever message passing would improve the game play experience immensely. Maybe add some preemption to python's scheduler so you didn't have to wait for a UI task to complete before updating other UI elements. That way searching the market wouldn't make it impossible to chat or interact with other ui elements.
the graphics engine is written in C++ to my knowledge....and it exists in a seperate module from the python code and uses callbacks to communicate between them.
the reason the interface stops is because this it is waiting on the network connection for data needed for rendering. It can't draw a ship unless it knows where to draw it. Some games, FPS mostly, have "predictive" code that, when a server update is not available makes a general guess as to where things are moving. If you've ever played a FPS on a crappy internet connection and been running along then all of a sudden to are jump to another place then you have experienced what happens when the prediction code guesses wrong. At some point in the dev work at CCP they decided against any sort of predictive code structure, probably because eve is not a game where you want what you see to be out of sync with what is really happening, it could lead to a poor decision which could cost you months of work. its not like BF2 where you just respawn with all your stuff.
there are impovements that could be made to the UI but predictive movement is not one of them IMO. i'd much rather have an option to completely dumb down rendering for fleet fights....i.e. draw all ships are simple flat shaded cubes and just keep the overview the same.
-xian
Your signature exceeds the maximum allowed filesize of 24000 bytes -Sahwoolo Etoophie ([email protected]) |
Solbright
|
Posted - 2007.03.30 22:33:00 -
[20]
Come on guys, think about was is happening. Take the market example: The servers will still take the same 6 seconds to respond. Just the client no longer has the extra 4 second stutter. Also, it's silly to think the client would be "busy-waiting".
As for achieving decoupling, you certainly don't need multi-threading for that.
|
|
|
Solbright
|
Posted - 2007.03.30 22:37:00 -
[21]
Ugh! Also, predictive coding is a done thing in Eve. Why do you think you get repeating warp-ins, damage happening before the missile hits, jumping drones and the likes.
|
Oblom
Minmatar
Sebiestor tribe
|
Posted - 2007.03.31 01:56:00 -
[22]
Edited by: Oblom on 31/03/2007 02:03:22
Lag is a common problem for any online game. But stopping screen updates completely while waiting for server to respond is just a sloppy program design. Nothing more. Not a "decision they made." You render what you can. You know where your ship moves, you render it. You know where static objects are, you render them. And you do it all the time. You don't know where dynamic objects are, you do something different. Predict therir movement or don't display them at all. But just freezing the screen is real mess and not an answer. Especially when completely unrelated things like opening market window cause the whole thing become dead. This is design error, admit it.
EDIT:
Xianthar, you mentioned other games. With lag causing jumping. Whose are FPS or sim games where players actulay aiming at moving objects. Here it's entirely different story. You don't really aim. So jumping won't matter much. Also jumping is better then completely freezing your client, because other players can see and target you while you can do nothing.
|
Oblom
Minmatar
Sebiestor tribe
|
Posted - 2007.03.31 02:23:00 -
[23]
Originally by: Solbright
Edited by: Solbright on 30/03/2007 22:58:15
...
As for achieving decoupling, you certainly don't need multi-threading for that.
It can be done and it was done numerous times. But it makes program structure rather complex. It used to makes sense under DOS and on weak processors where overhead of the real time OS was too high. But now it really doesn't matter. Using multiple tasks simplifes overall program structure and makes it easier to maintain.
|
Solbright
|
Posted - 2007.03.31 02:34:00 -
[24]
Lag is not the cause of stutter. Decoupling is pretty simple really and prolly easier to do in a single thread than trying to use IPC functions.
|
Oblom
Minmatar
Sebiestor tribe
|
Posted - 2007.03.31 02:45:00 -
[25]
Originally by: Solbright
Lag is not the cause of stutter. Decoupling is pretty simple really and prolly easier to do in a single thread than trying to use IPC functions.
It depends. You need to use asynchronous I/O for everything with exit/callback routines or check on status quite often inside other portions of the code and jump to differnt places, figuring out priorities and deciding what to do next. It's just makes program structure real messy. And IPC only hurts foe fiew minutes till you figure it out.
|
Solbright
|
Posted - 2007.03.31 03:15:00 -
[26]
Yeah, right! Like IPC is trouble free. Why do you think multi-threading hasn't been the norm since multi-tasking OSes have been all the rage on the desktop for a couple of decades atleast.
|
Oblom
Minmatar
Sebiestor tribe
|
Posted - 2007.03.31 06:11:00 -
[27]
Originally by: Solbright
Yeah, right! Like IPC is trouble free. Why do you think multi-threading hasn't been the norm since multi-tasking OSes have been all the rage on the desktop for a couple of decades atleast.
I didn't say multithreading or multitasking is trouble free. It's trade of. By using external scheduler (provided by OS) you usually get some performance penalty. Especially in OS with preemtieve multitasking. You can spend more time scheduling then processing. On the other hand separating real time application into separate tasks handled by OS lets you make the code simpler and better structured.
|
Solbright
|
Posted - 2007.03.31 10:04:00 -
[28]
Getting back on track. I'd just like to say, from observation ie: the now smooth market test, that stutter is not when the client is waiting for server response. At best, stutter is a result of too much data arriving from the server. The client has so much processing to get through before getting back to the display loop that you see a frozen display.
Actually, it's not really a case of the quantity of data either, it's more about the client's slow execution with this new data. Aka, bloatware rearing it's ugly head, or sloppy coding or whatever other evil sounding name is fitting.
|
Oblom
Minmatar
Sebiestor tribe
|
Posted - 2007.03.31 17:16:00 -
[29]
Too much data or not - it doesn't matter. Updates of the screen with available information should never stop. Like own ship, static surroundings and things like blinking stars  . Arriving data can be buffered and processed as time allows. There will be delay with displaying some objects, but no freezes. Then you optimize the code and see what can be done to make things faster. But I still think that in most cases it caused by server side delays with client just sitting frozen doing nothing while waiting for server to respond.
But again, it doesn't reallly matter. We are not going to fix it. We only can make a little bit of noise on the forums about it. Question really is will CCP ever attempt to fix it?
|
Solbright
|
Posted - 2007.03.31 22:24:00 -
[30]
Originally by: Oblom
Too much data or not - it doesn't matter. Updates of the screen with available information should never stop. Like own ship, static surroundings and things like blinking stars . Arriving data can be buffered and processed as time allows. There will be delay with displaying some objects, but no freezes. Then you optimize the code and see what can be done to make things faster.
Good stuff. Couldn't have said it better. :)
Quote:
But I still think that in most cases it caused by server side delays with client just sitting frozen doing nothing while waiting for server to respond.
http://oldforums.eveonline.com/?a=topic&threadID=497236
- Check the posting by Nonym Ous in particular, you get a good descripton of someone dealing with lag but no stutter. I bet, however, if he'd had the full force of the battle, ie: very little lag, he'd not only have had a dose of stutter to deal with he also would have been podded because of the stutter.
Quote:
But again, it doesn't reallly matter. We are not going to fix it. We only can make a little bit of noise on the forums about it. Question really is will CCP ever attempt to fix it?
Well, isn't that a good enough reason? To make some noise so CCP takes action?
|
|
|
|
|
| |
|
| Pages: [1] 2 3 :: one page |
| First page | Previous page | Next page | Last page |