| 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?
|
|
|
Oblom
Minmatar
Sebiestor tribe
|
Posted - 2007.04.01 03:44:00 -
[31]
Edited by: Oblom on 01/04/2007 03:48:15
Originally by: Solbright
Well, isn't that a good enough reason? To make some noise so CCP takes action?
They don't care and they don't listen. I started playing this game in 2005. And I quit. One of the reasons was this client freeze thing. People did talk about this back then. But no reaction on CCP part. And I just couldn't tolerate it after playing other games that don't have this problem. Actually no other game on the market has it this bad. EVE is the all time record keeper in screwd up programming. It was too irritating to me. The reason I am back is because CCP spam mailed me with 7 day free offer. I took it hoping that they made things better. Well, they didn't. They did other changes to the game that I care less at my level, but they didn't fix the things that bothered me most. I was stupid enough to give them another 15 bux just to make sure they have their priorities really screwd up. I found they they have. My fault. It was quite obvious during first couple of hours. So see you later CCP till the next 7 days free offer. But next time I will pay nothing.
|
Solbright
|
Posted - 2007.04.01 05:05:00 -
[32]
There's the rub, noone has been complaining about stutter. So how can CCP react if all is well? Everyone complains about the cluster lagging problem, and are completely silent on the client stutter problem except to tell the few little bleeps to shutup and buy a faster PC.
|
Solbright
|
Posted - 2007.04.08 06:15:00 -
[33]
After some more arguing about what is lag what is stutter in yet another thread. Be warned, there is multiple links back to this thread in there. 
As mentioned in there I've realised that the same stutter fix that was done for the market rendering can be applied pretty much verbatim to combat also. It's not a complete fix but it's a good start and it's an obvious incremental improvement that I'd expect CCP are already at work on.
|
Xianthar
STK Scientific
Rule of Three
|
Posted - 2007.04.10 02:37:00 -
[34]
Originally by: Solbright
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?
2 weeks post patch: everyone *****es about why the ship that their client thought was 15km away should have been scrammed when the server thought the ship was actually 80km away.
-xian
Your signature exceeds the maximum allowed filesize of 24000 bytes -Sahwoolo Etoophie ([email protected]) |
Elain Reverse
Caldari
Shokei
|
Posted - 2007.04.10 03:28:00 -
[35]
Originally by: Xianthar
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
How then you can freely fly over system when you client is desynchronized if it waiting for server teling him what to do?
|
Solbright
|
Posted - 2007.04.10 21:21:00 -
[36]
Originally by: Xianthar
2 weeks post patch: everyone *****es about why the ship that their client thought was 15km away should have been scrammed when the server thought the ship was actually 80km away.
This thread is about the client stuttering. You appear to be talking about lag effects.
|
Princesse Qiao
|
Posted - 2007.04.11 08:47:00 -
[37]
Originally by: Xianthar
2 weeks post patch: everyone *****es about why the ship that their client thought was 15km away should have been scrammed when the server thought the ship was actually 80km away.
-xian[/quote
This is interesting in relation to the 'distance bug':
what's interesting is that not only is there a disparity between client and server info but that the client once it has its own distances fixed seems to reject server updates to the contrary
|
Solbright
|
Posted - 2007.04.11 10:03:00 -
[38]
Edited by: Solbright on 11/04/2007 10:01:48
Originally by: Princesse Qiao
... but that the client once it has its own distances fixed seems to reject server updates to the contrary
Prolly not any new updates coming from the server. The server only sends updates for changes to the world simulation. If the model of the object motion is not changing then there is no further updates needed.
The client runs it's own world simulation that should closely match what is on the server. Sometimes this will get out of synchronisation for one or more objects and only getting straighten out when there is an update for that object.
A common reason for loss-of-sync is packet loss over the internet.
|
Solbright
|
Posted - 2007.04.11 10:28:00 -
[39]
Edited by: Solbright on 11/04/2007 10:33:58
I'm doing a lot of guessing of course, and the reality will be more complex that my summary.
One example of a bulk update that can straighten out much loss-of-sync is where the Overview is closed and reopened. When this is done the client requests a full refresh of the Overview info which the server will respond to.
Edit: Suck, nope, not true. Assumed too much there. Dunno why it has such a big stutter then if there is no new info for it.
|
Solbright
|
Posted - 2007.04.12 08:33:00 -
[40]
Guess that also makes the Overview refresh trick a debugging hack that has been left in for everyone to enjoy. Could do with some more of those for helping keep the game on it's feet.
|
|
|
Sal Alo
Minmatar
Sebiestor tribe
|
Posted - 2007.04.15 15:11:00 -
[41]
Originally by: Oblom
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.
/signed 101%
Whoever is afraid of death dies every day. Whoever isn't, dies only once. |
Solbright
|
Posted - 2007.04.15 22:19:00 -
[42]
Originally by: Sal Alo
Originally by: Oblom
... cause the whole thing become dead. This is design error, admit it.
/signed 101%
Except, imho, that won't be the design. It will be decoupled, ie: lag can't cause a stutter. The client code is simply too slow is all. It doesn't even need any server input and it still struggles big time. The client isn't handling the job of simulating and rendering, period.
It's still in beta, needing a major optimisation before releasing on the paying customer.
|
Solbright
|
Posted - 2007.04.21 08:50:00 -
[43]
For the record: Stutter and lag are two quite different beasts
because of Decoupling via the local simulator
which means Blocking against the server won't happen
|
Solbright
|
Posted - 2007.04.26 00:12:00 -
[44]
As for what is the cause of stutter and poor framerate in general. I now have two reasons that fit observation rather well:
- Boring old bloat. This has been my favorite but a recent hint suggests it might not be the main cause. That's not to say bloat isn't a problem! I'm not going to let it slide that easy. :)
- Flawed caching of geometry and texture data. This has been listed before but I've generally ignored it as too obvious and solved already. The recent hint made me think CCP intend to decouple the fetching so the data won't be needed to complete a rendering pass. The data will be used as it becomes available from the HDD. This method has the nice bonus of not needing to restrict the total number of models to a certain memory footprint.
I am still concerned that decoupling the texture fetching like this, while it's bound to have a big impact on stutter, it won't help general framerate at all. I guess that's where the other optimisations and redesigns come in.
Have to wait another year to find out ...
|
Solbright
|
Posted - 2007.04.26 22:30:00 -
[45]
The above flawed caching hint comes from this little present in the form of "better asynchronous resource loading". And, here's the follow up thread.
We finally have the long overdue acknowledgement of the client based issues covering both low fps and stutter. :)
|
solbright altaltalt
|
Posted - 2007.06.20 22:56:00 -
[46]
Just got another hugh hint of where CCP have gone badly wrong with the coding. With the release of Rev2 the cache files are shifted by default, Interface lag, into the middle of the windoze files. This has highlighted an increase in stutter for those that had Eve installed on a separate partition. It seems HDD performance is affecting Eve big time! Very poor coding there CCP. :(
I'm going to have to try setting up a ramdisc me thinks ...
|
Trilium Eagle
|
Posted - 2007.06.25 11:41:00 -
[47]
The file location change fortunately can be reversed by switches on command line so files are used from last place.
As for lag lately in mornings we had situations where three corp members were unable to !mine! due to lag and inability to move cargo from bay to cans. Getting drones to bay took few minutes and they were sitting on roid few km's from ship.
Something really gotten wrong with server 
|
solbright altaltalt
|
Posted - 2007.06.25 12:15:00 -
[48]
Originally by: Trilium Eagle
The file location change fortunately can be reversed by switches on command line so files are used from last place.
Yeah. But it's not a real fix, sadly. The ramdisc trick helps even more but isn't really enough either.
Quote:
As for lag lately in mornings we had situations where three corp members were unable to !mine! due to lag and inability to move cargo from bay to cans. Getting drones to bay took few minutes and they were sitting on roid few km's from ship.
Something really gotten wrong with server
These things happen after after such large patches. CCP will fix it up. No biggie really. Unlike stutter.
|
Psorion
Absolute Wrath Inc.
Executive Outcomes
|
Posted - 2007.07.10 12:36:00 -
[49]
More stutter..
1: Warp to an object greater than 20AU
2: Make a bookmark mid warp.
3: Observe the stutter as the people-place loads.
Cloaked and AFK at a system near you... |
Jim McGregor
|
Posted - 2007.07.11 16:55:00 -
[50]
New client with new network layer soon. Perhaps it will make the client more responsive in the ways you mention here.
---
Originally by: CCP Wrangler
You're not supposed to feel like you're logging in to a happy, happy, fluffy, fluffy lala land filled with fun and adventures, thats what hello kitty online is for.
|
|
|
Frug
Zenithal Harvest
|
Posted - 2007.07.13 22:49:00 -
[51]
I think it's fairly obvious that nothing's decoupled and that the market lag is due to the whole client waiting for an update.
- - - - - - - - - Do not use dotted lines - - - - - - -
If you think I'm awesome, say BOOO
BOOO!! - Ductoris
Neat look what I found - Kreul
Hey, my marbles |
Solbright
Advanced Security And Asset Protection
|
Posted - 2007.07.14 11:06:00 -
[52]
Edited by: Solbright on 14/07/2007 11:10:37
Originally by: Frug
I think it's fairly obvious that nothing's decoupled and that the market lag is due to the whole client waiting for an update.
There is no one cause. Lag exists. And stutter exists.
The client is decoupled completely. Which is why you get rendering while waiting for the response to a market listing. And you can click on other stuff during that time.
But when the market data arrives is when the client freezes for a short period while it handles the influx. This is the part that I call "stutter".
Stutter is fixable in a permanent sense. This is why I'm a stickler for having separate names for lag and stutter.
|
Solbright altaltalt
Republic Military School
|
Posted - 2007.07.19 14:30:00 -
[53]
Here's the proof for those that doubt the client has it's own decoupling.
And another outline of the differences between lag and stutter and the role of the client's simulator.
|
Solbright altaltalt
Republic Military School
|
Posted - 2007.08.08 05:23:00 -
[54]
Oooo, a nice bit of info from CCP Explorer.
It indicates there are conditions that trigger an automatic total reload of the client's world model.
|
Andrue
Amarr
|
Posted - 2007.08.11 09:45:00 -
[55]
Originally by: Za Po
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?
The main trick is not to fill the list in the first place. If you use a virtual listview you can handle millions of items with no lag.
--
(Battle hardened industrialist)
[Brackley, UK]
This is not a signature |
Andrue
Amarr
|
Posted - 2007.08.11 09:53:00 -
[56]
Multi-threading doesn't always help. It only helps if the tasks are accessing resources that can operate independantly. That typically means that only one thread can be using the CPU. The rest have to be talking to hardware.
Of course multi-core and hyperthreading CPUs help but each core still only allows one other CPU intensive thread to run. If you have a dual core CPU it can still only do two things involving the CPU at once. That's better than a single core but since the OS is always sniffing around it still doesn't give Eve the ability to always do two things at once.
If the market list is having to be processed and if the OS is using the CPU then Eve cannot update the screen no matter how multi-threaded it is unless you have a triple or quad core.
What multi-threading mostly does is let you have separate tasks for dealing with hardware to avoid polling algorithms. It also makes it a bit easier to share the CPU between different tasks. The latter means that instead of the screen not drawing for several seconds it draws in chunks taking turns with the other CPU tasks. For some things that's fine but actually for the screen it isn't acceptable. Thus sometimes you have to accept that the screen (or elements of it) will pause.
Having said all that I do suspect that Eve's UI could be improved. The market rendering delay suggests they aren't using a virtual list view. That means they get all the data and prepare it for rendering. Virtual list views allow you to only get and prepare the data that is actually visible.
--
(Battle hardened industrialist)
[Brackley, UK]
This is not a signature |
Solbright altaltalt
|
Posted - 2007.08.11 11:28:00 -
[57]
Originally by: Andrue
[Pile of techno-babble]
But, meh - this is all speculation. CCP developers aren't idiots and I doubt the UI issues are the result of crappy programming.
That one's still up for debate. I have a lot of respect for the designers and the effort/risk of the Eve experiment but the client's implementation just isn't cutting it. There has been no real improvement. Sometimes, when the stutter gets real bad, they look at fixing some small part that got way out of hand but never really solves stutter. And it is very solvable.
Quote:
It's risky to make predictions about cause/effect even when you have the source code. Doing it from the customer side of our relationship is almost bound to fail 
Well, there's no doubt about the client being solely responsible for stutter. And there's no good reason for stutter to persist over years of development.
|
Solbright altaltalt
|
Posted - 2007.08.11 12:01:00 -
[58]
Apologies if that came across a bit aggressive but you did defended CCP's performance over what is now 7(?) years of development. And greater than 4 years since official launch.
|
Andrue
Amarr
|
Posted - 2007.08.12 14:21:00 -
[59]
Originally by: Solbright altaltalt
Apologies if that came across a bit aggressive but you did defended CCP's performance over what is now 7(?) years of development. And greater than 4 years since official launch.
Yes and that's actually a very impressive feat. The fact it still does the job it was intended to and can still be added to shows that CCP did a lot of fundamental things right. Far too many cool and impressive programs are unmaintainable piles of crap.
But..I don't defend everything about the UI, nor CCP itself. If you search the forums you'll find some quite strong criticisms (especially of the UI design). In fact my post doesn't really defend them. There is a quite strong criticism of them if they really aren't using a virtual listview or equivalent.
--
(Battle hardened industrialist)
[Brackley, UK]
This is not a signature |
Solbright altaltalt
|
Posted - 2007.08.12 14:58:00 -
[60]
That and bloatware which makes the codebase insanely slow.
|
|
|
Solbright
Advanced Security And Asset Protection
|
Posted - 2007.09.11 00:21:00 -
[61]
Edited by: Solbright on 11/09/2007 00:23:07
Oveur's new blog on Rev 3 and Trinity 2 doesn't indicate any attempt to solve stutter. Feeling a little depressed ... well, there is not much actually said beyond new features so I guess I shouldn't view that as nothing changed.
------
Vote for Low graphics client |
Grez
Minmatar
Sybrite Inc.
|
Posted - 2007.09.11 16:56:00 -
[62]
Originally by: Solbright
Edited by: Solbright on 11/09/2007 00:23:07
Oveur's new blog on Rev 3 and Trinity 2 doesn't indicate any attempt to solve stutter. Feeling a little depressed ... well, there is not much actually said beyond new features so I guess I shouldn't view that as nothing changed.
ALL of the graphical rendering has now been moved off the CPU and onto the GPU, which means pretty much, if your getting stuttering, and it's graphics related, you should see a huge improvement with the new engine. That, or it'll indicate that your system has a problem with it's system bus being tied down with something.
---
|
solbright altaltaltalt
|
Posted - 2007.09.15 10:50:00 -
[63]
Originally by: Grez
ALL of the graphical rendering has now been moved off the CPU and onto the GPU, which means pretty much, if your getting stuttering, and it's graphics related, you should see a huge improvement with the new engine. That, or it'll indicate that your system has a problem with it's system bus being tied down with something.
Eve certainly benefits alot from having hardware rendering so it's not really a software renderer. It may have started out that way but hasn't been so for some years me thinks.
At any rate, it's not the renderer per-se that I'm worried about as that's not what is causing stutter. Stutter is more an indirect issue. One example that is often quoted is that when a texture is loaded from the HDD the renderer might block on the loading and the display freezes as a result.
|
solbright altalt
State War Academy
|
Posted - 2007.09.30 03:24:00 -
[64]
After a little bit of incentive I decided to writeup a better description of how lag functions.
The only other tidbit I can think of atm is why rendering speed (framerate) is not a part of game mechanics. This primarily hinges around the earlier mentioned simulator in the client. Which decouples processing of game mechanics in the server from that in the client, freeing the client to continue predicting object motion somewhat independently of the server.
|
Solbright altaltaltalt
|
Posted - 2007.10.02 07:37:00 -
[65]
I just looked up some dictionary definitions for "lag". They are mostly example based but one thing does stand out - comparison to a reference. There is always something to compare against for an expectation, the difference is the lag.
So, my idea around feedback mechanics being the basis of lag was just one of many applications. Thanks go to Capn Hack for nudging me in the right direction there.
When it comes to 3D game framerates, the function is not defined like that. There is the user's expectation but that is not really a reference when you consider how the current crop of 3D renderer's are written.
Your average 3D renderer makes no attempt to achieve a target framerate. It just renders the whole frame in a buffer then pops that to the display and immediately starts work on the next frame with no restriction on how long that will take to complete. The objective is to finish the rendering at the defined detail and quality levels with the available objects.
|
Solbright altaltaltalt
|
Posted - 2007.10.07 02:07:00 -
[66]
A nasty little stutter that has become more notable this year is the first time the context menu is popped up in space. For some reason it freezes the display for a short period. If this happens when there is a lot happening then the freeze lasts longer. It's situations like this that can get badly out of hand. :(
I've occasionally checked if it could be a lag side effect (I've been proven wrong before.) but there is no indication of network traffic arriving prior to the menu being drawn up. It's looking like the problem is purely within the client! As unbelievable as that seems.
The whole situation with stutter is not really acceptable. I can safely say that if the next few months with Trinty2 and co don't make a decent dent in stutter I'll be done with Eve.
|
Xaen
Caldari
Caldari Provisions
|
Posted - 2007.10.09 15:20:00 -
[67]
Originally by: Janya Rykayn
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.
Putting the client GUI in it's own thread separate from the network thread would accomplish this.
See the link in my sig.
CCP, see Model View Controller pattern plz.
-----------
Support fixing the EVE UI |
solbright altalt
|
Posted - 2007.10.22 00:23:00 -
[68]
Oops, I'm getting lazy, forgot to post the good news. A strong hint of a fix for the worst of stutter in Trinity: The expansion you have to see.
Quote: "It is, in fact, a brand new graphic engine, tuned and tweaked with everything from asynchronous resource loading to intelligent fallback mechanisms to give the best performance possible, and we're very proud of it."
The asynchronous resource loading should provide for much smoother framerates. :)
One thing of note is that this feature removes the need for prefetching of data from the HDD and presending of data from the servers. Makes the server coding simpler. Win-win all round. :)
|
|
|
| |
|
| Pages: 1 2 3 :: [one page] |