Quote:Original post by iMalc That's guessing and speculation.
I am pretty sure that I stated that somewhere.
Quote: If you open the file with the GENERIC_READ, FILE_SHARE_READ passed to CreateFile then other programs can also open the file. Otherwise the other programs will simply fail to be able to open the file.
I see that using that in Windows can work. Do you have any information on if this is also possible on *Nix systems?
Quote: I suspect that the 3rd party library you are using causes the lurch because it tries to preload a decent chunk of the start of the file when you tell it to start playing.
Yes, I am basically using the ogg vorbis libraries to stream ogg files. The ov_open() function seems to be what is causing the problem.
I don't see why any other thread would be accessing these files (especially since they are encrypted and can only be read by my program using overloaded callback functions.) So should I go ahead and just keep them all open? I expect this will completely eliminate the mid-game lurching because that is almost definitely caused by the ov_open() calls. And if I open all the ogg files just once at the beginning, that problem is eliminated.
Greg Philbrick, Game Developercoming soon . . . Overhauled CellZenith
You may ignore my post, but I'm not kidding that blocking file I/O is the reason for the lurch in your game, and is exacerbated by the fact that you have 20 files open at once. Disk access is slow. Most hard disks have an average seek time of ~8ms. If your files are fragmented and they are many, then this compounds the time that you will spend reading data from the disk, the time that it takes to return from an fopen or fread call. This is enough to cause noticeable hiccups in your game if you're loading files during play.
Asynchronous I/O can fix this by read or writing from disk on an OS thread, which means that loading that many files will be much less expensive (since the loading can happen while you are updating the game's frames).
@Aressera: I agree with what you're saying. However, I already know that once my file is open, doing anything on it is extremely fast (ie, if I'm looping one streaming sound there is no lurch at all when I loop back to the start of the song, even though this does call fseek() and fread() .) The slowdown only seems to come from having to actually open a new stream, which is way I supposed I should just open all the streams once at the start of the game.
Greg Philbrick, Game Developercoming soon . . . Overhauled CellZenith
Well I have implemented having all the song files being kept open continuously. Thus far it seems to work very well; the lurch from switching between songs is drastically reduced, and often completely absent.
But still, are there any hazards I should keep an eye out for?
Greg Philbrick, Game Developercoming soon . . . Overhauled CellZenith
