16 replies to this topic

[The Image]

Been thinking about how to improve load times, both going into a match and out of a match as it sometimes is still rather long even after some of the improvements earlier this year.

One thought that comes to mind is the fact that all the files are stored in compressed archives, and maybe permanently pre-extracting all the files from the pak's so that this CPU intensive game wouldn't have to deal with the extra load of extracting resources from compressed files to load into memory, just load the uncompressed files directly from my SSD, decreasing the load times 10 to 15 percent (best guestimate).

Is this possible for the more tech savvy player to do on their own now? Or is this something that PGI could add support for and allow the users to opt in/activate, as a 'low hanging fruit' to boost individual player performance/alleviate some of the annoying delays in the game?

Yeah sure, it will increase the drive space foot print of the game game by as much as an additional two-thirds, but heck, drive space is cheap, and the potential very noticeable decrease in load times might be enough to make it worth it.

Edited by The Image, 18 December 2018 - 01:39 PM.

[LordNothing]

when i got my new rig and its new nvme drive, i noticed i was one of the first players loading into the match, where i was usually in the middle.

and generally speaking even an nvme drive is still slower than the cpu, which can decompress files faster than the drive can read them out. big files also load faster because they tend to be contiguous, which leads to less overhead.

Edited by LordNothing, 18 December 2018 - 04:12 PM.

[Gen Lee]

I remember when Titanfall came out, and everyone was kind of taken aback that the game was around 60GB in size, especially considering that most of that was just audio. The developers used uncompressed audio to improve performance, so that the CPUs could process the audio faster, allowing them to spend more time on other parts of the game. Granted, this was a game that was built on a HEAVILY modified Source engine, so any extra performance they could squeeze out it was helpful. I have no idea how much using uncompressed audio helped, but with HDDs and SSDs these days, drive space isn't nearly as important as performance.

I wouldn't mind MWO using uncompressed files to increase performance. Whether PGI could have done this, or at least done it without making a mess of the game in the process, I have no idea. I'm fairly certain that they would have no intention of doing it now this late into the game's life.

Edited by Gen Lee, 18 December 2018 - 08:08 PM.

[The Image]

LordNothing, on 18 December 2018 - 04:10 PM, said:

when i got my new rig and its new nvme drive, i noticed i was one of the first players loading into the match, where i was usually in the middle.

and generally speaking even an nvme drive is still slower than the cpu, which can decompress files faster than the drive can read them out. big files also load faster because they tend to be contiguous, which leads to less overhead.

That's the thing though. When you start MWO, the game opens about 200 different PAK files. Just holds 'em open and this is good because opening, then closing, then opening, etc., is terribly inefficient.

HOWEVER, what I "think" I'm seeing is because these files are compressed, and each time we switch from Solaris lobby to mech lab, to main game, to CW lobby, to searching, to actual map, the system reads these PAKs, decompresses the needed file loads it into memory, then after your done with that particular mode, it clears the space to read files it already had decompressed earlier (switching from lobby to a quick play match, and back).

If what I think I'm seeing is actually happens that means, every time you go into any map, and even if you go into that map every game, 100 times, it will decompress the needed files 100 times.

Decompressing the files requires CPU cycles and file I/O.

If the game files could be permanently decompressed we'd avoid the redundant CPU cycles and file I/O and load into and out of matches that much faster.

And think about it, when you load into a match the server is probably telling our clients which 'mechs are loaded, with what weapons, and the various camos and colors being used, so on and so forth, all adding to the load time (over and above what's required for just the map itself) to get into match, ALL those specific files have to be extracted from the PAKs, yeah sure, it's fast, they didn't encrypt or go for max compression, but, it's still time that with the 250gb free space on my SSD, I could utilize to improve my gaming experience.

Making it a user selectable option in the future would be cool, I don't "think" it would require "new" coding, only changing how the files are referenced internally, which could literally be as easy as a SEARCH-AND-REPLACE/COPY-PASTE operation.

It just seems like something "easy" to do that would make the client "feel" more 'fresh and responsive'...

