Slowdown due to virus scanner?

[Radiant]

I'm told that many modern virus scanners do a full scan of any executable whenever it's opened; and I know that AGS (by default) stores all its sprites, room files, and sound effects in the main executable. This could be an issue, at least hypothetically, causing system slow down if a 50 to 100 megabyte exe is virus scanned whenever the player switches rooms.

But I don't personally have this issue. I wonder if some of the people who've worked on big games have heard reports about this? Or is it simply not a big deal because virus scanners are fast enough? Thanks!

[Khris]

I'm probably missing something, but why would the virus scanner rescan the file whenever the player switches rooms?
Also, my virus scanner (avast) seems to scan whenever I open a directory. Files recognized as viruses disappear as soon as I open the folder containing them.
I have never experienced additonal lag when opening a big exe file.

[Crimson Wizard]

I have never experienced additonal lag when opening a big exe file.

Heh, I have. The old version of my antivirus (Dr. Web) literally froze computer for 10 minutes when I tried to run "Downfall" (it was about 800 megs, IIRC).

[LimpingFish]

I'm running the free edition of Avira, and the only action I've specifically noticed it doing is auto-scanning a download. Whether it's actually scanning every exe I run I can't say for certain, but I've certainly never noticed any slowdown.

[Radiant]

I'm probably missing something, but why would the virus scanner rescan the file whenever the player switches rooms?

Because the new room has to be read from disk, and to do that the game has to open the file, and the file is an EXE; opening an EXE tends to trigger virus scanners.

[Khris]

I know
But wouldn't the exe be kept open for reading while the game is running? I have no clue how exactly antivirus programs operate, but my take is that it is impossible to change/overwrite an exe file that's currently being executed (because doing so is prevented by the OS), so there's no need to scan it continuously, just because some resources are loaded.

[Radiant]

Well, the EXE should be kept open (since sound effects are also streamed from it, and the sprite file is in there), and the scanner should not repeatedly scan it anyway, but that doesn't mean that's what actually happens   We can affect the former by asking the AGS developers, of course, which is why I'm trying to find out whether this is an actual, real problem or only a hypothetical one.

[Crimson Wizard]

Well, the EXE should be kept open (since sound effects are also streamed from it, and the sprite file is in there), and the scanner should not repeatedly scan it anyway

Frankly, I do not know how scanners know when to re-check the file, but when the resource is being read from the EXE, it opens it over again every time, and not keeping it open at all times.

The only exception AFAIK is sprite cache.

[Radiant]

Okay, so if I understand correctly, I can minimize additional opening of the EXE file if I

• Enable "split resource files" to move the room files out of the EXE
• Use winsetup to set the sprite cache size to something bigger than the ACSPRSET.SPR file
• Move sound effects out of the EXE file by compiling them into the VOX

[Crimson Wizard]

I added a note in the post above regarding sprite cache.

• Use winsetup to set the sprite cache size to something bigger than the ACSPRSET.SPR file

This will not affect this issue, because sprite cache keeps a file opened, unlike others.
Changing sprite cache size may improve game speed, but this won't have much effect (if any) for low res games.

Regarding room files: I don't know, we need to check the Editor code first to see what the splitting actually does.


EDIT: uh, *self-facepalm*.
You know what you can do? You can fully split the attached data from compiled exe, as the Wadjet Eye did for ported games.

[Radiant]

Interesting, what do you mean by that?

[Crimson Wizard]

Compiled.exe = engine.exe + attached data.
The data is surrounded by special symbols, which are easy to find (like, in hex editor).
You can cut the attachment (e.g. by some tool) into separate file. The engine is capable of finding data in a separate file too.

I explained this several times in the past year, here're some of the related posts:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=46152.msg636445497#msg636445497
http://www.adventuregamestudio.co.uk/forums/index.php?topic=44768.msg636469632#msg636469632

[Radiant]

So that's basically what the ac2game.ags file was in earlier versions of the engine, yes?

Anyway I can do that, but if selecting 'split resource files' does it automatically, then I'd prefer that. As I recall, it keeps the sprite file (and sound files) in the main executable, then if the executable is over the given split size (which, given the size of a sprite file, is pretty much guaranteed), it will put room files in separate files which are no bigger than this split size. I'm pretty sure that should still work.

[Crimson Wizard]

So that's basically what the ac2game.ags file was in earlier versions of the engine, yes?

Maybe, I did not work with pre-3 AGS much.
The engine looks for data in following files: "*.exe" (added to run windows exes on other platforms even without renaming), "ac2game.dat" and "*.ags".

Anyway I can do that, but if selecting 'split resource files' does it automatically, then I'd prefer that. As I recall, it keeps the sprite file (and sound files) in the main executable, then if the executable is over the given split size (which, given the size of a sprite file, is pretty much guaranteed), it will put room files in separate files which are no bigger than this split size. I'm pretty sure that should still work.

Well, it does not do precisely that, since some data may stay in exe, but it's up to you. Also, leaving some data attached to executable will guarantee that by running exe you will run exactly your game, and not some random data file found in the folder.