Reducing CPU loading on games using tricks

[chris330 0]

Hi,

I've always been keen to develop my own game purely as a hobby. I often think about it alot. I've gone back to uni (open uni) to study maths and I've read through a good book on physics engines and re-read a load of maths books at undergrad level and I'm doing really well at understanding stuff so I should be ok especially given how many pre-made graphics engines there are out there today.

My main concern is always performance. Most games for me and I think many others play terribly with bad frame rates no matter how visually attractive they are. I'd much rather play a basic visually appealling game that ran fast, so much so I devote sometimes hours of daydreaming a day to thinking how to get optimum performance out of a game using clever tricks to give the appearance of greater computing complexity than that which is actually present.

I was thinking for example of when flying aircraft and firing the machine gun instead of worrying about computing collisions for the first several hundred feet perhaps instead I could just ray cast along a distance that a bullet would travel during the first few moments of it being fired. Anything in the way would receive an instant hit and the bullet would be deleted after that occurence. It would mean alot less rendering and frame by frame collision detection I would think. At a point where the bullet would be expected to begin to fall from it's initial trajectory, then perhaps I could create an object at that point and then have it start to follow a route affected by gravity.

I was also thinking maybe a single registered trigger press would infact cause a minimum amount of rounds to be fired and over a set time. For example when ever a trigger press was detected a minimum 10 rounds would fire over a period of a small fraction of a second. Any additional trigger detections during that small time period would yield no response until the time lapse had ended and then if the trigger input was still detected or a new one initiated the loop would go again. Some clever code trickery using random numbers could slightly alter the numbers fired by using small random deviations around a secret set number like as mentioned 10 rounds but randomisation might make it say 11 or 8 as arbitrary examples. This would give the impression it was much more sensitive than it was.

Also during each round burst I was thinking of there being only 1 actual bullet course plotted. When acheiving a hit some more random numbers acting within a radius and some trig calcs could activate damages occuring within a circle centred at the plotted bullet's impact point. This would mean I'd get like around 10 bullets worth of action for only 1 actual computed trajectory.

Nasty stuff like the impact centre being on a tree or lamp post or some small object could be gotten around by doing a quick check to see if the computed bullet had struck a plane surface (i.e. a wall or fuselage or whatever) and if it hadn't and it had struck a small object then another computation could be made from there on until the next thing got hit but with each successive computation carrying a variable containing the number of bullets still in that bullet cluster.

Thus eventually you'd either hit a planed surface big enough to accomodate all bullets in the cluster or you'd compute out successive impacts till all were gone. The only issue I could see here would be if the evalution of the impact zone were too CPU heavy it would negate the benefits of not having to compute the trajectory of each round.

This I think would work well at reducing nasty high speed computations.

The other big problem would be trees. A big MMOG game I play has serious frame rate issues for only very basic graphics. We think it's due to alot of stuff being rendered that is unnecessary.

I was thinking of using the same scheme OFP uses for muzzle flash and bushes. Two planes at 90 degrees forming a cross with symmetrical textures on them but I want something more appealing. Is it possible to construct whole trees using multiple versions of this mapped plane concept?

I want good trees that are good enough to be believable but without any frame rate hits *especially* for bomber and helicopter pilots who will be having lots of these rendered on their screen.

Can anyone give me any ideas or help or even just comment constructively on what's been said? Thanks ;)

Edited August 16, 2009 by chris330

[Rhammstein 10]

Well I can comment a little on what's been said.

I guess you're describing air combat, whether air to air or air to ground, regardless;

It can be complicated, physics must be used for ammo that's fired, to give an accurate gaming experience. Many games, there actually are no bullets, a well made game can easily distinct between a miss, and a round that hit a hitbox. As far as improving performance for such operations, I can think of many other examples they may be better, because this is simple math, and computers today and handle it easily. With multi-core support, these physics calculations can be handled through thread to one of the cores, or even done by the GPU, if it's an Nvidia (Nvidia Physx).

