Ok, I know that heightmaps probably aren''t the best way to do levels in a 3rd person walk around game, but I decided to due to several factors. Anyways, I know that in the NeHe tutorials, the heightmap generated is VERY unefficient, it uses 4096 vertices, which is not THAT much, but think, if you were to size it up a little... at 2048, it already uses 16,384 vertices, that is a lot. My computer chokes at 4096, at a step size of... 256! My computer is a compaq though, it has a 700Mhz PIII, as well as 128MB RAM, I am going to upgrade the ram soon, I was hoping that would help. Anyways, is there any way to make the system better so that it isn''t so intensive on the ''puter? Another thing, I have a box drawn around the map to act as a primitive sky, but, I noticed after testing that the skybox was drainging a lot of power too, but it only has about 30 or less vertices, it is textured, but I wouldn''t think that it would gobble up THAT much power. I hope there is a way out of this problem, I really need it. En taro Adun! Doom to all who threaten the homeworld! *Protoss Zealot - Starcraft*

Hmm, well, I noticed something, the sky box IS what is drainging all of that power, I don''t know why. I think thnk that it is caused by the textures not scaled to the walls of the box. So, let me ask, if a texture of 64 X 64 pixels was stuck on a quad 500 X 3168, would it make a game run slower than a week peice o'' crap? I am going to test this soon, maybe it is my problem, or is it because the quad doesn''t have dimesnions that are powers of two? I dunno, I''ll try and find out.

En taro Adun!
Doom to all who threaten the homeworld!
*Protoss Zealot - Starcraft*

Hiya, I don''t like trying to help people out... ''cause I''m usually wrong

Here goes anyway....

Hmm, skybox thingy... makes the full screen have to be rendered, perhaps fillrate is the limit?

Ya got a slow card or running in high resolution, or both! ???

Probably completly wrong, but worth a shot

While this won''t help you much: The NeHe heightmap tutorial is designed for readability, not efficiency. If you were to write a production quality engine, you would not use heightmap code that looked like that. The last heightmap code I wrote packed the vertices into a couple arrays to be used in a vertex array style. You also have to take into account occlusion. You can''t render the entire heightmap every frame and still have a decent speed.

[Resist Windows XP''s Invasive Production Activation Technology!]

Zealot - look into some sort of spatial partitioning or frustrum culling for rendering your heightmap (quadtrees/ROAM etc)

Also your Skybox is really big! A trick with skyboxes is to make them quite small, but to disable update of the depth buffer when you you render it.

eg (pseudocode)
Set depth mask to false
draw skybox
set depth mask to normal

This will put the skybox in the background, but will allow any foreground stuff to draw over it. As the box is smaller the resolution of your textures will also be better.

Keef

-----------------------
glDisable(WORK);
glEnable(GL_CODING);

Keef is right. Plus, here''s another trick. Average out the span of the viewable region of the skybox based on its most probable distance from the viewer. Then, divide the whole of each side of the skybox into pieces roughly equivalent in size to this span. This way, looking up at the sky will in most cases render a polygon whose vertices don''t stretch too far past the window. This can be, I suppose, analogous to frustrum culling in which edges off the screen are not rendered. In turn, the respective texture associated with the polygon at hand will cover less area, which means less drawing for the renderer. Just a suggestion.