General Speed Enhancement Tips/Libs
Blitz3D Forums/Blitz3D Programming/General Speed Enhancement Tips/Libs
| ||
| My game will most likely have a problem of being very slow, for whatever reason, and I want to make sure it isn't, even on the lowest common denominator. So, I am here to ask: What do you do in general to enhance speed on your games? Are there any libs that would help with speed? What do you do to reduct speed based on high polycounts? |
| ||
| it depends on the genre you are talking about. I think you work on something fps/3rdps-ish, right? There are several traps you should ship around carefully. A high polycount doesn't neccessarily mean a low framerate, especialy on faster cards. But there are several nonos you shoulda avoid: -Too much Linepicking. CameraPick, LinePick, EntityVisible etc. are in this categorie. -MeshesIntersect or other exotic and slow Commands. -Too much bones Animations, with too bug animated meshes. -logical bottlenecks in your code. Sometimes people are using insane slow algotrithms. -Meshes not fregmented, so the camera cannot skip rendering parts that are out of sight. -Too many surfaces onscreen In case you have one huge map mesh I have written a little app lately that will take a huge mesh and split it into multiple fragments. You will then be abl to lower the camerarange to allow the camera to ignore geometry that is out of its range or behind its back: http://www.blitzbasic.com/codearcs/codearcs.php?code=1244 Based on this Map fragmentation code you may be able to create a working VIS occlusion system, btw. Well I think the best way to optimize speed is to learn how to find bottlenecks. Learn how to include some benchmarktests in your engine, so you'll see what's slow and what's not. And also try to test commands in gereral, like t1=millisecs() for i=0 to 1000000 n=camerapick(camera,320,240) next t2=millisecs() print "this took "+((t2-t1)/1000.0)+" secs" And of course, when you design maps and meshes for a game, you should always be aware of the polycount and how it should be. |
| ||
| Try to load as few resources as necessary. For example, if you game has a title screen(s), you may look into Freeing everything that only pertains to those screens before loading in your game. If it applies, try dividing your game into reasonable sections (levels, areas, maps) so that you only have to deal with one section at a time. Always look to optimise your code. Say, for example that you need to perform this check: If Playerheight > 5.0 and LinePick(x, y, z, dx, dy, dz) = ground Then blahblahSince LinePick is a processor intensive command, rewrite it like so: If Playerheight > 5.0 If LinePick(x, y, z, dx, dy, dz) = ground Then blahblah EndIfThis way, if the first check is false, the LinePick command isn't even executed. |
| ||
Don't put:Delay 200 In the main loop either :D Happy New year! |
| ||
| I can't top Ross's ultimate speed saving tip, but... Big textures will really hit performance on older cards with a poor fill rate even if they do support that texture size, plus of course they chew up video ram, which if exhausted results in much movement of data over a probably none too speedy agp bus. |
| ||
| On a more seroius note, use linepick, instead of camera pick. Line pick you have control over the distance of the pick. So try and keep them short if you can. Or, instead of a line pick, you could project a pivot with a collision type, and move it in the direction you want to shoot. Give it a stop collision response. And check the entitycollided() :o) |
| ||
| Instead of iterating thru subscripts of an array when comparing/matching data just to see if something exists or not concatenate data into a large string For AssyLoop=1 to DataItems DataString=DataString+Data$+"," Next Now you can use the Instr() function to determine wether or not the item exists. How well this works depends on how much data there is, which of course determines the length of the string. Really large strings take longer to process so sometimes you have to break them up into smaller chunks. It's also possible to match that data to... say, a file position by creating a numerical stripe array and prepopulating the array with relevant positional data. Then when instr() returns a match at whatever position in the assembled string the same position in the stripe array will contain the filing position - so most of the subscripts in the stripe are not used - only the ones at which a match could occur, but despite that inneficiency and being a pain to set up the speed of operation is very much faster than the iterative technique. It should go without saying that you don't assemble the string for each and every search. Usually these things remain in memory once assembled - so they also need to be maintained if data changes. |
| ||
| Thanks guys. I sure hope I can speed up my game. :) |
| ||
| Graythe: I don't know much about speed improvements in Blitz, but I know that really large strings are slow. I've done programs that store large amounts of data into strings. As the strings get longer, it takes Blitz longer to edit them. Instead, use a bank. I don't think Blitz has any problems working with large banks. |
| ||
| ;-- |
| ||
| wow.... |
   |