| Pages: [1] :: one page |
| Author |
Thread Statistics | Show CCP posts - 0 post(s) |
Splagada
Minmatar
Tides of Silence
Hydra Alliance
   |
Posted - 2007.06.27 11:44:00 -
[1]
Heya
just an old idea again, but that starts to be more and more needed now the average fleet battle can easily get past 100vs100, or in crowded systems
When we deploy fighters on 5 carriers at the same time i get a huge freeze which isnt related to server, but to my client trying to display all that
in one key you switch to "tactical" view. the exact same as overview icons, but inplace of the 3d models. no 3d to display, just dots, with the overview icon on top to make it easy to understand for the initiated player
arrows to show speeds if you want, or not
put that in light green on a dark background and it will really show like a "HUD" display
it would be USEFUL also for FCs
------
|
Spoon Thumb
Khanid Aerospace Group
Khanid Provincial Authority
|
Posted - 2007.06.27 18:03:00 -
[2]
heard this one before, and I like it.
Though ofc. ideally you don't have lag in big fleet battles :P
Khaldari
KPA are recruiting
In-game channel: khanidpublic |
Valandril
Caldari
Resurrection
R i s e
|
Posted - 2007.06.27 18:13:00 -
[3]
/signed in yet another "give us fleet eve mode"
---
|
Thor Xian
EarthForce
E.A.R.T.H. Federation
|
Posted - 2007.06.27 20:05:00 -
[4]
/SIGNED
________________________________________
~Fleet Admiral Thor Xian, Strategic Commander
Meet the Overlord |
Avalon Ranger
Caldari
Orphans of War
|
Posted - 2007.06.27 21:34:00 -
[5]
I think this is a great idea. It just removed the 3D models and changes them to Icons or letters or something. This would mean computer lag would be reduced and perhaps allow server lag to be lowered a little.
/Signed.
|
Lucus Ranger
Gallente
Blood Corsair's
|
Posted - 2007.06.27 22:29:00 -
[6]
/signed an signed again for good measure :)
/Prince of Darkness at your service..
Disclaimer: None of my ideas or posting reflects my Alliance/Corp in any way |
Aki Yamato
|
Posted - 2007.06.28 00:18:00 -
[7]
What about simply optimalize code to work properly ?
BIG GUN
BIG FUTURE |
Ghost Reaper
Reikoku
Band of Brothers
|
Posted - 2007.06.28 01:27:00 -
[8]
this does work, and i;ve used it in tha past, however it proves to be very hard to allign out when you have the full map open. If you use the solar system map, it doesnt work at all cause it stil has to generate everything, to give the locations though out the solar system.
Gr
|
Washell Olivaw
|
Posted - 2007.06.28 05:41:00 -
[9]
 Originally by: Aki Yamato
