Linux - X windows, problem with multible screens

[/dev/null]

The guy asked if there was a way to make sdl aware of the resolution, you said MAKE A METAMODE, which has nothing to do with sdl, and makes it so you cant use multiple monitors, its a shitty solution, and you are unwilling to try and make it better. Why? I dont know, I can only think of two options, either you dont have a damn clue how to fix it, or you are too lazy to do so. Neither mesh well with how you have responded to the question though. Im an arrogant dick and im well aware of the fact, so are all of you. I dont lie though, and I certainly dont make up shit just so I dont have to answer questions.

[/dev/null]

Your inability to use metamodes is stupid and lazy, you could literally use a bash script to get aware of what you are running on and what it can do, you choose not to. I dont get why other than you just wanting to spend another two years updating shit that has no effect on the game besides adding uneeded complexity. Im gonna take a wild guess and say you and lukejr are boys. Add lots of pointless shit, ignore basic functionality.

Maybe that selling hosting will work out for you *****, im guessing its going to fail miserably and youll rip off a lot of good people just to make money.

[delinquent]

lukejr is long gone.
You are an arrogant arse.
Valid point, but don't turn it into an argument.

Bash script? How does that work with windows?

[Z-Man]

Again, you are entirely correct. I am a 14 year old boy. Started this game around my first birthday when daddy got me a 'my first C++ program' book.

So, do you want to keep complaining and make stupid assertions, or do you actually want to help? If you want to help, give the name and possibly source code link to a game that does this 'correctly'. Otherwise, the only viable solution I can offer is the one already detailed: query screen modes, use SDL in windowed mode with adapted settings, maybe give the WM some hints to render the window quickly. As you correctly state, I am lazy (though I like to call it efficient) and do not want to deal with the ugliness of X11 window management for a small minority of players.

[/dev/null]

xrandr has plenty of useful text output you could parse with fairly simple regex and import into your own silly system if you are unwilling to call it directly. Asking that tron stops using a 15 year old system isnt arrogant. Pretending that its perfectly fine because it still does is pretty ignorant though.

How many of us still play games written in basic? Why should we just say its fine that they dont want to fix basic issues with how tron is done?

EDIT: I cant spell for shit

[/dev/null]

They are saying they cant reliably find a systems supported monitor modes, and Im calling bullshit. Every os tron runs on has a simple way to find that out. It just isnt ancient sdl shit, they already require xml support, seems stupid they are unwilling to add the libraries that tron already requires in order to at least parse it, if they dont want to access it directly.

Hmm the bash script on windows thing is a valid point, but im pretty sure it requires a paragraph of extra code at most to pull windows screen modes, windows is quite good at that kind of thing.
From what I can tell, they would rather ignore better options, and just dirty hack this game into obscurity, the last major revamp was almost ten years ago now

[/dev/null]

Basically every opengl game understands X screen modes btw, its silly you needed me to point that out. For making nix games you dont seem to play any of them.

EDIT: Shit, even stuff through wine is aware of the screen mode.

[Z-Man]

If you want to help, give the name and possibly source code link to a game that does this 'correctly'.

I do not currently have my second monitor hooked up for testing and do not have time to check "every other game"'s code.

[/dev/null]

Ive got a few monitors that only need a few cheap capacitors replaced, Ill send you one and pay for shipping if you are willing to test this and attempt to fix it. Should only be about five bucks in components, easily purchased from monoprice, im just broke as **** lately so I cant buy them. As for games that do it right, vendetta online, all of the quakes, all of the uts, even most windows games through wine. Shit even all the sdl based tux* games do it correctly. Arma is one of the few that dont. You arent one among many, you are a diamond in the rough.

[Bytes]

I feel that last point would have been more poignant were it not normally a compliment...

[Z-Man]

My monitor supply is fine, the spare one just serves other purposes right now (setting up a new VDR), once that is done, I'll move it back and set it up. Or move my laptop over to either monitor or the TV. Aren't Vendetta and the Unreal Tournaments closed source? If so, no information gained from there. I'll certainly check the Quakes. I remember checking on Tux Racer a while back (>5 years), it behaved exactly like Arma. No metamodes, no dice, and with metamodes, you could get it to run on one screen of your choice with the other blanked. I'll check again, 'course. The other tux games you're referring to would be Tux Cart and Supertux?

[/dev/null]

the uts run on the various unreal engines, which are pretty well documented, the tuxs on gentoo at least seem to behave better than tron. Quake would probably be the best option to look at, since its open source now. Unfortunately, I just realized that it and ut are opengl games, not sdl.

[Z-Man]

Had a look at Extreme Tux Racer. They don't use RandR, they don't use Xinerama. They just use SDL in the same way we do, with the same result for me: if I don't set up my metamodes, I get the view stretched across both screens. If I do set them up, I can get it to play on one screen while the other goes dark (or, if I feel like it, mirrors the first).
Now, I found one constellation where Arma does worse: the zero-install version 0.2.8.3.2, that one has a bugged loader and insists on using the outdated SDL libraries it comes with instead of the system libraries. There, 1280x1024 fullscreen sits in the center of the dual-screen setup, so takes up half of each screen. I'll try to push an update for that sometime soon, but no promises, the build system changes make a proper build a bit too risky for my tastes, so I may have to manually patch things.

I will continue looking at the other games, obviously, but nevertheless, two questions:
1. Which versions and builds of Arma cause you problems? Maybe it's just a simple library problem like the one I encountered.
2. What are those problems exactly and what do the other games do in the same situation? You haven't exactly told me that yet, and I still can't find a difference myself with a proper arma setup.

[/dev/null]

I feel I should bring this back up, since the recent sdl2 port of tron has none of the issues I was bitching about. You guys might want to invest some time into not using ancient shit

[/dev/null]

The real cuntfucker, is Im pretty sure I told you asses to use sdl2, and you told me it was impossibru. Which is obviously wrong as shit, since he pulled it off with slight changes to the makefile.

This reliable resistance to useful changes, while wholeheartedly embracing useless changes like xml, is why I no longer have any ******* faith in you guys anymore. You ignore longstanding issues with tron in order to focus on cosmetic bullshit. I can still drive right through ******* corners, but you guys never bothered to fix that, since everyone plays high rubber now, and cant grind for dick.

You might as well sell respawns on the android market.

The double best part is, no one ever cares what I say, so this will get buried in a pile of bullshit until the next they ignore something useful and I bring this up again.