Forums » Suggestions
A fix for which Linux?
A fix for Arch linux? A fix for Gentoo Linux? A fix for... Pandebian?
Yes, you have not heard of the last one. I am sure, but it exists. You want the VO devs to fix a problem that isn't theirs? How about you ask all the Linux's to fix it first? Or just fix it yourself. (or how about asking in the correct forum, the Linux one).
How about stating an actual problem, and how you tried to fix it? Maybe some people will give you help on your problem. Because I can do what you are asking in Linux, but you are thinking it is a problem for the devs of this game.
How about if you cannot handle the Linux OS (there will always be some tweaking to do) you just go back to Windows dude? What flavour of Linux are you using? I would put my money on some form of Ubuntu....
A fix for Arch linux? A fix for Gentoo Linux? A fix for... Pandebian?
Yes, you have not heard of the last one. I am sure, but it exists. You want the VO devs to fix a problem that isn't theirs? How about you ask all the Linux's to fix it first? Or just fix it yourself. (or how about asking in the correct forum, the Linux one).
How about stating an actual problem, and how you tried to fix it? Maybe some people will give you help on your problem. Because I can do what you are asking in Linux, but you are thinking it is a problem for the devs of this game.
How about if you cannot handle the Linux OS (there will always be some tweaking to do) you just go back to Windows dude? What flavour of Linux are you using? I would put my money on some form of Ubuntu....
I'm guessing this has something to do with this thread, and maybe also this one.
I'm open to trying to improve the Linux video/sizing/windowing support. But people need to articulate exactly what is desired, and what the ramifications are of that change, in terms of backwards compatibility with older distributions. So, the OP here is unhelpful, because wash doesn't really know what method to request here, or what the ramifications would be for other people.
The problem on Linux has always been a lack of a standardized way of doing things (like video modes, or window resizing), and instead a bunch of varied hacks that people kinda-sorta use, that work on some systems and not others. These hacks and tweaks evolve over time, but the fact that Steam doesn't even support automatic window-resizing gives some impression that we aren't the only ones who try to aim for the "most compatible" route.
So, yes, we could totally auto-detect things on the OP's specific system, and that would probably then break someone else's system / distribution / wm, like Yoda mentions.
Now, we haven't touched the Linux video mode / windowy stuff in some years, I imagine things have evolved, perhaps to a different set of not-entirely-standard concepts.
If someone has some specific goals for things we can do to help improve the game on basically all recent-ish linux (say, common distributions running 3.x kernels or newer), I'm game to try that.
But, understand that it will not be the highest priority. In terms of things that are best for the game, opportunities like being an early-mover on VR don't come along very often, and include things like massive marketing backing by some of the largest companies on earth. "Fixing" Linux videomodes (for some people), while a good thing, does not exactly present the same level of opportunity for VO, as a whole.
I'm open to trying to improve the Linux video/sizing/windowing support. But people need to articulate exactly what is desired, and what the ramifications are of that change, in terms of backwards compatibility with older distributions. So, the OP here is unhelpful, because wash doesn't really know what method to request here, or what the ramifications would be for other people.
The problem on Linux has always been a lack of a standardized way of doing things (like video modes, or window resizing), and instead a bunch of varied hacks that people kinda-sorta use, that work on some systems and not others. These hacks and tweaks evolve over time, but the fact that Steam doesn't even support automatic window-resizing gives some impression that we aren't the only ones who try to aim for the "most compatible" route.
So, yes, we could totally auto-detect things on the OP's specific system, and that would probably then break someone else's system / distribution / wm, like Yoda mentions.
Now, we haven't touched the Linux video mode / windowy stuff in some years, I imagine things have evolved, perhaps to a different set of not-entirely-standard concepts.
If someone has some specific goals for things we can do to help improve the game on basically all recent-ish linux (say, common distributions running 3.x kernels or newer), I'm game to try that.
But, understand that it will not be the highest priority. In terms of things that are best for the game, opportunities like being an early-mover on VR don't come along very often, and include things like massive marketing backing by some of the largest companies on earth. "Fixing" Linux videomodes (for some people), while a good thing, does not exactly present the same level of opportunity for VO, as a whole.
Out of curiosity, can you give a rough market share of which linux distros are used by VO players? (if the client reports it)
In my environment, almost everyone is on debian/ubuntu and derivatives, and this is sort-of confirmed by distrowatch, but I guess this could be quite different for different communities?
In my environment, almost everyone is on debian/ubuntu and derivatives, and this is sort-of confirmed by distrowatch, but I guess this could be quite different for different communities?
Specific goals for improvement:
1. Download Minecraft for Linux. It's a jar file. Run it from the command line.
2. Resize the window that opens and make it full screen.
3. Press F3 and see that it's detecting display size.
4. Build a shelter to hide from zombies at night while you make VO window resizing work in the exact same spectacular way.
1. Download Minecraft for Linux. It's a jar file. Run it from the command line.
2. Resize the window that opens and make it full screen.
3. Press F3 and see that it's detecting display size.
4. Build a shelter to hide from zombies at night while you make VO window resizing work in the exact same spectacular way.
I know that for multi-monitor configurations there have been essentially two competing approaches for a while, though I'm not sure if that is still the case.
1. Xinerama. I think ATI preferred this (I don't know what AMD is doing now)
2. Nvidia's Twinview
3. RandR appears to also provide some level of multi-monitor support.
I don't know how all of this comes together for detection of monitor modes. The weird part comes when you consider that not all monitor configurations are going to be laid out with gaming in mind.
For instance, my current configuration is
Physical
[2][1]
Logical
[1][2]
All that said, the game already detects the full resolution for both of my monitors combined (3328x1152), and I'm using Twinview.
1. Xinerama. I think ATI preferred this (I don't know what AMD is doing now)
2. Nvidia's Twinview
3. RandR appears to also provide some level of multi-monitor support.
I don't know how all of this comes together for detection of monitor modes. The weird part comes when you consider that not all monitor configurations are going to be laid out with gaming in mind.
For instance, my current configuration is
Physical
[2][1]
Logical
[1][2]
All that said, the game already detects the full resolution for both of my monitors combined (3328x1152), and I'm using Twinview.
Out of curiosity, can you give a rough market share of which linux distros are used by VO players? (if the client reports it)
In my environment, almost everyone is on debian/ubuntu and derivatives, and this is sort-of confirmed by distrowatch, but I guess this could be quite different for different communities?
No, we don't detect / report distro statistics.
I would wager it is vastly on the side of Ubuntu, along with the fact that we used to be distributed in the Ubuntu Software Center for awhile.
But, I know a lot of our veteran Linux users are not on Ubuntu. I don't know how grumpy said people would be if we focused our automation efforts purely on that distro.
1. Download Minecraft for Linux. It's a jar file. Run it from the command line.
2. Resize the window that opens and make it full screen.
3. Press F3 and see that it's detecting display size.
4. Build a shelter to hide from zombies at night while you make VO window resizing work in the exact same spectacular way.
The trouble is that I need to know how it's going about doing that, not just that it does it. We don't have a lot of time in general, right now, let alone time to research the tradeoffs of various Linux video/window-detection implementations. That's why I was suggesting that people who want this to happen.. come up with some specific methodologies, and their compatibility tradeoffs, and link to that information. That will be the most likely strategy for accelerating implementation.
We know what people "want", but that is meaningless without some sort of.. matrix of different ways of achieving that, and what the problems are of doing so.
In my environment, almost everyone is on debian/ubuntu and derivatives, and this is sort-of confirmed by distrowatch, but I guess this could be quite different for different communities?
No, we don't detect / report distro statistics.
I would wager it is vastly on the side of Ubuntu, along with the fact that we used to be distributed in the Ubuntu Software Center for awhile.
But, I know a lot of our veteran Linux users are not on Ubuntu. I don't know how grumpy said people would be if we focused our automation efforts purely on that distro.
1. Download Minecraft for Linux. It's a jar file. Run it from the command line.
2. Resize the window that opens and make it full screen.
3. Press F3 and see that it's detecting display size.
4. Build a shelter to hide from zombies at night while you make VO window resizing work in the exact same spectacular way.
The trouble is that I need to know how it's going about doing that, not just that it does it. We don't have a lot of time in general, right now, let alone time to research the tradeoffs of various Linux video/window-detection implementations. That's why I was suggesting that people who want this to happen.. come up with some specific methodologies, and their compatibility tradeoffs, and link to that information. That will be the most likely strategy for accelerating implementation.
We know what people "want", but that is meaningless without some sort of.. matrix of different ways of achieving that, and what the problems are of doing so.
The trouble is that I need to know how it's going about doing that, not just that it does it. We don't have a lot of time in general, right now, let alone time to research the tradeoffs of various Linux video/window-detection implementations. That's why I was suggesting that people who want this to happen.. come up with some specific methodologies, and their compatibility tradeoffs, and link to that information. That will be the most likely strategy for accelerating implementation.
It's a java process, so you should be able to generate stack traces of the running process for a bit more visibility, but you are correct, the challenge there will be determining how it is doing it. To start though, I recommend trying it and observing the behavior so you can try to reverse engineer what it is doing.
It's a java process, so you should be able to generate stack traces of the running process for a bit more visibility, but you are correct, the challenge there will be determining how it is doing it. To start though, I recommend trying it and observing the behavior so you can try to reverse engineer what it is doing.
You guys are making this way more complicated than it needs to be. Just add an option in the config page that lets people input arbitrary numbers for their window dimensions, instead of being locked into whatever the game detects unless we dig up the forum post explaining how to manually edit the config file.
That's really all you need to do. Once we have it set to run in windowed mode at our preferred resolution, we can just drag it over to our preferred monitor and press Alt-F11 or whatever combo our WM of choice uses to fullscreen applications (which is completely unrelated to actual fullscreen mode -- the WM just removes the decorations and then maximizes the window; from the application's POV, it is still a normal window).
@vanatteveldt: Arch Linux here, though I've previously used both Puppy and LFS while playing VO, and I think I was playing around with Gentoo back when I did the trial.
That's really all you need to do. Once we have it set to run in windowed mode at our preferred resolution, we can just drag it over to our preferred monitor and press Alt-F11 or whatever combo our WM of choice uses to fullscreen applications (which is completely unrelated to actual fullscreen mode -- the WM just removes the decorations and then maximizes the window; from the application's POV, it is still a normal window).
@vanatteveldt: Arch Linux here, though I've previously used both Puppy and LFS while playing VO, and I think I was playing around with Gentoo back when I did the trial.
It's a java process, so you should be able to generate stack traces of the running process for a bit more visibility, but you are correct, the challenge there will be determining how it is doing it. To start though, I recommend trying it and observing the behavior so you can try to reverse engineer what it is doing.
The chances of that happening are roughly zero.
Again, if the community as a whole would like to dig into the technical specifics of what solutions work best on all varieties of Linux, we'll be happy to take a look.
I do not have time to do that, nor is it a high enough priority (at all) to merit reverse-engineering some other game.
The chances of that happening are roughly zero.
Again, if the community as a whole would like to dig into the technical specifics of what solutions work best on all varieties of Linux, we'll be happy to take a look.
I do not have time to do that, nor is it a high enough priority (at all) to merit reverse-engineering some other game.
Inc, then use Rin's suggestion.
I agree with Rin. It was a pain to search how to set the damn custom resolution. Copy something here, try it and fail, do that until you finally end up with a working solution.
Cant we just have this set via Options? xsize/ysize/xf86vidmode toggles in GUI?
Or at least have it documented properly somewhere for others, rather than let them crawl trough lots of forum posts?
Also an option to remove decorations would be nice. Currently i have to do this with devilspie.
Cant we just have this set via Options? xsize/ysize/xf86vidmode toggles in GUI?
Or at least have it documented properly somewhere for others, rather than let them crawl trough lots of forum posts?
Also an option to remove decorations would be nice. Currently i have to do this with devilspie.
I also agree with Rin's solution, as it would save some messing about when trying to explain things to others. As long as it doesn't stop my setup working I really do not mind, and I do not think this change would.
Yeah use Rins suggestion
I agree please implement Rins suggestion:
"Just add an option in the config page that lets people input arbitrary numbers for their window dimensions"
Or just allow setting those arbitrary window size numbers in the config.ini file. Currently if I set any non-standard it resets them to the nearest size (or somesuch) :( The game is unplayable in a mixed-display-environment (1x4k, 1x1080p, and 1x1200p) where I just want to play on the 4k screen (it auto-resets it to 6960x2160 and makes unplayable).
"Just add an option in the config page that lets people input arbitrary numbers for their window dimensions"
Or just allow setting those arbitrary window size numbers in the config.ini file. Currently if I set any non-standard it resets them to the nearest size (or somesuch) :( The game is unplayable in a mixed-display-environment (1x4k, 1x1080p, and 1x1200p) where I just want to play on the 4k screen (it auto-resets it to 6960x2160 and makes unplayable).
I suspect a lot of this is due to people needing to fix the window borders overlapping critical controls like the chat window selection controls at the top of the screen or all the buttons that are at the bottom of the screen which are barely reachable before the cursor jumps down to the menu bar under the vo window. Both problems require a custom resolution to fix....
Perhaps creating a way to add a 10 or 15 pixel top and bottom border around the game area might fix the resolution issues for the most part. not a perfect solution but hopefully a lot easier to implement.
Perhaps creating a way to add a 10 or 15 pixel top and bottom border around the game area might fix the resolution issues for the most part. not a perfect solution but hopefully a lot easier to implement.
Meh, just add custom resolution options in the UI! Also a undecorate option (remove WM decorations) would be nice. Thats probably all needed (currently devilspie does that for me).
What Pizzasgood said.
If the game has some kind of requirements for window sizes, enforce those, but don't force the user to use only the resolutions supported by the first monitor the game detects for windowed mode...
For example, if the UI becomes horribly unusable with aspect ratios lower than 5:4, enforce that. If the display has to be at least 800px wide or things won't fit, enforce that.
If the game has some kind of requirements for window sizes, enforce those, but don't force the user to use only the resolutions supported by the first monitor the game detects for windowed mode...
For example, if the UI becomes horribly unusable with aspect ratios lower than 5:4, enforce that. If the display has to be at least 800px wide or things won't fit, enforce that.
PaKettle,
The complaint here is summed up in this image:
I have 3 monitors. One is 1920x1200, the other two are 1440x900 mounted portrait. Clearly the game is showing only the resolution options for the first display it detects, stripping out ones it doesn't like, and ignoring all of the others.
Here's the output of xrandr -q:
DisplayPort-1 connected primary 1920x1200+900+0 (normal left inverted right x axis y axis) 518mm x 324mm
1920x1200 59.95*+
1920x1080 60.00 50.00 59.94 30.00 25.00 24.00 29.97 23.98
1920x1080i 60.00 50.00 59.94
1600x1200 60.00
1280x1024 75.02 60.02
1152x864 75.00
1280x720 60.00 50.00 59.94
1024x768 75.03 60.00
800x600 75.00 60.32
720x576 50.00
720x576i 50.00
720x480 60.00 59.94
720x480i 60.00 59.94
640x480 75.00 60.00 59.94
720x400 70.08
HDMI-0 disconnected (normal left inverted right x axis y axis)
DVI-0 connected 900x1440+0+0 left (normal left inverted right x axis y axis) 408mm x 255mm
1440x900 59.89*+ 74.98
1280x1024 75.02 60.02
1280x800 59.91
1152x864 75.00
1024x768 75.03 70.07 60.00
832x624 74.55
800x600 72.19 75.00 60.32 56.25
640x480 75.00 72.81 66.67 59.94
720x400 70.08
DVI-1 connected 900x1440+2820+0 left (normal left inverted right x axis y axis) 408mm x 255mm
1440x900 59.89*+ 74.98
1280x1024 75.02 60.02
1280x800 59.91
1152x864 75.00
1024x768 75.03 70.07 60.00
832x624 74.55
800x600 72.19 75.00 60.32 56.25
640x480 75.00 72.81 66.67 59.94
720x400 70.08
The complaint here is summed up in this image:
I have 3 monitors. One is 1920x1200, the other two are 1440x900 mounted portrait. Clearly the game is showing only the resolution options for the first display it detects, stripping out ones it doesn't like, and ignoring all of the others.
Here's the output of xrandr -q:
DisplayPort-1 connected primary 1920x1200+900+0 (normal left inverted right x axis y axis) 518mm x 324mm
1920x1200 59.95*+
1920x1080 60.00 50.00 59.94 30.00 25.00 24.00 29.97 23.98
1920x1080i 60.00 50.00 59.94
1600x1200 60.00
1280x1024 75.02 60.02
1152x864 75.00
1280x720 60.00 50.00 59.94
1024x768 75.03 60.00
800x600 75.00 60.32
720x576 50.00
720x576i 50.00
720x480 60.00 59.94
720x480i 60.00 59.94
640x480 75.00 60.00 59.94
720x400 70.08
HDMI-0 disconnected (normal left inverted right x axis y axis)
DVI-0 connected 900x1440+0+0 left (normal left inverted right x axis y axis) 408mm x 255mm
1440x900 59.89*+ 74.98
1280x1024 75.02 60.02
1280x800 59.91
1152x864 75.00
1024x768 75.03 70.07 60.00
832x624 74.55
800x600 72.19 75.00 60.32 56.25
640x480 75.00 72.81 66.67 59.94
720x400 70.08
DVI-1 connected 900x1440+2820+0 left (normal left inverted right x axis y axis) 408mm x 255mm
1440x900 59.89*+ 74.98
1280x1024 75.02 60.02
1280x800 59.91
1152x864 75.00
1024x768 75.03 70.07 60.00
832x624 74.55
800x600 72.19 75.00 60.32 56.25
640x480 75.00 72.81 66.67 59.94
720x400 70.08
(it auto-resets it to 6960x2160 and makes unplayable).
Drazed, are you using the Nvidia blobs? They're the only ones I've seen do that stupid crap. :)
Drazed, are you using the Nvidia blobs? They're the only ones I've seen do that stupid crap. :)
Are you then splitting the image across multiple monitors? I suppose allowing a different resolution for each is possible but I am sure that would be rather taxing for the gpu's If that the case then a custom resolution for each monitor would be the most practical solution.