Page 1 of 1

What are the standard benchmarks to go by for FPS?

Posted: Fri Nov 07, 2003 8:43 pm
by Axion
What are the minimum numbers that I should shoot for that would still be considered playable? I'm thinking forty should be enough for everyone, or is that too little?


And while I'm here, another quick question- Do only structural brushes contribute to FPS, or do other things like static models factor into the equation?

Posted: Fri Nov 07, 2003 9:37 pm
by smartaiguy
40's is defientaly good...30's isn't bad

Basically what structual brushes do is break up your visibility so the game doesn't draw stuff on the other side of them. Detailed brushes are viewed as invisible when compiling vis. Those are good for steps and such as lots of small bits creates tons of portals increasing compile time but not really any effect on FPS. So they don't break up your visibility.

Cards

Posted: Fri Nov 07, 2003 11:56 pm
by tltrude
The FPS people see depends on the card they are using and the game settings they have. If you set all of yours to the highest and can keep the FPS from turning yellow or red, You are doing good.

Re: Cards

Posted: Sat Nov 08, 2003 12:24 am
by smartaiguy
tltrude wrote:The FPS people see depends on the card they are using and the game settings they have. If you set all of yours to the highest and can keep the FPS from turning yellow or red, You are doing good.
Yes, especially if your computer just makes the requirements.

Posted: Sat Nov 08, 2003 10:15 am
by jv_map
A pretty reliable performance indicator is the mtex counter. If you're running the game in 16 bits color, try keeping this value below 15 average. In case you're playing in 32 bits a mean mtex of 30 or below should make for a playable map.

You can find the color depth you're using in the video options menu. Or as a rule of thumb, when the skies look ugly (you can see some texture errors in the sky) you're using 16 bits colors.

Apart from mtex count also try to keep the triangle count below 20000.

When you meet these two conditions your map will play well on nearly any system.

Posted: Sat Nov 08, 2003 1:04 pm
by Slyk
Well there are a lot of issues. And 40 FPS isn't necessarily Ok. My personal goal is always a minimum of 60, and only for small sections that may tend to be the most 'brush busy'. My general preference when doing the building work is 70+.

Example. One of my maps, Tractor Works is in overhaul...well, done actually. FPS: 90+ in 80% of the map... LOW FPS: about 65 in one small sector. Runs GREAT until the 16th player joins...then lag sets in and gets worse with each next player...BUT only in ONE sector of the map that unfortunately is in the middle of the whole flow. Trying to sort out why, even have involved a few EA guys on the side.

EVERYTHING in the map contributes to the FPS and lag a map may experience. My strongest suggestion is to always MAX out your machine's settings. Of course this depends on your specific computer system and the better your is then the better your FPS. But what you want to do is figure that you should be building maps keeping the average, if not slightly BELOW average user machine in mind. Not the dudes with the latest and fastest everything.

I commonly use two machines to build my maps...one is a P4 1.7ghz with 512 MRAM, and a 4600ti video card. About average now days. My other is a P4 2.8 Ghz with 1GBRAM and a 4600ti card. BIG difference and you see the FPS shoot way up when building/testing on the #2 rig. I always trust my #1 machine numbers.

So, in closing. 30-40 frames per second may look fine to YOU on a local rig, but once you start adding players and action heats up, those numbers are likely to drop dramatically.... and this assumes you do all that you can to make your map as structurally sound and smart as possible.

Posted: Sat Nov 08, 2003 4:00 pm
by smartaiguy
Slyk wrote:Well there are a lot of issues. And 40 FPS isn't necessarily Ok. My personal goal is always a minimum of 60, and only for small sections that may tend to be the most 'brush busy'. My general preference when doing the building work is 70+.

Example. One of my maps, Tractor Works is in overhaul...well, done actually. FPS: 90+ in 80% of the map... LOW FPS: about 65 in one small sector. Runs GREAT until the 16th player joins...then lag sets in and gets worse with each next player...BUT only in ONE sector of the map that unfortunately is in the middle of the whole flow. Trying to sort out why, even have involved a few EA guys on the side.

