Path: chuka.playstation.co.uk!news From: "pal" Newsgroups: scee.yaroze.freetalk.english Subject: Re: Main Game Loop Technique [long] Date: 15 Jul 2002 08:57:04 GMT Organization: PlayStation Net Yaroze (SCEE) Lines: 52 Message-ID: <01c22bdc$7acc3d00$3da3933e@pal-s-omnibook> References: NNTP-Posting-Host: nas-cbv-9-62-147-163-61.dial.proxad.net X-Newsreader: Microsoft Internet News 4.70.1155 Ok I feel talkative today (yes, as usual actually :) ) As Ben said, you really need not worry about performance at that level. A function call with take some time, but this is to be considered against the whole time you've got (one frame) and other tasks that are so much more costly. If you want to get an idea of the cost of things, most individual operations only take a few if not just one (esp. on the PSX) CPU clock cycles; so you're comparing something in the range of 33MHz (CPU speed, if I remember properly) to 50Hz (frame rate). You can see there's room for an insane lot of single operations. (Of course a function call is more than one operation, but it's not a hundred of them either. And there are costly operations too, like the multiply-things for instance) What will eat your time usually is number crunching (calculations: 3d transformations, trigonometry... -- that's why we love tables), memory copying, sorting... mostly repetitive tasks performed on big amounts of data. For instance if you want to simply copy an image from one area of memory to another, it'll take roughly width*(height + d) operations (multiplied by something depending on the image bit depth to CPU word size ratio) : a small 32*32 image will need in the range of 1024 operations. And you're doing a lot of these (note that this is to get a general idea, not PSX-specific). The function call may become worth worrying about when you have a lot of objects doing it. In a shmup you may be going to have hundreds of bullets; then optimising the bullet's code by getting rid of function calls may be useful. But optimising your player ship's code should be useless -- unless there's a hundred players of course ;) . I think that the best thing to do is first write all your code in the clearest and more reusable way, then look for optimisation when it's finished or you hit a performance problem. It is more important to have maintainable and stable code than fast code until the final stages of a project usually. As far as I remember, in Invs the only optimisation (apart from changing /*'s into <<>>'s) is in the spline routine (for instance, all drawing is done through multiple function calls, eg playThatEnemy -> mySpriteFunction -> myMoreSpecificSpriteFunction -> GsSortSprite !!!), and if you look at the later levels there's really a lot happening on the screen with slowdown only occurring very far in the game (which I don't mean is good ^^; -- but you get the idea). About function pointers, I like them a lot too, they're very good for state machines, which we need a lot of in games. You may also consider that they are more flexible than coding your cases "in hard" (not sure about the English term here). pal