x64 Client Needed for ESO PC

blackweb · June 2015

Most of us now have 8-16 GB of relatively fast memory on the PC now. Most if not all games (except ESO) now have an x64 client to make use of all of that cheap, fast memory that is available. ESO however, uses only about 1.5 GB of RAM. As a software developer, I have no doubt that this is hurting performance in ESO on the PC. The fact that ESO is using only 1.5 GB of RAM means that it is swapping game data between disk, VRAM and DRAM rather than having most game resources pre-loaded or cached in main memory. This process, especially if ESO is using virtual memory or its own disk cache is much slower than loading most game resources into main memory. 1.5 GB just is not enough for a game like ESO, especially in Cyrodiil.

It is past time for an x64 client for ESO. Make it happen Zenimax.

KhajitFurTrader · June 2015

The 32-bit ESO executable is complied using the IMAGE_FILE_LARGE_ADDRESS_AWARE flag, so on a 64-bit OS it is possible for it to use a user-mode virtual address space of up to 4 GB. But it doesn't. Why?

On a 64-bit OS, the 64-bit client of WoW rarely uses more than 2.5 GB of memory, while running on a machine w/ 32 GB of physical RAM and usually more than 17 GB of it free, i.e. not even including the disk cache. Why is that?

One reason could be that it's simply bad programming style to allocate memory for assets that aren't needed yet. malloc() what you need in time, free() that what's become obsolete for a while. This is good sense. On a 64-bit address space, the pressure to free obsolete assets might be a bit lower, but there really isn't a good excuse for any process to be a memory hog (except when you're a RDBMS - then go for it). And between the OS caching disk I/O, and the engine pre-loading anticipated assets, there really isn't that much of a of a performance penalty.

People often ask for a 64-bit client, but sometimes for all the wrong reasons. An architecture change doesn't make any program automagically faster, unless it's able to be optimized for it. It's often overlooked that optimization mainly happens in the instruction set department specific to the x64 architecture, i.e. being able to do the same task in less CPU cycles, or do more work within the same time. Being able to address more memory surely can be helpful, but not all kinds of tasks can profit from this in the same way. It may help with some bottlenecks in different circumstances, but it's not a panacea.

That being said, word on the street is that the PS4 client already is 64-bit. Given the fact that all clients on all platforms share the same code base, it's only a matter of time and testing before we might see an announcement for a beta phase.

SirAndy · June 2015

I agree with the furry trader, simply recompiling for 64bit rarely ever improves performance.
In fact, more often than not, the initial performance will be worse.

The codebase has to be refactored and optimized for 64bit in order to gain anything.
I do this sort of stuff for a living, i'm currently working on a 64bit implementation of an enterprise level app that uses 75+ GB of ram at runtime.

blackweb · June 2015

SirAndy wrote: »

I agree with the furry trader, simply recompiling for 64bit rarely ever improves performance.
In fact, more often than not, the initial performance will be worse.

The codebase has to be refactored and optimized for 64bit in order to gain anything.
I do this sort of stuff for a living, i'm currently working on a 64bit implementation of an enterprise level app that uses 75+ GB of ram at runtime.

There are many kinds of performance. The 32-bit client fails when performance is needed most in ESO, in Cyrodiil. ESO runs out of resources in crowded battles in Cyrodiil. It is obvious that 1.5GB is not enough to run ESO in Cyrodiil. Lets compare 2 pc games developed at about the same time. Both are focused on massive or large scale pvp. First the platform is

Windows 7 x64
16 GB DDR3 2400 RAM
i7 4790k 4.8 GHz turbo-boost
Corsair H80i Liquid Cooler
Corsair AX 860i power supply
Asus Maximus VII Hero Motherboard
2x MSI GTX 970 Gaming 4G SLI
Samsung 1TB 840 Evo SSD
Asus 27" 1080p monitor

Games compared:

PlanetSide 2

Planetside2_x64.exe
Hundreds if not thousands of players on both sides
High Graphics Settings
40-110 fps
100 Threads
3-4+ GB memory used by the game
Game always remains playable no matter how big the battle, little or no perceptible lag.
Load times when zoning or respawning are about 2-5 seconds

Eso

Eso.exe*32
Hundreds of players on both sides
High Graphics settings
15-100 fps
40 threads
1.5 GB - 2GB memory used by the game
Load times when zoning or respawning are 15 - 60 seconds
Game is playable part of the time until the game client just runs out of resources at which point, the game becomes unplayable. Abilities stop working, the screen stops updating. Players often die without knowing what hit them.

Similar games in terms of resource and processing requirements. PS2 stays playable at all times, no matter how big the battle or how many characters are on screen or what they are doing. ESO frequently becomes unplayable. To make matters worse in ESO, players use tactics designed to cause opposing players clients to run out of resources and stop responding. PS2 uses twice as much memory, creates over twice as many threads and has much higher minimum frame rates than ESO.

This proves this statement:

"On a 64-bit OS, the 64-bit client of WoW rarely uses more than 2.5 GB of memory, while running on a machine w/ 32 GB of physical RAM and usually more than 17 GB of it free, i.e. not even including the disk cache."

false.

This statement is true:

"simply recompiling for 64bit rarely ever improves performance."

Ya think? Of course ESO should be optimized for x64. Now make it happen Zenimax. End client freeze up in Cyrodiil. Give us an optimized x64 client ASAP.

Romo · June 2015

Yep my game freezes up at 1.784 gigs 1 time per day.

Wish it wouldn't.

Win 8.1, 64bit.

blackweb · June 2015

Romo wrote: »

Yep my game freezes up at 1.784 gigs 1 time per day.

Wish it wouldn't.

Win 8.1, 64bit.

ESO PC is starved for resources.

blackweb · June 2015

The irony is this, the console got an x64 client before the PC did

blackweb · June 2015

Planetside 2 will soon stop supporting 32-bit operating systems.

https://forums.daybreakgames.com/ps2/index.php?threads/notice-regarding-32-bit-operating-systems.227437/

blackweb · July 2015

ESO is starved for system resources on the PC because of the artificial limitations imposed by the 32-bit client.

Whilhelmina · July 2015

Rest assured, it isn't working any more on 32 bit clients.

blackweb · July 2015

Whilhelmina wrote: »

Rest assured, it isn't working any more on 32 bit clients.

Do you have a source on that? When will the x64 client for pc be released?

Peanut1944 · July 2015

Whilhelmina wrote: »

Rest assured, it isn't working any more on 32 bit clients.

I have to disagree. After have a week of crashes support finally manage to sort it out. My graphics driver was out of date. I updated it. I have a windows7 32 bit.I have been playing all day today with no crashes and no problems whatsoever.

blackweb · July 2015

Its simple math really, 1.5 GB of memory and 40 threads just is not a sufficient amount of memory for a game like ESO in a place like Cyrodiil on high or ultra graphics settings at HD QHD or UHD resolution. Too many polygons, too many characters, too much processing etc.

Again, PlanetSide 2 handles more players including friendly fire and collision detection on HD + with high or ultra settings but it has an x64 client and runs about 100 threads on 3-5 GB of memory. Effectively double the resources of ESO. Both games are similar, a PS2 continent is about the same size as Cyrodiil with even more structures and more characters and vehicles. The PS2 x64 game engine far out-performs ESOs x86 engine under similar or even greater load conditions.

blackweb · July 2015

SirAndy wrote: »

I agree with the furry trader, simply recompiling for 64bit rarely ever improves performance.
In fact, more often than not, the initial performance will be worse.

The codebase has to be refactored and optimized for 64bit in order to gain anything.
I do this sort of stuff for a living, i'm currently working on a 64bit implementation of an enterprise level app that uses 75+ GB of ram at runtime.

The issue is not performance, it is scalability. ESO scales poorly in Cyrodiil. ZoS admitted this when they lowered the pop cap in Cyrodiil. That didn't really help much.

Ranique · July 2015

blackweb wrote: »

show previous quotes

SirAndy wrote: »

I agree with the furry trader, simply recompiling for 64bit rarely ever improves performance.
In fact, more often than not, the initial performance will be worse.

The codebase has to be refactored and optimized for 64bit in order to gain anything.
I do this sort of stuff for a living, i'm currently working on a 64bit implementation of an enterprise level app that uses 75+ GB of ram at runtime.

There are many kinds of performance. The 32-bit client fails when performance is needed most in ESO, in Cyrodiil. ESO runs out of resources in crowded battles in Cyrodiil. It is obvious that 1.5GB is not enough to run ESO in Cyrodiil. Lets compare 2 pc games developed at about the same time. Both are focused on massive or large scale pvp. First the platform is

Windows 7 x64
16 GB DDR3 2400 RAM
i7 4790k 4.8 GHz turbo-boost
Corsair H80i Liquid Cooler
Corsair AX 860i power supply
Asus Maximus VII Hero Motherboard
2x MSI GTX 970 Gaming 4G SLI
Samsung 1TB 840 Evo SSD
Asus 27" 1080p monitor

Games compared:

PlanetSide 2

Planetside2_x64.exe
Hundreds if not thousands of players on both sides
High Graphics Settings
40-110 fps
100 Threads
3-4+ GB memory used by the game
Game always remains playable no matter how big the battle, little or no perceptible lag.
Load times when zoning or respawning are about 2-5 seconds

Eso

Eso.exe*32
Hundreds of players on both sides
High Graphics settings
15-100 fps
40 threads
1.5 GB - 2GB memory used by the game
Load times when zoning or respawning are 15 - 60 seconds
Game is playable part of the time until the game client just runs out of resources at which point, the game becomes unplayable. Abilities stop working, the screen stops updating. Players often die without knowing what hit them.

Similar games in terms of resource and processing requirements. PS2 stays playable at all times, no matter how big the battle or how many characters are on screen or what they are doing. ESO frequently becomes unplayable. To make matters worse in ESO, players use tactics designed to cause opposing players clients to run out of resources and stop responding. PS2 uses twice as much memory, creates over twice as many threads and has much higher minimum frame rates than ESO.

This proves this statement:

"On a 64-bit OS, the 64-bit client of WoW rarely uses more than 2.5 GB of memory, while running on a machine w/ 32 GB of physical RAM and usually more than 17 GB of it free, i.e. not even including the disk cache."

false.

This statement is true:

"simply recompiling for 64bit rarely ever improves performance."

Ya think? Of course ESO should be optimized for x64. Now make it happen Zenimax. End client freeze up in Cyrodiil. Give us an optimized x64 client ASAP.

1: planetside2 is a fps. I didn't know the game, but looked it up, appearance between players is not a lot different and it looks like everyone looks the same. For a FPS that is no problem. for a role playing game it is.

2: the answer to whats better depends highly on the platform as well. I'll stick to pc cause thats where this is posted.

3: you haven't given any solid facts bout why it would be better.
The common issue is that people are mislead by how 32 bits programs work on 64 bits programs.

they think they are limited in the same way as 32 bits programs on 32 bits systems. This is incorrect. While a 32 bits system is limited to 4 GB of memory in total (where with windows, 2 GB is reserved for the system), a 64 bits system running a 32 bits program is limited to 4GB per program (or actually per process, ESO uses some side processes that stay out of this equasion, meaning only the core process has the limit of 4 GB). Yes it is a limitation, but much lower as people think it is.

ESO-lag is solved by a 64 bits process. This is untrue. As explained in the planetside issue, the problem is that each player on the screen is a different entry on the calculation of the screencontent. They all look different with different skins and looks and each and everyone has to be loaded in and played. However.. This is not a RAM-limitation, but a GRAM limitation (not sure if GRAM is an official term, I made it up, but it is the graphical RAM, also known as the RAM that comes with the GPU).

Although there are GPU that have up to 12 GB of RAM, they are very high end and expensive and more reasonable is that they have 4 GB (same as the 32 bits limit). that leads to a question...why do GPU's limit themselfs to so much RAM?? The simple answer is that RAM is just a waiting room. It is where data is stored that is ready to be processed by the CPU or GPU. But no matter how big you make this waiting room, if the processor doesn't keep up, it will always flood. that is why there is lag in cyrodil. The GPU is flooded. increasing the RAM doesn't change a thing bout that.

The speed of a system is as fast as the slowest part. With 32 bits systems running 32 bits processes, there was an issue cause it was 4 GB in total. with 64 bits systems running 32 bits systems it is 4 GB per process, the result is that it is no longer the part slowing down, it is the CPU and GPU. The cyrodil lag will not be solved by "just" adding more ram by changing to 64 bits clients.

blackweb · July 2015

Ranique wrote: »

1: planetside2 is a fps. I didn't know the game, but looked it up, appearance between players is not a lot different and it looks like everyone looks the same. For a FPS that is no problem. for a role playing game it is.

> This statement is false. PS2 has a LOT of character customization.

3: you haven't given any solid facts bout why it would be better.

Your assumptions about the processing demands of PS2 are false. PS2 is an MMO-FPS with many MMO features such as character and vehicle customization. If anything, PS2 is a more demanding MMO than ESO.

You don't seem to understand what happens when a 32-bit app runs out of memory. It usually pages to disk, often a very slow disk. this results in something called thrashing. Thrashing wastes CPU cycles.

Lets not over-complicate or over-think this. System resources are limited for x86 apps, period. As one poster said:

Yep my game freezes up at 1.784 gigs 1 time per day.

Wish it wouldn't.

Win 8.1, 64bit.

We have all seen this happen. On an x64 OS with 8 GB + of RAM, this will not happen unless there is a memory leak. Lets stop the b.s.. We all know that x64 with 8 GB+ RAM is better for a game like ESO with large-scale PvP and PvE. Stop crippling our gaming PCs by limiting ESO to 2GB RAM ZoS. The next update should include an x64 client. You have already built at least one x64 client for the console.

Why is the PC version of ESO still an x86 client?

Ranique · July 2015

blackweb wrote: »

show previous quotes

Ranique wrote: »

1: planetside2 is a fps. I didn't know the game, but looked it up, appearance between players is not a lot different and it looks like everyone looks the same. For a FPS that is no problem. for a role playing game it is.

> This statement is false. PS2 has a LOT of character customization.

3: you haven't given any solid facts bout why it would be better.

Your assumptions about the processing demands of PS2 are false. PS2 is an MMO-FPS with many MMO features such as character and vehicle customization. If anything, PS2 is a more demanding MMO than ESO.

You don't seem to understand what happens when a 32-bit app runs out of memory. It usually pages to disk, often a very slow disk. this results in something called thrashing. Thrashing wastes CPU cycles.

Lets not over-complicate or over-think this. System resources are limited for x86 apps, period. As one poster said:
show previous quotes

Yep my game freezes up at 1.784 gigs 1 time per day.

Wish it wouldn't.

Win 8.1, 64bit.

We have all seen this happen. On an x64 OS with 8 GB + of RAM, this will not happen unless there is a memory leak. Lets stop the b.s.. We all know that x64 with 8 GB+ RAM is better for a game like ESO with large-scale PvP and PvE. Stop crippling our gaming PCs by limiting ESO to 2GB RAM ZoS. The next update should include an x64 client. You have already built at least one x64 client for the console.

Why is the PC version of ESO still an x86 client?

Blackweb,

I just going to refer to my initial post and ask you to read it. Just saying that I'm wrong, without putting anything against it, is wrong. You clearly don't have any clue what you are talking bout. You have proven that when you started to claim that 32 bits programs out of memory switched to disk cache. that one is hilarious ridicilious.making a 64 bits client is a total waste of resources, please stop your witch hunt and stop making a fool of yourself! It is not going to happen and if it will I'll stop paying any money to ZOS cause of the way they waste it!

blackweb · July 2015

Ranique wrote: »

I just going to refer to my initial post and ask you to read it. Just saying that I'm wrong, without putting anything against it, is wrong. You clearly don't have any clue what you are talking bout. You have proven that when you started to claim that 32 bits programs out of memory switched to disk cache. that one is hilarious ridicilious.making a 64 bits client is a total waste of resources, please stop your witch hunt and stop making a fool of yourself! It is not going to happen and if it will I'll stop paying any money to ZOS cause of the way they waste it!

Ok so what you are saying is that when an x86 app runs out of memory, it doesn't page to virtual memory or disk and that I have no idea what I am talking about?

http://blogs.msdn.com/b/ericlippert/archive/2009/06/08/out-of-memory-does-not-refer-to-physical-memory.aspx

Eric Lippert makes some very good points:

The amount of data storage reserved for a process is only limited by the amount of space that the operating system can get on the disk. (*)

This is the key point: the data storage that we call “process memory” is in my opinion best visualized as a massive file on disk.

There is a thorough discussion on virtual memory or memory mapping that begins with.

So, suppose the 32 bit process requires huge amounts of storage, and it asks for storage many times. Perhaps it requires a total of 5 GB of storage. The operating system finds enough disk space for 5GB in files and tells the process that sure, the storage is available. How does the process then write to that storage? The process only has 32 bit pointers, but uniquely identifying every byte in 5GB worth of storage would require at least 33 bits.

This describes the scenario that ESO is running under.

The process can deal with this situation by attempting to identify portions of the virtual address space that no longer need to be mapped, “unmap” them, and then map them to some other pages in the storage file. If the 32 bit process is designed to handle massive multi-GB data storages, obviously that’s what its got to do. Typically such programs are doing video processing or some such thing, and can safely and easily re-map big chunks of the address space to some other part of the “memory file”.

Does more memory lead to better performance? As Mr. Lippert states, it does

I haven’t yet mentioned RAM. RAM can be seen as merely a performance optimization. Accessing data in RAM, where the information is stored in electric fields that propagate at close to the speed of light is much faster than accessing data on disk, where information is stored in enormous, heavy ferrous metal molecules that move at close to the speed of my Miata. (**)

Does 64-bit or x64 windows make a difference? It sure does according to Mr. Lippert.

And of course, many of these problems effectively go away on 64 bit Windows, where the address space is billions of times larger and therefore much harder to fragment. (The problem of thrashing of course still occurs if physical memory is smaller than total working set, no matter how big the address space gets.)

Note that Mr Lippert specifically addresses the problem of thrashing above.

Ranique,

You should think carefully before telling a Microsoft developer (which I am) or anyone for that matter that they do not know what they are talking about. I made my points in simple terms that non-technical readers could understand. We can go much deeper technically if you like but at this point, you will be arguing with Eric Lippert who as his bio describes is

Eric Lippert is a principal developer on the C# compiler team.

Feel free to respond to his blog post if you disagree with him. I would ask for an apology for your condescending, nasty and just plain wrong post that I quoted above but I don't think one will be forthcoming given your snide tone. Maybe it is you who should stop "making a fool of yourself"?

I think that it is safe to say that ZoS is working on an x64 ESO client for windows especially considering that Windows 10 which will be released in 19 days on July 29 will be 64-bit only.

http://techera.co.in/tag/windows-10-64-bit-only/

I hope this gives the Zos devs a sense of urgency about releasing a x64 client.

WEB

KhajitFurTrader · July 2015

blackweb wrote: »

I think that it is safe to say that ZoS is working on an x64 ESO client for windows especially considering that Windows 10 which will be released in 19 days on July 29 will be 64-bit only.

http://techera.co.in/tag/windows-10-64-bit-only/

I hope this gives the Zos devs a sense of urgency about releasing an x64 client.

Well, as a Windows developer your're surely aware that extended support for Windows 7 ends on 14/1/2020, and for Windows 8.1 it'll end on 1/10/2023. So that's 8 years until the last 32-bit OS is faded out. So there's no need for a sence of urgency whatsoever, because ESO as a 32-bit process will run just as fine on 64-bit Windows 8.2 10 as it did on its 64-bit predecessors. And given the recent track record of adaption rates of newer Windows versions, we'll see a significant installed base of Windows 7 right up to 2020.

And frankly, I don't buy into the FUD you're trying to spread here, and that blog post you've quoted has some issues. Files on a disk are addressed as clusters, not as singular bytes, and any process, be it 32 or 64 bit, can read, write, and seek any file of any size that NTFS allows (16 ExaBytes - 1 KB on Windows 7, even more on W8). Because it disregards such a simple truth in order to make a point, the whole point is moot.

blackweb · July 2015

KhajitFurTrader wrote: »

Well, as a Windows developer your're surely aware that extended support for Windows 7 ends on 14/1/2020, and for Windows 8.1 it'll end on 1/10/2023. So that's 8 years until the last 32-bit OS is faded out. So there's no need for a sence of urgency whatsoever, because ESO as a 32-bit process will run just as fine on 64-bit Windows 8.2 10 as it did on its 64-bit predecessors. And given the recent track record of adaption rates of newer Windows versions, we'll see a significant installed base of Windows 7 right up to 2020.

And frankly, I don't buy into the FUD you're trying to spread here, and that blog post you've quoted has some issues. Files on a disk are addressed as clusters, not as singular bytes, and any process, be it 32 or 64 bit, can read, write, and seek any file of any size that NTFS allows (16 ExaBytes - 1 KB on Windows 7, even more on W8). Because it disregards such a simple truth in order to make a point, the whole point is moot.

I am a Microsoft .NET platform developer including windows and the web. I have developed both x86 and x64 applications for windows and the web. I have been following Eric Lippert for some time and I have heard an interview or two with him and I have found his statements to be quite accurate. You will note that the post was made in 2009 which would mean that it applies to windows 7 x64, not windows 8 which is one of the reasons why I chose it. I believe that his statements are accurate for Windows 7 in a 2009 time frame. I think that it is safe to say that I would take his word on such issues over anyone here except maybe the ZoS devs themselves.

I am not selling any what was it that you called it, "FUD"?

Why anyone would resist moving to an x64 client for ESO baffles me. I am astounded that an x64 client was not released with ESO from day 1. Now we know that there are one or more x64 clients for the console, thus making the PC version a second class citizen. Now that the console versions of ESO have been released, ZoS has both the time and the resources to develop an x64 client.

I can think of no rational reason to keep trashing me for suggesting the release of an x64 client for ESO other than that your ego demands that you or someone you know be right.

Audigy · July 2015

A 64 bit client, just like DX 12 support are definitely handy and highly recommended for the future of ESO. However, both things need to actually be fully optimized within the ESO software.

To just add support wont help and while I am not in the coding department, I am sure the actual code of ESO has to change a lot to make full use out of both "tools".

About 2 months ago Matt said that these new "upgrades" will come over time, but that they also have to factor in that not every runs a 16GB rig with Win 10. I wouldn't be surprised if most people playing ESO still run DX11 hardware and not more than 8 GB of Ram.

Don't get me wrong OP, I support everything that can enhance the performance of the ESO client, but I believe that it takes a bit more time than we think. The Console version is as far my understanding goes, a rewritten version to fully utilize console hardware and not just a simple "port".

Merlight · July 2015

blackweb wrote: »

Its simple math really, 1.5 GB of memory and 40 threads just is not a sufficient amount of memory

Leave the number of threads out of the discussion, please. It has no relevance to memory use or performance. At any given point in time, most of these threads are asleep (your CPU can run 1-2 on each core). Moreover, thread context switches are expensive, so using fewer threads may be advantageous.

Ranique wrote: »

This is not a RAM-limitation, but a GRAM limitation (not sure if GRAM is an official term, I made it up, but it is the graphical RAM, also known as the RAM that comes with the GPU).

Historically it's been VRAM, as in Video-RAM. Nowadays I'd rather stick to GPU memory, as it's tied to the GPU, so it's clear what you mean.

blackweb wrote: »

Ok so what you are saying is that when an x86 app runs out of memory, it doesn't page to virtual memory or disk and that I have no idea what I am talking about?

That's not what he was saying. I believe he was trying to convey to you that if a 32-bit program on a 64-bit system with plenty of available RAM says it ran out of memory, it means it ran out of address space. No amount of swapping can increase the amount of memory you're able to address. You clearly understand that, but most of your extensive explanatory post seems out of place in context of ESO. Or any game actually.

blackweb wrote: »

This describes the scenario that ESO is running under.
show previous quotes

The process can deal with this situation by attempting to identify portions of the virtual address space that no longer need to be mapped, “unmap” them, and then map them to some other pages in the storage file...

ESO doesn't need larger address space. It needs to stop leaking memory. Which equals identifying what no longer needs to be mapped. Some patches were worse, some were better, but it's still leaking. Once they figure out what is not needed, they can simply throw it away, and reload it from game files when they need it again. OS disk cache will take care of the rest.

blackweb · July 2015

ESO doesn't need larger address space. It needs to stop leaking memory.

Thank you for your well reasoned post. I agree that ESO needs to stop leaking memory if it is. However, given the demands of the game itself in terms of polygons, objects, textures, audio and character rendering, especially in Cyrodiil, I think that ESO does need more address space. 1.5 GB may be enough memory in leveling zones or small group dungeons but it definitely is not enough in Cyrodiil for a game like ESO running at HD+ resolution. ESO should have access to at least 3x that much memory or up to 5 GB of RAM for Cyrodiil. The only way for that to happen is to move to an x64 client. I don't think there is any way that PS2 could run on 1.5 GB RAM even as efficient as its game engine is.

Let me explain why. In PvE, the scaling requirements of a game like ESO can be estimated fairly accurately. There will always be a cap (except in cities with lots of characters) on how many characters, npcs, how much scenery etc. that the game engine needs to be able to handle. However, in world pvp, the scaling requirements can be much harder to predict and much more extreme. Unless the game is booting people from a given zone or location, a lot of characters can be crammed into one area or view at one time doing all sorts of things at the same time. That is when the 32-bit client just cant keep up because it has very little room to scale up to meet the additional demand in Cyrodiil PvP.

FYI, ESO uses the Hero engine. Anyone remember world pvp on the Hero engine in SWTOR?

I am sure the Hero engine has been updated since 2010 but it has a history of struggling in large scale pvp.

KhajitFurTrader · July 2015

blackweb wrote: »

FYI, ESO uses the Hero engine. Anyone remember world pvp on the Hero engine in SWTOR?

This particular rumor has been debunked a long time ago: http://www.gameinformer.com/b/features/archive/2012/05/25/why-the-elder-scrolls-online-isn-39-t-using-heroengine.aspx

The gist of it: the Hero engine has been used for prototyping until the internally developed engine had been advanced enough to take over.

blackweb · July 2015

KhajitFurTrader wrote: »

show previous quotes

blackweb wrote: »

FYI, ESO uses the Hero engine. Anyone remember world pvp on the Hero engine in SWTOR?

This particular rumor has been debunked a long time ago: http://www.gameinformer.com/b/features/archive/2012/05/25/why-the-elder-scrolls-online-isn-39-t-using-heroengine.aspx

The gist of it: the Hero engine has been used for prototyping until the internally developed engine had been advanced enough to take over.

Its not a rumor. Its a fact. I just reinstalled ESO from the download client from the eso website and there was a Hero Engine splash screen with bright blue, bold letters the first time I started the game.

KhajitFurTrader · July 2015

blackweb wrote: »

show previous quotes

KhajitFurTrader wrote: »

blackweb wrote: »

FYI, ESO uses the Hero engine. Anyone remember world pvp on the Hero engine in SWTOR?

This particular rumor has been debunked a long time ago: http://www.gameinformer.com/b/features/archive/2012/05/25/why-the-elder-scrolls-online-isn-39-t-using-heroengine.aspx

The gist of it: the Hero engine has been used for prototyping until the internally developed engine had been advanced enough to take over.

Its not a rumor. Its a fact. I just reinstalled ESO from the download client from the eso website and there was a Hero Engine splash screen with bright blue, bold letters the first time I started the game. If you have a problem with that, take it up with the ZoS devs.

Guess what, there's also the Havoc logo in the splash screens, but ESO still has no physics engine in active use. ZOS may be legally bound by contract or license to display these logos, because the libraries in question have been used once during product development cycle (e.g. in prototyping) and then no longer. By all means, had they used the Unreal engine 7 years ago, we'd still see its logo around somewhere, even if ESO'd be running on the Quake engine right now...

And btw: the HE is Windows platform only. You suppose they're still using it exclusively on Windows, while OS X and PS4 (and XBone, to some extend) got their own, separate engines developed and maintained?

Trollwut · July 2015

I just want to summarize it.

TL;DR Saying ESO should be compiled in 64-bit because it's faster then is like saying that Windows 10 should be named Windows 12 because then it's more advanced.

Merlight · July 2015

Trollwut wrote: »

TL;DR Saying ESO should be compiled in 64-bit because it's faster then is like saying that Windows 10 should be named Windows 12 because then it's more advanced.

Isn't that how Windows 9 got skipped?

https://en.wikipedia.org/wiki/Windows_10#cite_note-slate-name-9

Whilhelmina · July 2015

blackweb wrote: »

show previous quotes

Whilhelmina wrote: »

Rest assured, it isn't working any more on 32 bit clients.

Do you have a source on that? When will the x64 client for pc be released?

Sorry, missed the question. What I was saying is just that support for 32 bit system is sketchy at best. We now have massive compatibility issues, which means that they could drop 32 bit support any time.
Which is a problem, as, as opposed to what was said above, Windows 10 WILL BE released in 32 bit.

blackweb · July 2015

Trollwut wrote: »

I just want to summarize it.

TL;DR Saying ESO should be compiled in 64-bit because it's faster then is like saying that Windows 10 should be named Windows 12 because then it's more advanced.

I never said that 64 bit would be faster. If anything, 32-bit is probably faster for less demanding scenes in ESO. The 32-bit version scales poorly in large battles in Cyrodiil. In that scenario, it is likely that an x64 client would provide better performance because of improved scaling by providing 2 or 3 times the amount of available system resources.

I stand by my assertion that an x64 client is desperately needed for ESO. The current 32-bit client will never scale adequately in Cyrodiil, it just cant keep up with the increased scaling requirements of large scale pvp.

Wily_Wizard · July 2015

Agreed. Resistance is futile, you will be assimilated by x64.