Difference between revisions of "Performance Problems"
imported>Dev akm (new page) |
imported>Haama (Not so bad, after all, fixed a few links) |
||
Line 24: | Line 24: | ||
== CPU-Hungry Script Functions == | == CPU-Hungry Script Functions == | ||
Generally, scripts have little affect on FPS, especially compared to graphics. However, if run every frame there are a few functions that will cause a noticeable (>1) drop in FPS: | Generally, scripts have little affect on FPS, especially compared to graphics. However, if run every frame there are a few functions that will cause a noticeable (>1) drop in FPS: | ||
# [[GetNumItems]] (OBSE) | # [[GetNumItems]] (OBSE) | ||
# [[GetInventoryObject]] (OBSE) | # [[GetInventoryObject]] (OBSE) | ||
# [[GetFPS]] (OBSE) | # [[GetFPS]] (OBSE) | ||
#* However, you can run this every few frames without a drop. This is most useful as an alternative to '''GetSecondsPassed''' as ((Number of frames passed) / GetFPS) approximates the amount of time passed. | #* However, you can run this every few frames without a drop. This is most useful as an alternative to '''GetSecondsPassed''' as ((Number of frames passed) / GetFPS) approximates the amount of time passed. | ||
# GetDistance | # [[GetDistance]] | ||
#* I have tested the others above, but not this one. However, I have seen it mentioned several times that GetDistance is a CPU heavy function, so I'm including it here. | #* I have tested the others above, but not this one. However, I have seen it mentioned several times that GetDistance is a CPU heavy function, so I'm including it here. | ||
#*--[[User:Haama|Haama]] 17:54, 10 September 2007 (EDT) | #*--[[User:Haama|Haama]] 17:54, 10 September 2007 (EDT) | ||
Line 37: | Line 36: | ||
The main problem with CPU-hungry scripts comes from Oblivion's "brick-wall" for FPS and script processing. Scripts won't touch FPS until you hit a certain limit, and then even a few extra small scripts can start dropping FPS. | The main problem with CPU-hungry scripts comes from Oblivion's "brick-wall" for FPS and script processing. Scripts won't touch FPS until you hit a certain limit, and then even a few extra small scripts can start dropping FPS. | ||
See [[Code | See [[Code Optimization]] for more details (in planning/progress). | ||
== AI Overload == | == AI Overload == |
Revision as of 13:03, 14 September 2007
Performance Problems
This section is intended as a place to list performance problems and tips, especially those related to scripting.
Gamemode Scripts
Avoid using gamemode scripts wherever possible. Use quest scripts if you can, or try to find ways to put as much of the script work into OnLoad, OnEquip, and ScriptEffectStart blocks as possible.
If you need to use a GameMode block, use an 'if' test or a flag so the code will only run when necessary. For instance, if you need to run an item script whenever the player hits a switch, place this on the switch:
scn YourSwitchScript short Working begin onActivate set Working to 1 end
and this on the item:
scn YourItemScript begin GameMode if YourSwitchScript.Working ... endif end
CPU-Hungry Script Functions
Generally, scripts have little affect on FPS, especially compared to graphics. However, if run every frame there are a few functions that will cause a noticeable (>1) drop in FPS:
- GetNumItems (OBSE)
- GetInventoryObject (OBSE)
- GetFPS (OBSE)
- However, you can run this every few frames without a drop. This is most useful as an alternative to GetSecondsPassed as ((Number of frames passed) / GetFPS) approximates the amount of time passed.
- GetDistance
- I have tested the others above, but not this one. However, I have seen it mentioned several times that GetDistance is a CPU heavy function, so I'm including it here.
- --Haama 17:54, 10 September 2007 (EDT)
Note that for all of these, they are incredibly fast functions. Even the slowest, GetInventoryObject, can be run 1000 times and the next frame will come up in less than a second. They will only cause problems if run them constantly (every frame or so).
The main problem with CPU-hungry scripts comes from Oblivion's "brick-wall" for FPS and script processing. Scripts won't touch FPS until you hit a certain limit, and then even a few extra small scripts can start dropping FPS.
See Code Optimization for more details (in planning/progress).
AI Overload
If you use advanced AI on a lot of NPCs or creatures, the game may start to suffer from so-called "AI overload", causing NPCs and creatures to fail to process their AI as you approach them. This can do nasty things like giving roadside bandits a lobotomy -- they just stand around and do nothing as you approach.
Creatures that are swimming seem to put an extra large burden on the system, possibly because the pathfinding is trickier in the water?
Low-Level Processing
Avoid low-level processing for as many creatures and NPCs as possible. Use the "No Low Level Processing" option to keep them from processing their AI unless the player is in the same cell.