Well they're here!
Some pics of a 3D example I am working on
It seems that PB is able to handle 3d quite well. This program was compiled with Ver.1.63w.
Still having some issues with doing the steps as seen in the pics but will work them out eventually.
Used TextureQuad to texmap 128x128 'FX' images
~Excuse the mediocre gfx
15 FPS...
I wonder... Do you think LockBuffer might be of use to increase this?
I havn't tried that yet, but yes.
I have to look into how it works
That's a pretty impressive result really, there's probably some time that can shaved off internally, but it's certainly a first. So congratulations on that one !
There's seems to be some depth cue lighting also ? This is interesting as there's not really a way of doing that in 1.63 without multi passing, or pre computing the textures.
Mip Mapping could probably help you here also. Mip Maps are pre-computed (scaled down) versions of the texture (They have to be filtered though). So when we render a surface, we pick texture based upon it's distance from the camera. Close up surfaces use the larger version, mid range use the 50% version, and far textures use the 25% version etc. You can have as many levels as you like.
While this will help remove some of the noise (due to texel drops) it's also faster to render from smaller textures. Why ? - because the texture fits in the cache better.
Create Mip Maps (http://www.underwaredesign.com/forums/index.php?topic=2996.0)
Wow. I never heard of Mip Mapping. Is all this precalculated?
The depth cue lighting was actually done in another program I wrote. I just roughly used the Zdepth value to determine a mathmatical value to call up pre-faded images loaded into memory. I didn't turn out exactly as I hoped. I copied each image darker than the next. The only thing is it takes up alot of memory so you have to keep the images small. I found 128x128 was a good size. I had 256x256 but the program choked a bit and I found little difference really.
I hope to get a short demo out soon.
QuoteWow. I never heard of Mip Mapping. Is all this precalculated?
Yep, even in hardware. You could compute the 'levels' of a texture as it enters the scene and then hold them in a cache. So when the texture is within range of the camera, it's considered local and cached. When it moves outside it gets flushed out of the cache.
QuoteI found 128x128 was a good size. I had 256x256 but the program choked a bit and I found little difference really.
Yeah, well since you have losts of different textures (shaded), then each time you draw from a different texture. The CPU is actually spooling the texture data into it's local cache memory (there are various levels of cache btw). Depending upon the cpu, the size of the cache differs. So the cost of fetching pixels from the texture differs. In particular if the texture memory is larger than the cpu's local cache, then the pixel fetching requires extra memory copies. All of which is performed by the CPU. What you might not know, is that the same problem exists in GPU world as well. Anyway, the point is the smaller you keep your textures, the less overhead the cpu will have when caching it and less overhead there will be fetching the texels from it.
In terms of size, there's no point in using a texture resolution that's higher than 'on screen' area of the surfaces being filled. It's just wasted memory, slows the program down.
Is it your own engine or a 3rd party dll?
Oh its a third party dll.
Without the 'Vertex Objects' lib this program would not be possible.
I tried making my own 3d engine but I was only able to simulate a Y axis and Z axis
rotation and it moved much slower.
So I must give much credit to the 'VertexObjects' lib. Has basic but valuable commands .
erm.. 3rd party DLL ?