Download: StressTest-v2-alpha1.7z
From the README:
StressTest v2 alpha1
v2-alpha1 Update:
- UI is more streamlined without the need to use console commands to display standard debugging messages or to continue repeated testing.
- Only Teleport Test is currently implemented.
Description:
Stress testing of game engine resources by continuously teleporting to references stored in an array.
Requirements:
Morroblivion v065
How to use:
Load StressTest.esp mwStressTestCases.esp in your load order. Place mwStressTestCases.esp below StressTest.esp. Start Morroblivion, load a savegame or start a new game. Within 1 second, you will see a dialog box allowing you to choose a test type of cancel testing. Only "Teleport Test" is implemented as of alpha 1. Click that test to proceed. A menu will display stats as each step is performed. There is a running total since starting the test. Press or hold down the spacebar to display a menu to continue or stop testing.
mwStressTestCases.esp is hardcoded with an array of 37 references to mapmarkers of most of the settlements in Morrowind. This will stress the engine's ability to manage NPCs in addition to just loading new cells.
FYI, within 30 minutes of my initial test runs with this mod, I discovered that Blockhead OBSE plugin was causing the majority of the random crashes for my game. Apparently, Blockhead is modifying all NPCs whether or not you have OCO2 or another face/body over-ride mod loaded -- this is true even with Vanilla face and bodies! This causes the StressTest to crash somewhere during the first test-run. If you decrease resolution, graphic quality and disable distant lands, you can increase the number of cell transitions before CTD -- but if Blockhead is installed, then it will inevitably crash before completing this first test run. (further discussion below).With blockhead disabled, Oblivion is now freezing during a loading screen about halfway through the fourth lap (which is actually displayed as lap "3" because it starts with zero). This comes out to somewhere around 163 cell transitions (37 * 4.5) before the game engine chokes.
So it appears that disabling Blockhead will increase the number of stable cell transitions with StressTest by 4 times. Why? I think there may be a memory leak in Blockhead. It is probably replacing the Oblivion face/body mesh loading functions, and it is using these new loading functions whether or not you have OCO2 or another face/body replacer installed. If you decrease other system resources by decreasing resolution, disabling distant lands, you can extend the time before eventual CTD... suggesting that the issue is related to allocated memory not being properly released in one of the blockhead replacement functions. I tried disabling all features in the blockhead.ini file, but no changes to the CTD rate. So I think the leak lies in the main part of one of these replacement functions.What about the loading screen freezes even after Blockhead is removed? I think this may be related to poor garbage collection by the vanilla Oblivion engine. I'm still running tests and modifying my setup variables to get past the ~160 cell transition barrier -- right now, I am running barebones Morroblivion v065, but I will try adding Oblivion Stutter Remover and maybe PurgeCellBuffers to see if these will help. FYI, it will take about 15 minutes to reach lap 4.
EDIT:
I am retracting my original statements regarding Blockhead for now. After more rigorous testing, I've found that StressTest results can vary within a wide range, so the original results could have occurred through random chance. I need to perform more trials before I can make any statistically significant conclusion whether or not Blockhead does or does not affect stability. Apologies.
It turns out Blockhead uses quite a few replacement functions:
From Main.cpp
When I have time, I will try to add code to fully disable the override handlers -- Hopefully, I can just check the INI setting to disable the override and then do a JMP back to the original Vanilla Oblivion function.
FYI, the source-code in-line comments/documentation is surprisingly easy to understand. As a non-native English speaker, I find that most of ShadeMe's writing is extremely frustrating to understand due to his attempts at humor. His writing style frequently breaks English translation software, and it pushes me towards autistic meltdown just to try to figure out if there is any useful information hidden inside. This is thankfully not the case here. So if you've had issues with understanding ShadeMe writing before, it is not a problem in this source code.
> Apparently, Blockhead is modifying all NPCs whether or not you have OCO2 or another face/body over-ride mod loaded
Isn't this what it's designed to do? OCO was created to use Blockhead, not the other way around.
> Does anyone know how to write the console messages to log?
ConScribe?
qwertyasdfgh wrote:
Correct, what I should have said is that it does not default-back to the original Oblivion functions if no over-ride information is present in an ESP or in the Data folder.
Quote:
Thank you! I could not remember how I was doing it before! (Probably secondary to brain injury and long-standing neurological disabilities).
Under wine I'm able to complete Phase 1 testing even with Blockhead most of the times. (OCOv2 + Seamless installed)
llde wrote:
That's really great news -- thanks for your report! The increased stability under wine is probably an extreme example of what I mentioned about freeing up resource demand from other areas (such as reducing textures, disabling distant lands) will increase stability. I wonder if something similar can be achieved on Windows when using a DirectX wrapper/emulator?
EDIT:
CONFIRMED!!! Using WineD3D for Windows will more than double stability (measured by number of teleports) before CTD happens when using Blockhead. I tested it with the latest Version 5.11 Vulkan. Was able to complete 76 teleports!OK, nevermind -- I tried to reproduce results, and now Blockhead without WineD3D is even better stability than with WineD3D. 112 teleports before CTD.
For what it's worth, I'm able to complete this test (first pass) under Windows with Blockhead installed. I tried it twice, first time it crashed in the middle of the second pass, second time closer to the end of second pass. Have not yet tried without Blockhead.
Some other things this can be related to:
1.) Whether or not game has "4Gb Patch" applied. I use GOG version which comes with it by default, but other versions still need it to be applied manually.
2.) Hardware?
qwertyasdfgh wrote:
You might be correct on both counts. I'm currently testing with Steam version (without 4GB Patch) on Intel integrated graphics. I need to do more testing to figure out what is different from today versus my tests from yesterday. Thanks for the input and your test results!
I just posted v2-alpha1. I was hoping to implement other test types before releasing, but I've been sitting on this version for a while now and don't know when I'll get around to completing it. The UI convenience enhancements are really too good not to share. So here it is in incomplete form (in the first post).
EDIT:
Also, some further testing with Blockhead and VWD/LOD mods suggests that CTDs are not related to just any memory/resource management but specifically VRAM management. The stats and changes that most significantly affect frequency of crashes are the ones that affect VRAM: modifying texture size (either from the in-game menu or by using an tool like Ordinator/DDSOpt), using texture replacers especially high resolution face replacers, etc.
Oblivion tend to use a lot of D3DPool_Managed resources. it is possible that the continuos back and forth between memory pools can cause issues.
I also wonder why the device is created with D3DCreate_MULTITHREAD.