Technical Issue Widescreen UI on my resolution

[S o l d i e r]

Is the resolution 1366x768 supported for Widescreen UI? I'm asking this because no matter whether that option is turned On or Off, my UI is the same.

 

[Damn Polak]

either you're doing something wrong, or you don't know what the widescreen ui changes
i use the same resolution, and it makes a difference

edit: are you using mb2 client or jamp?

 

[S o l d i e r]

either you're doing something wrong, or you don't know what the widescreen ui changes
i use the same resolution, and it makes a difference

edit: are you using mb2 client or jamp?

mb2 client
Shouldn't changing it change the width of your in-game ui?

 

[Damn Polak]

it only fixes streching of the ingame hud & fonts

 

[S o l d i e r]

Yes, that's what I thought, but my hud stays the same when I change that option.

 

[Puppytine]

Yes, that's what I thought, but my hud stays the same when I change that option.

Widescreen HUD in MBII client is always stretched.
It's displayed properly in jamp and jaMME.

[SOLVED] - Hud is still stretched out and disproportionate
Technical Issue - Difference between JAMP client and MBII client.
OpenJK vs JAMP

 

[S o l d i e r]

I don't understand why they removed the ratio feature in OpenJK, if it had already existed in JAMP.

 

[Puppytine]

I don't understand why they removed the ratio feature in OpenJK, if it had already existed in JAMP.

I don't understand it, too.

You can ask contributors of OpenJK about widescreen support here:
Issues · JACoders/OpenJK · GitHub
Or here:
OpenJK Discussion - JKHub
Or here:
irc.arloria.net, channel #jacoders.

There is a related thread, but it doesn't make more clear why they did throw away normal HUD rendering in widescreen resolutions:
Feature Request: Widescreen/Eyefinity Support · Issue #36 · JACoders/OpenJK · GitHub

 

[S o l d i e r]

I've contacted them regarding the issue: Widescreen UI problem in MB2 with OpenJK client · Issue #891 · JACoders/OpenJK · GitHub. Hopefully, it will get resolved.

 

[eezstreet]

JAMP does not have aspect correction for HUD/UI/Fonts. In fact it never has.

If there's an issue with the MB2 client, there's something wrong with the mod, not a problem with OpenJK.
It's not up to the OpenJK maintainers to look into problems that are mod specific, it's the responsibility of the mod developers to look into it.

 

[S o l d i e r]

Ok, ok, I didn't know. If I knew that it was MB2-side and not thought it was OpenJK-side I wouldn't have created that post on the GitHub. At least it's resolved now whose issue it is.

 

[Puppytine]

JAMP does not have aspect correction for HUD/UI/Fonts. In fact it never has.

If there's an issue with the MB2 client, there's something wrong with the mod, not a problem with OpenJK.
It's not up to the OpenJK maintainers to look into problems that are mod specific, it's the responsibility of the mod developers to look into it.

Well, that's strange to hear, since some developers said that lack of widescreen support is con of OpenJK engine itself:

1. OpenJK is an open source engine modification.
<...>
Cons:
<...>
- it is lacking of some features like ratio fix support (though they started adding it recently, but not completed), so everything looks stretched in the game

Aaaaaaand this is what @eezstreet posted on github:

Yes, it has absolutely nothing to do with JAMP or OpenJK. They fixed it in MB2 to specifically fix at runtime with the JAMP engine.

There is no ratio fixing in JAMP itself or OpenJK. Our hands are pretty tied because of below:

Its not feasible to make a 1 way fits all "fix" to make all objects snap how they should at all resolutions without fixing it in each respective mod PLUS the engine/renderer backend itself.

It would be nice to know who spread rumors suggesting JAMP itself was working.

I see a lot of contradictions over here.
So, before I get to my point, I just want to show everybody one more time difference between two engines in widescreen mode.
This is jamp:

And this is MBII Client (OpenJK):

Now it's time to ask Movie Battles team about this thing:

@LoU, @Stassin, @ent, @Viserys, @Spaghetti, is that true?
Did you really create some kind of runtime patching for jamp to fix widescreen HUD?
If you did, why didn't you make same thing for OpenJK? It should be even easier, since OpenJK is open sourced!
If you didn't, can you please comment on last replies from @eezstreet? Any explanations? Because this situation need to be cleared...

 

[ent]

I made the runtime patch for the ratiofix for JAMP.
Each time OpenJK gets recompiled (updated binaries) all the addresses that have to be patched become different, and finding them all the time and adding to MBII is just a waste of time. JAMP was compiled once in 2003.
Why does it work with jaMME (fonts are aligned more precisely there than in JAMP, btw)? Because I have created custom API (that extends base API), and that does not require runtime patches.
OpenJK devs could also make extended API for the ratio fix. They made it only for fonts and only recently (this year iirc). But there also must be ratio fixes for rotated images (2 types) for the HUD/minimap.

There were/are no rumors. It was always clear as is. At least for those who asked questions.

 

[hleV]