What about simply optimalize code to work properly ?
Because this is an MMO and the devs have little control over the amount of ships that players bring together.
Each 3D model is made up of polygons. Yours (and our) graphic card(s) have an upper limit of polygons they can handle. In a fleet battle this number is quickly reached. Right now it's the graphics engine that's the bottle neck but don't expect this problem to disappear with the new engine. It will be less common though.
It's a problem with all MMO's, these days it's usually solved with instances, but that's not an option for Eve.
Quote:
Everybody has a photographic memory, some people just don't have film.
|
solbright altaltalt
|
Posted - 2007.06.28 06:35:00 -
[10]
Originally by: Washell Olivaw
It's a problem with all MMO's, these days it's usually solved with instances, but that's not an option for Eve.
I disagree, Eve's client codebase would still stutter the same way with instancing. The servers are rarely the cause. Lag doesn't cause the display to stutter.
Polygon count isn't the problem either. Today's graphics cards can handle Eve's demands with ease.
|
solbright altaltalt
|
Posted - 2007.06.28 06:41:00 -
[11]
I'd sign this thread if I thought it would be a solution. Sadly, I'm confident a tactical only display wouldn't solve stutter either.
There is a major flaw in the implementation of the client software. Until that's fixed, shuffling the details on the display won't help.
|
Splagada
Minmatar
Tides of Silence
Hydra Alliance
|
Posted - 2007.06.28 10:37:00 -
[12]
that cant harm the performance to remove the 3d models anyway :p
------
|
Valandril
Caldari
Resurrection
R i s e
|
Posted - 2007.06.28 11:02:00 -
[13]
Originally by: solbright altaltalt
Originally by: Washell Olivaw
It's a problem with all MMO's, these days it's usually solved with instances, but that's not an option for Eve.
I disagree, Eve's client codebase would still stutter the same way with instancing. The servers are rarely the cause. Lag doesn't cause the display to stutter.
Polygon count isn't the problem either. Today's graphics cards can handle Eve's demands with ease.
Graphic cards can, but since when eve is using my graph card cpu instead my gcpu ?
---
|
solbright altaltalt
|
Posted - 2007.06.28 11:48:00 -
[14]
Originally by: Valandril
Graphic cards can, but since when eve is using my graph card cpu instead my gcpu ?
Bags still not the poly count though, it's more about the visable object count. And, in particular, a change in that object count.
I could be wrong but I really don't think the rendering pipe is what is slowing the client down. It feels more like the management of that rendering.
|
Valandril
Caldari
Resurrection
R i s e
|
Posted - 2007.06.28 11:57:00 -
[15]
Originally by: solbright altaltalt
Originally by: Valandril
Graphic cards can, but since when eve is using my graph card cpu instead my gcpu ?
Bags still not the poly count though, it's more about the visable object count. And, in particular, a change in that object count.
I could be wrong but I really don't think the rendering pipe is what is slowing the client down. It feels more like the management of that rendering.
Imo its issue that graph engine is old and weak ergo not using tweaks in ur graph card
---
|
Aki Yamato
|
Posted - 2007.06.28 12:05:00 -
[16]
Originally by: Washell Olivaw
Originally by: Aki Yamato
What about simply optimalize code to work properly ?
Because this is an MMO and the devs have little control over the amount of ships that players bring together.
Each 3D model is made up of polygons. Yours (and our) graphic card(s) have an upper limit of polygons they can handle. In a fleet battle this number is quickly reached. Right now it's the graphics engine that's the bottle neck but don't expect this problem to disappear with the new engine. It will be less common though.
It's a problem with all MMO's, these days it's usually solved with instances, but that's not an option for Eve.
As someone alrady noticed EVE dos not use GPU at all, nad if it does several houdred thousad polygons wtch can be ivolved in mass battla is piece of cake for present GPUs. So I disagree with you in this point that new engie wont solve it.
You can blame your client, that in every battle is waiting for data from serverside witch can be displayed on.
Or, you can blame jour PC that its took too long to load and display several ship, oh i remember old times of total anihilation multiplayer games thousand units on each side and everything works fine on much weaker PC, all it's matter of optimalization.
If you mean instances such render each model one time display several times, (technology first used in Supreme commander ?) then that's exactly what the CCP dev was talking about in that video from some gamecon, presenting new EVE engine.
BIG GUN
BIG FUTURE |
solbright altaltalt
|
Posted - 2007.06.28 23:25:00 -
[17]
Originally by: Valandril
Originally by: solbright altaltalt
Bags still not the poly count though, it's more about the visable object count. And, in particular, a change in that object count.
I could be wrong but I really don't think the rendering pipe is what is slowing the client down. It feels more like the management of that rendering.
Imo its issue that graph engine is old and weak ergo not using tweaks in ur graph card
It may not be using the latest toys in the pipe but it will be using hardware rendering. And CCP have stated that the engine is optimised.
I don't really believe the worn-out brush-off line that is held by all these weenies that the renderer is slow.
Besides, stutter only really affects change in object count. Doesn't make sense for that to be a rendering problem. And it ain't lag either. There is no network activity at all for some stutter actions.
|
Princess Morenta
Minmatar
Republic Military School
|
Posted - 2007.06.29 02:17:00 -
[18]
The old renderer uses CPU mainly although it does what it can with the GPU but it isnt optimised nor does it use bump mapping, etc.
Since its basically an old engine thats been around for ages only slightly tweaked, it was designed for when cards like GF 2 MX were the norm and Geforce 3s were in the hands of the rich and geeky.
The new engine will use that and is optimised to shove the load totally onto GPUs with regards to graphics meaning that it will both look better yet resolve the graphics lagging issue.
A huge factor of FPS drop is the client interface though.
But discussing the graphics engine is offtopic.
Id like to see a tactical map, maybe a 2D top down view with Green for friendly ships (Blue standing,Corp,Alliance), Red for enemy ships (Red minus, aggressed,negative standing) and say Grey for neutrals (Who turn red if they aggress)
Top down view would probably be best with differenciation between weapons fired, electronic warfare, etc.
Turret based fire = line?
Missile based fire = missile?
EW would depend..
Defcon style icons FTW as well
|
solbright altaltalt
|
Posted - 2007.06.29 06:56:00 -
[19]
Originally by: Princess Morenta
The old renderer uses CPU mainly although it does what it can with the GPU but it isnt optimised nor does it use bump mapping, etc.
Just because it doesn't use a particular bell doesn't mean it's slow.
Quote:
The new engine will use that and is optimised to shove the load totally onto GPUs with regards to graphics meaning that it will both look better yet resolve the graphics lagging issue.
Yeah, right! If that happens it won't be because of better GPU usage.
Quote:
A huge factor of FPS drop is the client interface though.
But discussing the graphics engine is offtopic.
Really? The reason for this thread is because of the frustration caused by stutter. The tactical display is an idea to avoid a large portion of the 3D rendering burden. I'm arguing that the cause of stutter is further back in the client codebase from the rendering pipe and therefore a tactical display will still stutter.
|
Princess Morenta
Minmatar
Republic Military School
|
Posted - 2007.06.30 11:48:00 -
[20]
Originally by: solbright altaltalt
Originally by: Princess Morenta
The old renderer uses CPU mainly although it does what it can with the GPU but it isnt optimised nor does it use bump mapping, etc.
Just because it doesn't use a particular bell doesn't mean it's slow.
Quote:
The new engine will use that and is optimised to shove the load totally onto GPUs with regards to graphics meaning that it will both look better yet resolve the graphics lagging issue.
Yeah, right! If that happens it won't be because of better GPU usage.
Quote:
A huge factor of FPS drop is the client interface though.
But discussing the graphics engine is offtopic.
Really? The reason for this thread is because of the frustration caused by stutter. The tactical display is an idea to avoid a large portion of the 3D rendering burden. I'm arguing that the cause of stutter is further back in the client codebase from the rendering pipe and therefore a tactical display will still stutter.
Err what are you smoking dude?
A CPU is a general processor capable of doing many things whilst a GPU is designed to process graphics routines and is more or less solely dedicated to doing that (With the exception of physics these days) therefore a graphics engine using a CPU will to do its work will ALWAYS be slower than a renderer that is using a GPU to handle its work (As a GPU is optimised)
Ever been in a fleet battle and watched your FPS drop like a mo'fo? Yeah thats the graphics engine trying to do all its work via your CPU drawing all them ships and all them effects...
EVEN CCP Have said it themselves in a speech about the new graphics engine so I think im gonna trust them over your words.. TYVM.
Your argument is fundamentaly flawed as the issue is recognised and acknowledged by CCP and set to be remidied client side by the graphics engine update when its ready... straight from the horses mouth as opposed to speculating on this that and the other.
They made the game and they know how it works (Although that could be debated at times but thats another topic altogether).
And for the record... I still want a tactical map EVEN with the new graphics engine.
|
solbright altaltalt
|
Posted - 2007.06.30 13:00:00 -
[21]
Originally by: Princess Morenta
Your argument is fundamentaly flawed as the issue is recognised and acknowledged by CCP and set to be remidied client side by the graphics engine update when its ready... straight from the horses mouth as opposed to speculating on this that and the other.
Wishful thinking. I hope you're right.
However, the average FPS is not the big killer. It's the huge stutters that can last for many seconds at a time.
The only possible relationship between stutter and the rendering engine is dynamic loading of the textures and the likes. But that's still not the rendering itself. It's more about just having the right files in memory and, to be honest, I have trouble believing Eve can use so much main memory and not have every ship texture in the game perma-loaded.
I'll repeat: If the new engine fixes stutter then cool, but it won't be the improved rendering code itself that does it. I personally feel that stutter is caused in a different place in the client.
|
Seriya
Caldari
Shadows of the Dead
Aftermath Alliance
|
Posted - 2007.06.30 17:21:00 -
[22]
/signed
Anything to make fleet battles smoother, even a little bit.
|
solbright altaltalt
|
Posted - 2007.07.01 22:36:00 -
[23]
Originally by: Seriya
Anything to make fleet battles smoother, even a little bit.
A lot more. There is no excuse for stutter, period.
|
Ladilaladingdong
|
Posted - 2007.07.03 11:17:00 -
[24]
Originally by: solbright altaltalt
Originally by: Seriya
Anything to make fleet battles smoother, even a little bit.
A lot more. There is no excuse for stutter, period.
|
| |
|
| Pages: [1] :: one page |
| First page | Previous page | Next page | Last page |