Lag...the great miracle, and the great mystery
 

Recently, I've been lagging worse than normal. A computer with the same specs lags less with light effects on than I do with light effects off, so something must be causing lag. If it's some kind of spyware, Ad-Aware couldn't find it. It might be because I only have, like, 400MB left on my hardrive.

Delete some pr0n.

Graal server's were lagging awhile back, but it seems to be good now. What client are you using and where at?

It may be a good idea to free some space up on your harddrive too..

If I had any, it would make choosing what to delete a lot easier :frown:

I was using version 2.31 on Zone. I don't use v3 because it only works fullscreen.

Try switching to DirectX in options. In Graal3 that is.

Lack of file space on Windows can cause a great deal of problems if that amount actually fluctuates a lot. Try deleting FILENAMESCACHE.txt, or turning it off alltogether.

What kind of lag do you mean anyway? Graphic lag? Network lag?

I got Graalv3 to work in windowed mode, but it's way, way laggier than v2.31

Defragment, maybe? Although most of Graal's files are tiny anyway.

Does this affect any other games?

I don't know. It doesn't seem to effect video files though.

It got horribly worse after today's NPCServer reset. I can't even go through doors. :-/

Unfortunately, there are like a million things that could be responsible. Greedy processes, fragmented files, broken/old drivers, etc.

GET MORE RAM!

AND ALSO.


Try deleting some files from your heads, shields, swords, and webgifs folder. If Graal is like most programs, it has to go through all the files to find the ones it is looking for, and it probably takes longer and sucks up system resources to look through thousands of files in order to load graphics.

Yeah that might work. I went and did that and noticed quite a bit of a speed boost on GK.

I am the forerunner of Graal Technical Support. I exist because nobody else does.

are you running @ 16bit colors? I know that 32 lags the **** out of my graal.

Why do you think it indexes the files during startup?

I didn't know it did, actually. However, if it indexes these files during startup, it still has to store this index in memory. The fewer it has to store, the fewer it has to process, the fewer resources it uses to do so, etc.

If the client didn't have to run a check when it was being used, then the client would not know whether it actually had the necessary graphic, and would not know to download any missing graphics. If it has to look at each indice to see if it is a certain graphic, then surely it must soak up some resources doing so.

True. But I do not think it is likely to be a bottleneck, unless the user has literally millions of files. There are plenty of very efficient ways to construct and traverse such indices.

Somebody once suggested making a fat32 partition and sticking all of the useless junk from Graal into it to speed up the client, perhaps you could try? :0

It depends, I think. Sometimes, depending on the computer, larger folders take a longer time to open. Larger can mean either many files or bigger files. I know my webgifs is 11.8mb and 2,800 files, which is a fair amount considering I rarely play Graal. In these cases, and pretty much any case, RAM helps. Even if it doesn't bottleneck, each indice must be examined. Does Graal look at filesize, modified dates, and such, or just names? Or must it scan the raw data? If it scans raw data, larger files could take a far longer time to completely scan.

In explorer? Yeah, but how's that relevant here?

A proper search procedure on a good hash table will defiantly not be any kind of bottleneck.


It compares the timestamp of the local file to the one stored on server. But why does that matter? It is not like it is storing that in memory.

*shrug*

I figured that if one program had difficulty opening it, then another might as well.


Is that what Graal has? I haven't seen the source code.

It has to do that, which takes time. Googi asked for anything to help fix his problem, and this isn't a far-fetched one to try.

Graal is indexing the files, it remembers the location and the timestamp, see FILENAMECACHE.txt. You can turn that off in the options, but the first start of the program will take some time then. In v4 it is displaying a window telling you that it is scanning the folders for fast access while doing it.
It can take quite some time on Windows because when accessing NTFS drives Windows loads information about access rights and such, which can take ages. It is not possible to turn off that, the only choice is to use some better file system (FAT32 is much faster, but doesn't have security options), or some better OS, or delete files. The folder scanning should not slow down the game though, it is only slowing down the start.

About lag: Try to update your drivers for gfx card and sound card, and check if you have anything running that is slowing down your computer (task manager)

Oh and turn up the volumes slighty, i.e the voice one. I heard there was a bug on that or so.

I deleted a bunch of head/sword/shield/body/etc GFX. It didn't do a thing.

"opening" folders is only meaningful in certain programs, such as explorer.

You are a bit confused on the way filesystems work. When you access a file, you aren't actually opening each folder in the directory tree to get to it. You are directly accessing that file. You just have to tell the computer where to find it.

For an example open up your local terminal (or whatever it is called on Windows), and do a cd $path. You will notice for all values of $path that the execution time will be the same (try a really deep path and see).

Like anybody remembers the DOS change directory command or it's usage besides us two :P

Ok.

Thank you for getting to the point, teaching me something in the process, all without posting short answers in which extracting information is like pulling teeth. Kudos. ^^
I do! Also, I remember del *.*, dir/p, and win(or exit). Also, open for text files. I need to know these things to play all my pirated DOS games.

Or anybody that has ever written a Windows batch file.