Pages: 1 2 [3] :: one page |
|
Author |
Thread Statistics | Show CCP posts - 0 post(s) |
kaplowwwwwwwwwwwww
|
Posted - 2009.11.04 13:05:00 -
[61]
because of the nature of computersd and the program and the fact eve was and is designed for less than 64bit there is technicaly no need for and no reason why eve would ever go 64bit as the client currently is. It all depeneds on IF the current engine requires it at all.
The only time you should see a 64bit version is: If the client needs it for enhanced performace. When the operating system needs the client to have it.
so the first case is prob 2-6 years (when eve graphics engine is updated again). When 64bit windows 7 is used at the levels xp is now. (when xp is gone basicaly).
|
Nefrin Maldoes
Minmatar People with Guns Initiative Mercenaries
|
Posted - 2009.11.04 13:25:00 -
[62]
Taking a Business course, we discussed something that is quite similar to this:
Cutting Edge vs. Bleeding Edge
Cutting edge is where a product or piece of technology is polished, readily available, and the public is ready to accept it as a replacement to an older product.
Bleeding edge refers to the newest and shiniest of all things, but that are not economically sound to invest in because you will only have a few adopters that *must* have the newest gadget on the market (I point in reference to the people who purchased a buggy iPhone for $600+ when they came out).
It's a fine line to walk between the two, and it gets even harder to navigate when it's focused at a community such as this, where there are a lot of tech geeks (like myself).
While the idea of an updated client with better graphics does send a tingle to nice places, I have to agree that gameplay > graphics hands down. I like to think that some (or most) of the people at CCP keep this in mind, which is why it took so long to kill the classic client, and why it will be awhile before they upgrade the client again.
As it has been pointed out, even if they only lose 10% of their players due a client upgrade, here's the math:
$15(U.S) x 12 months x 30,000 (30k based off of the last number I remember of 300k subscribers) = $5,400,000.00 loss in annual income. Even if they lost the annual subscribers that only pay $10/month, it's still a loss of $3,600,000.00 per year.
Doesn't make good business sense at this time.
Originally by: PostmasterGeneral at first i was like and then i was like and then we got to the shower scene and i was like and then i was like
|
brutoid
Caldari
|
Posted - 2009.11.04 16:49:00 -
[63]
Upping grahics does not equal nerfing gameplay improvements. These things are worked on by seperate teams.
|
LaVista Vista
Conservative Shenanigans Party
|
Posted - 2009.11.04 16:51:00 -
[64]
Originally by: brutoid Upping grahics does not equal nerfing gameplay improvements. These things are worked on by seperate teams.
No. But it does equal nerfing new features that requires art assets.
One of the biggest bottlenecks at CCP is the art department. Programmers are also in fairly short supply.
If the art department has to overhaul every texture to make use for DX11 features, they can't also be doing new ships or anything like that.
|
brutoid
Caldari
|
Posted - 2009.11.04 17:07:00 -
[65]
Originally by: LaVista Vista No. But it does equal nerfing new features that requires art assets.
One of the biggest bottlenecks at CCP is the art department. Programmers are also in fairly short supply.
If the art department has to overhaul every texture to make use for DX11 features, they can't also be doing new ships or anything like that.
I'll have to take your word for it concerning staff shortages at CCP? Maybe the art department is a bit thin, i guess that would happen if you're developing more than one game. But concerning EvE, just like with gameplay features, there are alot of graphical 'bugs' that need fixing too. If they are striving for 'Excellence' then all matters need addressing.
And by 'new ships' do you mean Dust?
|
Amida Ta
German Mining and Manufacture Corp.
|
Posted - 2009.11.04 23:23:00 -
[66]
Originally by: LaVista Vista
If the art department has to overhaul every texture to make use for DX11 features, they can't also be doing new ships or anything like that.
But it doesn't have to! There are features in DX11 like tesellation that wouldn't require more stuff from the art department than the stuff thats already in the game right now. Moreover CCP does not have an "art department" for Eve at all. Have a look at the videos from last fanfast for their organizational structure. _________________________ EveAI.Live - The EVE-Online API/class library for .Net, C# and VB.Net |
Spurty
Caldari Rionnag Alba Against ALL Authorities
|
Posted - 2009.11.04 23:39:00 -
[67]
Working for a software company that has been producing 64bit software for many years now I can with much experience say that the move from 32bit to 64bit is indeed niticable but only when you have to step back down to 32bit.
What shocks me most about peoples understanding of 32bit vs 64bit is that if they're argument is to be taken, we should have never left 16bit CPUs.
When every Line of code, hardware part, driver, bus, core and kernel runs in 64bit mode, stuff tends to fly, really fly!
My next games machine will have 32gigs of ram. This will be pretty weak compared to the 96gig box I ordered for running virtual machines off the netapp.
Seeing as companies like creative labs can bot work out how to write 64bit drivers fir their own hardware forcing opensource projects to spring onto life to deliver (it's not impossible, clearly they just don't want to put in the extra effort) it's not much of a stretch to see the path of least resistance is once more the soup of the day.
Gamers are a terrible force for bigger better faster more. You are pretty lame waving your "64bit, he'll we'llnot go" scarves. Demand progress, let grandads Clutch at the past
Originally by: Machine Delta When making a point, anyone taking it should consider the source.
pretty deep coming from you |
Chiyoko sama
Griefer-B-Gone Ushra'Khan
|
Posted - 2009.11.05 15:00:00 -
[68]
I've done several migrations to AMD64/Intel64 and have to confirm Spurty's comments.
- Alleviating the need for a mode switching and word conversion has a big impact-- aka "When... [everything] runs in 64bit mode, stuff tends to fly, really fly!"
- Since most graphics is offloaded to a GPU, its been my experience that database and bytecode/interpreted language code obtains the largest speedup. (See Python) What this means is the 64bit CMP/SCMP and SIMD instruction types have a huge impact.
- Most problems originate from uncontrolled binaries (which is in of itself a big problem -- poor code management) or poor programming practices (which is also another big issue in of itself)
- One of the biggest issue it seems overlooked is development of a real multicore capable client (see brethren on X360/PS3 platforms)
- If costs were truly the root issue, then DirectX is a bad option. Outside of the XBox/PC platform Direct3D isn't really used; rather OpenGL is used (which changes specifications ~1/10th as often as DirectX).
Its a simple matter, development companies without a 64-bit strategy are trapped in the thinking of the early 1990's. A development companies without a multicore strategy, are trapped in the early 2000's.
|
LaVista Vista
Conservative Shenanigans Party
|
Posted - 2009.11.05 15:41:00 -
[69]
The two posts above me seems fancy and all.
But right now, the biggest bottleneck is not the client. If you have a recent computer(3 years or so), you will be able to run EVE with fairly high details with fair performance.
The problem with EVE at present is the servers. It's not able to handle 1000's of people. And yes, the server software is 64bit, seeing as 1000 concurrent users will take up more RAM than can be allocated with 32 bits(As was seen from when Jita crashed after stackless python was deployed, when it ran out of memory).
The fact is that most performance issues comes from the fact that:
1. The EVE client is largely single-threaded due to the python-based UI. 2. The UI relies on the server(The server calls are blocking), and there's an inherent delay when talking to the server.
The EVE client is a dumb telnet client with a graphics, sounds, UI and networking engine. What is the most intensive one? The graphics part. That's where you will have a performance increase if anywhere.
EVE is not a data-intensive client. The server is, sure. Hence why it's running under 64 bits now. But the client has no need for a 64bit overhaul at this point. The performance improvement is likely to be minimal if at all existant.
In essence, it really comes down to this: Does your application need to allocate 4gb(3gb in case of consumer operating systems like XP or Vista) or more of ram?
|
Chiyoko sama
Griefer-B-Gone Ushra'Khan
|
Posted - 2009.11.05 17:44:00 -
[70]
Here's a handy dandy link for all to read. It explains software development guidelines... and that there is more going on than just address space. Intel« 64 and IA-32 Architectures Software Developer's Manuals
Originally by: LaVista Vista
In essence, it really comes down to this: Does your application need to allocate 4gb(3gb in case of consumer operating systems like XP or Vista) or more of ram?
If you wish to discuss just the addressing space features, then the primary consideration is caching -- (1)Texture/Models and (2)Client-side data. (1) could easily go above 4Gb. (2) just pushes it over the top. This is not to be confused with the current cache sizes set with in the client, but rather what would be optimal.
Originally by: LaVista Vista 1. The EVE client is largely single-threaded due to the python-based UI.
...aka a real multicore capable client. Additionally, Python isn't single threaded.
Originally by: LaVista Vista 2. The UI relies on the server(The server calls are blocking), and there's an inherent delay when talking to the server.
From a client side perspective, this is the same as point #1. Synchronous calls (aka blocking) over network IO is horrible for any client side functionality. This is behaviorally an intermittent hanging or frozen client. Any decent modern network programmer uses asynchronous calls (non-blocking or "get back to me when you have the data") which frees the process/worker thread to do other things. (note: CCP generally uses Async calls) Network latency is a different issue and not the same thing as a Sync/Async call.
While it could be analogized as a telnet client to a telnet server, the description falls short in even describing the predicative features of the EVE client (or any modern MMO client).
If you want to talk about improving Network IO, database transaction, and server performance then CCP will have to pay for that. ;)
Originally by: LaVista Vista EVE is not a data-intensive client. The server is, sure. Hence why it's running under 64 bits now. But the client has no need for a 64bit overhaul at this point. The performance improvement is likely to be minimal if at all existant.
So how many years ago is this thinking?
|
|
LaVista Vista
Conservative Shenanigans Party
|
Posted - 2009.11.05 18:12:00 -
[71]
Quote: If you wish to discuss just the addressing space features, then the primary consideration is caching -- (1)Texture/Models and (2)Client-side data. (1) could easily go above 4Gb. (2) just pushes it over the top. This is not to be confused with the current cache sizes set with in the client, but rather what would be optimal.
If CCP thought it beneficial to cache more things(Which can be changed by the user as it is now, by the way) and needed the extra address space, I'm sure they would do it. At this point in time, there's no sign that it is going to happen any time soon.
Quote: ...aka a real multicore capable client. Additionally, Python isn't single threaded.
Python in itself supports threading, sure. But CCP uses stackless python and micro-threads, which isn't real threadning.
Quote: From a client side perspective, this is the same as point #1. Synchronous calls (aka blocking) over network IO is horrible for any client side functionality. This is behaviorally an intermittent hanging or frozen client. Any decent modern network programmer uses asynchronous calls (non-blocking or "get back to me when you have the data") which frees the process/worker thread to do other things. (note: CCP generally uses Async calls) Network latency is a different issue and not the same thing as a Sync/Async call
Yet CCP doesn't use async calls. Have you every tried opening the alliance list? Your character sheet? Maybe your wallet? In all cases you can see blocking calls.
Try and go to the market, go to Search and type in 'a' and search. Now tell me that it's not blocking.
And yes, network latency is highly relevant when discussing async/sync calls. If the delay inherent to network calls wasn't so high, it would virtually not matter if the call was async or sync. Of course, that's not universally true, but the point is extremely important to make.
Quote: While it could be analogized as a telnet client to a telnet server, the description falls short in even describing the predicative features of the EVE client (or any modern MMO client).
Just because EVE is a telnet client(Which it really is, try and use a telnet client and put in TQ's IP) doesn't mean that it's not smart about things. The simulation code that runs on TQ is the same that takes place in your client. Both client and server runs the simulation at all time and sync up on a regular basis(Which can be forced by the client if it finds itself in an invalid state).
Quote: So how many years ago is this thinking?
I'm not saying tat CCP shouldn't work on getting the client in a position where they can make the move to offer a 64bit client. But it relies on having to get 64bit version of all middleware, working their configuration(build) system to also handle a 64bit version and do specific testing for the 64bit client. That's ignoring the fact the have to support patches from version to version for both 32bit and 64bit clients. That's a lot of patches they need to put together and manage.
I'm just saying that it's a very large cost that CCP will have to absorb for very little benefit overall. They will have to do it eventually, but I don't think that the time is right yet.
But if you know how to solve the problem, then I happen to know that CCP is hiring. You should apply and give us all a 64bit client.
|
Lateris
Gallente Dark Star Industries
|
Posted - 2009.11.05 19:07:00 -
[72]
At some point I see Eve evolving onto planets after Incarna with ships and avatars and I am not referencing Dust 514 for this natural evolution of Eve on our side of technology. The sandpit must grow in the next 5 years! So my question is due to my lack of knowledge of Microsofts DX.
Question: What is the advantage of going past DX 9 for the future of Eve? Is Eve really using DX 9 to its fullest capability? When adding a new DX version to a game does that mean all the art assets have to be redone?
|
Halycon Gamma
Caldari The Flying Tigers
|
Posted - 2009.11.17 02:20:00 -
[73]
Sigh, some shiny new thing comes out, and everyone wants to know when they'll upgrade to it. It doesn't make sense. Yes you can access more ram, and yes SOME processes are faster on a 64bit platform than a 32bit platform. Eve isn't either of those.
A tool should do its job, and no more. The more bells whistles and addons you give it, the worse it is at its original intended purpose. Eve Client may not be cutting edge in terms of a 64 bit codebase, but it does what its supposed to. Will adding a 64bit version improve the experience for anyone? Nope. So why add features that don't directly improve its original intended purpose? Instead deal with what you have.
Another 3-4-5-6 years down the line, chances are we'll get Trinity2.0 or whatever they wanna call it. With a completely revamped graphics system all over again. At that point in time, when doing a massive overhaul of everything on the consumer end.. it makes sense to explore the idea of introducing a 64bit version, or DX13, or what have you.
But, just because. The most interesting thing introduced in the last few years, to me, that could be added to Eve is real physics simulation through CUDA/OpenCL/DirectCompute. I'm much more excited about seeing non static pew pew animations, than I am in seeing prettier static pew pew animations.
|
Irongut
H A V O C Against ALL Authorities
|
Posted - 2009.11.17 02:44:00 -
[74]
DX10 is so last year, my DirectX goes up to 11!
--
|
Khemul Zula
Amarr Keisen Trade League
|
Posted - 2009.11.17 02:53:00 -
[75]
This definately needed to be resurrected.
Veal, murder. Baby Carrots, healthy snack. Food hypocrisy at work. |
Jonny Lumi
Gallente Blend.
|
Posted - 2009.11.17 03:05:00 -
[76]
Edited by: Jonny Lumi on 17/11/2009 03:05:23
Originally by: DigitalCommunist
*snip*
DX9 is a pile of crap, and I would love to see them dump it.
*snip*
Pile of crap? Saying this as DX programmer, I disagree. It might be old, but people still do pretty nice things with it.
Anyway, we should also try to remember that EVE is not a 3D photorealistic FP game (at least not yet). What advantage would we get from seeing overly detailed, tesselated, etc. ships? The most you see is brackets and small polygons anyway. I bought DX10 card for 120e (new), and client runs ~240fps outside station (test-run with vsync off), so why on earth would we need any "speed-boost from DX10/11"?? Even if they double polycounts and texture sizes, it wouldn't make much difference, since 60fps is all you need for fully smooth graphics anyway.
Was just thinking about the fact that whatever DX10 card you have, it is fast enough with DX9.
|
|
|
|
Pages: 1 2 [3] :: one page |
First page | Previous page | Next page | Last page |