Optimising advice wanted
Blitz3D Forums/Blitz3D Programming/Optimising advice wanted
| ||
| I'm writing code using TOKAMAK and simple geometry on a fairly high spec machine (Athlon 2500, GForce4 Ti4200 8xAGP, 1 Gb RAM) but my target audience will have substantially lower spec machines. Is there anywhere a guide on optimisation. eg. At present I've got a few substantial cube maps and textures involved. Do I need to shrink everything down to fit into say 4 mbs VRAM despite not deliberately loading them into VRAM? I rather concerned that things'll choke on a simpler PC and want to know how to avoid that/fix it if it happens. Cheers, |
| ||
| I suggest to use a low spec Machine to develop things, so you will be forced to take care of that thing. But you could also offer mutliple modes. So the user could choose from economy, average to high-end. You even could write a function that is capable of making a suggestion to the user, after testing the Speed checking the VRam size and the compatibility of cubemaping and HW Multitexturing etc. |
| ||
| biggest things that I found will slow your game down on a low end machine is. Number of collision polys Surface count entity count number of picks and pickable geometry. So you need to be very stingy on how many unique brushes you use in your scene, try and avoid overdraw and a lot of alpha. use invisible hidden collision as much as possible with static geometry on a low end system its far better to combine all visible geometry that shares the same brush into a single mesh and not worry too much about occlusion. try and keep pick distances short and I find that using simple geometry invisible collision for gameplay and keeping it completely seperate from the visuals works best. try and keep your camera ranges as short as possible without having it look crap, same with fog. and Keep dynamic lights under 3 (preferably 1 if possible lol) these things have worked for us so far and all our games untill the most recent, ran on a Pentium 2 400 32mb Geforce 2 and fly on a athlon 1200 geforce 3. thats about 50,000 visible polys, up to 4000 invisible colideable polys with sswifts shadow system. a lotwould depend on the type of game your making, but you will be surprised what you can do with fairly few polygons if your artist and coder is experienced at optimizing and knows how blitz works and are both willing to work together at the same goals, making compromizes where neccessary. Sounds obvious, but its amazing how few people can actually work in an efficient team like environment. |
| ||
| Thanks for the suggestions. jfk : I've only got the one computer! I was thinking of an auto optimisation system to limit the number of objects on a system to maintain a decent frame rate. Basically just run a few case situations, record the frame rate, and stick to the most complex one at a decent frame rate! Evak : "Keep dynamic lights under 3 (preferably 1 if possible lol)" How's about no lights at all? :) My system uses texture based lighting and no more than two textures per object to be sure target cards can cope. I've also got very few polys. I doubt I have more than 1000 triangle at the moment. However, I don't understand how surfaces get allocated to reduce their use. Is there an 'Idiot's 101 to Brushes and Surfaces' around? Does a brush=a texture? |
   |