@mrzeon: That’s a nice looking environment you have there.
As said above, the rasterizer is what’s outputting the image to the screen.
Your scene specification should run ok, not sure what the problem is. You could try some of these things…
Some causes of high rasterizer usage:
Extensive shader usage
High poly count
High object count
Are those shadows being calculated reltime using spot lights? Realtime shadows are very intensive and should be used sparingly. If a light source never moves then you can bake it’s shadows to a texture and apply the texture. This saves a lot of processing.
The cactus and sign in the left image in your post look very good, but appear to be very smooth. How many polys (triangle) are in your scene? If you aren’t already then you should try to minimise the number of polys. One option is to retopo your complex objects to a basic shape and then bake normals from the more complex shape to simulate smoothing/detail. Baking ambient occlusion will simulate self shadowing.
Blender has effective view frustrum culling to cull faces out of view, but even objects/faces that are occluded behind other geometry in the view are handled by the rasterizer. ie. They are behind other objects but are still rendered, then rendered over by foreground objects. Occlusion culling using invisible simple occlusion meshes hidden inside other meshes will tell the rasterizer not to render any object that is behind them.
Possibly not rasterizer related, but the flag that you have could be affecting performance if it’s a soft body. If it’s not going to be affected by dynamic objects brushing past it then you can simulate movement by using shape keys.
As far as I can understand it, “Generate display lists” is used to speed up rendering of many instances of the same object. If most of the objects in your scene are unique then this will probably have little effect.
This is a far from exhaustive list of optimizations, but might shed a little light on the possibilities available to you.
I might be wrong about this, but from my tests, I believe it to be at least partially true.
To clarify about the high object count… this used to be a real problem in BGE, but is much reduced by recent optimizations of the scene graph. Many objects will slow down your game/walkthrough, but if you have large high-poly objects that are rarely in complete view then you should experience an increase in frame rate by breaking them up. This enables the view frustrum culling to cull the sections of the large object that are outside the view. If the large object is completely in view then face culling will avoid rendering of the faces that are out of view, but view frustrum culling works better on whole objects. If the large object is broken up then view frustrum culling should be more efficient.
Thinking a little more, I’d say that 55% rasterizer usage was pretty low for a game with hardly any logic/physics. What is your physics/logic usage? You should certainly turn off collision for everything that the player won’t come into contact with. eg. Those posts, tables, chairs and the cactus outside should have collision boxes so the complex meshes aren’t being used. The sign, tops of arches, upper floor of the building, wall ornaments, behind the bar, etc. will never be hit.