xrogaan

Or better, submit it as a PR to the main project and get a discussion going on how to improve the software in that way.

Does Ross have both an nVidia and AMD rig? If so, does gamescope behave differently with nvidia than it does AMD? Could it be possible that gamescope simply honor the game's requests to run at a lower resolution? There is no verbose flag with which to run gamescope with. So despite various local tests, I am unable to understand what is going on nor know the true resolution a game's playing at. For instance, neverwinter night will run at a higher resolution but diablo (through devolutionX) doesn't look different at all, and FTL just doesn't like gamescope at all.

So, was the issue an outdated gamescope? Man...

The 12MB binary has probably been compiled with the debug symbols. Bigger, but gives more information when it crashes. When you run glxgears, do you actually see the gears or does it still not work? The situation seems unclear to me. If you get the glxgears window to works, try disabling lutris runtimes: right click on the game in the lutris library select configure in the system options tab, first option should be a disabled "Disable Lutris Runtime". Enable it. And now a word from Linus Torvalds, creator of the linux kernel, about nVidia (16 seconds). Sentiment echoed by the community as a whole. --- What follows is a commentary. Won't be helpful in troubleshooting the issue, but might be nice to know. Those two path shouldn't be relevant unless you are doing naughty things, like manually changing your system. Much like windows, linux has a PATH environment variable. It tells the system where to find binaries. You can see it using a terminal and typing echo $PATH Normally /usr/games comes last, and /usr/bin comes second (after /usr/local/bin). There are useful tools to know what binary is being resolve, as pointed out earlier the which command. But also the whereis command, that will output the manual and all binaries. It looks like lutris is changing the environment enough that gamescope gets confused. Now a point about the naughty things I was referring to. As you point in your message, you are getting confused: which gamescope binary is being run there? While you can do whatever you want, overriding system binaries is generally a bad idea. Instead you ought to use the /usr/local space. Reason is that you'll slowly start to forget which operations you did and how changed your system is, which leads to surprises down the line (if you wait long enough). Other benefit is that you can mount an external drive to /usr/local. Meaning if you wipe your distro, all the custom binaries will remain safe and/or will be able to be used on different computers.

Hello Ross. Nvidia cards being an issue with gamescope is a known problem. Also, I hate invision board and my inability to inline code. The helping bit in your log is the following (the negative integer): That's the value for VK_ERROR_NOT_PERMITTED_KHR. Reading up the documentation about it, we learn that this is returned when: There's something going on with gamescope that makes the driver iffy about the priority requests. I'm not learned enough to know what the priority is, that is if it's a user right to tweak within the system or something entirely internal to vulkan. At first glance it ought to be internal, as it pertain to how the hardware processes go. Being able to ask for specific priorities is one of the strengths of vulkan, as it removes intermediate "framework" layers. Issue comes when the hardware/driver is a little bit hostile to it (vulkan is not a nVidia proprietary tech).

Ross wanted to know if there was a modern port for the engine of terminal velocity. Turns out, there is one: https://github.com/jtrfp/terminal-recall I don't know its worth though.

Unofficial world of warcraft servers were written by looking at the client API calls. I highly doubt those people had access to the server codebase. So it's possible to retro-engineer servers.

Have you tried Perl?

As a preamble: I would have posted this in the serious section, but since I'm an entrenched lurker I do not possess the required amount of posts to be allowed there. If a moderator believes that this topic would be better in another section of the forum, then please feel free to move it with your moderation power. The CJEU (is the Court of Justice of the European Union) had to make a preliminary ruling in a case opposing the Belgian State to Top System SA. The Belgian State (here simplified to the State) wants to decompile a software developed by Top System SA to have to working on their system. This went all around the Belgian courts system to finally reach the CJEU, the conflict started back in 2008. The preliminary ruling answers two questions: Is Article 5(1) of [Directive 91/250] to be interpreted as permitting the lawful purchaser of a computer program to decompile all or part of that program where such decompilation is necessary to enable that person to correct errors affecting the operation of the program, including where the correction consists in disabling a function that is affecting the proper operation of the application of which the program forms a part? In the event that that question is answered in the affirmative, must the conditions referred to in Article 6 of the directive, or any other conditions, also be satisfied? (Note: As I understand Article 6, it limits the range of actions available to the end user to get the software working.) The answer to the first question is that the lawful purchaser of a computer program is entitled to decompile all or part of that program in order to correct errors affecting its operation. And that, to answer the second question, the end user is not required to satisfy the requirements laid down in Article 6 to achieve interoperability. From my understanding it may means that, to get a dead game working again, we can decompile in order to test and resolve issues, and to that effect we're allowed to share information about the process so long as it remains topical. I'm obviously not a lawyer, so my understanding is as limited as any other layman. What do you all think about this?

Hey Ross, you might like this: https://store.steampowered.com/recommender/

Hey Ross, heard your partial rant on the GUI design. You might be interested in this: https://www.deviantart.com/devillnside/art/Slate-2004-847243016 There are more resources in the links of that submission, mostly for windows based theming. Can't really get too exotic unless people rewrite the display server (how windows behave and so on).

You're absolutely right. I can programmatically edit video, pictures or audio if the task at hand is repetitive, however I need a visual aid and the help of a finger pointer if I need to create something new. The pointer can come from the mouse, which is most common, or a graphic tablet. Audio is the bastard child though, probably the easiest of the three that can be altered without a graphical tool. But audacity is definitively more helpful than just text. Some coders also get tired of the keyboard and move to a voice driven interface instead (due to typing related diseases), using code words instead of full english. More on the subject in that video:

CLI aren't faster, at all. They are plainly more powerful for any given task that do not require visual aid, which has the side effect of sometimes being faster. For example, working on a RPGMaker game I need to create a tileset from multiple individual images. For that purpose I can use one line in a terminal to ask a software to collate all images contained in a folder into one, that same task would be longer and a lot more painful if I were to use a graphical tool. CLI as a user interface are unintuitively easy to use, requires a mental map of the task you want to accomplish and a proper understanding of the different available tools. That being said, your mouse driven interface also requires a mental map and accomplish much of the same. Different interfaces for the same outcome. One isn't better than the other, they're just different. CLI people rarely do use their mouses though, everything is driven by the keyboard. So much so that, in the various README and configuration files, they condensed the representation of those keyboard shortcuts to glyph-like symbols hard to understand for the neophyte. Example from emacs, a text editor, that has a keyboard driven interface: https://www.gnu.org/software/emacs/manual/html_node/emacs/Keys.html#Keys ; they explain the C-x thing in the previous chapter about user input (C means control, which is the CTRL key).