Stretched HUD [with possible fix!]

[DEFCON1]

I would like this to be fixed if possible

I've found some code for VC, unfortunately not for SA. I doubt it's of any use for you devs, anyway:

http://squiddy.marway.org/gta/source/vcwidescreen.txt

http://squiddy.marway.org/gta/screens/v ... eafter.jpg

I would like to try doing it myself, but... I don't know much and my custom build won't run anyway.. I may try on a older working version I have.

Edited June 10, 2010 by Guest

[dzek (varez)]

my hud is ok, when im using "widescreen" mode ..

[darkdreamingdan]

I've used that VC mod. It's definitely possible for MTA to implement a fix, but it's relatively low priority. You get used to the stretched HUD after a while, and it means script can consistently know where your HUD is for drawing stuff.

[DEFCON1]

my hud is ok, when im using "widescreen" mode ..

Not for me. With widescreen enabled, the world isn't stretched but my hud still is, like in the upper part of the image. Game's resolution is 1920*1080 as it's my screen's native resolution.

Talidan, do you know the memory addresses that need to be modified ?

[eAi]

No, he doesn't, but it's the kind of thing we're pretty good at working out

[DEFCON1]

I would like to learn how.. Which program(s) do you use? tsearch? IDA?? lol

[DEFCON1]

Ok, after wasting a few hours with Cheat Engine, I THINK I've found the address, and which value to set to it.

The address is 0x00859524, with original float value of 0.002232143

After few tests, I've concluded that this value need to be changed to:

For 16/10 resolution: ( (16/10) * 0.002232143 ) / (4/3) = 0.0026785715

For 16/9 resolution: ( (16/9) * 0.002232143 ) / (4/3) = 0.0029761905

So.. a simple fix would be to set this address to ( (ScreenWidth/ScreenHeight) * 0.002232143 ) / (4/3) or simplified:

(ScreenWidth/ScreenHeight) * 0.0016741072

I am not sure if that is the only adress to be changed, and also not sure if it will work for everyone... but it worked for me, in single player game. Please tell me what you think

Edited June 11, 2010 by Guest

[darkdreamingdan]

Nice work, though im not sure about those Hex values. Report the issue on Mantis alongside your findings and i'm sure someone could look into it.

[NTAuthority]

I have a proper C# fix for this value and other values that are required to be changed too (not just pixel width, also 'screen size in pixels'), however, the default HUD is messed up partially if changing pixel width. I could try finding out a way to fix this (it did work in VC with weapon icon on the other side) and provide a patch if required (and converting to 'proper' C++)?

Other issues happen with certain scripting functions using the GTA 'virtual screen' hardcoded to think it's 640px wide, but as MTA doesn't use GTA virtual screen functions that's likely no issue.

Also, 859524 is the 'pixel height' value (1/448), while a proper fix should be 4 bytes earlier, in the 'pixel width' value (1/640).

EDIT: some more explanation (14:21 CEST)

Changing things vertically is not the proper way to fix widescreen issues (like GTA from III to VCS do). The proposed fix changes the vertical height to fit in with the game's vertical widescreen fix, but a proper fix would be done horizontally. Another fix I'm tracking down is a 'proper' horizontal fix to replace GTA's 'widescreen' option... I've found out how Racer_S's GTA3/VC tools fix it and the only thing I need to track down if I'm right is the 'static' FOV value, the one the game interpolates to if CCamera::Cams[0].FOV is changed.

The proper fix seems to increase the horizontal FOV and change the (also set by widescreen) flag that likely configures the relation between horizontal and vertical FOV... where 'widescreen' reduces the vertical FOV instead of increasing the horizontal FOV... if anyone would be interested in having a GTA IV-ish proper widescreen patch, let me know and I'll also make a MTA patch for that.

[DEFCON1]

Yes, this does change the height of the hud, not the width, but changing the width with address 859520 bring a problem with the weapon icon which doesn't move along with the other HUD elements. But to move that icon horizontally, we can use address 866C84

Both addresses need to be changed to: (original_value * (4/3)) / (ScreenWidth/ScreenHeight)

So it's also possible to scale the whole hud, for example to 75% of it's original size:

859520 = ( (original_value * (4/3)) / (ScreenWidth/ScreenHeight) ) * 0.75

859524 = original_value * 0.75

