"graphics lag" in borealis and other areas (a "solution")

[Demoder]

I've done some research on gfx lag in zones where there are a lot of people around.
In Borealis for instance, or outside rome blue basic, a lot of people tend to gather. Whenever I pass by these, I drop to 0.x fps while the game is loading textures and whatnot.
This is, from what I have seen, something many people have experienced.
So, today, I decided to do a experiment.
I loaded up FileMon (http://www.sysinternals.com/Utilities/Filemon.html) and filtered for client.exe.
Whenever I moved, the playfield file (eg. cd_image\data\statels\800.pf for borealis) was accessed on the filesystem.
Whenever new textures were loaded, "cd_image\data\db\ResourceDatabase.dat" and "cd_image\data\db\ResourceDatabase.idx" was accessed on the filesystem.

So, I set up a 3GB ramdrive (!) and copied Anarchy Online onto this.
I started AO, ran around in borealis and rome... without graphics lag.
NO graphics lag. At all. Nada. Was entirely gone.

So, my question to FunCom, is this:
Can you PLEASE make AO load up the playfield files for the area you are in into memory, and make AO access it in memory instead of disk?

And can you PLEASE load the texture files, and KEEP THEM, in memory, untill they have not been used for a while? AND access them in memory instead of disk?

Because to me, it seems like AO is hardly using memory - only disk.

Also, I am having this impression that AO is memory greedy, and unload textures as soon as they are outside of your viewrange... Could it be possible to make AO adjust this by how much memory you have?



Last words:
This 3GB ramdrive crippled my box ("only" have 4GB ram), so I'm unloading it and playing AO the normal way. With gfx lag. I will look into making cd_image only go into ramdrive. Would save some space, and possibly make it possible to do other stuff while playing AO afterall.

And, I think that by moving the game to a ramdrive resolving the gfx lag, proves that most the gfx lag is caused by frequent access to the harddrive instead of efficiently utilizing the memory available on a computer.

Sidenote: Making AO load textures and playfields into memory and keeping them there would take significantly less space than loading the entire game onto a ramdrive like I did....

Edit: I'm not quite sure if this was the right forum to post it in. Please move to whichever forum is the right.




UPDATE:
I was playing with the client NOT on the ramdrive, and I experienced doorlag. When this doorlag appeared, there were a ton of write requests (!) to my prefs folder, for my char, to the Prefs.xml file. Most had "SUCCESS" as result, while some had "FAILURE". (file: "prefs\<account name>\Char<charid>\Prefs.xml" and some to "Prefs\<account name>\Prefs.xml" and "Prefs\Prefs.xml"). This was with doorlag in Fair Trade. I have no explanation for why it wanted to write to my prefs files at that time though. As normal, when going through the door again, there were no doorlag. This time there were no write requests to my prefs files either.

A smaller, provoked, doorlag in Rome Green Superior shop, on the way into trade department, showed about 134 access requests in one second spread on ResourceDatabase.dat and .idx. This was for as long as the doorlag lasted. (this is not considered a normal doorlag imho)


Update2:
I noticed that the prefs files are written to regulary.
Can the doorlag issues possibly be caused by the prefs files being written to at the same time as a rather huge ammount of textures are loaded?
Any devs able to comment on this?

[Sefus88]

wherever it belongs...
bump!

[Damon7]

bumpage

[TheWalrus]

This is not as easy as you would think. Actually lots of stuff still is NOT unloaded from memory and it hurts people like me, who only have 512mb of memory or so.

What I would like to see is AO unloading MOST of the textures from memory after each zoning.

edit: perhaps if FC made it so that you can tell AO to use this or that much memory or to load/unload previously stored textures etc. Not sure how doable it is, nor do I think such option would ever make it to the client

[Onack]

me wants...
bump!

[Demoder]

This is not as easy as you would think. Actually lots of stuff still is NOT unloaded from memory and it hurts people like me, who only have 512mb of memory or so.

What I would like to see is AO unloading MOST of the textures from memory after each zoning.

edit: perhaps if FC made it so that you can tell AO to use this or that much memory or to load/unload previously stored textures etc. Not sure how doable it is, nor do I think such option would ever make it to the client

To specify, what I'm asking for, is to load the gameworld textures and generaly playfield data into memory when you enter a zone. It's then natural to unload whatever was loaded in the previous zone. Then, whenever a texture is loaded other than the static gameworld textures (eg. a player armor texture), keep that in memory for a good while instead of unloading it whenever the texture is leaving your viewrange, for then to load it when you possibly just seconds later have to load in the same texture.

As someone mentioned to me after reading this post, FC could as well split up the textures database into smaller chunks, so that each access to the database containing the requested texture does not take that much time. (Currently, my "ResourceDatabase.dat" is about 1,28GiB.)

[Demoder]

I'd like to hear if other people find the same as me, and eventualy, get confirmation or contra-info on my conclusions.

Meanwhile, please keep bumping this post till we get some comment from FC on this

[DaviasI]

Good idea, except for the fact that FC has to deal with the fact that any given computer will have lots of different memory footprints.

For people like TheWalrus it would definitely not work because XP takes up 200-300MB of RAM and AO takes up more than that so its already accessing the swap disk. So no matter what they do its just gunna be slower.

For systems such as mine which have 1.5GB+ of RAM your idea would make more sense, if you don't consider the fact that:

For some users AO has had memory problem in which it didn't uncache textures from RAM when you zoned and just added the new ones in so the memory footprint ballooned until it was nearly a 1GB of old textures from half a dozen zones ago and would crash. Now I know for some people that problem was solved but I see that a few people still have to re-log after every couple of zones.

A lot of the lag I get from places like Borealis is player related since the players tend to move in and out of buildings a lot so at any given moment half a dozen or more players with random textures on may pop into range or vanish from it.

Now this does not excuse places like Omni-Trade which is nearly deserted and still causes insane amounts of lag even on an AMD 3000+ cpu. 1.5 GB of ram loading off of a WD raptor (150GB)

Now my problem is I've had contradicting expereiences with lag. On one hand the machine listed above always gets lag in Borealis and extreme lag in Omni trade. On the other hand, with an AMD 64 4200 (yes a much more powerful machine) with 2GB of ram and another WD raptor (74GB), I experienced well over 70 FPS and no lag whatsoever in Trade or Borealis (a very strange feeling for a regular visitor watching people go pew-pew and then being able to tell which ones are lagging). I didn't lock the game to one processor or do anything else special on this new machine. All effects were on, ground and view distances were set to max. If it were a problem of AO not loading all the game textures in RAM I should have exprerienced at least door lag on the new machine, but got no lag. AO didn't load up the entire database in memory, it still had the same memory footprint as on the older machine.

BTW in both machines I killed set the swapdisk to 0. And I haven't run out of RAM. Even while doing back to back apf, zod, beast raids on the slower machine. I've not taken the new machine on a pande raid, because well its owner will claim it soon and no point setting everything up just for that.

All I can conclude from my experience is, faster processor makes everything go better. After 1GB of RAM the amount of memory is irrelevant.

[Doctorhyde]

2 questions:

1) What are you using to create the ramdisk?

