I've read the book, and I have it sitting on my shelf - but I've not really toyed with the code that much. So I'll answer what I can...

Quote:Original post by darkm00n
1. I'm looking at a lot of the Render and SetAnimation functions and they seem to all want a time variable, which is the same in both cases. Why is this? The book explains it by saying that with a start time variable (set in SetAnimation) and later when the animation is rendered (with timegettime() again as the time variable) - this will help because the animation will know how much time is passed and be able to render from the starting time to the end time.
Is this the only reason this is used?

This is common in most rendering systems. If you're drawing a mesh, you need to know how much time has elapsed since the last frame, so you can animate it properly. If you just adjust it by a constant amount each frame, then the animation will be at a different speed if you get a different frame rate - e.g. on different machines.

Quote:Original post by darkm00n
2. Also, in his code he uses a Barrier class, for temporary barries (like a door) that you can animate. Unfortunately there is no collision detection between the door opening and closing animations. Would this be hard to program?

Hmm, I'm not sure about that. The barrier is solid when it's closed, correct? Then just remove the barrier once the door has finished opening, and add it when the door is starting to close. That way you don't ned to deal with getting jammed between the door and something, and it shouldn't cause visual problems.

Quote:Original post by darkm00n
3. Also, If anyone has read his Nodetree class and code, can they explain to me why he uses a QUADTREE and OCTTREE. The explaination says that the QUADTREE is for game levels where the Y value of the camera doens't change much, and OCTTREE is for levels which are more 3D and allow you to look around - I semi-understand the concept, but then he says QUADTREE is used for 2D levels. So would a QUADTREE just be some 2D area of space in the current view, and it just breaks the current viewable area down into nodes?

If you have a largeish terrain, that's pretty flat, then you might as well consider it 2D. So, a quad-tree is used, where you sub-divide the terrain into 4 squares. Then you sub-divide each of those 4 squares into 4 smaller ones, and you continue like that. Then you can see which squares (nodes) are visible from the camera, and only render those.
If your terrain is more complex, then it makes sense to use the Y coordinate as well. So you have a 3D area. You can't really divide a 3D area into 4, you divide it into 8 cubes - hence the Oct-tree.
Google probably has some more information about quad-trees and oct-trees if you're interested. Or just let me know if my explanation is rubbish [smile]

Quote:Original post by darkm00n
4. In some oo Jim's examples, (such as the Nodetree and Mapping ones) when you view the joins between textures from a distance away, they look jagged - like when the floor joins a wall. They're fine up close, but as you walk away there's a jagged shimmering effect. He says that he's using the slowest method of texture filtering in the program.. does nayone know how I can stop this effect from happening? I've used anistropic filtering and anti-aliasing when playing games before - would I need to use something like this to remove this effect?

I'm not sure about this at all. You could try enabling anistropic filtering and see if it helps. To enable anistropic filtering, call this (where pDevice is the pointer to your D3D device): pDevice->SetSamplerState(0,D3DSAMP_MAGFILTER,D3DTEXF_ANISOTROPIC);
pDevice->SetSamplerState(0,D3DSAMP_MINFILTER,D3DTEXF_ANISOTROPIC);
And you might also need this (I'm not sure though):
pDevice->SetSamplerState(0,D3DSAMP_MIPFILTER,D3DTEXF_ANISOTROPIC);
That code is for DirectX 9, but I think it's exactly the same for DX8 (It's SZ8 in the book, isn't it?). If it's not the have a look at the docs for IDirect3DDevice8::SetSamplerState().