Because before, the global file of the game was basically full. As I understood it, this is why changes to one server had to be across all servers. I remember there being several changes TLPers wanted that "couldn't be done" because doing so would have to also place the same changes across all servers, and non-TLP servers would have been negatively affected. So what I'm wondering is: Now with vastly more space in the global files, they can make individual servers have their own "laws of physics" separate from the laws of physics on all the others, specifically because of the change?
S
Secrets
would know if I'm interpreting any of this correctly or not.
Nothing would change if it was 64-bit for Vaniki. The crashes are independent of servers. 64-bit simply resolve an out of memory crash (that could potentially occur on any server or game client connected to any server, not just Vaniki), and increase client and server performance by about 5-17%. It depends on your hardware and their setup.
The part you posted about a 'global file' is nonsense - you probably picked up on the 'GlobalLoad.txt' file, which is just the list of models the client pre-loads upon entering world, so that other zones do not have to cache that model - they're persistent in memory. There's also an 'OnDemandResources.txt' which streams models and races across zones on the server's request - for example, it isn't always needed to have, say, a very specific cash shop item in memory at all times. This allows you to load them once for a specific zone, and then unload them.
In a 32-bit address space, due to a limitation with DX9 memory management, it's possible to exhaust texture memory after a while, when:
a) zoning too many times and too frequently
or
b) loading and unloading too many dynamically loaded resources
In EQ1's case, the newer zones are more graphically intense and they swap out models and textures more frequently, exhausting the amount of availble 'freed' memory in sequential order. For example, if 20 textures that are 256x256 are allocated at the same memory space, and only 12 are freed, and Windows decides to allocate two 32x32 textures within that freed memory, that means there's significant memory fragmentation and that area cannot be reused for the 256x256 textures again, so if they're reallocated, you're left with a gap between memory marked as freed or 0'd.
It would be rare to see a memory limit reached in say, North Qeynos on a TLP server - as most people do not have cash shop cosmetics enabled, and most are looking for nostalgia and do not run Luclin models so thus Hero's Forge models are not present, either.
It's theoretically possible if too many players have the same weapon cosmetics, or if you preview too many items in the cash shop, and then continuously do this across multiple zones for a 12 hour gaming session that you may end up exhausting the game's physical memory ceiling of 4GB - there will eventually be too little 'gaps' in free memory that textures could be allocated to, and thus the game would crash.
It would have no impact if Vaniki was run on 32-bit or not for most day to day users, as the server would run the same as the other decades of TLP servers without much issue. And even if you did hit an out of memory crash, you simply log back in after that extended play session and the game's likely fine for another few hours.
Vaniki is also less populated than other TLPs, so it's likely it would have not been noticeable anyways. Even if it managed to attract the attention of one of the higher pop severs, it still would not have been an issue as those other servers generally ran fine.
I personally have experienced this same issue on Unreal 3 both as a player and a developer - for instance, APB: Reloaded currently has an out of memory crash that was identical to how EQ1/EQ2 were seeing due to their client being 32-bit.
APB: Reloaded's development team is now moving to 64-bit instead of their 'engine upgrade' as it will be more impactful. I imagine after determining that is a lot of where their performance issues lie within, they made the decision - it will be interesting to see if that reduces stutters considerably in that game as it did in EQ1. Their 'Unreal 3.5' upgrade was struggling with the DX11 renderer as that code was half-baked, really - it wasn't ever really production ready. So I'm glad to see them move this direction instead of that. Players need a stable gameplay experience first before adding onto graphical fidelity at the same time. I imagine EQ1 will attempt higher graphical fidelity after having made this move.
APB Reloaded is in a similar situation with disk loaded assets and performance degradation - they write all dynamic textures to disk and load them as-needed per-session via a memory map from disk... However, the DX9 renderer still has the same bug that EQ1/EQ2 encountered, and there's frequent complaints about out of memory crashes.
The game also encounters a silly amount of stutters as a result of loading and unloading from disk, and EQ1/EQ2 both have had less stutters since migrating to 64bit.
I can imagine that is attributed to extra registers for math, direct hardware access, the native CPU task scheduler instead of an emulated one, bypassing the Windows on Windows translation layer for 32 <-> 64, and the higher memory ceiling meaning that Windows can reliably use more memory and without CPU figuring out where that memory is available at within the user-allocated memory regions.
Anarchy or justice: which will you choose? Hit the streets as a licensed vigilante or hardened criminal in the gritty metropolis of San Paro, where shootouts, car-chases, robbery, and vandalism are all in a day’s work.
www.gamersfirst.com
