Advertisement

Optimization suggestions?

Started by February 01, 2003 05:00 PM
9 comments, last by DalTXColtsFan 22 years ago
http://home.att.net/~tennisman5/ABigDisplayListCity.zip This is a demo I''m working on. It''s about a 2 Meg file because it includes all of the bmp files I''m using and requires Visual C++6.0/MFC. It started out as 24 small buildings. Now it''s 196 pretty big buildings with a still-ugly skybox (I''ll experiment with skyboxing later.). The texture files range from 50K to 400K. Anyway, rendering the buildings and rotating was slowing me down to about 10 FPS. I tried compiling the city and skybox as a display list and that seemed to make no difference. So I would like to ask, what are some general guidelines to keep in mind as far as optimization? I know I''ve seen professional computer games with tons more detail than my 196 rectangular prisms that run a lot faster than that. Any suggestions? Thanks! Joe
Try looking into frustum culling
MSN: stupidbackup@hotmail.com (not actual e-mail)ICQ: 26469254(my site)
Advertisement
how come one of the robots is patrolling through the buildings?

Maybe you should also look into using models, instead of manually positioning and rotating each polygon

What do you plan to make with this btw?


[edited by - nexius on February 1, 2003 8:16:39 PM]
MSN: stupidbackup@hotmail.com (not actual e-mail)ICQ: 26469254(my site)
Holy cow! That source file is huge! I''d say it''s about time to start doing a little file I/O to make it easier to work with the data here. Also, split some stuff up into separate source files (functions that don''t directly affect global data or the result of the main program itself should be put in other files). As for your problem, it''s likely you just need some good frustrum culling. Oh, and checkout vertex arrays, I believe they are the prefered format on most cards.

______________________________

And the Phoenix shall rise from the ashes...

--Thunder_Hawk -- ¦þ
______________________________
______________________________________________________________________________________The Phoenix shall arise from the ashes... ThunderHawk -- ¦þ"So. Any n00bs need some pointers? I have a std::vector<n00b*> right here..." - ZahlmanMySite | Forum FAQ | File Formats______________________________________________________________________________________
quote:
Original post by neXius
how come one of the robots is patrolling through the buildings?

Maybe you should also look into using models, instead of manually positioning and rotating each polygon

What do you plan to make with this btw?


[edited by - nexius on February 1, 2003 8:16:39 PM]


I originally had much smaller buildings and the robots were walking up and down the streets - I just forgot to adjust the robots'' coordinates.

I will definitely look into modeling - OpenGL Game Programming is the book I''m reading and it seems to talk about MD2s. Do you know of any other "preferred" model formats, like maybe 3ds?

This particular project is just to help me learn OpenGL - nothing more. I''m kind of adding in things piece by piece.

Thanks for the feedback.
quote:
Original post by Thunder_Hawk
Holy cow! That source file is huge! I''d say it''s about time to start doing a little file I/O to make it easier to work with the data here. Also, split some stuff up into separate source files (functions that don''t directly affect global data or the result of the main program itself should be put in other files). As for your problem, it''s likely you just need some good frustrum culling. Oh, and checkout vertex arrays, I believe they are the prefered format on most cards.

______________________________

And the Phoenix shall rise from the ashes...

--Thunder_Hawk -- ¦þ
______________________________



Thanks for the feedback - I''ll read up on frustum culling. I''ve read about vertex arrays but haven''t tried them yet.

Yeah, I agree that source file is getting pretty big . I was thinking about making a robot class for one, that could help.
Advertisement
Greetings again all, and thanks again to those with suggestions.

I read up on frustum culling and get the idea.

I did some other playing around with my demo and found that one of the problems was that the buildings are just too darned tall. I added a line to the beginning of the DrawTexturePrism routine so divide the y size by 4 and the frame rate shot up well over 30.

That made me wonder if frustum culling really wouldn''t help me all that much unless I divided up the tall buildings into, say, "subbuildings". That way if I was like on the ground walking down one of the streets it could "only" render like the bottom half of the buildings, that could help. It would also allow me to not send the "insides" of buildings to the rendering pipeline at all, like for example if a building is between two buildings that are taller than it, don''t even send the inner sides.

Anyone else ever done anything like this that could offer some insight? Other than frustum culling, vertex arrays and hardware acceleration are there any other "general" things you can do to optimize, or does it pretty much come down to analyzing each individual game and figuring out what "optimizes" it the best?

I''d appreciate any input.
Sorry, I have no comments about optimization, just wanted to say that I can''t see the robots, though I could if I commented your glCallList(cityList); line. Also, the framerate was 155 for me and my card''s not the greatest- ati 8500. In fact, it was too fast for me because the zoom keys were so sensitive. But anyway, it is very nice! (I recognize your skybox bitmaps, hehe)
You should try looking into some sort of portal culling if you are going to, say walk down a street.
The One and Only
hmmm

If I were you I would build a single display list of a textured cube. The cube would be drawn from the bottom, not the center, so it would scale correctly.

Then I''d make an array of building objects (objects of type "building", where building is a structure). The building structure would hold the texture index, the position of the bottom of the building, and the width, height, and depth.

Every frame I would loop through all building objects, check if it is in the frustum (if not continue), then call glScalef() (with the width, height, and depth as parameters) and then call the cube display list.

You could also put the cube in a vertex array... that would be like cutting the vertices down from 24 to 8. (each quad shares 8 vertices with neighboring faces)

Try that and if it is STILL slow then look into BSP trees =)

Good luck!



"If you gaze long into an abyss, the abyss will gaze back into you."
- Friedrich Nietzsche (1844-1900)

(my site)
MSN: stupidbackup@hotmail.com (not actual e-mail)ICQ: 26469254(my site)

This topic is closed to new replies.

Advertisement