Using a File Descriptor with the SDK
Archives Forums/Blitz3D SDK Programming/Using a File Descriptor with the SDK
| ||
Hi, I've been thinking about this for a while:
#include <stdio.h>
FILE *hFile = fopen("file.3ds","rb");
BBModel mesh = bbLoadMesh(hFile);
I know the function bbLoadMesh() only accepts a string parameter and reads in the file from there and setups everything else, but is there a way to pass the handle/pointer directly for processing without having the function to load file from disk? |
| ||
| Yea, it would be very usefull to have bbLoadMeshFromMemory(Mem) function in addition to usual bbLoadMesh(). If we will be able to load resources from memory it will be easy to use/write resourse managers, packers etc |
| ||
| I've got so many reasons why this accessibility should be implemented: Alter a file in memory without adding another I/O processing to the hard drive, Be able to use memory mapped files! (which means very low latency and very fast I/O access), decrypt a loaded file in memory without creating a temp file, alter b3d file properties in realtime without making any changes to the original file, and etc. This applies to any bbLoad* Function whether bbLoadMesh, bbLoadImage, bbLoadSound, and since its written in c++, it can be overloaded easily. I just don't want the SDK restricting me using string parameters for specifying a file. |
| ||
| If we will be able to load resources from memory it will be easy to use/write resourse managers, packers etc I found a way you can do that...well its a bit of a cheat, implementing faked memory mapped files. You need a ramdisk driver to do this. I wrote a b3d benchmarking app that calls a commandline to create a 256mb ramdisk and copy a variety of resources, (mainly textures and meshes) beforehand on a z: drive that I specified. Since its handled by the OS, rather than addressing blocks of memory, you can access just by file based approach which makes it compatible with bbLoad*(String filename) functions with the benefit of the speed of ram. :) Then I stream load the resources in my main renderloop checking if there was any drop in frames as images and mesh file loads. So far I did not see any heavy stutters. When compared to a hard drive, it lags a bit when loading large files. |
| ||
| I also /sign this suggestion. bbLoadMemAnimMesh(pointer, size, [parent]) This would be VERY nice. I was thinking about implementing my own ".pac" format as used in many games to add a little layer of protection for my resources. I found a way you can do that...well its a bit of a cheat, implementing faked memory mapped files. You need a ramdisk driver [...] Well, the thing is that it would be very unorthodox for an off-the-shelf customer game/app to install a ramdrive device. ;) I got a good tip though that I've been using myself in the past: If your language supports threads and you code you application to support queueing of load operations, you can have another thread "pre-read" the file once and then signal your main-thread to access it. This will in many cases speed up the read-time significantly as the file will be cached in ram by the OS on the second read. This is only a partial workaround for the loading speed aspect though. The models still need to be there (unprotected) in the filesystem ... |
   |