Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Derrek3D]

Since I'm having some slowdowns in my game, I ran Process Monitor to see how my game accesses the file system and now that I've checked, I'm not sure how to interpret the results. I'm not sure why, but Process Monitor reports excessive disk access when my scene is running. Sprite images are being loaded over and over again and so are sounds (although I've taken care to use LoadSound() and then PlaySound() with no parameters on all occasions). Particle images are being read non-stop over and over.

Has anyone encounter this issue before? Is the Process Monitor report wrong in some way? Am I doing something wrong in my game that causes this?

My goal is to load everything the scene needs at scene startup and then stop accessing the file system completely for the remainder of the scene.

[Mnemonic]

The sounds will always access disk, because they're being streamed, and even if the sound finishes, it's not stored in memory.
Images, however, stay loaded until they're released (unless the sprite is marked as "streamed"). There is some juggling going on, but only for 2D actors, to reduce memory load.

[Derrek3D]

Hmmm... A few more questions then, if you don't mind...

1. I use particle emitters and call AddSprite() to add png files as the particle images and Process Monitor reports that they are being read over and over. Does it make any sense?

2. If all sounds are streamed from the hard drive, what is the LoadSound() method for? I thought its all purpose was to preload a sound file so that the loading from disk won't occur during the scene.

3. A more general question, isn't there any way to preload everything to memory at scene startup? Loading during the scene itself is causing my scene to stutter. How can I avoid this?

[Mnemonic]

1. I use particle emitters and call AddSprite() to add png files as the particle images and Process Monitor reports that they are being read over and over. Does it make any sense?

Well it shouldn't, unless the particle emitter is destroyed in the meantime.

2. If all sounds are streamed from the hard drive, what is the LoadSound() method for? I thought its all purpose was to preload a sound file so that the loading from disk won't occur during the scene.

Before the sound can be played, it needs to be initialized (this means mainly initializing the Vorbis decoder and allocating the sound buffer). LoadSound() does this initialization without actually playing the sound.

3. A more general question, isn't there any way to preload everything to memory at scene startup? Loading during the scene itself is causing my scene to stutter. How can I avoid this?

You can preload the graphics and you can pre-initialize the sound. That's about it.

[Derrek3D]

Well it shouldn't, unless the particle emitter is destroyed in the meantime.

I checked and rechecked and as far as I can tell, the emitter is not destroyed during the scene's lifetime. I also went digging even deeper and I found two strange findings using Process Monitor:

a. If my emitter has one call to AddSprite() (i.e. the emitter should use one image for its particles), the number of times that the particle png file is read from the disk is closely related to the MaxParticles attribute of my emitter. If I set this attribute to 10, for example, I get few reads of that png and if I set it 100, I get a *lot* of reads. It's the same png for all particles so I thought reading it over and over for each particle or more could be a bug although I can't be sure.

b. If my emitter has two calls to AddSprite() (i.e. the emitter should use two random images for its particles), both png files keep being read non-stop. As if when the emitter loads one png, it loses the other and then needs to read it again. Unlike when calling AddSprite() only once, this behavior remains for as long as the scene is running.

Before the sound can be played, it needs to be initialized (this means mainly initializing the Vorbis decoder and allocating the sound buffer). LoadSound() does this initialization without actually playing the sound.

I understand, but isn't there any way to load the sound file to memory and play it from there? Is there a design reason for this? I mean, why stream 10K or even 100K files and cause a performance hit if they are small enough to be kept in memory? Can this be an official request?

You can preload the graphics and you can pre-initialize the sound. That's about it.

I asked in another thread but since it's related I'll say it here as well. What about speech lines? They are ogg files just like any other sound file but I can't preload them? Will my scene stutter each and every time my actor says anything?
And what about preloading other stuff? For example, if I call Game.SetCursor("Cursor1.sprite"), then I call Game.SetCursor("Cursor2.sprite") and then I call again Game.SetCursor("Cursor1.sprite"). Will Cursor1.sprite be read again from disk or is it kept loaded in memory from my first call to Game.SetCursor("Cursor1.sprite")?

[Mnemonic]

Regarding sprites, it's actually a bit more complicated. We have to differentiate between sprite files and image files. Image files are only loaded once, because they're static. Sprites are loaded for each particle, because each particle uses a different animation instance (the image files referenced by those animations are only loaded once).
However, since WME allows you to pass an image file directly to SetSprite(), for your convenience, so that you don't need to create one-frame sprites, the side effect is that the image file is checked everytime a new particle is created (in this case, the image works as a sprite itself). Confused already?

Usually there's little harm loading sprite files over and over, because they are small (especially when the game is compiled, they're loaded in compressed version). The real slowdown is loading the image files (especially huge ones), and those are cached (unless you reference them directly, as I described above, in that case they're indeed loaded and dropped immediately, this definitely could be improved).

However, unless you're using huge images for particles, IMO the Windows and disk cache optimize any possible slowdowns.



Regarding the sounds. They are streamed from disk if they are longer than the sound buffer (3 seconds by default, I think). Otherwise the entire sound is loaded into buffer and played. After being played, the sound is dropped, because currently the engine doesn't have a way of knowing whether the sound is going to be used again one second later or not. Again, for repeated short sounds the disk cache usually does the dirty work. I didn't study this any deeper, but the real performance hit seems to be the Vorbis initialization, because e.g. if you use WAV files for footstep sounds, the stuttering doesn't occur.

What about speech lines? They are ogg files just like any other sound file but I can't preload them? Will my scene stutter each and every time my actor says anything?

I'm afraid so.

And what about preloading other stuff? For example, if I call Game.SetCursor("Cursor1.sprite"), then I call Game.SetCursor("Cursor2.sprite") and then I call again Game.SetCursor("Cursor1.sprite"). Will Cursor1.sprite be read again from disk or is it kept loaded in memory from my first call to Game.SetCursor("Cursor1.sprite")?

I already answered this above. Only image files are cached. The actual sprite definitions are not, and IMO there's no reason for it.

[Derrek3D]

Thank you for the detailed explanations. I posted a request regarding these issues here: http://forum.dead-code.org/index.php?topic=2653.0