Feature Request: Widescreen/Eyefinity Support about openjk HOT 44 OPEN

That shouldn't be too hard... Make the menu position & size controllable via cvar so you can place it on the center screen, basically. Maybe allow the screen center to be set via cvar (influencing the projection matrix) for people who use differently sized screens.

Thanks for mentioning this, this is exactly the kind of thing we can do now and that fits well into this project.

from openjk.

I have menu stuff worked out for one of the mods I'm going to be working on for JK2. Its more of a mod-specific thing.

Mostly what needs to be fixed is the FX stuff for flashes, which don't properly stretch to fit the screen. That's about the only feature lacking from "widescreen support", unless you want to hack up font drawing and stuff like that. Mostly modcode being touched on here though.

Sent from my Windows Phone

From: Jacob M. Davismailto:[email protected]
Sent: ‎4/‎6/‎2013 4:29 PM
To: Razish/OpenJKmailto:[email protected]
Subject: [OpenJK] Feature Request: Widescreen/Eyefinity Support (#36)

Any chance you guys are going to update these to work properly in widescreen and eyefinity? They can be made to run at any resolution via an ini file, but it'd be nice to have proper resolution detection in the menu, or at the very least just fix the HUD for WS and Eyefinity.

When Return to Castle Wolfenstein's source was released, a guy did a fix for them for widescreen and triplehead, I've mirrored his source code here: https://github.com/thelolotov/RTCW-WSGF

He unfortunately seems to have dropped off the face of the earth, otherwise I'd just ask him.

Anyone willing to give this a go? It would be amazing to have widescreen and eyefinity working properly in these games, and it couldn't be that hard to port from another Q3-based game, his solution was kind of bare-bones, but it worked.

I have the programming capabilities of a legless frog, otherwise I'd try and do this myself, but if there's any way I can help, please don't hesitate to ask. I can clear up any confusion regarding my request, etc. If someone does do this, I can give you guys a plug on wsgf.org, as I am staff there.

Thanks either way, guys!

Reply to this email directly or view it on GitHub:
#36

from openjk.

I can't quantify how happy it makes me that people actually care about this. I wrote some memory hacks about a year ago for both of these games to center the HUD in eyefinity and widescreen, but I never managed to implement them very well. They worked, I just didn't really have an elegant delivery system for them.

As I said, someone else has done the work, someone with programming ability just needs to re-implement it.

These games were a huge part of my childhood, and I'd love to be able to play them again in eyefinity.

from openjk.

@eezstreet Yeah, it works okay in widescreen, but the HUD is stretched, and it's stretched in Eyefinity too, where it becomes one hell of an eyesore, and also nearly unusable.

from openjk.

Hud stretching in widescreen is hard to fix. At least universally. We can fairly easily create a 16:9 and a 16:10 hud-mod, but writing a hud system that allows for arbitrary resolutions is a lot harder.

The "show any existing menu only on center screen" thing... yeah, that's a mod thing. We can't magically make it work in mods. But @eezstreet, I think we should put this into the modbase.

from openjk.

Fixing it automatically is hard to fix, yes, but if you just make the values for width and location more accessible, it'd be enough. I wrote a fix to center the HUD in eyefinity, just spent some time in cheatengine finding the location of the width value, divided that by 3, and found the location value nearby, incremented that by 1/3 the screen resolution.

Really, all I want/expect is an entry in a cfg to let me set the width and location of the HUD, right now I have to use memory hacks, which are a real pain to write and implement, not to mention deliver.

I'll post my cheatengine notes if they'll help, they should list the values that need to be modified.

from openjk.

Yeah, that's just how I understood it.

I know this is possible

We've got the full sourcecode, anything is possible.

from openjk.

Managed to get my CheatEngine scripts working again

Before fix:
http://i.imgur.com/xToe12sh.jpg
After fix:
http://i.imgur.com/3MR1bNCh.jpg

from openjk.

Most impressive. Care to share how you accomplished this hack? I am familiar with CheatEngine, but I've never done anything like this with it. o_O

from openjk.

http://pastebin.com/NpV9vgwf
http://pastebin.com/XeyR9sjg
http://pastebin.com/AZDwPinu
http://pastebin.com/qVA3psNP

That's how. Find the HUD width, divide by three, then you have to get dirty with assembly to push it to the middle.

from openjk.

How about porting this to OpenJK? ;)

Sent from my Windows Phone

From: Jacob M. Davismailto:[email protected]
Sent: ‎4/‎11/‎2013 10:18 PM
To: Razish/OpenJKmailto:[email protected]
Cc: eezstreetmailto:[email protected]
Subject: Re: [OpenJK] Feature Request: Widescreen/Eyefinity Support (#36)

http://pastebin.com/NpV9vgwf
http://pastebin.com/XeyR9sjg
http://pastebin.com/AZDwPinu
http://pastebin.com/qVA3psNP

That's how. Find the HUD width, divide by three, then you have to get dirty with assembly to push it to the middle.

Reply to this email directly or view it on GitHub:
#36 (comment)

from openjk.

That's what I'm asking for. I'm not skilled enough to do this myself. Big difference between dirty memory hacking and actual programming.

from openjk.

Ill take a look at this tonight unless someone beats me to it.

from openjk.

We may want to wait until #60 is resolved and the game has some sort of understanding of multiple monitors. It could affect how we determine when/how to scale the HUD.

from openjk.

You are probably right Razish, any fix for this issue may need to be changed once multi-monitor support is implemented. Will hold off for now then :)