I made the runtime patch for the ratiofix for JAMP.
Each time OpenJK gets recompiled (updated binaries) all the addresses that have to be patched become different, and finding them all the time and adding to MBII is just a waste of time. JAMP was compiled once in 2003.
Why does it work with jaMME (fonts are aligned more precisely there than in JAMP, btw)? Because I have created custom API (that extends base API), and that does not require runtime patches.
OpenJK devs could also make extended API for the ratio fix. They made it only for fonts and only recently (this year iirc). But there also must be ratio fixes for rotated images (2 types) for the HUD/minimap.

There were/are no rumors. It was always clear as is. At least for those who asked questions.

Is it really that time-consuming to have proper UI ratio in MB2 releases? I honestly wouldn't know, hence the question.
You're not asked to correct it every time a new MB2 devbuild or OpenJK build is up, only between MB2 major/patch releases.

 

[eezstreet]

Well, that's strange to hear, since some developers said that lack of widescreen support is con of OpenJK engine itself:

Aaaaaaand this is what @eezstreet posted on github:

I see a lot of contradictions over here.
So, before I get to my point, I just want to show everybody one more time difference between two engines in widescreen mode.
This is jamp:

And this is MBII Client (OpenJK):

Now it's time to ask Movie Battles team about this thing:

@LoU, @Stassin, @ent, @Viserys, @Spaghetti, is that true?
Did you really create some kind of runtime patching for jamp to fix widescreen HUD?
If you did, why didn't you make same thing for OpenJK? It should be even easier, since OpenJK is open sourced!
If you didn't, can you please comment on last replies from @eezstreet? Any explanations? Because this situation need to be cleared...

You seem to be confusing three different people:
- ent is not an OpenJK developer
- ensiform is not me
- I am eezstreet

ent is correct, we could extend the API, however that would introduce potential compatibility issues with mods and therefore it's not something we want to pursue. Really the MB2 devs should fix it, seeing as how they have a tailored fork of OpenJK and jaMME (which has the fix) is open source. cough or they should stop dragging their heels and open source the mod already cough

Either way, we didn't remove it, the devs just didn't fix it on their fork.

 

[ent]

Is it really that time-consuming to have proper UI ratio in MB2 releases? I honestly wouldn't know, hence the question.
You're not asked to correct it every time a new MB2 devbuild or OpenJK build is up, only between MB2 major/patch releases.

Not just time.
OpenJK can be compiled by different people in different moments of time, so if it works fine on some "official" build, then it won't work fine on custom or outdated ones. And to detect which one is official and which is not can be prolly done with comparing md5 hashes, but it's just extra unnecessary work, and all those things have to be changed manually in the code each time.
So you have to keep in mind all the time you update MBII to also remember to change those stuff all the time.
And having OpenJK open source and not making an extra API is really silly and that way would be done once and forever, instead of manually doing the dirty way with the runtime patching.

 

[ent]

however that would introduce potential compatibility issues with mods

Just make extra API with enums like I did:
jaMME/cg_public.h at master · entdark/jaMME · GitHub
just assign to some big number.

 

[Puppytine]

You're not asked to correct it every time a new MB2 devbuild or OpenJK build is up, only between MB2 major/patch releases.

Since it's just a binary hack, that relies on addresses in memory, it isn't very easy to update for each mb2 release.
Such things take time and efforts.
My sentence about "It should be even easier" was a littler premature .

- ent is not an OpenJK developer

Indeed he isn't, I know that.
I just meant:

since some developers [of Movie Battles] said that lack of widescreen support is con of OpenJK engine itself

- ensiform is not me

Oops, that's my fault.
I wasn't attentive enough.
Sorry.

we could extend the API, however that would introduce potential compatibility issues with mods and therefore it's not something we want to pursue.

Are you telling me there is no way to create API for OpenJK safely?
I really wish you just grab it by the pussy from jaMME and put into OpenJK, so any mod (including MBII) could use it.
What can possibly go wrong?

Don't complain at us for "removing" something when we didn't remove it, the devs just didn't fix it.

I won't.
I complained only because I didn't know that Movie Battles uses binary hacks in jamp to fix widescreen ratio.
Now I'm gonna complain that you don't want to adopt ent's API

 

[eezstreet]

Just make extra API with enums like I did:
jaMME/cg_public.h at master · entdark/jaMME · GitHub
just assign to some big number.

We don't use that old trap API for OpenJK-based things, we use something similar to what SP does with pointers.
Regardless, the MB2 developers would still need to keep their fork updated. It hasn't been updated in 9 months.
Commits · MBII/OpenJK · GitHub

The correct way to approach this would be:
- MB2 devs (or ent, or whoever) implement aspect correction on the MB2 fork of OpenJK
- It works perfectly well and looks good already in MB2
- (Optionally) a pull request is made to include this in the main branch of OpenJK

The way people are asking to approach this:
- OpenJK devs (maybe) implement it
- MB2 devs (maybe) pull from upstream
- It (maybe) works in MB2 without further changes

 

[ent]

Use whatever way you think correct for you. Just explain how to access that new API with pointers - that's all.