I'm using irrklang for playing sound files. I just got a simple solution to override file access, so now irrlicht is the provider for files. I assumed it will work from archives as well. https://www.ambiera.com/irrklang/tutori ... ccess.html
Here in this short tutorial is the fopen solution. I know that for irrklang there is a separate forum, I'm just asking whether from irrlicht point of view, adding archive file to irrlicht should allow my project to open files with fopen() from the archive?
Last edited by ibax on Sat Mar 30, 2019 12:03 pm, edited 1 time in total.
If you talk about the c file function fopen - that one can't use our archives. I don't know much about irrklang really, but maybe it allows to play from memory-blocks. And archives allow you to have memory-read-files.
IFileArchive* archivePointer = 0;
IFileSystem* fs = device->getFileSystem();
for ( i = 0 ; i < fs->getFileArchiveCount() ; i++)
{
IFileArchive* tempArchive = fs->getFileArchive(i);
const irr::io::IFileList* tempFilelist = tempArchive->getFileList();
for ( j=0 ; j < tempFilelist->getFileCount() ; j++ )
{
path s2 = tempFilelist->getFileName(j);
if ( strstr ( (char*)s2.c_str() , "intro.wav" ) )
{
archiveIndex = i;
fileIndex = j;
fileSize = tempFilelist->getFileSize(j);
fileOffset = tempFilelist->getFileOffset(j);
archivePointer = tempArchive;
}
}
}
txtLog.writeLogDigit( "menu1_WelcomeScreen(): Archive index is: " , archiveIndex ); // I have the archive index
txtLog.writeLogDigit( "menu1_WelcomeScreen(): File index is: " , fileIndex ); // I have the file index in the archive
txtLog.writeLogDigit( "menu1_WelcomeScreen(): File size is: " , fileSize ); // I have the filesize
txtLog.writeLogDigit( "menu1_WelcomeScreen(): File offset is: " , fileOffset ); // I have the offset for the archive
sound_engine->addSoundSourceFromMemory( archivePointer+fileOffset , fileSize , "intro" , true );
sound_engine->play2D( "intro" , false );
So if I would like to search the correct postion of my file, then its pointer is the IFileArchive pointer plus the offset... Am I correct? That is have to find the pointer pointing exactly to my file...
Ah, crap, I didn't realize you can't directly access to the block of memory allocated by MemoryReadFiles. And also you don't know from the interface if MemoryReadFiles are used (thought they are in the case of zip-files).
Also not quite sure what the FileOffset is right now. But I don't think it has any connection to the archivePointer.
Basically to access files you remember your index when you found a file (index is 'j' in your case). Then you get an IReadFile * with archivePointer->createAndOpenFile (j);
Or you can open a file directly with archivePointer->createAndOpenFile("somefilename.wav");
The problem is the usual way now to access the memory is with IReadFile::read() function which copies it. Which I suppose you want to avoid here. As the memory is already in a memory-block, just Irrlicht not giving you any legal access to it.
There is an illegal way probably which you shouldn't use as it's bad taste and will break once Irrlicht messes with the interface etc, but... might work right now.
If you look at CMemoryReadFile then you might notice the first variable currently is: "const void *Buffer". So you might for example include a file like source/Irrlicht/CMemoryReadFile.h directly and cast to IReadFile* to CMemoryReadFile* and then you could access that variable. Ugh. Oh well - while we are at doing ugly stuff...you can also avoid the include. And cast with *filePtr to some memory-pointer like void* (Note: _not_ filePtr directly, you need *filePtr to get the content of the first variable which will turn out to be the pointer containing the memory).
So,can it be made nicer... yeah. If you use Irrlicht trunk (instead of an official release) we can think about adding something. Like a getType() function similar to ISceneNode. Then you could check the type at least. And maybe an additional interface for IMemoryReadFile in between IReadFile and CMemoryReadFile which gives direct access to that pointer. Are you using Irrlicht trunk and want me to change it? Will maybe take a few days (I'm off travelling to some family wedding next few days), but I guess I could add that.
Thanks for your answer, I really appreciate that. Of course I'm interested in any solution which helps me (and this forum), so definitely I will wait for your proposed solution, implemented into the svn trunk.
I just would like to ask you to put some comments as well, or have a short description, how to use it, what to do, etc
(Btw... does this mean that nobody is using compressed files to store sound files, effects? Or how others play sound files from archives??)
Sound files tend to be compressed already pretty good (.ogg or .mp3), so not sure if .zip compression adds there anything. Obviously different for effect-files like .wav, I guess those can be compressed.
The reason is not to have 1000+ sound files, but rather have one password protected zip file.
This also denies copy of copyrighted sound files.
These are the two main reasons, why I need to use password protected archive files.
As seen in other thread, it's likely already possible somehow to do this. Not even sure the solution I'm working on will make it nicer. But can't really tell anything about irrKlang as I haven't worked with that so far. But likely you have to write some interface class between irrKlang and the irrlicht file-system.
Anyway in svn trunk IReadFile has now a getType() function. Which you can use to check if you got an irr::io::ERFT_MEMORY_READ_FILE. If so you can cast your IReadFile* to IMemoryReadFile*. And that has a getBuffer() function which allows you direct access to the memory block.
I never tried to work from a trunk version, so let me summarize what I did...
Checkout from svn rev5800, rebuild the whole solution. With this way, I will get irrlicht.dll and the library files (irrlicht.exp, irrlicht.lib). These two library files were put to my solution (replacing the existing ones), I rebuilt my solution, and put the previously get irrlicht.dll near to exe. The solution is compiled without error, but my app is not working.
I just would like to ask, whether the above steps are OK to work with a trunk version? (getting dll and library files)
I was able to play a soundfile from a password protected zip file, with the above described trunk version from svn. Many thanks CuteAlien for the irrlicht software modification and for the description as well.
Will do some more testing in the next days...
There is still one question is in my mind. I have to use this trunk version from now, am I right? Can it have any unexpected consequences?
If you run into problems, just post about them. You don't have to update trunk all the time (for example if your version right now works -stay with it).
There's still a few problems in trunk, but less than in the Irrlicht 1.8 release.