What factors greatly affect fps(frame per sec)?
Blitz3D Forums/Blitz3D Programming/What factors greatly affect fps(frame per sec)?
| ||
| Hi all, What factors greatly affect fps(frame per second), besides no. of trangle of meshes and no. of objects? Thanks in advance. Sammy :) |
| ||
| The number and type of picks [spherical radius is cheap poly is expensive, box is inbetween) and collisions, the number and resolution of textures [and blending of same exceeding the hardware texture limit given by HWTexUnits() which forces blitz to multipass], the number and type of lights [ambient is free, directional is cheap, spot is expensive]. |
| ||
| Oh and any kind of type for loops. Like bullets and such. Don't use detailed bullets that aren't needed. In other words don't make a 60 tri bullet with a 256x256 map and try and run a For Each loop. |
| ||
| number of surfaces level of detail camerarange |
| ||
| On low end systems music can actually have an impact as well. |
| ||
| ..rendering cube maps can kill your FPS like small bug.. |
| ||
| I remembered that the command "Text" and 2D-GUI also affects fps. Sammy :) |
| ||
| So basically as you can see from the above list... everything is a potential FPS hit. It's up to you to find the bottlenecks in your code |
| ||
| LinePick and CameraPick is the slower: -the higher the pickrange (camerapick uses the camerarange) is. -the more objects are in the scene! Other things: The camerarange. Not only the max should be low, the min should also not be too small since a very small value like 0.0001 will force a (unnecessary) high z-resolution. The number of Triangles in the scene The number of surfaces used by all meshes The number of surfaces within the camerarange (and their number of triangles) The number of keys in animated meshes The number of bones involved in vertex weighting (animesh) Bad Triangles. (triangles that are existing twice in one mesh). They may slow down some cards extremly because the renderer kind of stumbles over them. Additional Renderworlds() (used by many effects, eg. cubemap or glow) Bad programming. Well of course you can do many things wrong. Here's an example for an enviroment that runs fast also on relative slow machines: 50 thousand triangles total used by 100 surfaces camerarange min:0.1 max:200 Oh yes, and too many alpha blended objects. Especially when they are big on screen. |
| ||
| And of course there's the fill rate, that's a biggie sometimes! |
| ||
| Hi Dark Half, May I ask what is "fill rate"? Thanks in advance. Sammy :) |
| ||
| also real time pixel manipulation (read/writepixel[/fast], plot, [un/]lockbuffer, set/graphics/imagebuffer), expecially on loops.. |
| ||
| Any stuff of 2D in a 3D environment is potentially a killer. If you need a HUD or the like, use 3D objects (sprites) instead and draw to their textures instead (and only draw anything to it if it is really needed and not only because you were bored or to lazy to check if an update is needed through a state variable ;-)) |
| ||
| also, poly-to-poly collisions. |
| ||
| as a side note on this topic... i was just today (yesterday) confronted with something that was directly related to what you are asking... even though my porblem wasn't exactly frame rate loss, it was very closely related... i had to throw up a lot of particles for an effect i was trying to get, and not only whenever the effect was in the scene and the particles being rendered, did the frame rate drop, but the motion of the other objects also slowed down a bit... then they would rapidly, and noticeably speed up when the particles effect was out of the view... i had to eliminate some of the particles was my first thought... or at least to shorten the average life of each one... right... well, i found out that it wasn't really the frame rate that was the main source of my problems... it was the timing between the game logic (main loop) and the rendering loop and the vwait flipping... take out the vwait... right... well, i tried that too... the solution was the not so obvious one of slowing down the game logic loop to a point where it would never outrun the screen refresh... of course this meant that i had to retime all the motion values for my objects up a bit... but now, even though the framerate is just a bit slower, the game now runs smoothly, even with all the particles in place... so, in short, it's not always the fastest frame rate that you've gotta take into consideration... native Blitz apps will reach a point of diminishing returns at some point, if you push it... i've found that balancing everything is the way to get the best performance out of Blitz... --Mike |
| ||
| Hi all, Thanks a lot. (I think "fill rate" is refered to data assignment. eg. reading data into variables/types/array.) Sammy :) |
| ||
| No fill rate is related to graphics. Its one of the most overlooked things that normally will make your game break on 1-2 generation back graphiccards even if it runs on your system. |
| ||
| Oh, I see. Then, "fill rate" is hardware-dependent on end user pc. http://digilander.libero.it/F1Land/3dfxarchive/develop/tech/fillrate.html Thank you. Sammy :) |
| ||
| exceeding the hardware texture limit given by HWTexUnits() which forces blitz to multipass], How do I know I've exceeded it? |
| ||
| I think it will be evidenced by an increase in Trisrendered(). You exceed it by using more texture layers on an object than are supported by hardware. Extra texture layers will hit your fill rate as well of course. |
| ||
| how can you calculate/test the amount of texture layers that are being generated for an entity ? |
| ||
| You know it up front, as you have to assign them. several textures on an object does not lead to several layers but to several surfaces. Adding them to different layers manually does (or using a modelling app that supports that for B3D files). |
| ||
| Any stuff of 2D in a 3D environment is potentially a killer Does it means the following? BB Commands are divided into 2 groups: 2D and 3D. For good performance, we should not use 2D commands in 3D graphics mode, or vice versa. eg. "DrawImage" (2D command) should not be used in "Graphics3D" (3D command). Use "loadmesh" instead? Am I right? Thanks in advance. Sammy :) |
| ||
| I am wondering the same thing. Are drawimage commands bad in a 3d game? What if you are drawing them to a texturebuffer? Is that bad too? |
| ||
| Even if you draw to texture buffer, they are bad. But by drawing them to texturebuffer, you have one pro: If it is something that does not need to be redrawn on every frame, you can draw it once to the texture and simply display the object afterwards (great for HUD for example). So no need to draw the image on every frame again and again. |
| ||
| What about WritePixelFast? Is that bad or is it ok? (I am thinking about writing to the back buffer, but info about any buffer would be ok) |
| ||
| Basicly drawing to textures is needed only in rare cases. Drawing Images is pretty fast. AFAIK the only thing that may slow down SOME machines is "Text". Then again, you won't draw images in a 3d game, will you? |
| ||
| Yes you, will for HUDs for example that have dynamic content (radar for example) But they are normally not needed to be updated in realtime in which drawing them to a "HUD Texture" is the better usage, so you can update it when needed. (and gives you alpha as well :-) ) |
| ||
| What does HUD mean? |
| ||
| Heads U Don't..... Sorry, it means head up display. I've encountered some fps issues with the first piece of B3D I hung together. Went back to the drawing board to gain appreciation of what kills fps... You can't beat a good design. |
| ||
| Hi all, In old computer (Apple 6502), multiplcation and division takes more time to process than addition and subtraction. Are there any advantages using : 1. "Shift left/right" command, 2. lookup table technique to by passby multiplcation and division? Or Blitz3D already can multiply and divide very fast and there is no need to do this? Thanks in advance. Sammy :) |
| ||
| the screen resolution will kill your framerate if it's too high. |
   |