Bad Performance on Simple Map Created 17 years ago2006-09-19 22:51:41 UTC by RotatorSplint

I decided to make a gm_construct remake because 2_v2 sucked, and now, the map's almost finnished. However when I recently did a test compile, the view I had of the whole map had some crazy FPS readings and horribly choppy game play. I set net_graph to 3 and watched the FPC counter jump from 110 to 60 every millisecond or so, causing some terrible studders that really became apparent when I moved around.

Of course, I was a little too thick to realize that the 60-somthing displacements I had (all set to a power of 4) were causing this (Too much Blender3D for me ). But after condencing 30 of them into one with a power of 2 (it's just some flat land), and the other 30 of them into 4 with a power of 3 (the pool of water that's characteristic of all gm_construct-type maps), the FPS readings I had inscreased only marginally.

The choppiness is really apparent when I stand in a corner and look at the whole map; it becomes less so when I move to the middle and look around; and obviously less so when I look at the sky or straight down.

My computer has never had such issues as these - It handles the Water Hazard chapter in HL2 perfectly well, why not this simple map?

And so, my question is: What the hell is goin on with this map of mine, and why can't my computer handle it?

You need to optimize better. See "Controlling Visabillity and compile times" in the Valve WIKI. The engine is probably rendering the whole map at once.

Also 60 FPS is good. Anything below 40 isn't good. And 20 is REALLY bad. And of course anything above 40 is good.

Well I'm not sure if 60 was the minimum, it was changing so quickly that it wasn't settleing on any specific number.

I'll run some tests later to see if it's somthing other than the displacements, like the water or somthing. Thanks for the wiki idea too .

Have you placed any models in the map? Or expensive water? These two things are what cause the biggest performance hit. Displacements and brushes, contrary to popular belief, are easier to render.

Also 60 FPS is good. Anything below 40 isn't good. And 20 is REALLY bad. And of course anything above 40 is good.

TV screens have a maximum of 50 or 60 Hz. Having 100 or 150 is irrelevant. (My screen has a response time of 25 ms so it can only display up to 40 FPS. Crappy, I know )

Use +showbudget (think that's it), it should tell you were the most performance impact is coming from.

@Kasperg: What part of the texture name tells me I'm using expensive water? The water I'm currently using is called "dev/dev_water2"

I wouldn't worry about the frame-rate if it just stood the same. Jumping from the glass-smooth 120 FPS to the 'okay' 40 FPS is really noticable and hurys the eyes... well at least my eyes.

@Strider: I'll give +showbudget a try in a little while - I have band practice to get ready for and go to tonight, so I don't have a lot of time : .

I can also post the map in the problems vault if any of you all would like to take a stab at it and perhaps make a diagnosis.

Thanks for the suggestions thus far.

dont use dev water!
numpty.

60 fps is indeed fine, so i dont know what you're complaining about.

Perhaps scale the textures a bit higher?

I set net_graph to 3 and watched the FPC counter jump from 110 to 60 every millisecond or so

I think this is usually something external to the game.
In my case, running the map at the same time as Hammer4 or a p2p program will cause this kind of framerate jumps. While you are experiencing the framerate problems, you might as well load another map and see if it happens there too.

May be here you catch major Source bag - each prop_static entity takes one fps just for "here i am!" (and i think evey model entity, but dont check) . So, if you see 100 models on map in one time - you will have "-100fps" just becose Source have this bug plus time to render models. If you want ti make forest on Source - you need thery complex prop_static models.

+showbudget will helps.

+sv_cheats 1
and after hit <shift> + <F1> to enter dev mode were you can turn off/on rendering displacment, water, cubemaps, models, etc

There is no evidence that each mosel takes up -1 fps. No one can prove that considering the FPS is dynamically changing constantly, also considering that the engine doesn't render models sometimes, (if properly optimized.) so therefore a model would take up nothing. Models arent very expensive. When I made my dm_ravenholm map I basically put occluders everywhere and it incressed my FPS by like 10. I had ALOT of models. (And no I didn't go nuts placing occluders.)

I recently sent a tutorial on optimization to Seventh-Monkey I am just awaiting him to put it up. So maybe you can read that when it is up.

Will do, Exos.

I used +showbudget, and most of my issues come from dynamic lighting. This is a night map, BTW. If I look accross the map with no regular lights in view (there's a little vehicle park where I'll but buggys, that is where the only 2 point lights are in the map.) I have an FPS reading of 30 (this was using the FPS counter on +showbudget, not net_graph), if I view the map from that little vehicle park with the two pointlights in view, the fps frops so a scary 15. If I move to the middle of the map, i average an FPS of 40.

I usually have Hammer4 running in the background, as well as the SDK, Opera, and the occasional Steam Chat window. I'll have a test and see if closing those helps at all.

Also, I tested the original gm_construct, and my frames are A-OK on it.

TheGrimReafer and I have been doing some work on the map. He has a relatively nice computer and reports a perfectly fine framerate on his machine. It's definitely time for me to get a new one, but I just havent had such a problem before... maybe this is my computers limit?? Thast makes no sense... considering the performance I had on the Water Hazzard levels...

Thanks for the feedback, I'll run some more tests when I can

It's the point_lightspot entities that are eating up your resources. Make sure you set the flag on dynamic lighting to off for those entities.

That one thing alone can eat up tons of framerates. I don't understand why Valve doesn't set those settings to off by default. Dynamic point_lights are only useful if you attach those entities to scanners (i.e. moving NPC's).

Wow point spot lights (if not properly used) can make your FPS HORRIBLE! Just like Satchmo said. I had a map that was like 10% done before, The FPS was like 120, as soon as I added a point_spotlight it went down to like 30.

They're regular lights, not light_dynamics : .

It's clear that the FPS issues are from those lights, but even if those were fixed, I'd have the weird jumpiness when not viewing those lights, just less so.

I'll have a look, though, and see if I can do somthing to improve the lights. I'm almost to the point of scrapping the map A) because I have some more nifty ideas for other maps, and B) because this stupid thing just wont fix .