faster frame rate advise
Blitz3D Forums/Blitz3D Beginners Area/faster frame rate advise
| ||
| I am having some frame rate issues on a pretty slow computer and was wondering if anyone had ANY advise for making games go faster on low end computers. |
| ||
| Reduce the amount of drawing. Turn off as much alpha as you can. Reduce surface count. Use LOD. It really depends on what exactly is slowing down your game. Show a demo? |
| ||
| Turn off debug mode for your final executable... For a few more, check out my programming tutorial. |
| ||
Put somewhat in your mainloop and before if you not have yet.
Const IntFPS% = 60
FPS_Period = 1000 / IntFPS
FPS_Time = MilliSecs() - FPS_Period
While Not KeyHit(1)
FPS_Ticks = FPS_Elapsed / FPS_Period
FPS_Tween = Float(FPS_Elapsed Mod FPS_Period) / Float(FPS_Period)
For FPS_Cnt = 1 To FPS_Ticks
;put in new meshes here
FPS_Time = FPS_Time + FPS_Period
If (FPS_Cnt = FPS_Ticks) Then CaptureWorld
;gamecontrol here
;UpdatePlayer ()
UpdateWorld
RenderWorld FPS_Tween
Flip
WEND
|
| ||
| Make sure to select 640x480x16 when testing on older equipment as it saves both on vram and will boost rendering speed significantly compared to say a default of 800x600x32. |
| ||
| Always do only what is nessesary in the main loop. If you need to create the illusion of an asteroid belt where each asteroid is moving and turning, then parent all asteroids to a pivot and turn one asteroid each frame instead of moving and turning 200 asteoids at the same time. If you need to maintain a sorted list of items, use a sorting routine which enables you to sort one iten at a time, one each frame. In short, reduce each task to it's smallest component and do one monumental task in many small steps instead of one big step. Andy |
| ||
| Don't combine 2D and 3D drawing operations. That'll cripple old GPUs. Don't use screen filling textures either. A large sprite or texture backdrop, somewhere around the 70%+ area of the screen, causes a massive slowdown. If you're using 2D commands always use locked buffers where you can. |
| ||
| i will use fullscreenfilled textures. cause lots of cards can handle this easy. come on guys, wake up, its the 21. century ;) ati radeon 9800 pro is pretty old, but it can handle this task easily... don't stick around with old GPUs... everyone who plays games regularly will have a relatively good gfxcard. and those who don't - they don't care. |
| ||
| mrjh asked for ANY advice ;) As Mustang's recent atmosphere research supports... ...I get ~740 frames per second with my nebula/starfield bg object - which has 116 triangles in total and one 2048*2048 map (nebula) and one 256*256 map (starfield). This using GF7800GTX and "Graphics3D 1024,768,0,2". If I take the bg object away I get ~1460 frames per second... so it did drop to half but it also draws maybe 3-4 times more pixels on screen. Fullscreen FPS: with nebula/starfield 986, without 2115. So it seems to be consistent at least, and fullscreen is always faster than windowed, I think. If you're producing a game with fullscreen/large textured sprites, and are getting frame-rate issues, elliminating the large sprites may help solve them, possibly with a lot more success and less effort than redesigning your main loop to process game components less frequently. |
| ||
| >mrjh asked for ANY advice ;) hmm, ok ;) |
| ||
| Ati radeon 9800 pro isn't exactly old tech compared to what most people are using. It's better than my card :D |
| ||
| I have the Xtasy 9600SE 128mb 8X AGP. How's that compare to the kind of vid cards some of you are extolling the praises of? |
| ||
| I still have a 9200se. Ok, it's low end. but when a game works on it then it may work on most machines. Here are some hints to make a game fast on real slow machines: First of all: Polycount. If you don't know about that then you should start here. It's a science by it's own to create Meshes with the absolute Min of Triangles neccessary! So don't use nice looking meshes with thousands of triangles (a lot of free meshes in the web do this, they are not created for games design), but get some meshes that are polycount optimized in the first place. For a low spec machine, try not to have more Triangles than say 20'000 rendered per frame (use TrisRendered() to check it). This doesn't mean you can't have more than 20kTris in you level: Camera Range: When you create a level (assuming FPS), always keep in mind to build everything in a way that allows to have a very low camera range. Use a Level that is made of many objects, not only one big mesh. The Level may be made of several building parts, hundereds of items and fine furniture stuff, animated enemies, plants etc., but make sure they're all loaded as seperate meshes (although using CopyEntity for indentical objects may be useful nevertheless). Now everything that is out of the camera-range will be ignored by Renderworld, and therefor it's much faster. But, as I said, you need to keep this in mind during the entire process of level design. If you forget it sometimes, eg. with a long corridor, you may fix this later with some additional stuff (good old crates :) ) that are placed in the corridor in a way that allows the wanted low camera range. Collision: Use an Enemy system that does not use Collision by default, but only when NPCs are very close to the player. Alpha: Don't use Alpha in more than one layer. Not only is their z-order messed up anyway, it may also slow down things exremtly when Renderworld has to "go" trough multiple alphatransparent onjects. The Size of the alpha object also depends here, so every pixel counts. Note: The HUD probably also uses Alpha, I'd suggest to use Blendmode 3 for HUD instead. Linepicks: Try not to use Linepicks, especially no long distance linepicks (and Camerapicks). Of course, in some situations there's no way around them. But try to reduce it to the min. Functions: Don't use function calls for every poop. Every function call is using the stack to place it's return adress, hands over parameters, jumps to and back, corrects the stack pointer. So the Useage of something like c=Add(a,b) my be costy when called in a loop. |
| ||
| jfk: Functions: Don't use function calls for every poop. Every poop? Oh, my! ;) |
| ||
| Funny, for years I thought "poop" describes those not so good smelling bio gas clouds that sometimes materialize near some of our special friends, but hey today I realize this is a part of a ship, a tech term. Hmm. So I got to release a new version of my demo since it contains the phrase "picked up a CD: Madonna, yet another poop". Well, this is not my native language, I only picked up some words on cartoon network, so please excuse me. |
| ||
| LOL. Actually, I know he meant "loop", not "poop". It's just an "oops" of the fingertips on the keyboard. |
| ||
| Thanks for all of the advise. It has been very helpful. Andrea, that code is very usefull to me, but I was wondering if you could explain how it works. Please? |
| ||
| "Use a Level that is made of many objects, not only one big mesh. " i used one big mesh for my level (100.000 tris), when i load the mesh via loadmesh() there is nearly no culling. but when i load it via loadanimmesh, trisrendered() gives me bout 20.000 - 100.000 polys (depends on your location in the level). it seems blitz can cull childs of a mesh. of course, collision detection is still fully enabled for the whole level... thats not so good. but its still pretty fast on my laptop... |
| ||
| Use a low poly version of your level/landscape for collisions checking. if you do have a high poly landscape/terrain, this will speed up things :o) |
| ||
| Thanks, this has all been very helpfull! Still if anyone else has some advice, feel free to post! |
| ||
| Trade in the low end computer for a middle or high end computer :) |
   |