You're probably at the point where you need to disassemble or decompile it, using e.g. Ghidra. It would probably be pretty challenging - you won't get to see the original variable names or anything so it can be pretty hard to figure out what you're looking at, even if you are experienced at programming.

Are all, more complicated, game exe fixes really made with that method?

There are a lot of mods out there that patch the exe. I don't imagine most modders have that level of coding knowledge... or do they?

Yes they do, they either do it at the assembly level or they decompile using Ghidra. Ghidra is actually the easier option in many cases, but the really old school people just went through it at the assembly level.

Edit: I should mention that people who do this sort of thing tend to use a debugger to step through the code at the assembly level as it runs or so I hear.

eddman wrote on 2024-04-06, 02:29:

Are all, more complicated, game exe fixes really made with that method?

There are a lot of mods out there that patch the exe. I don't imagine most modders have that level of coding knowledge... or do they?

Is this a DOS game or a Windows game, and what do you mean by Vert-?

32 and 64 bit Windows EXEs come in a format called PE. There is a Resources section which is fairly easy to edit using the appropriate utilities without affecting the rest of the EXE. If that is where your game has the list of supported resolutions there (e.g. as part of a dialog template) you may be in luck rather than using a hex editor.

You might try Extensive File Dumper (freeware, uses same engine as IDA Pro though) to help you make sense of what you're seeing in a hex editor: https://hex-rays.com/wp-content/static/securi … y/files/efd.zip
That is an alternative to a full-on disassembly.

Thanks. Never thought about PE. I'll see if there's anything in there.

EDIT: That revealed nothing related to the FOV or any other game options.

jakethompson1 wrote on 2024-04-06, 03:37:

Is this a DOS game or a Windows game, and what do you mean by Vert-?

2005 windows game, Pilot Down.

Back then games were designed for 4:3 resolutions. Forcing a wider resolution causes the top and bottom to get cut off, hence Vert-.

This can be fixed by increasing the FOV value which basically "zooms out" the view, to make it Hor+.

Some games store this value in a config file but some like the one mentioned have it embedded in the exe.

The resolution is actually set with a launcher exe and passed along to the main exe. There are four options to choose, 640x480, 800x600, 1024x768 and 1600x1200.

Changing the resolution was easy. In the hex editor I did a simple text search in the launcher exe for one of those numbers, say 1024, and found them.

The FOV is stored in the main exe. I can find the word "FOV" in two places but can't figure out where the value itself is located and what it looks like.

FOV will be a floating point value. These are much harder to hunt out in a hex editor. Your best bet is to attach a debugger and change the FOV in the game via some mechanism (menu option? console?) and watch the memory to see the locations that are changing data. Floats are 32-bit values, so you should be looking for data aligned on 4-byte boundaries and changing as a 4-byte chunk. If you know floating point representation, that might help a bit to find which values could be the FOV.

Finally, as a gamedev, I wouldn't hard-code FOV but rather either have it coming from a config file (tweakable or not) or read it from the level's data or script maybe? (if the game exposes camera controls to the designer).

Good luck hunting!

Under OpenGL 1.x FOV is controlled by a projection matrix which is loaded with glLoadMatrix, so you'd want to look for that in the code for something to modify. In later versions that use vertex shaders, if you run the game in a debugger you can often find plaintext GLSL shader code and it'd be possible to change the FOV calculation if you can inject modified shader code into the game.

Direct3D is likely similar, except I know that it has an obfuscated format for storing shader code so good luck.

bakemono wrote on 2024-04-06, 18:12:

Under OpenGL 1.x FOV is controlled by a projection matrix which is loaded with glLoadMatrix, so you'd want to look for that in the code for something to modify.

Well, assuming the game uses the OpenGL matrix stack - as it isn't really required in GL 1.x at all. The game might upload the transformed vertex data in homogenous coordinates or screen coordinates and bypass the matrix stack altogether. This wasn't that unusual as it allows the developer to retain control of the lighting and fog. In that case I think it would be trickier to track down.

This guy has had some success digging around blindly:
https://www.youtube.com/watch?v=wy8QRyzR5IU
(Read the comments, first response to FinalLuigi).

I've had most success using:

- IDA (free version) for dissasembly and debugging
- this site for help converting b/w assembly and machine code (or vice versa): https://defuse.ca/online-x86-assembler.htm
- HxD for editing the binary (any hex editor would do of course, but I like this one)

I created a wide screen patch for Boiling Point: Road to Hell using these tools, including increased FOV. Unfortunately there was no way (that I could find) to do that without resorting to editing DLLs, but yes thoroughily checking for a way to do this via config files first is the way to go.