2) is there any way under XP to move just 1 file to a ramdisk and redirect calls for that file to the ramdisk file?

I only have 2GB ... I could get alot of benefit from having \Funcom\Anarchy Online\cd_image\data\db\ResourceDatabase.dat onto a ramdisk, but I don't have enough ram to do the entire CD image.

I know how to do the above under Linux, but my Windows skills aren't up to par.

[Demoder]

2 questions:

1) What are you using to create the ramdisk?

2) is there any way under XP to move just 1 file to a ramdisk and redirect calls for that file to the ramdisk file?

I only have 2GB ... I could get alot of benefit from having \Funcom\Anarchy Online\cd_image\data\db\ResourceDatabase.dat onto a ramdisk, but I don't have enough ram to do the entire CD image.

I know how to do the above under Linux, but my Windows skills aren't up to par.

I used a trial version of "RamDisk Plus" (http://www.superspeed.com/download/trialversions.php) to create the ramdisk.

You can use "Junction" (http://www.sysinternals.com/Utilities/Junction.html) to do what you describe in your second question.
I have just done this with the cd_image folder alone (can be done with individual files), and that improved gfx performance significantly. Doorlag still occurs, but is less severe. I'm going to test with loading my profile into ramdrive too.

That particular ramdrive software seems to let you tell it to save the ramdrive data to a image on disk when you power off, and load from this image when you start up windows again.

EDIT: Seems like that, since AO is loading off the hd, it is quering the hd filesystem to be pointed to a file on the ramdrive. This query itself causes some graphicslag. But it is reduced by the fact that the data is stored on the ramdrive.

[Daiken]

FC should implemant this, it sounds all good but its to much work and extra downloading to make this work..
stupid thing is i have a high end computer, and i always go WTF? when i get lag.. now i know why ^^

[ninor]

Have u tried to put ur prefs on the ramdrive? That should reduce doorlag and it is only a few MB.

This actually sounds more like a bug to me, since i see to reason to trigger any pref writes while changing rooms in a dungeon (pulling missions or accessing bank is somthing different).

As for the texture part, this seems like a greater problem since it has to take a wide varity of systems and even operating systems into account. Finding a good workable solution for FC is far from easy or fast to implement.

[Demoder]

Have u tried to put ur prefs on the ramdrive? That should reduce doorlag and it is only a few MB.

This actually sounds more like a bug to me, since i see to reason to trigger any pref writes while changing rooms in a dungeon (pulling missions or accessing bank is somthing different).

As for the texture part, this seems like a greater problem since it has to take a wide varity of systems and even operating systems into account. Finding a good workable solution for FC is far from easy or fast to implement.

When it comes to the prefs folder, I tried to move only cd_image and the prefs folder to the ramdrive.
This reduced lag, but it did not have the same effect as moving the whole thing onto the ramdrive.
I suspect this is because it actualy goes on HD, finds the pointer that points to the ramdrive, then reads from the ramdrive. So there is _some_ HD I/O, but far less. Again, there is some lag with this, but far less.


Note:
Some of the doorlag may be because textures are loaded the first time you see them.
This means, if you open a door to a big room, with many mobs, it loads the textures for all those mobs when you open the door.
I think it could be better to preload this when you enter the area, at least to some extent. Like missions, preload the textures for all mobs/items (or almost all mobs/items) to reduce the amount of texture loading from disk when you go through a door.
It seems to me, that when you zone, the game loads the textures of the things you will see around you when you have completed zoning before you get out of the "changing area, please wait" phrase.

[Runz]

you must know already funcom knows how to make a great rpg but after that well lets just not give up our day jobs.

[Puheenjohtaja]

Seems like the players have to solve lag issue for funcom
Great post btw, will have to try it myself too.

[Runz]

I used a trial version of "RamDisk Plus" (http://www.superspeed.com/download/trialversions.php) to create the ramdisk.

You can use "Junction" (http://www.sysinternals.com/Utilities/Junction.html) to do what you describe in your second question.
I have just done this with the cd_image folder alone (can be done with individual files), and that improved gfx performance significantly. Doorlag still occurs, but is less severe. I'm going to test with loading my profile into ramdrive too.

That particular ramdrive software seems to let you tell it to save the ramdrive data to a image on disk when you power off, and load from this image when you start up windows again.

EDIT: Seems like that, since AO is loading off the hd, it is quering the hd filesystem to be pointed to a file on the ramdrive. This query itself causes some graphicslag. But it is reduced by the fact that the data is stored on the ramdrive.

be nice for a simple tut for us slow ones :P

[Khalem]

The graphics lag you experience when running around cities have been discussed before. You are right on in your analysis, but there is one small detail you didnt mention.

The fact that it stutters is not so much that it reads mostly everything from disk, but the fact that the frame rendering stops completelty until it has been read from disk, hence why you see the 0 FPS when it happens.
Basically, AO tries to load and render the textures in a single frame, meaning that the more people in the area there is (think tower battles and cities), the longer it will stay completely frozen while the game finishes reading everything from disk.

The door lag related prefs folder reading is news to me, and it definately sounds like something funcom should look into.

[Enno]

The fact that it stutters is not so much that it reads mostly everything from disk, but the fact that the frame rendering stops completelty until it has been read from disk, hence why you see the 0 FPS when it happens.
Basically, AO tries to load and render the textures in a single frame, meaning that the more people in the area there is (think tower battles and cities), the longer it will stay completely frozen while the game finishes reading everything from disk.

Thank you. You get a silver star for the correct answer And I've working on that issue for quite some time now, but you'll have to be patient, it's a big change. Because not everyone has memory to make a 3 GB ram disk (I certainly don't).

And to the original post: Yes, the playfield file loading is pretty braindead, too, and Andre has had a look at that earlier (basically, it forgets everything it doesn't look at after about 10 seconds).

[Khalem]

Whee, i get a star :P

Its reassurning that you guys are very aware of the problem, and i realize that its easier said than done to fix it.

Im curious though

I was playing with the client NOT on the ramdrive, and I experienced doorlag. When this doorlag appeared, there were a ton of write requests (!) to my prefs folder, for my char, to the Prefs.xml file. Most had "SUCCESS" as result, while some had "FAILURE". (file: "prefs\<account name>\Char<charid>\Prefs.xml" and some to "Prefs\<account name>\Prefs.xml" and "Prefs\Prefs.xml"). This was with doorlag in Fair Trade. I have no explanation for why it wanted to write to my prefs files at that time though. As normal, when going through the door again, there were no doorlag. This time there were no write requests to my prefs files either.

This seems like very odd behaviour, or was this what you reffered to when it comes to playfield loading? Or does the same problem apply to mission doorlag too? Earlier testing done around the release of SL revealed that mapupgrades had a major effect on doorlag in missions, although i do belive that some dev (might have been you Enno?) commented recently that this too was related to the rendering in single frame issue.

[Runz]

Thank you. You get a silver star for the correct answer And I've working on that issue for quite some time now, but you'll have to be patient, it's a big change. Because not everyone has memory to make a 3 GB ram disk (I certainly don't).

And to the original post: Yes, the playfield file loading is pretty braindead, too, and Andre has had a look at that earlier (basically, it forgets everything it doesn't look at after about 10 seconds).

Or you can save your self some work and upgrade the engine!

Woot Plat Star for me!