Speeding up an RTS game?

Started by
5 comments, last by 6 19 years, 10 months ago
Hi. I''m currently playing around at writing a simple RTS game as a learning experiance. I''ve got most of the components up and running using a standard height map, and some basic units that I can move around with the mouse. I''d like to make the game larger and more detailed and was wondering what the best way of speeding up my game would be. I''m currently using display lists for models and vertex arrays for the terrain, but was wondering if using an Octree, Quadtree or BSP would help performance, and if so which is the best one for an ''Age of Mythology'' type game?
----------------------------------------------------
Check out my casual TBS game blog
----------------------------------------------------
Advertisement
Of course quad-tree is the best for the terrain rendering engine, and you should use VBO''s(it may increase your performance for a 3 times)
Of course quad-tree is the best for the terrain rendering engine, and you should use VBO''s(it may increase your performance for a 3 times)
You should dynamically change your level of detail (LoD) of your terrain (i.e. with the ROAM - real-time optimally adapted mesh - algorithm).
For details about see the NeHe-Forum on gamedev.net - there has just been a post on terrains and a lot of links on this topics have been posted there.

Combine ROAM with a quadtree for frustrum culling. If your terrain has lots of mountains in it, check on backface culling and/or occlusion testing for further performance.

Draw your terrain as triangle strips in a vertex array or dynamical vertex buffer object (dynamical to be compatible with the ROAM algorithm).


x = rx ( 1 - x ) ; r > 3.5699
... and chaos may begin ...
x = rx ( 1 - x ) ; r > 3.5699... and chaos may begin ...
Thanks for that guys. I''ve had a quick look at VBO''s and they seem pretty straight forward enough. I''ve also had a look at some demos using ROAM, but when you moved over the landscape, it looked weird as the detail improvement made the contours change in front of your eyes. Perhaps it was just the demos I was looking at that were simple. Does anyone know of any game that use ROAM?
----------------------------------------------------
Check out my casual TBS game blog
----------------------------------------------------
quote:Original post by 6
Thanks for that guys. I''ve had a quick look at VBO''s and they seem pretty straight forward enough. I''ve also had a look at some demos using ROAM, but when you moved over the landscape, it looked weird as the detail improvement made the contours change in front of your eyes. Perhaps it was just the demos I was looking at that were simple. Does anyone know of any game that use ROAM?


Triangle binary tree, ah la ROAM, can be more appropriate for terrain with a continuous level of detail than quadtrees. They also have an implicit LOD representation. You can also frustum cull, etc using exclusively the tribin tree. I am not sure why the other posters recommended using a quadtree.

Halo uses a more modern version of ROAM. The old ROAM is quite outdated. Graphics card can take alot more punishment today and so performing such CPU intensive calculation ( priority queue with seperate split/merge lists ) may not be the best idea anymore. There is a great ROAM article on Gamasutra here.

Extremely noticable popping probably means the coders of the demo''s you checked out, sucked. Again, halo being the perfect example since there are so many gorgeous outdoor scenes in that game. If you didn''t know they used a CLOD algorithm you would never notice the little popping effects.

Farcry has a decent CLOD but it breaks down horribly in a number of places such as when you use the zoom on a weapon. Its all a matter of give and takes.

Anyhow, here are a couple of shots from my first terrain engine.

Screenshot of a scene WITHOUT LOD

Screenshot of same scene WITH LOD

Superimpose them and you can see the differences. However LOD makes scenes like that possible while still maintaining a good frame rate.
Just checking; you do exclude things that aren't in the scene from drawing, right? =)


And it's always good to keep the rendering separate from the gameupdates... in my game I got three threads so far; GameLogic,Update() and Draw()


[edited by - Rasmadrak on June 3, 2004 9:52:54 PM]
"Game Maker For Life, probably never professional thou." =)

This topic is closed to new replies.

Advertisement