You may have seen reference to a Deus Ex loader I was working on in another thread. I got everything done with it that I could think of. There might be something I forgot or a bug somewhere. Anyway here it is if anyone is interested in trying it. Be sure to see the notes through the rest of this thread in addition to the dxloader.ini and the documentation.

That looks pretty awesome. Does it have any of Kentie's fixes too? Might want to use it for TNM 1.0.5

Cool, thanks. I still need to look at some of the other loaders and see if I forgot something or not, since I just did what I knew from the changes I've made manually to my own DX installs. Those renderer settings I put in the config file probably need work, since I really didn't find too many good sources for "suggested settings". It could probably use detections for the renderers themselves.

Since I'm still working on it, if anyone has any ideas on things to add/change I'm welcome to them.

I'm speaking from total ignorance, so laugh if you want to.

When OpenGL is selected as the renderer would it be possible for the loader to change the ini to UsesSt3C=true? It's no hardship manually doing it but people forget and the files are in my documents not the game folder in Windows 7. Just a thought by someone who knows very little.

What about the dual-core fix, or whatever that was?

You might also want to implement some kind of FoV adjustment so that the crosshairs/view work properly in e.g. widescreen resolutions. You could either go kentie's route (pick from a set of default FoVs based on common aspect ratios) or the route I use in my mod (calculate the FoV necessary for a given resolution, although for this you'd want the player to be able to choose resolution through the launcher too). I'd suggest the latter, as it's more accurate/precise and works for all possible resolutions. FoV for binoculars and scoped weapons will still be screwed up for non-4:3 resolutions, but that's not something you can really solve without modding the scripts in DeusEx.u, so that's out of the bounds of a launcher.

You can do it through the copied settings in the loader ini. However, I have been thinking about forcing DetailTextures=True and UseST3C=True for the current renderer. Might be worth it?



I saw the Kentie launcher does this. I don't know if it's necessary or not (not having Vista or 7 here to test with), but I can copy things there if it is without too much trouble.



The loader ties the process to one processor upon running by default (CPU 0). I believe that was the multiple core fix, but I could be wrong...



I have a function which calculates and sets FOV based on the resolution selected for the common FOV dimensions (4/3, 5/4, 16/9, 16/10). It's already happening behind the scenes (though I could probably make it user-settable if necessary).

I looked at Kentie's stuff and found a few things this launcher isn't setting. I'll probably add those in the next revision (which will hopefully come in the next few days).

Yeah there's a couple of games with bits and pieces in My Documents on my PC with Windows 7. It's kinda weird what game files it puts there.

Which I just got done. I don't know if there's anything else that needs done in terms of fix settings, but I'll probably go ahead and clean up a couple of things and post what I have here now very soon.

I posted the current build on this loader. Be sure to check your DXLoader.Ini if you are running HDTP and double-check your DXINI at least once for testing purposes.

Changes
1) Split up HDTP Paths into Texture Path and System Path, since I don't know how the final build of that will look. Better to do that and be flexible than have to change this when HDTP is released.
2) The loader now deletes and replaces Paths lines (New Vision, HDTP, Shifter) in response to a problem I noticed in the old method.
3) Added FPS Limit, Sound Latency, and "Disable Mouse Acceleration" options.

Questions
1) Are there any other settings that need added or fixes that need done?
2) Should detail textures be forced in the render settings?
3) Do files need to be set to the "My Documents" folder?

Why just the common aspect ratios, though? If you have a correct working formula, it should work for any possible resolution. This is especially useful if someone happens to be playing using, say, one of those not-quite-16:9 resolutions on some notebooks, and in general would be better practice, in my opinion.

I don't have time at the moment, but later tonight I'll probably dig through my source code and find you the formula I use (which I got off some very useful website regarding photography and geometric projections).


EDIT: Okay, the information I based my math on is from here: http://wiki.panotools.org/Field_of_view (specifically "Conversion from horizontal to vertical and vice versa")



desiredVFOV is the vertical FOV angle we want to retain, in radians (i.e. the vertical FOV that vanilla DX has on a 4:3 screen), so that things look right. newDefaultFOV is the new horizontal FOV we're calculating, rootWindow.width and rootWindow.height are the resolution, and that "57.2957795" is just a conversion factor from radians into Unreal angle units. In my tests it seems to work fine (and theoretically should be perfect unless I did something disastrously wrong), and in fact gives better values than kentie's launcher.

I really didn't see a relationship for the FOV values I knew based on common aspect ratios and didn't find one too easily on search, so I figured the best thing would be to just compute the aspect ratio and then substitute the value. Not the best thing, but the best thing I knew to do at the time.



Thanks for the formula. I will definitely make use of it in the launcher.

This looks very useful. It's about time DX got a launcher like this.

Latest beta version of the loader posted (build #3).

Changes
1) Forces DetailTextures=True and UseS3TC=True in the renderer settings for dxini, no matter what is set in the dxloader ini. This should be helpful from a support standpoint if this loader is used with New Vision (and maybe HDTP).
2) A custom resolution may now be set within the menu system. For full screen, this will not be of too much use, since DX will correct the resolution to the closest supported thing (in other words one of the resolutions already listed by the detection routine), but for windowed screens this can be helpful if someone wants a setting that isn't auto-detected as supported by the video card and display.
3) The formula G-Flex posted in this thread is now being used to calculate the FOV based on the resolution that is entered.

Questions (Answered and not)
1) Do files need to be set to the "My Documents" folder? Kentie does this through changes to the Unreal DX launcher code which forces DX to look there instead of DX/System for files. Given the number of customizations that I'm sure have been made by other mods, it'd probably be questionable to try and make a similar modification. Research into whether there are other ways to do this might be warranted.
2) Are there any other settings that need added or fixes that need done? For example, would forcing Vsync=True be helpful?

If there isn't anything else or any bugs that need fixed, this should be close to finished now.

I've had a few issues with the My Documents thing.
But I think if you were include it, allow it to make a new folder for each individual mod; I don't think Kentie's mod does do that.

As for issues I've had with it, it seems that it doesn't copy the .ini to My Documents after the folder has been created when you launch the .exe for the first time. Maybe someway of checking differences between the two files to make them both sync up-to-date. I know we've been caught out previously when people have needed help installing NV to make sure they've added the UseS3TC=True line to the .ini in the Documents folder rather than in the System folder.

That's what I'd want to do if I figured out what needed to happen to make it work.



The DX launcher code is a little heavy-handed in this regard, since it forces DX/System as a path. Kentie's launcher solves this by forcing the paths in the DX code for INI and LOG to My Documents, placing the default DX ini files there if they do not exist already. In doing this, the rest of the DX code treats it like a new install with the ini files present in My Documents. While this was good for vanilla DX if there are issues that require those files in My Documents, the elemental problem I'm seeing in this fix is duplicating this without touching the original DeusEx.Exe code like Kentie did. Given that there are mods which probably modified the original Deusex.exe as well, one would have to manage the change with a very light hand to not break anything else.

(as a thought, something I might try is putting Kentie's exe in place of TNM.EXE or 2027.EXE and see whether that breaks something)