Sorry your browser is not supported!

Hey

Ive made my .exe version of my game well its the BETA of the game... but everyone whoplays it, including myself, walks 3 steps and then it will freeze for a second, and then another 3 steps and it will do the same again over and over... and its not worth playing when it takes your 5 mins to talk down the corridor :S

Can you tell me why this is happening and how i can solve it

There are many answers to this one given on the forums. I suggest reading some of the posts that have similair topics as yours.

FPSC can produce good games, if you follow some simple guidelines.

1. Keep it small. Don't use huge rooms, don't huge large opne spaces, don't use long corridors. The more the player can see, the slower your game will run. Play some of the example games that others make and check out some of the examples included with FPSC, it will give you a good idea how to create levels.
2. Don't stuff your rooms with lots of items, keep it to a minimum.
3. Don't put more then 3 enemies in one room, perhaps even less.
4. Test, test, test, test. Before even giving out a game, test it. Get to know the engine, learn it's weaknesses and strengths. Don't just create what you want, but create what works. when you test keep your eye on the framerate. Try to accomplish between 22-32, don't go lower.

For more hints, search the forums.

I will have to disagree with Ben A here about the stability of the engine being primarly due to dynamic objects within the infrastructure of the particular location of the player cam.
lol.

Either way, I believe that there are several primary points of lag in FPSC, and that the Dynamic Objects affect it the least.

First, I associate the single FPI condition "plrcanbeseen" to generate the highest amount of lag possible. Unlike what Ben A is indicating (or how I interpret it) separating enemies via rooms will not reduce the lag generated by this condition. To do so, you must edit the Enemy FPI script you are using to ONLY activate the enemy if the enemy is within the room, use of a zone will accompish this easily, although the diversity of avaliable AI scripts prohibits me from giving a simple fix that you can apply to any and all scripts.

Second, room construction and transition can rapidly bring FPS to a halt. All dynamic objects do not block forward rendering, this means that if there is a door that leads to a larger room, you will render both the small and the larger room. Similarly, if your doors go in a singular direction, you will render all rooms simutiniously. Use of windows acts similar to doors, with the exception of the degree of render. Windows can cause an entire level to render (because it is possible to see the entire level through a window) so be careful in their placement.

Third, Continual Physics Reactions. This means that you have a dynamic object that will continually undergo physical forces (like enemys and doors, but further more if you have a such a system setup [spawn a ball it bounces and despawn it, repeat]).

Fourth, Segment curroption. Now this WILL drop your FPS lower then any of the above methods, but the occurance is highly scarce. Basically, a segment in the level has some 'fault' that causes it to render wrong, this, in turn, degrates the FPS rapidly, and in somecases causes the game to stop all together. Removing and replacing the faulty segment repares this minor obstruction.

Fifth, Physics Chain Reaction. Once again, a massive FPS drop, but is specific to event. Basically, if you pile a bunch of physics objects together and set off an explosion it will freeze the game for several seconds.

Sixth, Lifts. This is a tribute to Uman for pointing it out, lifts will cause massive FPS loss, but the cercimstances are unclear. Once again, highly situational so is listed as a last note.

Six and a Half, Level Design. This is HIGHLY situational, the FPSC engine WILL cause lag all over your levels for indescript reasons, and unless you want crap levels (meaning a level that is bland and unapealing) you will NOT follow Ben A's advice to make 3x3 rooms (okay, 4x4) go big, but manage well. Remember that the more that connects to a 'main' room the more that is potentially rendered. And if you can't break the FPS lag, split the level up. But do NOT make a dull game just because the engine hiccups now and then, work AROUND it not with it.

