multithreaded texture loading (C/C++)
Blitz3D Forums/Blitz3D Programming/multithreaded texture loading (C/C++)
| ||
| hello, i found a way to load an image into a texturebuffer, from inside a dll. so now you could load your texture-images into a blitz3D scene using a separate thread... the idea is to do a bit of pointer magic to cast a (BB) ImageBuffer to a (C/C++) DirectDrawSurface & fill it up with RGB data from inside your dll code.. problem (if any DirectX developer got an idea..): still not supporting mipmapping. mail me pieter(at)lab-au.com for source-code -- don't mail me to distribute binaries. |
| ||
| I've been playing around with multithreaded loading as well. So far I've only fiddled with meshes but i'm about to start experimenting with images as well. One thing that is important to me is that I don't want to load the data into a memorybuffer at once, but instead stream it piece by piece directly from file. To allow for smooth streaming I written a little app in Blitz that loads any mesh of choice and then writes the rawdata into a new file in the following order: Total number of surfaces Texturename for first surface(if used) Number of vertices in first surface VertexList of first surface(pos, uv's, normals & colors) Number of triangles in first surface TriangleList of first surface ... and repeat for the rest of the surfaces. When I load a mesh using this raw datafile I actually managed to load it faster than Blitz's LoadMesh command. For example, I loaded the castlemodel(from the samples) 100 times using LoadMesh and using My rawmesh loader. With LoadMesh it took 11717 milliseconds With RawMeshloader it took 2877 milliseconds. As an extra bonus I can manipulate the vertices at loadtime, such as setting vertexcolors & scale the mesh. I also tried a renderworld after each added triangle, and it's so cool to see the mesh gradually build up, though it slows down the loading ALOT, wonder why? ;) hehe Anyway, so far it's not really multithreading but more like streamed loading. Tonight, I will try the same approach on images. What worries me are the sounds. Meshes and textures can be created in Blitz but afaik sounds must be loaded. |
| ||
| sounds cool, very interesting. must be great to see the geometry being streamed into the scene till now, i didn't try to find the data structure BB is using for representing 3D geometry (and to use it in C/C++ for true multithreaded loading). guess it must be quite a lot more complicated than imagebuffer... |
| ||
| LAB[au], Do you load the imagedata directly into the texturebuffer or do you first create a separate imagebuffer(in blitz),load the imagedata into it and then copy the image to the texturebuffer with copyrect? |
| ||
| You can stream music in using playmusic, however I don't imagine sound samples taking up much space anyway. |
| ||
| I've often thought about his kind of thing - loading a file bit by bit. I'm using multitasking routines to build up and destroy my scenery bit by bit so as not to interrupt the frame rate - that's with custom meshes built inside the program, but I've been thinking about loading stuff too. Would allow for great big levels... |
| ||
| I thought about using a DLL, but I'm gonna try using only Blitz3D first. To keep the framerate up I'm gonna use a timeoutvalue in the meshloaderroutine. For example, if I set the timeoutvalue to 10 milliseconds the meshloader will load the data for a maximum of 10 milliseconds and then bail out, letting Blitz move on with the loop. The next time the meshloaderfunction is called it will continue where it was. A low timeoutvalue should be equal to high framerate and slow loading while a high timeoutvalue should be equal to low framerate and fast loading. |
| ||
| ...answering question from Sweenie (Posted 2004-03-03 04:16:03) i load the imagedata immediately into the buffer, not needing CopyRect etc. or any other blitzcommand. (btw. using CopyRect you still need to write immediately to a buffer -- as it is not possible to copy a bank into a buffer..) i needed this for loading massive amount of imagedata (> 1300 512x512 textures) into a scene -- where i load (& unloaded) the images from the harddisk just when i need them. |
| ||
| problem (if any DirectX developer got an idea..): still not supporting mipmapping. I thought that the mipmapping wouldn't work because of your "behindthescene" altering of the texture buffer. But maybe if you first create an ordinary blitz imagebuffer, fill it with data using your DLL and then copyrect this image to the texturebuffer it would work. Or have you simply forgotten to set the mipmap flag when using CreateTexture()? |
| ||
| i really want to generate the mipmap in a background thread -- so it doesn't disturb smooth animation/interaction (generating mipmaps is quite fast, but user-noticable & results in shocking motion) (btw: your tip works: mipmaps are generated, thnx !) |
   |