866C84 = ( (original_value * (4/3)) / (ScreenWidth/ScreenHeight) ) * 0.75

[attachment=0]mta-screen 2010-06-11 20-08-50.jpg[/attachment]

But there is a problem with texts such as zone and car names.. they appear not centered but to the right...

I'm currently searching addresses of positions and scales (or size) for all hud elements, so maybe there will be some new functions such as setPlayerHudComponentPos( player, component, x, y) and etc...

Edited June 12, 2010 by Guest

[dzek (varez)]

one question - is your mta running smoothly on full hd?

what specs do you have?

[DEFCON1]

Yes, hopefully it run perfectly (only clouds make some fps drops..)

i7 920

4870 1Gb

3Gb of Dominator 1600

But this game doesn't require half of this to run smoothly at 1920*1080, I think.

[NTAuthority]

Some screenshots of my FOV work (needs cleaning up and MTA integration still):

http://imgur.com/n9pIW.jpg - 4:3 reference

http://imgur.com/qwvAh.jpg - 16:10 stock (stretched, very much)

http://imgur.com/bU8GU.jpg - 16:10 custom

[DEFCON1]

I don't get it, NTAuthority. I think everything is fine with the actual FOV in MTA (when the Widescreen option is enabled).

And more importantly: does YOUR fix make the vehicle name's text and zone name's text to the middle of the screen, as the original 4/3 display ? Or they move at the right side of the screen?

Mine have this problem, and I don't think that it is fixable... Also I searched for addresses to move and resize individual parts of the hud,the only one I found which does not cause problems, is the health bar... I have found for the radar but this also affect the armor/breath bars so it's unusable. Something else I've found, it also affect the audio volume (wtf), or even vehicles's tire's width!... many problems like that lol

[NTAuthority]

I don't get it, NTAuthority. I think everything is fine with the actual FOV in MTA (when the Widescreen option is enabled).

Some more comparison screenshots showing why 'widescreen' does not cut it:

http://files.dotbas.net/img/fov-1610-default.jpg (non-widescreen, non-fixed)

http://files.dotbas.net/img/fov-1610-rs.jpg (widescreen, note the lack of vertical information -- widescreen monitors are meant to have more horizontal information!)

http://files.dotbas.net/img/fov-1610-nt.jpg (widescreen off, custom FOV setting, note that the vertical information remains, and more information is added horizontally. this only offers a negligible gaming advantage and as such is not a 'cheat')

And more importantly: does YOUR fix make the vehicle name's text and zone name's text to the middle of the screen, as the original 4/3 display ? Or they move at the right side of the screen?

Mine have this problem, and I don't think that it is fixable...

It likely doesn't, but that's mainly as MTA's position change code replaces it with something meant for the 640px wide default 'virtual screen', easy to change by editing MTA's source.

Also I searched for addresses to move and resize individual parts of the hud,the only one I found which does not cause problems, is the health bar... I have found for the radar but this also affect the armor/breath bars so it's unusable. Something else I've found, it also affect the audio volume (wtf), or even vehicles's tire's width!... many problems like that lol

That's likely because these values are pooled with other read-only values to reduce the size of the .rdata PE block. III/VC made every instance of a variable with the same static value have a different memory location, but SA's compiler actually pools them to be similar. To change these effects, the code using them would need to be patched, and not the hardcoded values.

[DEFCON1]

That's likely because these values are pooled with other read-only values to reduce the size of the .rdata PE block. III/VC made every instance of a variable with the same static value have a different memory location, but SA's compiler actually pools them to be similar. To change these effects, the code using them would need to be patched, and not the hardcoded values.

I start to get it

It's like, "this sound effect need the same value than an existing one used to display a part of the hud, so let's use this existing value!", lol! So from what I understand, it is needed to create a new variable with a similar value, and tell gta_sa.exe to use this new value for our needs, instead of the default one that is used for something else.

But I have really no idea how to do that, especially within an external program such as MTA. Is there any MTA function that use this method, so I could study that ?

I let you do the MTA patch of course, you probably know much more than I do. In fact I don't even care about those misaligned texts (but MTA team probably does)... at least I've learned how to find some basic addresses lol

Oh, also you should obviously test with the original HUD, as it looks like a scripted hud

PS: I agree for your FOV fix, it is definately needed.