Im runing a scene with 51K vertecies and out of that 3 characters ( enemies ) with 2k vertacies each , It runs on about 10 fps on my q6600 gtx480 8gb ram . and this only the begining of first level of teh game, not even a half of it, the enemies shot their fireballs it runs on about 3-5 fps .
I cant realy make a good graphic game like that, i realy rather not to move to unity for the game making, is there any solution for this ?
Thanks in advanced .
Btw this is my project with 1 enemie :
Is it possible that there’s a buggy script causing it somewhere?
I dont have any errors in the console .
Check for any sensors triggering too often.
Check if you really need that much vertices for a simple level like that. You haven’t added that much poly detail to the level compared to the original and you have ~51 000 where the original probably had under 200.
Post a wireframe image and a screenshot displaying the framerate so we can see what is kiling it.
You also mentioned somewhere you are using lots of spotlight, maybe too much.
It works good as long as im not adding more than one enemy, This are the enmy details :
Script :
import bge
def main():
—cont = bge.logic.getCurrentController()
—own = cont.owner
—scene = bge.logic.getCurrentScene()
—sphere = scene.objectsInactive[‘Sphere’]
—fireBallEmitter = scene.objects[‘FireBallEmitter’]
—imp = scene.objects[‘Imp’]
—loop = bge.logic.KX_ACTION_MODE_LOOP
—sensorInactive = bge.logic.KX_SENSOR_INACTIVE
—firstTimeOnRadar = cont.sensors[‘FirstTimeOnRadar’]
—checkNoSteering = cont.sensors[‘CheckNoSteering’]
—radios = cont.sensors[‘Radios’]
—near = cont.sensors[‘Near’]
—radar = cont.sensors[‘Radar’]
—stuck = cont.sensors[‘Stuck’]
—fireWhileStandingSensor = cont.sensors[‘FireWhileStanding’]
—stuckRight = cont.sensors[‘StuckRight’]
—steering = cont.actuators[‘Steering’]
—stopFire = cont.actuators[‘StopFire’]
—fireWhileStanding = cont.actuators[‘FireWhileStanding’]
—attackNear = cont.actuators[‘AttackNear’]
—attackFar = cont.actuators[‘AttackFar’]
—sight = cont.actuators[‘Sight’]
—player = scene.objects[‘DynamPlayer’]
—bumpRight = cont.sensors[‘BumpRight’]
—bumpLeft = cont.sensors[‘BumpLeft’]
—if own[‘Counter1’] == 10 :
own[‘Counter1’] = 0
—if own[‘FireCounter’] != 0 :
own[‘FireCounter’] -= 1
—if bumpLeft.positive :
own.applyForce((100,0,0), True)
imp.playAction(‘WalkCycle’,1,23,0,1,10)
—if bumpRight.positive :
own.applyForce((-100,0,0), True)
imp.playAction(‘WalkCycle’,1,23,0,1,10)
—if firstTimeOnRadar.positive :
imp.playAction(‘WalkCycle’,1,23,0,1,10)
steering.target = player
impAction = imp.getActionFrame()
impAction = int(impAction)
cont.activate(sight)
if own['FireCounter'] == 0 and radar.positive and fireWhileStandingSensor.positive :
cont.activate(stopFire)
scene.addObject(sphere, fireBallEmitter, 100)
if fireWhileStandingSensor.positive and radar.positive :
cont.activate(attackFar)
imp.playAction('HitAndFire',1,25,0,0,3)
cont.activate(steering)
cont.deactivate(steering)
------if impAction == 0 :
own.restoreDynamics()
------elif impAction == 25:
own.restoreDynamics()
cont.activate(steering)
cont.activate(stopFire)
imp.playAction(‘WalkCycle’,1,23,0,1,10,loop)
------if stuckRight.positive and own[‘Counter1’] == 0 and radar.positive :
own.applyMovement((0,0,0.5), False)
print(“Right”)
------elif stuckRight.positive :
own.applyMovement((0,0,2), False)
print(“RightAgain”)
------if stuck.positive :
own.applyMovement((0,0,1.5), True)
print(“Left”)
------if radios.positive:
---------if own[‘Counter2’] == 300 and radar.positive :
own[‘Counter2’] = 0
cont.deactivate(steering)
cont.activate(fireWhileStanding)
own.suspendDynamics()
own[‘FireCounter’] = 26
---------elif radar.positive and own[‘FireCounter’] == 0:
cont.activate(steering)
cont.activate(stopFire)
own.restoreDynamics()
imp.playAction(‘WalkCycle’,1,23,0,1,10,loop)
---------elif near.positive :
cont.activate(steering)
cont.activate(stopFire)
own.restoreDynamics()
---------own[‘Counter2’] += 1
------if near.positive and radar.positive :
cont.deactivate(steering)
cont.activate(stopFire)
own.suspendDynamics()
cont.activate(attackNear)
imp.playAction(‘HitAndFire’,1,25,0,0,3,)
------own[‘Counter1’] += 1
Logic bricks :
Rather than just taking guesses, use the framerate and profiler to see where the weak parts of the game are (logic, rasterizer, animations, etc). If the Rasterizer is where most of the FPS is being lost, try joining pieces of your map together. If your game is a ‘corridor’ game, then you could just get the rooms that are on-screen / you’re in and render them (either with Python, or using an Occluder). By default, the BGE renders everything that’s on-screen, which is a waste if you can’t see most of it.
It looks like you’ve got a LOT of lights with shadows in that scene. Cut down on the number of lights, and try to have only one or two shadow lights. You can make an overhead directional light set to “shadow only”, if you wish(and parent it to your player, so it will follow them around). Also, watch your batch count. Each object in the Game Engine is a batch, and each material used within that object is another batch. Keep it down low, if possible. The fireballs are affecting your performance a lot? How are your fireballs set up? If they involve several lights, or too many particle objects, that might be a problem. Also, check the framerate and profiler to see wheat’s taking the most time. I would guess it’s the rasterizer, but it could be logic or animation. If animation is the bottleneck, try simplifying your rigs by reducing the number of bones and keyframes.
First off, as SolarLune said, you need to profile your game. It’s useless (and quite the waste of time) to just sit and guess all day. If you want to know more about what the various profile stats mean, take a look at this.
This isn’t accurate. By default, the BGE makes use of view frustum culling. So any objects outside of the view frustum (the camera bounds) are not drawn. However, if you have one single object for most of your level terrain, the whole thing will always be drawn since some part of the object is always in the view frustum. This means it helps to break up really large objects.
Now, as a guess to your performance issues, I’m going to guess that you’re spending a lot of time in physics. Near and Radar sensors are not that cheap, and you’ve got five per enemy.
Indeed ,you are having lots of radar and near ,the radar is a killer ,and expensive sensor…
Maybe I’m mistaken, but I think I said just what you said (but not as detailed) - that whatever has a bounding box that’s on-screen (and so can be seen by the camera) will be rendered…? If the object is off-screen, then the BGE will make use of frustum culling, yes. And yeah, if you have one single object for your gigantic terrain, it will be rendered, but not unless some part of it (or it’s bounding box) is on-screen…? Again, maybe I’m mistaken.
EDIT: Bah, never mind.
@Sahkan - Follow Moguri’s link to learn more about the profiler - it’s really important to game development.
You’re right except you keep stating that if something is on screen it won’t render. Basically, frustrum culling (As I suspect you’re aware, but I’ll restate anyway) checks the objects AABB from Bullet against the camera frustum. If it is not inside or intersecting with the frustum it culls is.
Ah, sorry, I misread what you said. I was thinking “scene” instead of “screen.”
Huh? I said clearly in my post “whatever has a bounding box that’s on-screen (and so can be seen by the camera) will be rendered”.
EDIT: @Moguri - No problem.
I meant in reference to post #6! 
At least we’re clarified
Guys… so much talk around the same.
Anyway, thanks for the help… best way to get more fps is to have the map/ground/levelmap in separated meshes anytime we think apropriate.
(and i was thinking in using python to put objs near the player and remove them as the player goes into a certain distance - some kind of weak LOD…)
I was gunna suggest. Are your models Poly based or Triangle based?
Triangles are rendered more efficiently in realtime.
Lighting especially shadows and specularity are a major killer. Check your numbers if not create a simple LOD lighting solution or use lightmaps in areas where its not needed.
Are you using the most efficient texture formats/sizes?
CTBM
Maybe its better to study a good “How to improve fps in bge for dummies” book.
Or maybe someone has already writed it somewhere.
Near and radar sensors are the biggest FPS killers I’ve ever seen. Two or three of them on my PC drops the frame-rate by 5-10FPS.
Lights is the other biggy.
Finally there is poor script design.
Hum… never thougth of that…
Thanks for the info!
Decimate ! anything high poly is a scene killer,
break everything into pieces,
look into LOD
Large objects = hard to lod
small chunks can be ->(far far away)=0 faces model “dummy” (closer-medium) zoom in/very close (high poly)
a building made with “I-beams” and “wall face sections” is easy to design to be destructible, as well as LOD etc
