Pages: [1] 2 :: one page |
|
Author |
Thread Statistics | Show CCP posts - 1 post(s) |
Adel Sorra
Gallente Steel Beasts Cold Steel Alliance
|
Posted - 2007.10.12 21:44:00 -
[1]
THANK YOU!
read more
|
Solbright altaltaltalt
|
Posted - 2007.10.13 10:03:00 -
[2]
Fingers crossed for it to hit stutter out of the park.
|
Grace Manturi
|
Posted - 2007.10.14 01:06:00 -
[3]
What does that mean?
|
Solbright altaltaltalt
|
Posted - 2007.10.14 03:06:00 -
[4]
Originally by: Grace Manturi What does that mean?
"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."
Asynchronous resource loading in this case I believe refers to decoupling the rendering engine from the file loading of the data that makes up the display. So, for example, if a ship model is not in memory and still to be fetched from the HDD then the rendering engine will steam ahead without it and just place a default blob on the display. When the data is loaded and can be used for rendering it will be displayed correctly.
The feature could be extended to other parts of the client also. Even menus could benefit, instead of freezing the display for a second or two while the menu gets constructed it could instead display a blank panel that gets filled in a few seconds later. Market updates are known for this issue.
|
Valeo Galaem
New Eden Advanced Reconnaissance Unit
|
Posted - 2007.10.14 05:25:00 -
[5]
Originally by: Grace Manturi What does that mean?
In even simpler terms...
If your hard drive is slow or needing to do a lot of work for EVE, the game won't lag.
Thar be Pirates
You are not authorised to hack into CONCORD's mainframe Your Wallet has been emptied!
CONCORD Encryption Methods |
solbright altalt
|
Posted - 2007.10.14 06:08:00 -
[6]
Originally by: Valeo Galaem If your hard drive is slow or needing to do a lot of work for EVE, the game won't lag.
Not quite right. The HDD is one source of stutter. The speed of the HDD will affect how bad the stutter is as will other factors. But a fast HDD does not fix the problem even if the HDD was the sole contributor to stutter.
The client was just badly written is all. Hopefully the new one is up to the job.
|
Tonto Auri
|
Posted - 2007.10.14 09:53:00 -
[7]
Originally by: solbright altalt The client was just badly written is all. Hopefully the new one is up to the job.
Not quite right (c). It is still written in python (huge part of it). -- Thanks CCP for cu<end of sig> |
Xordan
Caldari Meridian Dynamics FREGE Alliance
|
Posted - 2007.10.14 10:23:00 -
[8]
It means that the area of code which handles loading is run in a seperate thread to the rest of the engine. The engine will tell this loader what needs loading and then continue rendering and doing everything else while the loader loads, simultaneously. Then when whatever has been requested to be loaded is loaded, the engine will make use of it. The advantage of having them asynchronous to each other are that the engine doesn't have to stop doing everything else when it needs to load something = performance improvment. Also you can undock and start flying around while everything is still loading, which should help those with slower HDD's as they won't have long wait times when undocking.
|
solbright altalt
|
Posted - 2007.10.14 10:48:00 -
[9]
Originally by: Xordan ... which should help those with slower HDD's as they won't have long wait times when undocking.
It'll help those with the best money can buy also.
|
Adel Sorra
Gallente Steel Beasts Cold Steel Alliance
|
Posted - 2007.10.14 11:57:00 -
[10]
Originally by: Grace Manturi What does that mean?
Reminder to myself: not everyone on the internet has a technological background
|
|
Shinhan
Phoenix Knights Dark Nebula Galactic Empire
|
Posted - 2007.10.15 10:00:00 -
[11]
Edited by: Shinhan on 15/10/2007 10:00:58 YAY, I hoped this would be a part of Trinity and its good to know that it is.
Originally by: Xordan Also you can undock and start flying around while everything is still loading, which should help those with slower HDD's as they won't have long wait times when undocking.
Maybe. With asynchronous loading they can probably allow the above scenario but its not certain they will.
I think this is more intended for menu lag and market lag.
-- Selling apples, 1 signature each. ѼѼѼѼѼѼѼ |
|
CCP Lingorm
|
Posted - 2007.10.15 11:35:00 -
[12]
Actually it will be applied to models.
So if a model is still loading then it will just render a default marker and carry on.
When the Async load is finished the graphics engine will then do a draw with ht new model.
Nice? We think so.
Look for some other tweaks that are coming soon.
CCP Lingorm CCP Quality Assurance QA Engineering Team Leader
|
|
Nomore Telindus
Gallente Pangalactic Punks n' Playboys Omega Alliance
|
Posted - 2007.10.16 14:37:00 -
[13]
Originally by: CCP Lingorm Look for some other tweaks that are coming soon.
Async grid loading (during warp) would be awesome.
|
Adel Sorra
Gallente Steel Beasts Cold Steel Alliance
|
Posted - 2007.10.16 17:52:00 -
[14]
Originally by: CCP Lingorm Actually it will be applied to models.
But you will enhance your window manager, right? loading the market won't freeze the screen, right? please, just say yes
|
ElfeGER
Black Eclipse Corp Band of Brothers
|
Posted - 2007.10.16 18:03:00 -
[15]
Originally by: Nomore Telindus
Originally by: CCP Lingorm Look for some other tweaks that are coming soon.
Async grid loading (during warp) would be awesome.
I would be glad if I would get anything to load at all but it doesn't even start to freeze the client most of the time
|
solbright altalt
|
Posted - 2007.10.16 22:15:00 -
[16]
Originally by: El***ER I would be glad if I would get anything to load at all but it doesn't even start to freeze the client most of the time
Now, now. No talk of lag in this thread please.
|
Dr Slaughter
Sebiestor tribe
|
Posted - 2007.10.17 08:41:00 -
[17]
Originally by: Nomore Telindus
Originally by: CCP Lingorm Look for some other tweaks that are coming soon.
Async grid loading (during warp) would be awesome.
based on your projected arrival point, loading objects in your optimal range as the highest priority? :)
|
Ticl Er
Sweetrock Mining Knights Of the Southerncross
|
Posted - 2007.10.17 14:39:00 -
[18]
Please provide a hotkey to disable model loading all together.
|
Eleana Tomelac
Gallente Through the Looking Glass
|
Posted - 2007.10.17 15:13:00 -
[19]
Originally by: Ticl Er Please provide a hotkey to disable model loading all together.
And eve going to ASCII art? -- Pocket drone carriers (tm) enthousiast !
Say hello to my tiny friends ! |
Nomore Telindus
Gallente Pangalactic Punks n' Playboys Omega Alliance
|
Posted - 2007.10.17 15:19:00 -
[20]
Originally by: Dr Slaughter
Originally by: Nomore Telindus
Originally by: CCP Lingorm Look for some other tweaks that are coming soon.
Async grid loading (during warp) would be awesome.
based on your projected arrival point, loading objects in your optimal range as the highest priority? :)
Ships are interactive, so predicting their movement is a bit tricky (And the result is ugly under lag situations. Try any FPS servers with high ping). But you can (almost) safely preload any non-moving objects; Buildings for the missioners and POS modules for the 0.0 pilots. Plus dreads/carriers in siege/triage mode.
|
|
solbright altalt
|
Posted - 2007.10.17 21:39:00 -
[21]
Edited by: solbright altalt on 17/10/2007 21:44:27
Originally by: Nomore Telindus
Originally by: Dr Slaughter based on your projected arrival point, loading objects in your optimal range as the highest priority? :)
Ships are interactive, so predicting their movement is a bit tricky (And the result is ugly under lag situations. Try any FPS servers with high ping).
There is a difference between object loading and the model/texture loading. Object loading, as you've pointed out, is dependent on the server pre-sending while everything else is dependent on the client pre-fetching from the HDD.
This thread is about the resources local to the client. Server talk is a dirty subject. :P
|
Jensius Duo
Damned Legion
|
Posted - 2007.10.17 22:55:00 -
[22]
Originally by: Ticl Er Please provide a hotkey to disable model loading all together.
Text-based EVE client anyone?
Quote: Jita Local> /overview #3 | 11km | RandomNublet | Velator #5 | 13km | Station | Jita IX - Moon 4 - Caldari Navy Assembly Plant Jita Local> /lock 3 Locking #3/RandomNublet (Velator)... (4.3s) Jita Local> /approach 3 Approaching #3/RandomNublet (Velator) Speed changed to 123m/s Jita Local> #3/RandomNublet (Velator) is locked Jita Local> 1M, to my wallet now! Pay or pray beotch! RandomNublet: Please no shoot me((( ...
|
Nomore Telindus
Gallente Pangalactic Punks n' Playboys Omega Alliance
|
Posted - 2007.10.17 23:56:00 -
[23]
Originally by: solbright altalt This thread is about the resources local to the client. Server talk is a dirty subject. :P
I know. But you can't prefetch anything if the server doesn't tell you what to load.
|
Dr Slaughter
Sebiestor tribe
|
Posted - 2007.10.18 09:47:00 -
[24]
Originally by: Nomore Telindus
Originally by: solbright altalt This thread is about the resources local to the client. Server talk is a dirty subject. :P
I know. But you can't prefetch anything if the server doesn't tell you what to load.
LOL to both of you. Pre-loading static objects starting within optimals from the x,y,z of your grid load would be nice, and don't load models which are 'filtered' in the hud would be... well.. interesting.
|
Ryysa
Caldari
|
Posted - 2007.10.20 12:43:00 -
[25]
Originally by: Dr Slaughter LOL to both of you. Pre-loading static objects starting within optimals from the x,y,z of your grid load would be nice, and don't load models which are 'filtered' in the hud would be... well.. interesting.
The main issue is imo server load when it comes to lag.
This actually might be a pretty good idea, but you'd need to store your overview settings on the server in that case.
Not that it's a bad thing. Not loading models clientside that are not on overview wouldn't really give that much of a boost to performance imo. Although it depends on how you view it. EW Guide - KB Tool - My Music |
solbright altalt
|
Posted - 2007.10.21 01:00:00 -
[26]
Originally by: Ryysa The main issue is imo server load when it comes to lag.
This thread is not dealing with lag or the servers.
Quote: This actually might be a pretty good idea, but you'd need to store your overview settings on the server in that case.
Huh? Explain.
Quote: Not that it's a bad thing. Not loading models clientside that are not on overview wouldn't really give that much of a boost to performance imo. Although it depends on how you view it.
It'll massively improve stutter.
|
solbright altalt
|
Posted - 2007.10.21 01:09:00 -
[27]
Originally by: Nomore Telindus But you can't prefetch anything if the server doesn't tell you what to load.
Both Prefetching and presending are not needed with async loading implemented. The data sent from the server is able to be displayed immediately on the client. As long as the server is keeping up, ie small lag, then there is no need to presend the objects any more than currently.
If the server isn't keeping up then additional presending won't help. It'll still not send anything.
|
Ryysa
Caldari
|
Posted - 2007.10.21 23:19:00 -
[28]
Yay, so you now follow every thread that I post in, and whine at me there, cute.
Originally by: solbright altalt This thread is not dealing with lag or the servers.
This thread is in general about lag. Decreasing clientside latency from 100 ms to 10 ms, won't make any difference if the serverside latency is 10000ms.
Quote:
Originally by: Ryysa This actually might be a pretty good idea, but you'd need to store your overview settings on the server in that case.
Huh? Explain.
Read the what I said above.
Quote: It'll massively improve stutter.
Well, your dinosaur of a computer won't run full Trinity engine anyway. On my computer, which is 2 years old but properly configures, I have totally zero stutter and very little if any clientside lag (except if the client is bugged). In larger battles, I have serverside lag, again read what I said above about latencies.
Quote: Both Prefetching and presending are not needed with async loading implemented. The data sent from the server is able to be displayed immediately on the client. As long as the server is keeping up, ie small lag, then there is no need to presend the objects any more than currently.
Actually the problem is, when you warp in to some place, is that no data is sent at all for a long time and then everything is sent at once in one huge package. A smart presending algorithm, which would activate from the moment you activate warp (since your exit coordinates are known at the time of warp end) would reduce this delay a huge amount. It could be abused though, as in, the client would know certain objects are there, before he actually sees them. It is possible to tune the algorithm though, to not send any data which would really be of tactical advantage.
Basically as I said again, unless you are using a total dinosaur of a computer, clientside lag should not be an issue for you with turret animations and effects turned off, even in large fleet battles. Until serverside lag gets fixed, any clientside stuff is really not all that important. EW Guide - KB Tool - My Music |
solbright altalt
|
Posted - 2007.10.22 00:43:00 -
[29]
Edited by: solbright altalt on 22/10/2007 00:46:59
Originally by: Ryysa Yay, so you now follow every thread that I post in, and whine at me there, cute.
Just the ones that deal with stutter. Maybe you find Eve client performance enough of an issue to be *****ing and not playing also?
Quote: This thread is in general about lag.
No it's not. Further reading - Here, here, and particularly here.
Quote: Decreasing clientside latency from 100 ms to 10 ms, won't make any difference if the serverside latency is 10000ms.
Correct, but that is not the topic here. Nor will lag impact on stutter except as a side effect of reducing stutter by the virtue of there not being any new objects to deal with.
Originally by: Ryysa This actually might be a pretty good idea, but you'd need to store your overview settings on the server in that case.
If you mean that there will be less data flowing because the prefs have the overview set to minimum then it won't help. That is putting more burden on the servers where lag is already a big problem.
Quote:
Quote: It'll massively improve stutter.
On my computer, which is 2 years old but properly configures, I have totally zero stutter and very little if any clientside lag (except if the client is bugged).
I very much doubt that. You just choose to lump it in with lag.
Quote: In larger battles, I have serverside lag, again read what I said above about latencies.
Of course. But lag is a different topic with other programs running on different hardware.
Quote: Actually the problem is, when you warp in to some place, is that no data is sent at all for a long time and then everything is sent at once in one huge package.
That may trigger stutter but the client's job is to handle it. If the client can't do the job of displaying the game state for us then it's failing in it's primary function. The server has enough calculations to deal with already.
Quote: A smart presending algorithm, which would activate from the moment you activate warp (since your exit coordinates are known at the time of warp end) would reduce this delay a huge amount.
Async loading eliminates this need. Takes the burden off the server altogether. Assuming the client coding is any good that is. Objects will be able to be displayed immediately as tactical icons. Maybe there might even be a preference to not load model data at all and save a lot of people from running around in map view.
Quote: clientside lag should not be an issue for you with turret animations and effects turned off, even in large fleet battles.
But it is a problem - for all. And hopefully the async loading will come to our rescue.
I'm not saying lag doesn't exist, it does and badly at times. But that is no reason to go round saying that nothing else is a problem. Especially when stutter is so fixable - entirely and for good. Lag will never be eliminated, CCP will always be fine tuning ways to reduce lag.
|
Ryysa
Caldari
|
Posted - 2007.10.22 00:55:00 -
[30]
Edited by: Ryysa on 22/10/2007 01:01:24
Originally by: solbright altalt random crap
I don't care what you think this thread is for, neither are you anyone to tell me what it is for. You are also an unimportant alt, get over yourself. Throwing personal insults at me will get you nowhere, as I couldn't care less about what you personally think about me, since once again, you are a no one for me. Not in this game, and not in real life. I'm glad we've got that cleared.
Quote: Correct, but that is not the topic here. Nor will lag impact on stutter except as a side effect of reducing stutter by the virtue of there not being any new objects to deal with.
There is no "stutter". As in, there is no spoon. If you have severe "stutter" then your computer's config sucks or it's too old.
Quote: If you mean that there will be less data flowing because the prefs have the overview set to minimum then it won't help. That is putting more burden on the servers where lag is already a big problem.
Actually, this would be a linear operation upon sending data, and the operations that make stuff slow are the non-linear ones. Don't try to poke guesses at programming complexity, where you have no idea about. Each client on a node could easily have an overview preference settings based upon which data would be filtered, this wouldn't be expensive to implement. However, that is again not the problem, nor is the amount of traffic the problem, the problem are serverside optimizations.
Quote: I very much doubt that. You just choose to lump it in with lag.
Well, come over to my place and give it a go if you don't trust me. Having about 7 years software dev experience in networking solutions, I quite certanly can say what is clientside lag and what is not.
Quote: That may trigger stutter but the client's job is to handle it. If the client can't do the job of displaying the game state for us then it's failing in it's primary function. The server has enough calculations to deal with already.
What I wrote about this, results in about a 1/3 to 1/2 second pause on my screen, once. Nothing I can't deal with when to activate a module I need to wait 10 seconds. But yeah, async loading would solve this to some extent.
Quote: Async loading eliminates this need. Takes the burden off the server altogether. Assuming the client coding is any good that is. Objects will be able to be displayed immediately as tactical icons.
You're more and more missing my point. Currently the clientside delay is unimportant. If the server issues would be sorted out, then clientside delay would be come important, until then this is all "feature bloat".
Quote: But it is a problem - for all. And hopefully the async loading will come to our rescue.
It is because you say so ? Usually the people who complain about clientside lag in fleet battles are: 1) People with REALLY old computers - who won't be able to run new trinity engine without upgrading anyway. 2) People who I refer to as "dumbusers" who have their computers full of malware and spyware, in this case async loading will not help anything.
All the other people, that I've played with, have not complained about clientside lag, however we all have complained about serverside lag.
Quote: I'm not saying lag doesn't exist, it does and badly at times. But that is no reason to go round saying that nothing else is a problem. Especially when stutter is so fixable - entirely and for good.
As I said before, eliminating clientside stutter in EvE, while nice, is like trying to give a '65 car a new paintjob instead of changing the engine.
Quote: Lag will never be eliminated, CCP will always be fine tuning ways to reduce lag.
Actually, majority of noticeable lag will be eliminated when CCP managed to code an efficient solution to running one node on multiple cores. Also, allowing the client to ultilize multiple cores would solve 90% of the stutter using raw power. EW Guide - KB Tool - My Music |
|
|
|
|
Pages: [1] 2 :: one page |
First page | Previous page | Next page | Last page |