Your code looks OK to me (I only read the hiding parts though), but I am unable to test it since I don't have DGDK1 on this computer.
Anyway, what you could do is use squared distances for comparisons instead; in that way you will save yourself some unneccesary execution time on the square root operations. You could also look into frustum culling and combine that with distance culling; that should be able to reduce the number of rendered objects to between 1/2 and 1/4:th on average, maybe more depending on your field of view and vantage points. You could also (obviously) reduce the clipping distance. One clever thing is to set it to a factor of the objects' average size so that grass won't be rendered unless it's, say, closer than 50 meters away while trees will still be seen at 400 meters distance. For more complex objects like the trees you could also use several LOD meshes that you switch between based on the distance.
I manage to get decent speeds in my game engine using the above approach. I also use a separate culling thread that checks distances between the camera and all scene objects over time; as such it is possible that not all objects are culled in sync with each screen refresh and we thus get rid of the slowdown that may occur because of checking / updating all objects (of course you have to use some kind of locking mechanism to ensure that the culling thread is paused while the actual rendering takes place).
Hope that helps
Quote: "I am not sure if it actually works but i scaled down the sky to hide some of the hills in the distance."
That will not help (unless you set the camera range accordingly). DGDK does not support native occlusion culling.
"Why do programmers get Halloween and Christmas mixed up?"
Because Oct(31) = Dec(25)