Topic: PERFORMANCE ISSUES - FRAMERATE SLOWDOWN (Read 6928 times)

psikotropico · « **on:** March 10, 2010, 01:23:51 AM »

hi all... I was thinking that could be awesome if we create a list of possibles situations where some of us had experienced framerate slowdown, explaining the causes of that... or if we have reached the limits of 3dRad... this could be very helpful in the design stage of our projects and, of course, to avoid stupid questions like if we can make a Gran Theft Auto like game...

I will start with some examples based on my experience:

- Less is more. Just be simple. Avoid high-poly models. Less system requeriments to play your game lets you to distribute it easily and, of course, lets you to add more features to it.

- Do not link too much objects to a script. Seems to be a bunch of internal messages between objects that causes some overhead even if internal parameters are not used. i.e: I was working in a script that resets all objects in the project. Bad idea, because I need to link ALL objects to that script... better if I use an EventOnInput and link all objects to the EOI. another example: I was using a script to show/hide the whole GUI (all sprites and textprints) in the project... bad idea... better if I use an EventOnTimer (at 0 secs.) that makes the same job.

- Do not use too much textprints. The textprint object is made by more than 100 quad polys with alpha texture... that causes big loading times and framerate slowdown in some cases. Just design your interface with less different fonts as possible and use iPrint() function.

I will post more examples later... please feel free to post your bad experiences.

shadmar · « **Reply #1 on:** March 10, 2010, 03:39:36 AM »

From my experience :

30 sprites loads faster than 1 textprint. So basicly you could use 30 images for static text before needing a textprint.
Valueprint is not needed it has the same loading time as textprint, use 1 textprint and can display numbers and use iPrint() when you can. (I know text-font/color variations can then be an issue)

Imposters are good but always hide the ones not in the camra view, test this by using iSphereVisible(), this way you can handle a forrest of thousands trees, a city of buildings etc..

Hide, disable physics enabled meshes when not needed (or in sight)

Normalmapping/light calclulations is gpu expensive, only do it when needed.

Never enable skinmeshes rendering statistics unless you really need to.

Play around with collision resolution, lower gives better performance but longer initialization time.

If you hate multilevels, there is an option to refresh skinmesh and rigidbodies using iObjectrefresh()

Post effects/camrafilters kills your fps, like bloom and blur

Shadows are very expensive, keep them as simple as you can or don't use at all.

psikotropico · « **Reply #2 on:** March 10, 2010, 04:24:15 AM »

Quote from: shadmar on March 10, 2010, 03:39:36 AM

30 sprites loads faster than 1 textprint. So basicly you could use 30 images for static text before needing a textprint.

interesting

loop · « **Reply #3 on:** March 10, 2010, 05:04:24 AM »

* if you are making a physics based game and need to stack a lot of rigidbodies one over the other, and notice your framerate slowdown a lot when a certain number (3 or 4

) of rigidbodies are stacked, you may find a solution decreasing the physics simulation accuracy.
see iSimulationQualitySet(int) at http://www.3drad.com/Script_reference.php
NOTE: this performance tip is based on the previous physics engine (ODE), now with physx this isnt suppose to happen.

* more important that the number of polys you model have is the textures resolution. make sure its as low as possible, and if you can, save it in .dds format (DTX 1/3/5 is even better).

* the less "drawcalls" the better, meaning the less skinmesh objects you have the better, so if you can use just 1 skinmesh object for your entire world, better!

* try to keep your objects number to the minimum as possible, being this recomended minimum (or maximum you can use without going nuts) about 150-200. for more info about this point, see here: http://www.3drad.com/forum/index.php?topic=3825.0

Weapon121 · « **Reply #4 on:** March 10, 2010, 07:56:59 AM »

* Starting and stopping continuosly too many scripts will kill framrate.
* Having tooooo many scripts hurts framerate, I try to merge the less intense scripts together
* As psiko says, the less objects conected to a script the better. Get rid of any unused objects in your project and forget about setting them to inactive.

**** START SMALL AND TEST THE PROJECT AS YOU ADD STUFF, so you can catch early on any potential problems. I usually add an object , then compile and test as I go. this has saved me numerouse headaches!!!

Rush3Fan · « **Reply #5 on:** March 10, 2010, 09:18:06 AM »

I have been working on the car physics in my game, but not recently. I discovered that the wheel meshes were the only thing preventing me from merging 4 player cars with good framerate. That's 16 total skinmeshes with 100 polys each. But now it's probably only going to have two player because of all the stuff in the background controlling the game. But I think battle mode might be a bit simpler as far as the controlling scripts. I might be able to squeeze 4 player into battle mode.

Recently, I've been working on the second level in my game. I try to keep the texture size around 64 x 64 pixels. You ask why? There's about 150 of them and it really starts to add up.