Continued... Some hints in that regard is to make use of the teleporters (you can have any object teleport the player, but that isn't covered here) and separate the level sections. Either by distance on the plane you were on, or by incrimenting the plane number by 2 or more. Adding hallways between rooms ALSO helps reduce lag, as does pointing windows into blank landscape. Going 2 floors down [not by teleporter] increases to general sense of 'size' in a level and reduces the overall lag (as opposed to keeping the entire level on a single floor/plane).

Seven, abuse of dynamic objects. Only if you severly abuse dynamic objects with massive scripts and mutiple animations with 'allways active' on will you have lag because of it. Don't believe me? Put over 100 similar (when NOT abusing dynamic objects, you have 'groups' of things that will be dynamic) objects, perhaps 10 groups with physics on. On my 1.8GHZ laptop I didn't feel the horrible lag often discribed. Although, I don't run over 200 background processes. Add in Dynamic Lights here. They will cause a set amount of lag, but it isn't entirely 'bad' lag... until you have too many in a given location.

I was waiting for you to contradict me

I really do hope people will follow your advice, we all know they get stuck pretty soon. I love it when people who never did anything substancial with FPSC advice us how to use. Please do follow Merranvo's room and window advice and you can throw away yet another level.

Please follow Ben A's advice and get a level that is horrible in comparison to Doom I.

"I love it when people who never did anything substancial with FPSC" (Ben A, Post 4) act like their game is something substantial and parade around delivering inappropriate condescending comments.

Ahh, don't even care that much about you anyways. I care more about you giving horrible advice to these gullible children.

@Merranvo,

Please forgive my lack of understanding. Although I don't experience too much lag, as I increase the size of my levels I'm sure it will become more important. Perhaps you can explain something to me.

What would be the primary difference (in lag) between the engine checking "plrcanbeseen" vs the engine checking for the player in the zone.



I'm assuming you meant "if the player is within the room", since an inactive entity cannot enter a zone.

The rest makes sense. Thank you.

I use to post the code to the 'plrcanbeseen' to show the complexity of it... but that is kind of old.

Use of a zone IS better then distwithin, which will 'activate' the enemy on that time (even better if you simply 'spawn' the enemy). The problem with Player Can be Seen is that constantly running it calculates if there is an object blocking the view (and if it is a window to 'break' it), then it calculates if the player is hidden by the darkness of the light. The number of calculations is what slows down many games, and because most AI's aren't set to turn off after a certain distance, ALL enemys are constantly asking if they can see the player, even if it isn't reasonable for them to see it.

The problem is that Plrcanbeseen is needed to make the 'ai' work well. I guess that you could 'remove it' and have the AI act on other senses (unfortunatly, we don't have a "plrshotdammage") (or a "facingplr"). So, in the end run, you would have the AI fireing at the player without knowing if it is actually hitting it. (Of course you could do cheap ass AI and have the enemy auto target the player)

note: plringunsights runs processes similar to plrcanbeseen.

Thanks Merranvo,

That actually makes sense.

Best.

Sounds like a plan Merranvo... use zones to spawn them rather than drop them in the level and let them "hang out" there while you run around the level. Ok I am sold. I'm going to try it tonight.

By the way, I edited the setup.ini to run it at 800 x 600 at 32 bit and it looks...ummm...blurry. I thought reducing resolution might speed up the game a bit more but it's like looking underwater all the time at lower resolution; my eyes my eyes!!!

It might also be worth pointing out that triggerzones can also cause serious lag.

Fred is absolutely correct. Adding to many triggerzones to spawn enemies will cause a serious lag. In essence, triggerzones do the same as the Plrcanbeseen script command does. Triggerzones are constantly checking if the player is already near them.

The combination is the best, use enemies that are there from the start and use spawn zones. For me this always gives the best results.

Ok good thing I read this. I was placing trigger zones last night. Didn't notice any lag though but better to play it safe and follow your advice.

thank you.

Exactly how do you do that,Ben?
Is that using triggerzones or do you have some other way of doing it?

I have just a few comments on Lagg Issues I could make in detail but I wont as everyone has to work out how to get around the problem which is very much personal to the individual and their own game levels.

In general though I dont have any large large levels in my opinion as they are all only 40 x 40 tiles the max world size of FPSC and I dont acredit levels of that size as being described as large.

They can be complex though depending upon what level of content you include and how complex everything that elments do are likely to be.

FPSC as a general rule it seems to me can handle almost anything that can be thrown at it - levels of almost any size and complexity within reason of common sense and necessity to achieve a good game content. Problems with lagg have been aparent for many reasons known and supposed. Many of the causes can be acredited to faults in game level building or content or media or erronous scripts which will kill fps very quickly. So to will errors at run time caused by physical holdups of entities - characters for instance that get stuck on a path or cant get through a doorway due to reasons of physics or simply not being able to negociate a free path - these will cause serious affects on fps when the player may not even be in proximity as the engine is held up with an entity trying to carry out a procedure that it cannot fulfil and thus the engine spirals in a never ending circle of math. You can see this to be the case if you can cause it to happen purposefully.

Those are all things which are basically errors which reflect not the normal efficiency of the engine which if they did not exist would perform adaequately. However until recently there were many opportunities for users through such level errors to sustain lagg isuues in almost any level where the likelyhood of one or other of many possible cause screeping in to a level were very high. The chances of escaping a lagg causing fault being very low so a high proportion of users would find it happening.

True to say perhaps the greater the content and larger the level size the more chance of errors creeping in but in my opinion it has nothing to do with the volume of content itself - just that the chances of lagg causeing errors creeping in are greatly increased the large and nore complex the level. So great care is required to ensure levels are well constructed, though out and that all media is credible and error free.

I have always had maximum world size levels and high volumes of every kind of detail content you can think of and not actually had unplayable fps speeds.

With the release of V1.04RC2 the unacceptably slow fps speed should be a thing of the past. Lee has made some serious improvements in engine efficiency. Cant say about anyone else but I am seeing constant max fps throughout levels and they dont get any larger than max world size that I utilise. I build right out to the last extreme tile of the level and have none spare. I also cram them full of any content I choose to throw at it no matter how complex I simply disregard any complexity issues and FPSC does not complain about it and maintains 30-32 fps throughout.

The only exception to this is in outdoor levels where the serious lagg issue occurs. This issue I have said many times and it is accepted as far as I know by TGC is a separate issue from the general overall fps speeds returned by FPSC and occurs usually only in small specific restricted areas. Lee knows and I presume everyone else now understands what causes it. Its not anything the end user can do anything about except try and rebuild levels to work it out. Often it just moves somewhere else if you try to do that as this is decided at compile inside the process when FPSC allocates the poly counts to view in various locations or something along those lines so its trial and error there. It does not relate to what the camera sees from any view but what the engine sees and it sees what it should not very often.

If you are afriad of it well stick to small levels but its no guarantee it wont crop up even then. Go for it is what I would say - until you try you will never know so I will stick to my large levels and optimise everything needed if necessary. Its not something you can do in a day or even a week - its a long job.

There are numerous well made suggestions here in this thread and many of the suggestions may well be trues causes of slowdowns in fps for those users who encounter them but perhaps not for all - everyone know how FPSC behaves so differently on different users systems. You can follow general rules and guidlines but at the end of the day its down to each inmdividual to beat the problems that they have crop up in each individual case by working hard at it.

It should be much easier now than it was for users previously using earlier versions.

If you have probs with speed then you simply need to isolate what causes it and remove the cause - removing construction to make levels smaller is not the answer as its not inherently the cause. Look for anything but that. As has been said there can be many other reasons for bad or inefficient fps speeds being returned by the engine - best get rid of them first before smashing you levels to bits for if you dont they will still exist.

Some here have pointed effectively to what amounts to leaks in a level and FPSC will sometimes render high levels of polys often far away from player proximity at the other side of a level when you would not expect it to and that can be avoided - not necessarily by removing content at all - there are other efficient ways to do it. In areas of high lagg look in wireframe mode to see where many distant world objects may be being rendered unecessarily and take steps to remove them - by your own ingenuity not buy physically reomoving the content. Enough said you can work out how to do it yourself. Ive said often enough.

TGC may never get around to removing the Serious Lagg Issue so if you want large complex levels you can have them now but you have to put in a lot of effort to do what TGC cant give you and that is remove polys and where necessay engine math procedures by optimising levels and taking those out of the equation unless absolutely necessary and when required. i.e. If you cant see it you dont need it -(until you need to see it). Youve heard of LOD - well you aint got it so you need to find ways of achieving the same end result. You have an inefficient compile rendering system whereby you have erratic and sometimes massive unecessary poly counts so you need to find a way to reduce it. Combine those with good design practice and theres no reason why you should not be able to to have levels as large and complex as you would need. By and large I discount true entities completely as they seem to have little or no bearing on fps speeds. Theres no reason why you should nt be able to have enough to produce a complex and very detailed environment. As someone mentioned I dont use lifts anymore but made up my own workaround for them as they were flawed and returned seriously low fps in complex levels - in essence the more complex the level the slower they bcome eventually grinding to a halt. Not sure if thats been fixed but I doubt it and I like the workaround anyway so I stick with it. Trigger zones I have loads of them and dont see they have any affect on fps at all - of course some of the default scripts for zones that come with FPSC dont work very well with some kinds of entities so they could be a cause of slowdowns as being a case of erronous scripts as mentioned - I use my own when that is the case as with my spawning of entities on the fly - the default ones just did not work corrctly and thats a bad sign. You should be able to tell when a script works well with any entity if the entity behaves well or erratically. Badly behaved entities and characters are a sign of engine inefficiencies in regard to that entity - change them (the scripts) or get rid of them.

I exclude the Serious Lagg Issue from that as I cannot say that it can be conclusively laid to rest in very large complex levels particularly outdoor levels, as much more work needs to be done to find an end user solution if there is one. By and large users tend to just live with it and not try to find a workable solution - it would take some serious thinking and effort and I am not sure it can be overcome. Personally I dont have the time at the moment but will look for a best option scenario to find a solution eventually if TGC dont come up with anything.

Yes I noticed that entities really do not affect the fps. I've thrown TONS of entities in my level and the fps remained stable.One thing I did notice in my levels are the long corridors. Not very smart designing on my part. It killed my fps. I agree, it's all about smart designs. One technique I came up with is getting rid of unnecessary corners or spaces when creating real-world enviroments e.g inside an office or a hospital. I mean go into a real-life office/room and it's basically a room with four walls, a low ceiling, and a door. Office building floor plans when viewed from above is basically a square shaped design and right in the center are the elevators. Really simple. So yes it's all about smart and efficient design methods.

Ok I am running my mouth here already. Sorry.

Okay, uman, I am going to have to revoke your mod licence. Scaring the little ones with those long winded speeches.

Ben A, please try to understand the severity of Plrcanbeseen.

PlayerDistWithin is auto calculated... but it is spherical, crossing many planes (so if the player is below the entity it may still be 'distwithin' {unless I am mistaken})

TriggerZones are basically cubes, and calculating if an entity is near a cube is a simple calculation. Basically just range calculations.

Of course, like any dynamic object, triggerzones have a script that has to be executed... and eventually it will take it's toll... Back at the 100 Dynamic Objects... the 'scores' were (apox...)

32 (uncapped) viewing the objects (dynamic).
44 (uncapped) viewing the objects (static).

I know that dynamics will persist through the level... but that is 100 dynamics and you still haven't fallen in the 25 FPS range. Basically, my point was that dynamic objects, when not abused, don't hurt FPS all that much. (Unfortunatly, I did not test with physics off... so whatever physics adds also is included [I put like 10 of 10 different boxes in... and coverting it to static was bad enough (there WAS a minor difference between MP and SP [as I recall])]

Just use triggerzones indeed.

I have been playing around with Airslide's using a camera to spawn entites script.
With some adjustments you can use any dynamic entity to spawn enemies and it seems to work better than using a triggerzone.
But you did a good job in your contest entry of using triggerzones.

Thanks

Didn't try Airslides camera script yet, perhaps I will someday. I've been using his AI script and that is very impressive. The one I did write for Commander Josh works great, but his works even better. I'm very sure I'm going to use it for the next Commander Josh, so perhaps I'll get around testing the camera spawn script also.