[MW Waldorf Statler]

Problem No1...the most talented programmers thats familiar with the cryengine and modified all and build the basicstructur leaves the company in the time of the transverse disaster ...

[LordNothing]

you people have never had to deal with a large number of small files before. like when i was backing up a couple decades of mod assets not to mention several gigs of source code (and mind you a lot of those files are smaller than the file system allocation unit). you see your data rate drop through the floor as soon as you get to that part of the backup.

the problem isnt using the compressed files. its that it unloads everything between matches and has to load everything again. my game engine just loads all files to ram, and then closes the files. they stay in ram until the engine is closed. mind you while the game is running textures are being copied from ram to the video card, models are being copied, and transformed for rendering. the original copy of the game data just sits there in ram and it doesnt have to touch the file system at all once its running. mind you the game data is very small compared to mwo and thus i dont need to stream things in and out on the fly.

cryengine is a lot more advanced and likely has to deal with more data than can be stored in ram at any one time. hince all the loading. but unless you are using some kind of ancient cpu it should be able to handle the compressed files faster than uncompressed ones. and you certainly gain performance with an archive (even an uncompressed one) over loading the files directly. lots of stop and go where as a big file loads all at once. and mind you the game only loads at the start of the match, its not doing anything else while its loading, the cpu fully focuses on decompressing data.

if you want to blame something blame those huge 2k textures the game uses. i sure as hell hope those are pre-compressed as that is a lot of data and compressed texture formats can have ratios as good as 8:1, and they do not need to be decompressed to use them (they are very easy to decode and that can be done at rasterization).

Edited by LordNothing, 19 December 2018 - 03:49 AM.

[cyclist1994]

You people are just guessing.
You have no clue of any implementaions.
Also many performance relevant stuff isn't even depending on the engine.

[The Image]

Yes, a lot of this guesswork based off observation of the system activity.

I too had a job in technology, working for one of the planet's largest banks as an SE for their reconciliation system. This software processed hundreds of thousands of files from internal and external sources ensuring that credit card accounts, automatic bill payments, ATM transactions, etc., etc., etc. were correctly processed and accounts were properly debited/credited based on actual activities. I can tell with absolute certainty that non-compressed files were absolutely, positively faster to work with than compressed data, to the point of we had a specific system built to receive and decompress any files that came in a compressed state (and because of the various external sources using various means of compressions, we had to build a system that could handle ANY type compression).

A compressed file requires significantly more CPU processing to open, decompress, THEN read/load into memory than a non-compressed file, by several orders of magnitude.

If you have an inefficient file system, it can be even more of an issue.

For the archival process it sounded like you were describing, yes compressed files process faster but that's because your typical archival process is a contiguous 'data stream' from one location to another. The smaller, more compact/data dense the file, the better.

For actual programmatic functionality however, nope, non-compressed is best. It's a lot 'wasted' CPU cycles otherwise.

And absolutely agree, I don't believe this particular suggested change would make ANY difference to us while in a match (where the Crysis engine does most of its work), it could just make getting into and out of a match very much FASTER and feel less... clunky...

Edited by The Image, 19 December 2018 - 06:03 AM.

[Gen Lee]

In a game where a player being disconnected for any reason results in a major disadvantage for the team as a whole, the time it takes to load back into a game can be a very big factor regarding winning and losing a match. This is especially true when disconnects happen quite frequently, and they do. I wouldn't mind quicker loading times if it meant the game took up more space on the drive.

[LordNothing]

cyclist1994, on 19 December 2018 - 05:31 AM, said:

You people are just guessing.
You have no clue of any implementaions.
Also many performance relevant stuff isn't even depending on the engine.

ive wrote enough file handling code to know what im talking about.

[Nightbird]

.pak files can be just .zip files. I renamed a .pak file to .zip and it extracted correctly.