Although no game exists that I know of that really pushes the limits, one could be made (I'm one of the many people that email M$ occasionally about Combat Flight Simulator, and why they dropped it)

Such as a bomber with several gunners firing at several interceptors, now that would make for an a$$ load of calcs, but great coding could make this very easy to do. The only thing that makes things complicated is, in such a situation, is the game engine must, first, be aware of where each plane is in the 3d map. Say there's 8 interceptors, all at different altitudes and airspeeds. An airplane firing a round while in a roll or changing it's angle of attack will effect the rounds that were fired, as will the airspeed, higher airspeed, more velocity on those rounds.

Now a Cpu must be calculating all of these things, if it's a quality product, damage models will be dynamic. A round fired from 3,000 yards from a plane moving at 300 kts should damage a plane less, than another plan firing from only 400 yards out, in a dive at a very high rate of speed, that round, if hitting the same hit box should do more damage.

Having such things dynamic would require big power, I hope one day to see a WWI or WWI combat sim, again, and better done.

The flying physics in all M$'s flight sim's were great, and still are. I only fly small planes, irl, just private and instrument, so no jets.

I find FSX to be incredibly accurate, except that not feeling the G's on your body sucks, but some ppl will pay thousands for the machines to replicate them.

Really I'm not sure what you mean to improve, a lot of what you've mentioned is already done. (but absolutely I know what you mean, virtually anything can be optimized, not just flight sims but all software) Some so incredibly optimized it's mind boggling. And with the power of the GTX 295, better yet two of them, and a fantastic quad core, we have the ability to do amazing things. However your interest in optimization is important, and believe me, it's on every single programmers mind. They're constantly looking for better ways to accomplish things. DX10, better yet 10.1 has gone so far to improve what can be done on the graphics and even physics (Nv) side of things, so much so that it even required the redesign of all modern GPU's. This new unified architecture is the best thing to have happened to PC gaming since, IMO, shader model 3, and honestly SM3 really has nothing on what's happened with DX10/D3D10. (Hopefully you're familiar with how a DX9 GPU is designed, and how up to 90% of the GPU, in a game can actually be sitting idle, simply because different operations required different parts of the GPU. With a DX10 GPU, the Shaders, or as many call them your alu's, are universal. So it's only a matter of allocating the power of them to provide optimum performance. I've seen benchmarks where a GeForce 8600GT blew away 2 7900GT's in SLI because of this.

I think it's very important devs don't simply take advantage of the power of newer hardware rather than spending time optimizing their code, what's possible, even now, even on my rig, is incredible. And I think it's a shame nothing exists to take advantage. Games must be written to well support dual core, but more importantly written to take FULL advantage of a Quads cores, and all the extra cache. Also I think every single developer should include awesome, next gen effects using Nvidia's Physx, but in such a way that a gamer that cannot take advantage won't lose out, as far as gameplay, rather a simply animation, or whatever it may be, be used instead. Like Cryostasis for example.

(IMHO Hardware physics are just absolutely incredible, and need to be used, more often, and in more ways than we've seen. For those than have ATI cards, I don't know what to say, perhaps AMD can develop their own system and embed it into their cards one day. I know a lot about gaming, and I can see down the road, there's gonna be some pretty sick stuff coming to those of us lucky enough (Or informed enough) to have chosen a Nv card. Thank you ageia technologies for getting the ball rolling.)

Maybe you can rephrase exactly what you mean, you can use the combat flight sim analogy again, it's easier for me being an aviator and obsessive simulation user (Racing, Flying, etc). Also we can never forget with every little optimization in a game or sim's code, the netcode's gotta remain intact.

Let me know if I missed you're point, or got it and simply went off in another direction than you'd intended.

Forgive me if I went off topic with the DX10 discussion, I just think it's being overlooked by 99% of people, all the while it's the most incredible revolution in PC gaming to date.

Edited August 17, 2009 by Rhammstein
Grammar, I'm sure I missed plenty anyways

[chris330 0]

Hi thanks for the reply.

Wow to be honest most of that went way over my head! I'm going to write my own game in the future and I'm thinking a long way ahead of how to optimize the hell out of it using tricks. That's what I'm really interested in. If you know of better ways to do things I've suggested please share them, or if you know of good ways to do something I haven't mentioned please say also.

I'm not really clued up at all on all the advanced stuff you talked about with regards to modern hardware, most of my concerns at the moment are just about finding very lean optimized ways of performing calculations that relate to flight & combat simulations. Stuff like what you mentioned about processor orientated code is something I don't understand and best left to people like yourself who obviously have very good and advanced understandings of such things.

• You mentioned something really interesting about planes rolling and pitching whilst firing. If the bullet is created at an instantaneous moment during the plane's roll then I assume it's correct practice to just perform a typical trajectory computation from the point of origin when it was fired. I assume given how fast the bullet leaves the airplanes gun barrel, the plane's roll speed has no real affect on how the bullet flies from the moment it's fired. Surely if at that moment the bullet is just created at the right place at the end of the barrel you can just plot a normal trajectory as if it had been fired from a stationary gun in the sky.
  
• You made a brilliant point about the velocity of the plane affecting the damage inflicted by the rounds fired from it. I assume here the faster the plane is flying the greater the damage inflicted by the bullets. I was thinking about this alot. I reckon I could simulate this nicely by using an equation with some kind of linear decay in it which affected the damage of bullets in relation to their speed. Shoot I wouldn't even have to actually change the value of the bullets' speed in the game world at all, I could just keep a computational track of what their speed *should* be then obviously this would dictate how much damage they did.
  This way I can again just perform a simple trajectory calc using 1 bullet (a tracer) representing several others and have its range pre-determined in the game code. This means it can fly at a constant speed throughout its lifespan along its trajectory before being deleted when it hits its max range value. Again it's actual max range when instantaneously fired could be slightly altered using a random number. It's not quite realistic but it would not be noticeable given how fast it all happens.
  Bascially to cut all that b/s down to something readable - I could leave the way the bullet was rendered in the game world unchanged yet through some simple calcs alter its damage in relation to the speed of the plane that fired it. It would be a nice toy for guys who say wanted to dive strafe tanks to get through their armour.
  
• I have thought of a problem with the single bullet computation method. The original idea was to have it fly until it hit something then activate some code which plotted a small circle centred around the impact point plotted at right angles to the bullet's direction of travel. It would look if you can picture it, like a pen (the bullet) being pierced through the centre of a circular piece of paper. Some more code could come up with some quick random dispersion plots of points within that circle (think of taking a permanent marker and putting a few small marks randomly on the circlular piece of paper). Then some more code could check forward from these new points along the same direction as the bullet was originally travelling (think of putting a new pen through each mark on the circular paper and having them point the same way as the one in the middle). If after checking a set distance forward from each new mark no objects where found (thus no impact) then a new trajectory would plot from that point. Think of it as any pens on the new marks that weren't touching anything were deemed still active. Those that were touching something did damage to it and were deleted.
  A major problem with this is that technically if the centre bullet hit a small object very early on then it would produce a perpendicular cirle with new rounds created that all hit nothing and thus then all had to be rendered from then on totally negating any CPU saving benefit.
  The other massive problem with it is the opposite scenario. Say the centre bullet went through a very tight gap. Obviously in reality some of the bullets distributed around the one at the centre would not make it through the gap. That wouldn't happen with this method. With this method the centre bullet could make it through the gap, register no collision then hit something else and then decompose into several impacts to simulate other bullets in the cluster. That would look so silly. Imagine getting a round through a gap between the semi closed shutters of a cottage window only for the game to then render impacts across a 10 foot radius inside the room!

Anyways I'm rambling now but that's all I want at this stage. Just ideas chucked out raw. I've actually thought of a full solution to this problem and tomorrow I'll post up with pics a full and clear method. ;)

[Rhammstein 10]

Btw do you use Flight Simulator of any version?

Also, a lot of what you're discussing is the reason hit boxes are used in games, it's not perfect, but it's much easier. My only beef, especially with the MS Combat Flight Sim games was, while perhaps a round fired may not continue on it's path after a hit, a cannon certainly would.

So, what always bothered me, regardless which version I was playing, there were times I'd score a hit, with my cannon, that wouldn't do much damage. But I knew in real life that it would continue, through the outer shell of the plane, and do further damage. But the games weren't setup that way, they just had the exterior hit boxes, which if you hit enough times would bring a plane down. I guess back then the technology, or PC's in general weren't strong enough to support more dynamic hit boxes of some kind, like kill shots. A shot from a cannon from the right angle could realistically penetrate far enough to kill a pilot, yet this wasn't possible in any way in game, if my memory serves me well. It's been a very long time. I can't even find my discs to fool around with the games. I always thought a shot on a canopy should have knocked it off, and caused absolute hell for the hit pilots vision. I could go on and on and on.

Peace

[PuH 0]

Actually, your main points, hitscan for the first few meters and sending multiple bullets packed in a cluster and then unpacking them when they are about to hit something, has been done in Red Orchestra (trying get you a link where the lead coder descibes it)

[chris330 0]

Hi as promised I've returned with a theory of how to do this. Interesting points by the way Rhammstein thnx for the realism tips. PuH if you're still interested it goes a bit like this:

Bullet package created when gun fired. Could be from plane, infantry, tank lmg whatever. Ray cast a certain distance that the bullet would be travelling so fast through it near enough reaches the end of the ray distance instantly. Anything that is in the way receives full damage from bullet number in package.

After that intiate a circle that is facing 90 degrees to the bullets travel direction. At each frame render a new circle and create a cylinder (abstract concept) back to the last circle and chk to see if anything is in the way. If something is discovered find the first contact point moving forward from the first circle till it touches the collision object. There use random numbers to place the number of bullets in the package at various radius from the circle's centre. Store the radius values used in variables. Now check forward using the idea mentioned above with pens and paper from these points to the place where the second circle in the original pair was placed. If any of the bullets hit anything do damage and delete.

Return to the place where the second circle in the original pair was placed and continue as before, but the next time a hit is detected the bullets must be placed randomly between their old point radius and the radius of the circle, which is why their old radius was stored in a variable mentioned above. Otherwise their positions within the circle could fluctuate randomly and they could for example get through an open window only to render and inflict damage in a way that woud be impossible. Once their position in the circle has been obtained it can only go outwards from that in the next frame not inwards as obviosuly bullets are spreading outward from the centre tracer they cant go out then come back in a bit!!

Wth each passing frame the circle could be made bigger to simulate the spread getting larger as the bullets got further from the firing point. I've had a good think and this works for me right now.

Only worry is will this be even more intensive than calcing each one individually?

[Balschoiw 0]

The trees:

Using planes with alpha textures and arrange them in a 90° offset is one way, especially if you want to compute accurate shadows.

Another way I use for unaccessible terrain is to have a single plane with an alpha texture of the tree and have a script attached to the tree that continously check the players position and sets the facing of the tree accordingly. This way the player will always see the tree from the right angle while it´s just a simple plane. For shadowing the scene I use baked shadowmaps or blob projectors as the shadow of the rotating tree would change when it turns.

In a current project I have done it that way:

- Near to player: either 3D models of trees with high textures and precision or tress made of two planes. Both of them static

- For far away trees: Single planes with transparent tree texture and the script to rotate towards player with either blob-shadow or baked shadowmap.

Another way is to create vegetation on the fly while the player is moving around. Predefined trees, bushes, billboard grass actually are placed with a script on the fly to save performance. Still, this method is more complicated than the above and often doesn´t really work if the script isn´t really perfect as the rules of placement are hard to define sometimes.

I guess it depends on what you want to do, your setting, your area, the freedom you want to grant to players. Especially keeping everything dynamical, like pixel shadows, bumpmaps, etc is really a big performance eater. Still there are projects where you need to have it for realism reasons.

Sharing textures is a good way to save ressources. With different UV set´s you can apply a single texture to multiple objects and save ressources.

[chris330 0]

Oh my word this will no doubt provoke a big follow up post with loads of questions. Sounds like a really neat trick you've devised there I really like the sound of using code to display a plane at the player in the right way instead of rendering multiple polys. I'm tired right now but I'll post a digest and question post of your great reply later thanks!