Tactical Combat Camera

[Tethys]

Flocke is gonna beat me up for this post, I know it

For the better part of yesterday I have been searching around the exe using IDA and hXd, trying to find the subroutine(s) responsible for the camera system in tactical combat. What I found was a mess to say the least; I've only managed to break things mostly, but I did get some results from the initial camera position upon entering tactical combat screen. I was able to force tactical combat to start with camera zoomed all the way out (no gradual zoom out as usual, it was as if you pressed hotkey "Insert") using a simple test nop. I believe it also disabled the gradual zoom out after turn process as well, but could not verify due to inability to complete turn using turn process zoom camera.

I want to try to fix, or work around, the zoomed in camera that is used after pressing "TURN", (camera(s) used during turn process) where the camera will change to focus on your ship as it moves away from the camera; it either crashes right there or lags horribly when shield hob is displayed (if you get past this point, camera will reset and will view you incoming from target). These view changes are cause for many crashes and lag associated with tactical combat in heavily modded versions of BotF.

To be clear, I am not requesting a fix, or a workaround. I would like to know the subroutine responsible for this camera angle and camera position change procedure so I can better understand how changes in different areas can affect an outcome. I have found some dwords in various locations in the dgroup section of exe, nearby are values (that I have not attempted to change) I suspect may be distance figures? But I am not sure how exactly camera works; I do not want to randomly change values, any additional information would be useful.

I am using sct_trek_8_3_2020.idb for reference.

[Spocks-cuddly-tribble]

It might be better to rely on the QD database in this matter. My understanding of 3D mechanics (in general and wrt ancient BSP workarounds) is very limited. It took me quite some time to understand trek.exe phaser slot values.

Also if you already identified some relevant code areas, it might be wise to share this info here, in case some of the 3D engine experts are willing to help you.

[Tethys]

Code: Select all

AUTO:0049AB49 85 F6                                           test    esi, esi
AUTO:0049AB4B 0F 85 20 01 00 00                               jnz     loc_49AC71

Nop these and it disables the initial tactical camera zoom out to static location. Uses static location from the start.

Code: Select all

AUTO:0049AB61 85 D2                                           test    edx, edx
AUTO:0049AB63 0F 84 34 01 00 00                               jz      loc_49AC9D

If you also nop these bytes along with the above, the camera starts somewhere in BFE, and some weird stuff happens pressing backspace to reset view. Although it does seem to take longer to crash out with these disabled, you can't really see anything here, even moving aroudn with the arrow keys.

[Spocks-cuddly-tribble]

Key trigger for your first switch (static location) is ds:5918B8

So as a first step you might try to enforce (first two bytes 0F 84 -> 90 E9) or remove:

Code: Select all

AUTO:0049A192                 jz      loc_49A5AB

AUTO:0049C6B5                 jz      loc_49C823

[Flocke]

Actually with mpr++ I failed on the tactical camera as well. When I changed the mpr++ camera angle, the BotF render engine clipped away weapon animations I relayed on for the replacement rendering. Given the processing overhead I however rather searched out for the values BotF used one level up prior to this render routine mess, so I could bypass the BotF camera clipping. Therefore I never looked into how the BotF camera was controlled and can't help on that.

But despite I fully agree that it would be great to have a better combat view, I pretty much doubt that it helps prevent crashes or even increases the framerate or responsiveness or compution speed. The closer the camera, the more is clipped. And the more is clipped, the less must be computed. That's what is clipping for. Ofc in mods where you have high resolution models, this might be contraproductive, given there is more detail to show. But in case you refer to the long delay prior to rendering the combat outcome, this definitely is not related.

The whole combat result is pre-computed, that's what is causing the delay. As I remember, you can even watch it place temporary files for computing the combat in the BotF folder. What you see after the delay, is just a playback of the combat result. This was likely done for performance optimization to that time. And as far I know, the combat compution processes the hobs as well, so it is no surprise it crashes or lags in exact that moment, where the camera is switched.

[Tethys]

Hi Flocke, first off thanks for the reply. That is unfortunate you were not able to crack BotF camera during your projects

