Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

FPSC Classic Product Chat / Performance issues

Author
Message
Leander
17
Years of Service
User Offline
Joined: 20th Sep 2007
Location: Austria
Posted: 31st Oct 2007 01:42
Here are my collected questions on performance. Please help, I really need to know this.

1) I always thought that static lights with medium lightmapping (smart lighting) only took up ram in the editor. When the game has been built the lights don't have to be calculated because they are simply painted over textures in the building process.

I used smart static lighting without shaders, without dynamic lights in my arena game. One light per room. Sometimes two. The lag was terrible. WHY? Aren't lights just painted over textures and lighting should NOT take up much memory after the game has been built?

2) When I build a game with high textures and use a game launcher by (don't know his name) the settings can be changed. It is also possible to set textures' "divideby" to 4 in the setup.ini. The quality changes but not the FPS. The FPS are still the same. It doesn't run faster.

Is there a difference between a) building a game with high textures and turning it into low texture version by editing the ini AND b) building the game with low textures?

3) I read somewhere that a game needs longer to load if the ini is changed after the building process. Because textures have to be recalculated or something. Is this true?

4) Some corridors (vent duct) lag. Floors as overlays seem to lag. I could solve this only by adding a room below these corridors and overlays. In my arena game I had to add a total amount of - let's say - 30 room segments just to get rid of these lags. The segments are unused, not visible and take up loading time. But I couldn't find another solution.
What do the pros say?



coming soon...
uman
Retired Moderator
20
Years of Service
User Offline
Joined: 22nd Oct 2004
Location: UK
Posted: 31st Oct 2007 03:41 Edited at: 31st Oct 2007 03:47
I can only answer the questions as I see the answers in my case and experience. FPSC often tends to behave so widely differently across users systems and in the individual game levels they have. So these are general guidlines, brief overview or observations.

Game build time I have no concern for if there is a lot of high quality world content of any kind to accommodate during the process. - I can wait to build a game.exe it does not take very long and well worthwhile if the end result is good.

Textures I have large numbers of different textures and other content in my levels. They tend to be high quality throughout. Personally I have not noticed any significant difference at game run time using different settings nor any significant difference on impact during gameplay.

FPSC can handle large quantities of media of all kinds without any particular difficulty with the exception of characters as we know. However complexity and quality of content will add to the burden on the engine at run time as the engine struggles with all it has to do when characters or more preciseley their AI (FPSC can handle the Character models complexity fine) put the engine under stress.

The issue of the lag you refer to is well known of course but your particular reference is an interesting one as you have by your own ingenuity found the workaround for the particular causse in this instance. Well done. The workaround is documented in the past but not well known generally speaking. Some segments such as the ducts (which have flaws) you mention cause the serious lag issue to occur as you have encountered. The workaround as you have discovered is to completely enclose offending areas in further outer room segments enclosing the areas and sealing them of from leaks completely. This solution is not always ideal as one can not always do it if one can see the outer enclosing rooms so no use in outdoor areas of course. Sealing off the offending segments when effective actually reduces the number of polys the engine calculates in the build process and at run time and does not increase the number. It is the erronous segments and or build process calculations which cause FPSC to produce the massive poly count swings seen at run time which causes the serious lagg issue where it occurs in game. If suucessful then enclosing off offending areas in further segments reduces the polys and fixes the problem because FPSC does not calclate at all the polys of the outer enclosing rooms nor any unecessary splitting or mutiplication of polys (caused by the bad segments) when it divides the level up during the BSP compile process with the result that poly counts and polys to view at run time are reduced and the lag removed.

If a BSP compile process does its job well and efficiently then you can discount the number of segments you use in your levels. They will not have significant impact at run time as the engine should only draw the polys to view. FPSC can handle what you can throw at it when it does its job well, unfortunately the FPSC build process nor any other BSP engine is 100% consistent nor an exact science and FPSC does it sometimes very erratically, can see through walls and around corners and the end user has no control over it. The result can be vastly differing and erratic massive poly count swings in game view at run time as the seeing around corners and through walls serioiusly impact on the gameplay.

The two issues which cause major problems of Lagg. Characters AI routines and massive ploy count swings which cause FPSC serious lag issues both highlighted here are not user controlable. They are base engine or compile errors or inefficiencies call them what you like and beyond end user influence.

You have to live with them or work around them best you can.

Texture issues will have a relatively minor impact by comparison though in some engines size of textures used repeating over world objects do impact on poly counts during the compile process and thuse the polys to view at run time in that the process divides up world objects and spilts them into additional polys based upon the textures sizes and the nunber of reputitions. i.e. a set of polys for every repeat of the texture over a surface. I am not aware technically that FPSC does this though and viewing polys in wireframe view run time should confirm this. The FPSC tile system should ensure that you have one textures fit to one segment face and not split a segment into further polys at all.

Some entities and segments can some times generate a compile error during the build process which does not stop, when a ploy vertex or vertexes go astray and bounce around everywhere creating further polys in an endless fashion until the build process joins an offending stray vertex to a fixed point and the process ends and this results in very serious lagg at run time. If this happens and it can occasionally. I have had it happen with Default FPSC staircases cutting into walls. You can see the result in game if wireframe mode. It will sometimes cause the player to encounter invisible polys in game which you can not bypass. It will bring your game FPS to a standstill. It is a serious error and you have to remove it. Remove the entity or segment and try replacing or removing altogether and replace with another will usually fix the problem.



"There are those who said this day would never come - What have they to say Now?"
Leander
17
Years of Service
User Offline
Joined: 20th Sep 2007
Location: Austria
Posted: 31st Oct 2007 07:03
Uman You are the man. Thank you very much for your informative answer. It's 6am here and I have to go to bed but in short:

Your answer was helpful, I created many test games with different settings. Strangely, with smart lightmapping and high textures the game was just greyish with white boxes where the menu's tgas are. I had to reboot my PC. Then it worked.

I'll release a version with lights later. I'm content with the results so far. The only thing left I'd like to know: can the brightness keys be deactivated? The user can turn the lights up and down with "," and "." (German keyboard). I want to set the brightness by editing the setuplevel.fpi. The user should not be able to use the ligthing keys. How can I avoid this?

It's just not fair when a dark corner is meant to be dark and you should hardly be able to see things...but users turn the lights all the way up and see things clearly that I want to hide.



coming soon...

Login to post a reply

Server time is: 2024-11-27 04:58:38
Your offset time is: 2024-11-27 04:58:38