from openjk.

I'd say just have a cvar for the 2d size and position, then apply that to all 2d rendering done. All menus should be done via StretchPic2D or what it's called, and end up in the renderer in the end.

Example: Say you have 3 FullHD screens. You'd then set hud_xoffset 1920 and hud_xsize 1920 and the Hud and all menus would only be rendered on the center screen. Automatic setup is not really required. This does not fix the widescreen issues, but widescreen can be done with a menu mod for the time being, until we have a new, improved GUI system.

from openjk.

I agree with mrwonko, just make some easy to access cvars, maybe give us a way to change in a menu, along with an fov slider? That's all I can realistically ask for. If someone wants to charge ahead and make this all work automatically, that's just icing on the cake.

from openjk.

I had a look at this and it is easy to implement, mostly. My 'problem' is, I can fix all of the 2d rendering with a change to the back end renderer except the console (which calculates the font size in the cgame dll rather the exe).
This would break mods, which replace cgame.

If you want to change it in your local copy just change the qglViewport call in RB_SetGL2D in tr_backend.cpp, as this is what controls everything 2d that is rendered by the backend renderer. (See http://imgur.com/ORddguO)

from openjk.

The solution to this probably isn't as simple as people think.

One way would be to fake it, and create a single window which covers all monitors, but then how do you implement v-sync if different monitors have different refresh rates? With a single window, the faster monitor will be required to wait for the slower monitor.

The other way (which I believe is the correct way), is to create a window for each monitor, and adjust the camera 'frustum' for each screen to show the relevant part of the game. Obviously this would require a lot more work.

I may be wrong on some of this though :p

(I'm also removing the milestone as a result of this)

from openjk.

I may be wrong on some of this though :p

You are. The nice thing is that the driver takes care of all that. To the application, it just looks like a single screen with a huge resolution.

from openjk.

What if each monitor is driven by a different graphics card (with different vendors)?

from openjk.

This was always about ATI's Eyefinity, right? Of course a universal solution would be more work.

from openjk.

Well, the issue mentions widescreen support too :/

from openjk.

Okay, you are overthinking the solution by no small margin. There's absolutely no reason to reinvent the wheel, we already have driver solutions like AMD's Eyefinity and nVidia Surround. For people who want to go nuts mixing cards and monitors, there's SoftTH, all that needs to be done here, is to make the HUD boundaries adjustable, and possibly make it easier to select custom resolutions, but that's just icing on the cake, since we can do that via cvars in the cfg already.

I mentioned widescreen support because the game's HUD is screwed up in widescreen resolutions as well. Not as big of an issue there, but it's still a flaw, and I've seen much less important bugs squashed in this project already.

Literally all that needs to be done is to give an easier way than memory hacking, to adjust the HUD size and span so it's all centered nicely and not stretched across all three screens and unusable.

from openjk.

Did a quick search, and SoftTH only works with Direct3D games, as well as requiring Windows 7. But I suppose if the game can see the monitors as one massive screen (for same-vendor cards) then that makes things easier. I suppose the HUD adjustments are easy enough though

EDIT: What happens on menu screens? Does the menu get shown only on the central monitor?

from openjk.

SoftTH is being open-sourced, and will likely be updated to support a greater variety of setups, including DX10+ and maybe even OGL.. If someone wants to implement some complicated multimonitor support for that minority within a minority in this project, that's fine.

But that seems kind of ridiculous when there's already several solutions that are more widely-used, and are vastly easier to support. Minecraft is the only game I know of offhand that works with such a setup, anyone truly interested in triplehead gaming would use eyefinity, surround, or at least a Matrox TH2GO. Either way, this issue is about the majority of triplehead users, all we need is a HUD fix. Easier resolution changing is icing on the cake.

from openjk.

If someone wants to implement some complicated multimonitor support for that minority within a minority in this project, that's fine. [...] Minecraft is the only game I know of offhand that works with such a setup

Supreme Commander is another one. But as mentioned we don't need to do anything quite that complicated. (Well, personally I would need it - I'm on a HD6000 series card with 3 differently-sized screens of which one is rotated - eyefinity does not like rotated screens pre-7000-series. But just ignore me.)

from openjk.

Go to your local Goodwill, look for a bunch of similarly sized monitors, I've found a bunch of 19 inchers with the same AR, and even the same resolution for 15 bucks a pop. If there aren't any, just keep visiting weekly, you'll find em eventually. And how big a difference in monitors are we talking here?

from openjk.

Way to derail a thread, eh? I don't think I have a local Goodwill here in Germany. But I'm fine with my setup and actually like having one of my screens rotated. A website with a fixed width of <1000 (like, say, Github) is much more visible in portrait mode. But since you asked, I'm using 1280_1024 17" PN + 1050_1680 20" PN + 1920 * 1080 23" IPS, which is actually quite nice since they have roughly the same DPI. Just not suited for surround gaming.

A good surround gaming implementation would, besides allowing for rotated screens:

• let me only use only part of a screen (say I only want to have 1080 pixels vertically, not 1680, since most of the additionally rendered image would not end up on any screen anyway, I'd waste 1920_600+1280_656 pixels), or, even better, not render the invisible parts in the first place - a solution that just renders a big image and then displays parts of it on each screen is much easier to implement though
• move the center so it's actually centered on my central screen despite the outer ones having different widths
• Have the HUD not be at the very sides but on the central screen - which is what this thread is mostly about
• Taking it even further - this is where it may start to have serious impact on the balance though - it would allow me to define the physical position of my screens in relation to my eyes. For normal use I don't have my screens in a plane, the outer ones are rotated so they too face me, so the game should not render as if they were on a single plane. This makes just rendering one big image impossible since you need to use different projection matrices. This would allow you to mimic a CAVE, too.

from openjk.

Ahh, yeah, probably no GWs in Deutschland, but whatever charitable or otherwise thrift stores are available.

A better solution for you would probably be SoftTH when it's available for OGL, the amount of work that would go into supporting all this stuff in JK itself would be insane. Personally I have 3x landscape 19 inchers all next to each other, and a 19 incher in portrait mode for all the things I want to be able to see while in-game. Might be best to just sell off the monitors you have and start fresh, multi-monitor gaming works much better when you're using similar monitors.

from openjk.

Unless OpenJK changes to a GPLv3 license, SoftTH's license isn't compatible with ours unfortunately.

from openjk.

Where do licenses come into play? SoftTH is an external mod, as of now, it (theoretically) works in any old DX9 game. You don't have to implement at the source code level, it'll work with binaries. Wouldn't be much use otherwise.

from openjk.

Good point :p

from openjk.

SoftTH is GPLv3? Then you mustn't use it with any non-GPLv3+ games, as per the GPLv3 license.

from openjk.

That's not how it works, it's designed to work in any closed-source, compiled, DirectX game. It's not something you implement in source code. The license, AFAIK is for the source code of SoftTH, which was recently, or will soon be released. Author doesn't want some asshole charging for it.

from openjk.

For reference: http://www.kegetys.fi/forum/index.php?topic=2123.0

This is the hack itself. It will likely be improved upon by other people, since the source code is available here:

http://www.kegetys.fi/forum/index.php?topic=3176.0

I am not a lawyer, but I am 100% sure that the license only pertains to the source code, and derivatives of the hack, to prevent someone from making a bunch of improvements, then throwing up a pay wall. The hack itself can be used however you'd like. It would be entirely useless if it was limited to GPLv3 DirectX games (How many can you name?) and he demos it with a bunch of games that are certainly not GPLed.

from openjk.

That's not how it works, it's designed to work in any closed-source, compiled, DirectX game. It's not something you implement in source code.

I know. The GPL does not care. You mustn't use GPL Modules in non-GPL programs and vice-versa, and adding proxy DirectX DLLs - which is how I assume it works - counts as a module as far as the GPL is concerned. The entire point of the GPL is to force anybody using it in any way (except starting a program) to use it himself.

I'm sure the creators of SoftTH didn't intend this - they likely just don't understand just how radical the GPL is.

from openjk.

Either way, it's up to the end user to install the mod, so litigation is a non-issue.

from openjk.

@mrwonko

You mustn't use GPL Modules in non-GPL programs and vice-versa, and adding proxy DirectX DLLs - which is how I assume it works - counts as a module as far as the GPL is concerned

It would count as a System Library, which is fine to link.

from openjk.

Anybody interested in this?

from openjk.

Unless there's a GPLv2 compatible way to do this, should we keep this issue open?

from openjk.

Let me reiterate, SoftTH is NOT required for this, at all. SoftTH is a user-side solution. We need to fix the HUD, and preferably make it easier to switch resolutions. SoftTH is entirely unrelated. Some quick and dirty logic for fixing the HUD:
if AspectRatio > 1.6 then
HUDwidth = currentres / 3
HUDposx = currentres / 3

Obviously that's not necessarily the cleanest solution, but I'm just trying to make a point.

Forget about SoftTH, it's NOT needed in any way, don't worry about it. It's not a game-side solution to this problem. It's for users without a Matrox Triplehead2Go or Eyefinity/Surround.

from openjk.

You would still require changes to the cgame/ui. So existing mods and proper base won't be able to magically be fixed HUD or menu wise.

from openjk.

I, and many others, just want to be able to play the base games in triplehead properly. If mods want to fix themself for triplehead, that's fine.

from openjk.