Stranglehands wrote: »

There was a short glorious period, I think after the craglorn update(?) when I could put my graphics settings to high without it crashing or the textures going screwy. That's all I want out of this 64-bit patch really

I can finally play the game with the settings cranked all the way up to 11, but it took a new rig with an i7 6700k and a 980ti. It looks gorgeous! I even turned grass back on, though it makes spotting mats on the ground much harder from a distance, because all the flowers look so pretty

Still slows to a crawl in Cyrodiil, though.

People are forgetting it's a different assembly language architecture, too. 64 bit capable commands should (if done right) be more efficient than multiple 32 bit commands to perform the same function.

Anytime software is upgraded to fully utilize the available hardware, it should be a good thing.

Much of depends on whether they are also trying to optimize, or basically doing a straight conversion of the 32 bit client. How much of an actual performance difference there will be, not counting the lack of need to load/unload things from memory as often, will remain to be seen.

It's not so much that your 32 bit client will get 'sped up' as it is that your 64 bit hardware has been forced all this time to throttle down...

The only immediate downside to this is that there will now be 32/64 bit specific bugs that may not occur on the alternate client, giving them twice as much to fix...

Slylok wrote: »

I am looking forward to the 64bit client.. They can possibly increase texture quality since the RAM isnt going to be a problem anymore.

u sound like a pve-er, have u seen the lag in cyro, leave that texture alone

Merlin13KAGL wrote: »

People are forgetting it's a different assembly language architecture, too. 64 bit capable commands should (if done right) be more efficient than multiple 32 bit commands to perform the same function.

I highly doubt they're going to make changes to the game code with the 64-bit client. Namely because of this:

Merlin13KAGL wrote: »

The only immediate downside to this is that there will now be 32/64 bit specific bugs that may not occur on the alternate client, giving them twice as much to fix...

Speaking of which,

KhajitFurTrader wrote: »

Merlin13KAGL wrote: »

The only immediate downside to this is that there will now be 32/64 bit specific bugs that may not occur on the alternate client, giving them twice as much to fix...

My educated guess ist the the active development of the 32-bit branch will eventually be frozen, declared as being deprecated, and then faded out. Until then, major feature updates to the 64-bit client, if applicable, might be backported -- or not.

I don't think that is feasible. Client code needs to be exactly the same across versions - barring some improvements specific to a branch - if both are to be used for the same server, otherwise you wouldn't be able to have people on both clients playing together. The only thing they could make different is stuff that doesn't affect the game, e.g. the UI. But I don't think you'd get much improvement from UI changes.

daemonios wrote: »

I don't think that is feasible. Client code needs to be exactly the same across versions - barring some improvements specific to a branch - if both are to be used for the same server, otherwise you wouldn't be able to have people on both clients playing together. The only thing they could make different is stuff that doesn't affect the game, e.g. the UI. But I don't think you'd get much improvement from UI changes.

If you meant the network code needing to be the same on both client versions, you're right. But servers seldom care about which renderers run client-side, or how they manage their memory. For all we know, server code is the same for all client platforms.

Concerning the client, 3rd party libraries which support 32-bit only would need to be replaced with entirely new products. Whether these support both modes and thus will be used in both branches remains to be seen. I'm rather curious myself whether a certain cross-platform HTML rendering library that is used to display the UI's in-game help and bug report section will get replaced on both the 32 and 64-bit versions of the Mac client, since it broke with the introduction of Mavericks. But I don't think that OpenGL 4.1 and FaceFX will be backported to the 32-bit Mac client, due to the existing memory constraints.

danno8 wrote: »

GW2 added a 64-bit client a few months back and all you had to do was download a few hundred MB or so and just replace the old GW2.exe with the GW2-64.exe. It was pretty easy.

Aside from the a few widespread problems on the first day it has otherwise been pretty smooth. Personally I have had no issues with it at all.

However, to be fair ANET is far, far, far better at finding bugs and squashing them fast, and they seem to be able to just push out patches to the servers on the fly, even while people are still playing. In fact their whole server/client system is superior to any other MMO I have played.

Truth. It took me 8 minutes to download HoT at midnight on launch when everyone else was downloading at the same time. They use magic, its the only logical answer

Capraid wrote: »

moesmaker wrote: »

You must be kidding. Take a look on their forums. It's client crashes all over the place. And have you tried playing GW2 on a mac? It's a buggy mess.

