Using a File Descriptor with the SDK

Blitz3D SDK 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 ...