EVERYTHING in the map contributes to the FPS and lag a map may experience. My strongest suggestion is to always MAX out your machine's settings. Of course this depends on your specific computer system and the better your is then the better your FPS. But what you want to do is figure that you should be building maps keeping the average, if not slightly BELOW average user machine in mind. Not the dudes with the latest and fastest everything.

I commonly use two machines to build my maps...one is a P4 1.7ghz with 512 MRAM, and a 4600ti video card. About average now days. My other is a P4 2.8 Ghz with 1GBRAM and a 4600ti card. BIG difference and you see the FPS shoot way up when building/testing on the #2 rig. I always trust my #1 machine numbers.

So, in closing. 30-40 frames per second may look fine to YOU on a local rig, but once you start adding players and action heats up, those numbers are likely to drop dramatically.... and this assumes you do all that you can to make your map as structurally sound and smart as possible.
Yes, true...

FPS

Posted: Sat Nov 08, 2003 6:09 pm
by tltrude
Here is somthing to think about. I was testing an idea for using an inverted curve cylinder as a skybox yesterday. At first I had square brushes as the top and bottom of the skybox (the whole thing is surrounded by a caulk box too). The FPS was over 100 and the cylinder worked fine except the corners of the ground brush were dark. So, I added an inverted end cap patch as the ground.

I had already reduced the complexity of the curve cylinder, but not the end cap. The FPS dropped by 20 points to the 80's! When I reduced the complexity of the end cap (twice), the fps shot back up to over 100 again. The whole map is only 1024 X 1024 and is empty, but the reduced number of patch mesh faces made a dramattic difference in preformance.

Re: FPS

Posted: Sat Nov 08, 2003 7:01 pm
by smartaiguy
tltrude wrote:Here is somthing to think about. I was testing an idea for using an inverted curve cylinder as a skybox yesterday. At first I had square brushes as the top and bottom of the skybox (the whole thing is surrounded by a caulk box too). The FPS was over 100 and the cylinder worked fine except the corners of the ground brush were dark. So, I added an inverted end cap patch as the ground.

I had already reduced the complexity of the curve cylinder, but not the end cap. The FPS dropped by 20 points to the 80's! When I reduced the complexity of the end cap (twice), the fps shot back up to over 100 again. The whole map is only 1024 X 1024 and is empty, but the reduced number of patch mesh faces made a dramattic difference in preformance.
Holy smokes! :o :shock: :P :P :!: :!: Thats a heck of a lot better than my computer will do with a square sky box. And I've got a good computer too (maybe you've got the settings set low) - 2.66 Ghz, 512mb SDDRAM, 64mb vid card (can't remember what)

Posted: Sat Nov 08, 2003 8:07 pm
by jv_map
Well you should never place a sky texture on a curved surface. The texture is adjusted to look like a sky and the actual shape of the skybox doesn't make any difference to the looks of it. If you use a sky cylinder with e.g. 80 triangles, the texture coords of all these triangles have to be adjusted to make the sky look like a sky, compared to just 12 triangles for a sky cube. Apart from that curves by themselves require more processing power than regular brushes, since LOD changes have to be calculated all the time. Thus, this way of making a sky needlessly drains cpu power away.

Posted: Sun Nov 09, 2003 2:56 am
by smartaiguy
jv_map wrote:Well you should never place a sky texture on a curved surface. The texture is adjusted to look like a sky and the actual shape of the skybox doesn't make any difference to the looks of it. If you use a sky cylinder with e.g. 80 triangles, the texture coords of all these triangles have to be adjusted to make the sky look like a sky, compared to just 12 triangles for a sky cube. Apart from that curves by themselves require more processing power than regular brushes, since LOD changes have to be calculated all the time. Thus, this way of making a sky needlessly drains cpu power away.
True. Since the map was only 1024 x 1024 it'd be fast anyways.