TOPIC: Serious RP FPS needs Optimizing

The brush-work in your ZARP Gaming server may get very complicated.
Nameful's friend has offered to help fix the gamemode bugs. Because EMP is having trouble looking at the issues within the lua compiler.

For every brush that isn't an entity, the compile process will try to determine what the player can or cannot see when he is looking at this brush.



This is okay for big walls, but you certainly don't need to have this done for every brush. Imagine you have a room with 300 small pebbles* ( all brushes ) spread accross the floor, four straight walls a floor and a roof. If you had to calculate what brushes can or can't be seen from any point in this room, you can be quick: all brushes can be seen at any time. The small pebbles won't cover any whole brushes, so we dont have to bother figuring out whether or not certain brushes don't need to be rendered because they are covered with the pebbles.



Go AI. Unfortunately, the compile programs don't have AI and will try to calculate what you can or cannot see using every single pebble in the room. Yes, that is way over 300 calculations where none are required! What a waste of time! What can we do against that? There must be a way to tell the compile programs what brushes to ignore?

* It is never a good idea to make 300 brush-based pebbles, but this is used as an example. Please do not try to make a room with 300 brush-based pebbles, unless you have a death wish.

Like I said, entities aren't used in the visibility determining process. I will explain why and how in the visleafs chapter. Putting 1 and 1 together we can conclude that by turning all our pebbles into entities, we can tell the compile program to ignore the pebbles! But this is a waste of memory: all options of those entities (inputs, outputs, movements etc) will be loaded into memory. Say we tie our pebbles to a func_door, then the pebbles will use the memory of a func_door. All pebbles will be able to move and act like a func_door. Since the pebbles will never be used as a func_door, this is a waste of memory. So, in essence, we need an entity that is ignored in the visibility determining process, but also doesn't have any special functions so it doesn't use extra memory ingame. This entity listens to the name of func_detail.

A func_detail can be made like any other brush-based entity, simply select a number of brushes and press "tie to entity". Func_detailed brushes act just like world brushes: They are solid, cast shadows etc. There is only a minor bug, which causes light to bounce around a func_detail because the func_detail doesn't break up the world brushes around it (this effect is called lightbleeding, as the light is 'bleeding' around the brushes. Suffice to say that if you didn't understand that, don't worry about it. You will only see it when you make a large brush ( eg wall or floor ) func_detail which blocks light/casts shadows.

Lightbleeding is caused by func_details not breaking up world brushes around them. Because of the way the lighting is calculated, light is able to cross the light-blocking func_detail by travelling along the lightmaps of the world brushes around it. If a func_detail is between a very dark and a very light room, then the func_detail on the side of the dark room will appear dark ( as it should ) but with a light edge around it due to the lightbleeding. You can stop this by increasing the thickness of the func_detail, or by turning it back to a normal world brush.

It's handy to use the func_detail as default brush-based entity in the editor's options. It doesn't matter if you tie 1000 brushes to 1 func_detail or 1000 func_details, but usually it's easiest to group certain brushes into a single func_detail ( eg group all brushes making up a window into one func_detail ). It only makes editing easier, it doesn't matter ingame. You will probably do this automatically once you use get to use func_detail extensively. Because you will be using it a LOT. Or atleast you should be. Learn all about the main uses of this magical entity below.

User was banned for this post: EMP(Constant forum Trolling)

Can someone finally ban this clown?

Nameful wrote:
Nameful can you send EMP your FPP optimization tool, because Falco doesn't have much coding experience.

Nameful wrote: I think thats the first time we've agreed on somthing.

Why did Santa do to get banned?


EDIT:

Oh

Post graph.

OK GUISE. OFFICIAL NEWS HERE m8.