Your mistake is trying to play games on MAC.

ESO's MAC client is 100% native, and we get great support from ZOS. GW2 is Cider port, and I always had problems.

AzraelKrieg wrote: »

Wollust wrote: »

Can someone explain to me what's good about a 64 bit client? No IT knowledge here

The architecture of PC software can place limits on hardware usage. A 32-Bit operating system such as the older versions of Windows (95 through to XP) were 32-bit and limited the amount of usable hardware (RAM was limited to 4GB). 64-bit systems remove that low limitation make it possible for better use of available hardware.

Would indeed be nice to be able to utilize more of my 32GB of RAM.

WalkingLegacy wrote: »

VRAM only bottlenecks you if you're gaming past 1080p. Most 'gaming' GPUs have more than enough VRAM for 1080p. (MSI 970ME)

Upgrading to a SSD does not help much for games built on Hero engine. ToR and now ESO prove my theory on this. I mean, you'll see improvement over a disk but the game still loads poorly when compared to other games.
(I use a Samsung 850 512gb)

The 64bit client should have been developed from the get go. 32bit will be the thing of the past in a few more years.

Will be interesting to see if it actually brings any improvement to client side though. I'm sure if all goes well, all the fixes the push with this DLC will make it look like it was a magic fix from the 64bit client.

How much VRAM a game uses depends less the game resolution and more on the size, the color depth of the textures, the number of textures, and the location of the textures in the game environment. The architecture of the video card will determine how efficient the VRAM can be managed from the operating system.

Textures define the surface materials you see in the game such as wood, brick, dirt, smoke, water, game effects, and etc. The design of the game engine will determine what the maximum color depth is and resolution of a texture, and how many texture can be displayed concurrently between scene updates. The amount of VRAM in a video card determines how much of the scene information can be retained between video updates.

The speed of the motherboard memory bus and the hard drives system determine how efficiently the VRAM can be reloaded with different textures as the player moves from one location in the game to another which continuously changes the scene data.

How the game engine manages various resolutions is directly related to the capabilities of the video cards that are available when the game engine was creating or updated. The developers try to design a texture management system that will work with the current VRAM capacity of the video available at the time the game engine is designed.

The game engine’s color depth will be defined by the texture format; this format may be JPG, PNG, TIF, BMP, or a proprietary format; proprietary formats are usually quicker to manage and more efficient then general purpose formats. A texture using 32 bit color uses twice as much storage as one using 16 bit color.

Texture size is also determined by the number of pixels used to store the image information. The larger the texture size, the more information is stored, and the sharper the material looks in the scene. If the texture size isn’t large enough, the material in the scene with look pixelated.

So here’s the dilemma:

1) Having too many small textures in a scene will fill up the VRAM cache and require constant steaming of texture data from the hard disk to the Video card’s VRAM.

2) Having a few extremely large textures per scene will also will fill up the VRAM cache and require constant steaming of texture data from the hard disk to the Video card’s VRAM.

So it’s possible that if the game texture settings are set too and the drawing distance is set to the maximum, a game may still be unplayable even at 1080 if the card doesn’t have enough VRAM to support this particular game configuration.

It’s also possible to game at a higher display resolution if the texture resolution is lowered, or the drawing distance reduced, or both, and have the same performance as you had at a display resolution of 1080.

Upgrading to a quality built SSD does improve physical loading times independent of whatever application or game engine is being used.

I’m running ESO on a i7 4 GHz system with 64 GB of RAM, a Samsung Pro 1 TB SSD plugged directly into my PCIe slot and ESO is the only game or application that has large loading times when fast traveling between zones. All my other games such as GTAV, Skyrim, and Fallout 4 load almost instantaneously. When installing ESO in a RAM disk I notice that the game is much quicker than even when running from a SSD, but the loading times when fast traveling between zones haven’t changed.

I’m inclined to believe that the reason the ESO loading times are long is due to other factors such as syncing the player to the zone, verifying that the player’s game data is not corrupted, and etc., or maybe the ESO servers are having issues? There are just too many variables that we as players will never know, so anyone’s opinion as to why the load screens are so slow is just that – an opinion - not fact!

Sorry about being long winded here, I just back to ESO after playing Fallout 4 logging 700 hours since November and I still haven’t found all the side quests yet – unbelievable!