Harry Harrison,
Firstly may I say that there are a number of issues involved here which you are almost certainly aware of.
Number 1.
These issues are related to flaws in the engine itself and so are liable to split mainly into two distinct categories either found to be constant across the board or or an eraratic nature. Furthermore they are open to become intermixed and have influence in certain areas of a map agrivating the problems in specific areas.
They are subject and influenced somewhat by the normal rules of sensible design for BSP type engines - though today many such engines have improved somewhat and some achieve much faster fps than this one in comparable siutuations.
I detail what I know to be the case from "My" understanding of problems the engine has having gone through the stage of using FPSC since early EA, Beta Testing V1 and having followed its development through these, information I have seen or read and these issues relating to fps in FPSC when Beta Testing and reporting my findings and difficulties to the TGC team - usually in communication with Lee though not exclucively as much was just directly posted in the Beta Testers Forum when it was active.
Of course we cannot adjudge our correctness in relation to accessing anything as we a not in a position to understand how the engine is actually supposed to work by design and calculate anything which affects fps as only the developrs of the program can say that and confirm exactly how it should work and where if anywhere there are erronous results returned by the engine. That information is sparse and not exactly detailed or commented upon to users in general.
So what I know that is apparently not disputed :
FPSC currently renders polygons it should not and does not cull them as it should even regarding standard BSP compiling. We know this as we can prove this in testing by standing facing a wall directly close to it with little in view and get in areas limited to as little a single tile massively incorrect poly readings and resultant low fps which will fluctuate back to normal sensible figures as we move around even sometinmes at the next tile when in some instances doing so will put much more visually in the camera view. There are instances when you can get high fps and simply adding another couple of segments in a "specific" location can cause a halving of fps suddenly - remove them and fps jumps back up. Thats incorrect somehwere along the line.
Now that all relates to segments and world geometry and how FPSC and the compiler calculates the BPS in splitting up the level when it does the compile deciding what it sees in any particular view and what it dont. Apparently it calculates this in the case of FPSC in a way which is not logical to the user as made clear by what we see in camera view and what FPSC sees in gameplay in the those areas as mentioned of highly fluctuating poly counts and the resultant massive lagg and fall in fps in specific areas.
Now thats somewhat further complicated from the user point of view in the case of FPSC as we are allowed to place entities of many kinds including used as walls placed as static entities to be seen as part of world geometry or so its described. Being part of world geometry they should in effect become part of the solid world environment in the BSP process during compile and behave as such in game play blocking the view and so on as would any normal world object level geometry - the question is do they actually do so - we dont even know if placed segments behave correctly in this way. It seems perhaps not as proven by our examples either some gemoetry is seen as invisible to the engine and does not block the view in calculations of polys or the engine can see and calculate along routes around corners and alike - leaks if you like.
Personally I am not in posession of the knowledge or information of what the compiler does when calculating a levels ploy counts, or what FPSC engine can see and what it cant. How can anyone except perhaps TGC understand that and I doubt they do either.
During development Lee as I understand it spent much time on tracking down a bug which causes this serious Lagg issue and as far as I am aware it was never isolated or corrected because the exact reasons eluded him and time ran out.
The issues of fps and slowdowns are apparently also liked with agresssive calls on the engine from dynamic entities needing to share allocated engine calculation times, which brings us to
Number 2.
All dynamic entities have brains and require a great deal of math and involves the engine in a great deal of calculations. These calculations have to be made in real time and that is limited - it has to be shared amongst all those entities that need to make calls to the engine. Needless to say the more dynamic entities you have the more maths the engine needs to struggle to compute at one time.
In essence the FPSC engine design is slow to handle these calculations. Dynamic Enemy entities are the biggest drain on these resources as they have many calls to make on time during the thinking process required by the AI descision making process. This is a factor which is well known in AI routines in many engines. Advanced AI requires power.
In the case of FPSC thinking time for Dymnamic Enemy entities became problematical for Lee as they were one cause of rather high rates of drop off in fps. At one stage it was suggested that they might be the cause of serious areas of Lagg and that may also be a contibutory factor and would be in areas of high concentrations of Enemies (isrrespective of other dynamic entity numbers) as they require a great deal of Thinking Time - though serious Lagg spots can be apparent when there are just one or two enemies in a whole level and this is a secondary issue to world gemoetry issues and a separate contributory cause of lagg as far as I can ascertain.
The issue of thinking time and slowdown of fps caused by these Thinking Enemy entities was given much priority by Lee in developing FPSC - though in essence the engine is limited in its a capability for handling the calculations required and balancing out the sharing of the burden of the math for the engine is somewhat self defeating. There is just not enough to go around - the thinking time requirements of the Dynamic Enemies are just too great a burden for the engine to handle efficiently and Lee even rather unrealistically suggested at one point he should make the enemies "Stupid" to speed up the gameplay. I dont know if that was supposed to be a joke - I guess so.
At the end of the day V1 had to be released and the Dynamic Enemies thinking time problem had to be addressed by Lee the best it could and that was indeed done even though it still remains an issue speeds have improved over the early stages of EA.
Theres still work that needs to be done for the future of FPSC.
I am sure some will disagree with those statements and I point out thats just as how I understand the issues. Incorrectly perhaps.
Now this all dont help you much as it dont fix any of the issues and there is no way for a user to overcome them - just work within the limits and try and work around the problems - they are not going to go away. Only TGC can fix the issues if they so do in any future release.
So what can you do. Firstly FPSC needs a good system to run it on or you will have speed issues anyway. - Given thats out of the way.
Harry,
I know nothing about your levels so its difficult to offer anything other than general advice.
I can say that all of my levels are large - large as the world size will allow i.e. 40 x 40 x whatever and in the horizontal I would take up as much of the level space as is possible, plus as much height as the design requires.
I would say that in general its a well known issue wih some engines that the centre of the world can have a big influence. i.e. the further away from centre the greater the chance of slowdowns - the perimiter extremities are the worst offending areas which is where I find most problems occur. If you are not using the whole of the world area dont start your level in the top corner as the editor wants you too when starting an empty level start in the middle and work outwards. I think that might help unless TGC can say different - dont expect a comment.
If static entities are supposed to be compiled as part of world geometry I dont see why they should be a heavy drain unless again its an erronous issue with compile. Perhaps the engine can see through them giving you high poly counts - this could account for the problem I guess.
If you have a rail track of high poly count models or other such high poly count models used then try and reduce them. When I made my tube train level in Game Studio A6 I usued high poly rail tracks they even had the nuts and bolts on them. Why do you think I changed it to a simple monorail track in FPSC? Polys.
I had not understood the engine to load Dynamic entities only when the player gets within range of their location, but that the engine loads all content at level run time but switches off the entities activity "those brains or thinking time" and only activates them thereafter on player proximity. That is a solution installed by Lee to partly overcome the thinking time. I may be wrong of course and probalbly am.
Ideally we might be able to get and heres for anyone that wants to take it on board and experiment - entities to Spawn on player promimity or sight and remove themselves when the reverse - then respwan again when the player comes back - effectively load and unload dynamic entities in real time - That probably cant be done and might not make any difference anyway. So may be a waste of time.
Comment TGC - ahh no.
To be honest I dont know aboout 100 dynamic entities in view and active at any one time - not enemies were they. Thas just asking too much of FPSC.
You may well be correct in your findings as although I have a lot of entities in general I tend to space them out as much as possible or at least distribute them evenly and they tend to be a mix of static and dynamic.
Whichever way we look at it we have those poly counts and thinking time to consider - if the engine is not doing its part in minimising those polys and handling the maths then we are on a hiding to nothing.
You can go around in circles changing your level design and the problems just crop up elsewhere just the same. Its happened to me in outdoor areas especially where you cant seal the leaks. Fix lagg here it crops up somewhere else - it just moves around erratically - game builders cant handle erratic - its not logical and makes no sense.
Dont go by the manual regarding static and dynamic entities except for in the case of enemies which are a special case due to their thinking requirement - use dynamic or static - whichever you find the best as long as you can maintain collison where necessary.
Thats not all I can think of but Im worn out so perhaps another time.
I am attaching a screen shot of the first level of my game - not sure how much you can glean from it though you can get an overall idea of the level area. Some rooms are 6 or 7 levels (tiles) high - other sit one above the other so you cant see all heights here of course. The level now takes ages to load in editor and needless to say testing is a long process. Still I probably have much yet to add including wall/room segmets additional texture count and many perhaps hundreds of additional entities - and lighting of course.
I am not sure how FPSC can handle that but may well be asking you for advice later.
If you look at the screen shot you will see the right hand side of the level is a little short on content - and yes you guessed correctly - that area had problems with serious lagg so I was forced to buid in other directions.
Hope that helps a liitle.