, I pretty much doubt that it helps prevent crashes or even increases the framerate ...

Empirical evidence suggests otherwise. Resetting the camera, using backspace in my case (I have not tested thoroughly the Insert/Delete hotkeys during tactical combat turn process) I can play through all turns of tactical combat without issue. It is a hassle, forgetting to press it or not pressing it in time. It has been a stable workaround for me.

But in case you refer to the long delay prior to rendering the combat outcome, this definitely is not related.

No, not referring to initial computation or calculation. That should all be predetermined before the tactical combat video takes place. Crash happens most often immediately before or shortly following the SECOND camera switch (viewing your ship, flying toward your viewpoint), but I'd just like to cut out that entire cutscene completely (both camera switches) and just use the default TOP VIEW always zoomed out camera for the entire tactical combat. Sounds simple? LOL

, so it is no surprise it crashes or lags in exact that moment, where the camera is switched.

Not quite. Typically you can't get camera to switch without combat engagement (using Hail, ship not moving, camera not moving, no additional hob files), so it is hard to say whether or not the lag is coming from camera switch, or from shield hob. Some cases have suggested both are to blame, but only one thing has worked around the problem for me and that is immediate manual reset of tactical camera view during tactical combat process. It works 95% of the time; there are cases where large ships (ie Cube) or outpost/starbase will still crash even with manual camera reset. Shield hob is expanded in size and may even interfere with camera. But these assumptions are speculative.

Side note: I can do some tests without shield hob (set all ships in combat to 0 shield) and see if crashes disappear. It would be nice if someone could make a very low poly shield hob model (can be square for all I care) to see if this has any effect on the issues faced here. But I understand if that is not feasible.

UPDATE: I just ran a few tests and in each test I was able to play through ALL turns without significant lag, and without a single crash. Shield hob removed using 0 value on ship stats shield strength and shield recharge. Shield hob is the problem, or either too many hobs being active at once too close to camera. Cheers.

[Flocke]

UPDATE: I just ran a few tests and in each test I was able to play through ALL turns without significant lag, and without a single crash. Shield hob removed using 0 value on ship stats shield strength and shield recharge. Shield hob is the problem, or either too many hobs being active at once too close to camera. Cheers.

I have no idea what might be wrong on the shield hobs or the camera clipping but great find!
If I remember correct, the shield effect always was oriented by the weapon fire. Might be that the clipping is interfering here and it fails to calculate how to direct the shield effect given the phasers were clipped or something. Who knows.
In case it is related to the clipping, you possibly just need to nop some clipping routine, rather then to change the camera view. But whether that's easier to find I can't tell.

[Tethys]

I have been talking with Thunderchero frequently and apparently the DxWnd program seems to fix all the combat lag and crashes I am experiencing. Whoever made that happen should be rewarded the highest honor. Highly recommended. It should be the default launch option.

I have seen the shield hob in unwrap. It has 6 faces and they are all separated. Each face shaped like a cone. They could have at least lowered the profile to make it look more realistic.. but I suppose laziness may be to blame. Either way, a new camera view would be nice yeah, so I will still pursue the project even if it's just for the learning experience.

[Spocks-cuddly-tribble]

You run BotF with a modern OS without DxWnd or MPR++ and yet you haven't noticed any terrible mouse-lags?

Throw him to the floor, please: https://www.youtube.com/watch?v=HrcbCW4y9Dw&t=64s


And IIRC the BotF shields (software rendering) look in-game similar to the TNG effects. Only complaint is the size/perimeter display glitch, analysed by Thunderchero: viewtopic.php?f=4&t=3469#p46374

[thunderchero]

You run BotF with a modern OS without DxWnd or MPR++ and yet you haven't noticed any terrible mouse-lags?

yeah he is using windows 7. after finding that out. I tested on my test windows 7 OS and as soon as I started game I got "Blue screen of death"

So in my tests BOTF no longer works on windows 7 without DxWnd or MPR++.

[Tethys]

No mouse lags. Only the combat lag, which is now gone. Oh, I did have a screen flickering effect in the main menu which I have not seen since using DxWnd. Very stable now.