You'd be surprised how good a small texture looks when correctly tiled.

n_iron · « **Reply #6 on:** March 10, 2010, 05:37:56 PM »

Hi everyone
Thanks psikoT this is a great post long over due.

A few things to contribute.

I know Fernando has mentioned this before on the forum but build small scripts for each object. for example use a script for animation for each character one for walk and idle animation and another for combat animation. this also helps to break up the complicated scripts making it easier to debug (Object Orientated Programing)

The functions below I have only used in a test program and plan to use it in the future. It will download skins etc replacing ones already in your game. This has the potential to allow you to design many levels with a minimum of objects in your object list. I also tested loading them from the Hard Drive and it also worked. The only draw back is when compiling a game you have to manually load the extra objects for distribution.

Quote

int iFileDownload(string,string)
Downloads a file from the specified Web location to the local computer.

void iObjectRefresh(OBJ_X,string)
Change the resources (3d models, textures, etc) associated with the specified object.
This function is typically used to update SkinMesh, RigidBody, SkyBox or Sprite object geometry/aspect run-time, for example after the new artwork has been downloaded from a server (website) by using the iFileDownload() function.

For an example of usage, see the demo project called WebDownloadDemo.3dr

When you look at a game like Assassins Greed 2 the scenes in Venice are brilliant but it take takes careful planing and a multi-million dollar budget to achieve this standard, but this is no reason why anyone of you can't strive to achieve similar results.

n_iron

electron_theory · « **Reply #7 on:** March 10, 2010, 08:19:20 PM »

Quote

When you look at a game like Assassins Greed 2 the scenes in Venice are brilliant but it take takes careful planing and a multi-million dollar budget to achieve this standard, but this is no reason why anyone of you can't strive to achieve similar results.

are you saying that a GTA4 clone is possible??

singh · « **Reply #8 on:** March 30, 2010, 09:51:24 AM »

one more thing if you are using high poly models then add LOD(level of detail) system to it to increase frame rate gradually !

it will help you put high poly models in your game .

Mic · « **Reply #9 on:** March 31, 2010, 08:31:04 AM »

Quote from: Rush3Fan on March 10, 2010, 09:18:06 AM

I have been working on the car physics in my game, but not recently. I discovered that the wheel meshes were the only thing preventing me from merging 4 player cars with good framerate. That's 16 total skinmeshes with 100 polys each. But now it's probably only going to have two player because of all the stuff in the background controlling the game. But I think battle mode might be a bit simpler as far as the controlling scripts. I might be able to squeeze 4 player into battle mode.

Recently, I've been working on the second level in my game. I try to keep the texture size around 64 x 64 pixels. You ask why? There's about 150 of them and it really starts to add up. You'd be surprised how good a small texture looks when correctly tiled.

Something to add about the wheels. That is why I like to create my own car class. Such as in my off road truck game. I made the real wheel the place holder wheel found in the car folder. And that way I avoided 4 extra skin mesh links per car.

sven h · « **Reply #10 on:** October 24, 2010, 05:59:55 AM »

A tip:
In google sketchup (I don't know if it's possible on other design programs),
If you want to make an object (for example a cilinder) take less memory:

When you're making the 2d figure, in this example the circle, right click on the circle and select "entity info". Then there is a section "segments". If you fill a number lower than its current number of segments, and then pull the figure, the model will take less memory because the model has less faces.
This won't work on a 3d model, so do this before you're making the whole 3d model.

Alec · « **Reply #11 on:** October 24, 2010, 10:34:33 AM »

This is a very valuable thread. How's that I haven't noticed it

?

xat · « **Reply #12 on:** December 02, 2010, 10:41:44 AM »

Is it better to use a 1x1 pixel texture if it's just one color?

jestermon · « **Reply #13 on:** December 02, 2010, 02:41:40 PM »

Quote from: xat on December 02, 2010, 10:41:44 AM

Is it better to use a 1x1 pixel texture if it's just one color?

Not really, since textures are converted to power of 2 before are used by the GPU. The smallest power of 2 is a 2x2 resolution, so that's the smallest you should go.

maxigg1 · « **Reply #14 on:** March 13, 2011, 08:12:30 PM »

the scanner to shoot a large rigid body, it takes a long time to analyze it.

I think we could separate the rigid body into several parts, and thus reduce the analysis time for the scanner.
If you know of an easier way for script code, please let me know. thanks.

This forum is now archived!

News:

Author Topic: PERFORMANCE ISSUES - FRAMERATE SLOWDOWN (Read 6928 times)

psikotropico

shadmar

psikotropico

loop

Weapon121

Rush3Fan

n_iron

electron_theory

singh

Mic

sven h

Alec

xat

jestermon

maxigg1