As you can see, 146 MB extracted to 548GB. The game folder is 21GB, and using this compression ratio would extract to 79GB (I'm not gonna bother to try for real). The question would be, would your storage be able to read 79GB faster than reading 21GB + decompress it? The answer is usually the latter, reading a much smaller amount of data and spending CPU cycles to decompress it is MUCH FASTER than simply reading uncompressed data.

[The Image]

Nightbird, on 19 December 2018 - 03:18 PM, said:

...

The answer is usually the latter, reading a much smaller amount of data and spending CPU cycles to decompress it is MUCH FASTER than simply reading uncompressed data.

Yeah I think you're right for a few different reasons.

I forgot that maintaining a single open file lock and then using the PAK archive structure is typically faster than open multiple files (as long as your archive is less than.. what? 1500 files or something like that, can't remember... anyway...) so there are efficiencies gained from that alone. Somewhere near 200 open files locks vs. the probably 2000 that would be necessary in an uncompressed state has definite efficiencies that even with significant tweaking of Windows' file heuristics you wouldn't be able to compensate for.

Guess I just didn't think this idea through as far as I should have.

The file would be ultimately be pulled into memory faster if it were compressed, but it's all the additional file IO that is generated for each individual file that makes the difference. The potentially thousands of small files that have to be referenced when loading 24 custom 'mechs into a "large" map with detailed terrain...

[LordNothing]

Nightbird, on 19 December 2018 - 03:18 PM, said:

.pak files can be just .zip files. I renamed a .pak file to .zip and it extracted correctly.

As you can see, 146 MB extracted to 548GB. The game folder is 21GB, and using this compression ratio would extract to 79GB (I'm not gonna bother to try for real). The question would be, would your storage be able to read 79GB faster than reading 21GB + decompress it? The answer is usually the latter, reading a much smaller amount of data and spending CPU cycles to decompress it is MUCH FASTER than simply reading uncompressed data.

they have been zip files as far back as quake 2.

while you were in there did you check to see what texture format is being used?

never mind, they are .dds files. a common texture format for games (this is the ms file format for s3tc, a format so old my voodoo card supported it). this format supports multiple compressed and uncompressed modes so more investigation is required.

looks like they are using 5 map channels. 3 of which appear to be using the dxt1 format (4bpp), a really efficient format for storing rgb color data. these are what looks like a diffuse color map (your base texture), a damage mask (to render damage effects), a color masc (i assume for allowing custom colors), this only seems to use the red channel. the other 2 are a normal and specular map and appear to be using dxt5. specular uses all four channels and the normal map uses 2. in other words pretty standard stuff. also i figure this is as compressed as you can get. id have splurged a little and use bc5 as a normal map format and bc4 for that color mask, its a shame those formats never caught on.

Edited by LordNothing, 20 December 2018 - 05:13 AM.

[MrVaad]

The pak files are used in many different ways (you can see that by monitoring mwoclient.exe
- the big ones are accessed only to read the needed files.
- some small ones seems to be kept compressed in memory.
- some small ones are fully uncompressed and loaded.

I'm also preparing a big post on the user.cfg config and an optimisation i found regarding the shader cache in the pak files (i gained a few seconds when loading a level, from 13 to 8 in the testing grounds for caustic fields)

And from what i've monitored, disk access is mainly when loading a level. There's almost nothing during the match, big stalls were mainly caused by shader activation.

And a very important thing !
MWO only loads files contained in a pak file (except for shaders generated in the shader cache of the user directory)
This behaviour can be changed with a variable in user.cfg but of course, this one is LOCKED

Edited by MrVaad, 20 December 2018 - 06:33 AM.

[Nightbird]

MrVaad, on 20 December 2018 - 04:44 AM, said:

I'm also preparing a big post on the user.cfg config and an optimisation i found regarding the shader cache in the pak files (i gained a few seconds when loading a level, from 13 to 8 in the testing grounds for caustic fields)

Cool, but please test in private lobbies. Testing grounds is local, lobbies are server side, and the permitted changes are only enforced server side.

[MrVaad]

Can you start a solo game in private lobbies ?

Anyway, i do test my changes in match (to check which variables are locked)

[LordNothing]

its not really that obvious that you can do it. you need to start a group and then you can launch into a custom match.