Многие игры не сворачиваются, не табаются, глючат при включенном компизе и.т.д. Меня это очень не нравилось. Гугля просторы интернета я наткнулся на чудесный скрипт, под названием xlaunch. Создаем папку
sudo mkdir ~/.scripts
Сохраняем этот скрипт в /home/scripts/xlaunch. Далее выполняем:
chmod 755 /home/scripts/xlaunch
chown your_name_here:users /home/scripts/xlaunch
echo PATH=\"\$PATH:/home/scripts\" >> ~/.bashrc
Далее перезапускаем терминал, переходим в папку с игрой, и выполняем:
xlaunch wine fifa.exe
Все, теперь наша игра запустилась в новом Х сервере. Переключиться обратно на рабочий Х сервер можно комбинацией CTRL+ALT+F1.
Что же это нам дает?
Удобное переключение между игрой и рабочим пространоством, избавимся от глюков игры при включенном компизе, прирост в производительности (да, да. игры запущенные в wine действительно стали быстрее работать).
UPD: Действительно забыл,чтобы на новом х сервере работал звук, выполните:
sudo gpasswd -a username audio
-
Во-первых, можно использовать и startx
Во-вторых надо выполнить "sudo gpasswd -a username audio" чтобы был звук.
-
-
Как именно через startx?
-
-
startx ~/.config/bin/game.sh -- :1
В скрипте можно попутно отключать компиз:
metacity --replace & $@; compiz --replace
А то автор мельком написал про компиз, но не написал что простой запуск 2-го X-сервера будет так же с компизом, который часто замедляет OpenGL приложения, особенно wine-игры.
-
-
Этот скрипт все делает за вас, и в случае закрытия игры так-же закрывает х сервер и.т.д
-
-
Я через startx запускал пару игр и при закрытии X также закрывался. Не вижу разницы. Просто привел альтернативный вариант.
-
-
Я вас не упрекал :)
-
А разве не нужно скопировать скрипт в /usr/local/bin? Иначе как заставить его запустится из папки с игрой?
Кроме того, возвращение на робочий сервер через CTRL+ALT+F7, игра -- на CTRL+ALT+F8.
А так у меня все заработало, спасибо!
-
-
У меня игра на ctr+alt+f8, а рабочее пространоство на ctr+alt+f1.
-
-
интересно, однако. Я думал, иксы всегда на 7 консоли стартуют..
-
-
Иксы стартуют там, где ты им укажешь. Просто 7я консоль по дефолту получается.
Если консоль икс-серверу не указана, то он берёт первую свободную. Обычно, в большинстве дистров по дефолту, первые 6 консолей заняты процессами логина (getty или аналогом), а 7-я свободна, на ней никаких процессов не запущено, вот её иксы и берут.
-
Пользуюсь старичком xgame.
-
у меня не сработало. Пишет xlaunch: команда не найдена. Делал так:
сохранил скрипт в файле /home/samath/scripts/xlaunch
chmod 755 /home/samath/scripts/xlaunch
chown samath:users /home/scripts/xlaunch
sudo gpasswd -a samath audio
Пробовал xlaunch кидать в /usr/local/bin. При запуске, например кс:
xlaunch wine hl.exe
получаю
Starting /usr/bin/wine on DISPLAY 1
и все, больше никаких признаков жизни.
P.S. Вообще на десктопе игры запускаю в отдельном икс сервере другим способом. Но решил попробовать этот, т.к. мой старый метод хреновенько срабатывает на нетбуке - кс запускается с артефактами и играть не возможно.
-
Я делал так:
xinit /usr/bin/openarena -- :1
-
Шикарный скрипт. У меня чуть-чуть попроще, не эффект, похоже, тот же.
В /usr/local/games/bin/ лежат скрипты с таким содержанием:
1
2
3
4
|
#!/bin/bash
X :2 -ac -terminate &
sleep 2
sudo -u gamer LC_ALL=ru_RU.UTF-8 LANG=ru_RU.UTF-8 env WINEPREFIX='/home/gamer/heroes' WINESERVER='/usr/bin/wineserver' WINELOADEr/lib32/wine' WINEARCH='win32' DISPLAY=':2' /bin/sh -c " cd '/home/nerewar/heroes/drive_c/Program Files/Heroes of Might and Magic V /usr/bin/wine 'H5_Game.exe' 2>&1 " |
Игра запускается в отдельном Х-сервере и из под специального игрового пользователя. Ярлыки на скрипты добавлены в wbar для полного удобства.
-
Я криворукий идиот, наверно. Скачал, выполнил, даже в /usr/local/bin положил, но:
%xlaunch.sh wine /mnt/D-Games/Games/Two\ Worlds\ II/TwoWorlds2.exe
Error: can't find launch.sh:
- Is it in you PATH?
or
- Do you have enough right to execute it?
-
-
И с sudo аналогично.
-
-
Удалил расширение и выполнил из папки с игрой: Starting /usr/bin/wine on DISPLAY 1
Но я не один такой, это радует.
-
echo $PATH - покажет какие пути у тебя в PATH. Только по этим путям программа будет выполнена без указания самого пути до программы (или скрипта). В любом случае, никто не мешает указывать полный путь, например, /usr/local/bin/xlaunch.sh wine /mnt/D-Games/Games/Two\ Worlds\ II/TwoWorlds2.exe
-
-
Мне никто и не помешал. но результат тот же или Starting /usr/bin/wine on DISPLAY 1
Т.е. fail
-
-
Понажимай Alt+Ctrl+F[1-8] может просто не происходит переключения на новую запущенную X-сессию.
-
-
Проверял.
-
Вот честно, по шапке бы надавать за такую "инструкцию"
Сохраняем этот скрипт в /home/scripts/xlaunch. Далее выполняем:
chmod 755 /home/scripts/xlaunch
chown your_name_here:users /home/scripts/xlaunch
Далее переходим в папку с игрой, и выполняем:
xlaunch wine fifa.exe
Почему /home/scripts? Этот путь есть у всех?
Зачем chown?
Почему добавив в /home/scripts мы уже вдруг можем вызывать скрипт без указания пути? Это что, стандартный путь для $PATH?
Ну вот честное слово, взялся писать инструкцию - разберись сначала с азами сам, или, если уж настолько лень - то не пиши настолько подробно.
-
Прошу прощения...Когда писал-сильно болела голова(в моем городе заметель, а я уж сильно реагирую на погоду :( )...Только в "нормальном" состоянии понял, что много чего не указал. Естественно, для удобсват нужно создать папку:
sudo mkdir /home/scripts .
-
-
А еще после этого нужно открыть файл ~/.bashrc в текстовом редакторе и прописать:
1
2
3
|
export PATH=$PATH:/home/$USER/scripts
|
и перезапустить терминал, из которого будете запускать свой скрипт.
После таких манипуляций не надо будет писать полный путь к скрипту.
-
Зачем создавать эту папку, когда есть /usr/local/bin ?
-
-
Зачем туда кидать непонятные скрипты, нужные лишь одному пользователю?
-
-
Да, лучше для этого создавать левую папку в /home, добавить её в $PATH... Зачем по-твоему стандартные пути существуют? /usr/local/bin как раз для пользовательских скриптов и программ существует. Не надо изобретать велосипеды. И, если уж на то пошло, и не хочется выносить личные скрипты куда-то там, то и для этого, есть стандартный путь ~/bin - для каждого пользователя свой.
-
-
Неправильно, /usr/local не для пользовательских скриптов, он для:
ПО, которого нет в репозитарии, которое устанавливается локально на данную машину, или на небольшое количество машин, стандартный путь - установка в /usr/local
Пользовательские скрипты устанавливаются именно в пользовательской директории. Я обычно устанавливаю их в директории ~/bin
Почему не нужно устанавливать их в /usr/local/bin?
Потому, что не всегда приходится работать на машине, где работает только один пользователь, не всегда даже права root есть на данной машине.
Когда несколько пользователей начнут класть свои скрипты в директорию /usr/local/bin, очень вероятны конфликты имен и вообще непредсказуемые вещи, типа запустили скрипт, не совсем обратив внимание на имя (оказалось похожим или вообще такое же, а Ваш затерт) и он выполнил совсем не то, что Вы хотели.
Опять таки свои скрипты, это часть рабочего окружения, удобно, когда копируешь свою заготовку для домашнего окружения и вот уже все работает.
Часто домашние директории пользователей и самих пользователей используют для размещения разных проектов на одной и той же машине (Очень удобно!) Там скрипты с одним именем могут выполнять одни и те же действия.
У меня на блоге статеечка есть, которая немного касается тих вещей.
-
-
Там скрипты с одним именем могут выполнять одни и те же действия.
Пардон, седует читать: Там скрипты с одним именем могут выполнять разные действия.
-
Дайте ссылочку на почитать. Можно в личку, а то еще рекламой сочтут.
-
А что делать если home смонтирован с noexec?
-
-
Есть предположение, что тогда это рабочее место, где правят бал администраторы с коими тогда и предстоит обсуждать этот вопрос.
-
Есть мнение, что noexec на скрипты не распространяется. ☺
-
-
$ ./test.sh
-bash: ./test.sh: Permission denied
Вполне себе распространяется.
-
-
k. в следующий раз буду уточнять, что я имею ввиду.
-
$ sh ./test.sh
Вот так.
-
/bin/bash /home/blablabla
?
-
-
$ /bin/bash ./test.sh
Hello world!
А вот это работает.
-
И, если уж на то пошло, и не хочется выносить личные скрипты куда-то там, то и для этого, есть стандартный путь ~/bin - для каждого пользователя свой.
Да ну. А у меня чего-то не работает.... Если конечно не добавить ~/bin в $PATH.
Так что это либо наглое 4.2 либо давайте ссылку на стандарт (или какой-то другой документ).
-
-
А в арче по-умолчанию не работает /usr/local/bin
в стандарте про скрипты в /home ничего не прописано.
вот цитата про /usr/local
The /usr/local hierarchy is for use by the system administrator when installing software locally
Так что пользовательские скрипты лучше кидать туда. Ибо они и есть то самое "ПО, которого нет в репозитарии"
-
-
Не совсем так.
Пользователей может быть много. Каноническая схема:
- иерархия /usr - софт дистрибутива, общий для всех хостов с этим дистрибутивом, ставит администратор
- иерархия /usr/local - софт не входящий в дистрибутив, общий для хоста, ставит администратор
- иерархии /home/$USER - для пользователей, ставят пользователи, каждый себе сам.
Если делать по другому, рано или поздно будут конфликты.
-
-
Другими словами - /usr/local - это то место, куда скидывается то, что не из репозиториев. Для домашней машины пользователь и есть администратор, так что /usr/local - как раз для него.
Если хочешь, чтобы твои скрипты были доступны не только тебе, но и другому пользователю, то в /usr/local/bin - им как раз и место. Не хочешь или нет прав на /usr/local/bin - тогда в ~/bin.
-
-
Есть и еще нюансы.
На пользовательские скрипты не нужно делать sudo
В общем, если общие для всего хоста, то да, /usr/local/bin
Если индивидуальные для пользователя, то $HOME, я обычно делаю $HOME/bin
чтобы не заморачиваться, это всем ясно.
-
-
Так и на скрипты в /usr/local/bin не надо делать sudo. Для тех скриптов/программ, которым обязательно нужны права root - есть */sbin
-
-
Это же пользовательские скрипты, иэ нужно редактировать, добавлять.
-
-
Для домашней станции проблем с добавлением и редактированием быть не должно - здесь каждый сам себе админ и права рута есть если не у самого пользователя, то у папы/брата/дяди - точно. В остальных случаях добавлять скрипты для всех пользователей и не нужно, хватить и ~/bin
-
Вот значит диру в /home добавить в $PATH - можно, а ~/bin - это ж так сложно.
-
-
Да, лучше для этого создавать левую папку в /home, добавить её в $PATH... Зачем по-твоему стандартные пути существуют?
Это ведь ваши слова, так ведь? :)
-
-
Вот именно. ~/bin - это стандарт, во многих дистрах оно отключено по-умолчанию, но от этого оно не перестаёт быть стандартным местом для пользовательских скриптов. А всякие /home/scripts - это изврат.
-
-
Пруфлинк то будет или нет? Или номер стандарта. Это HFS или POSIX какой?
-
-
То, что есть надо ртом, а не задницей - стандарт, хотя и не записано ни в каких ГОСТах...
-
-
Есть ртом - это врожденный инстинкт. А стандарт - это документ (соглашение), созданое при участии заинтересованных экспертов конкретной области, определеяющее, как все эти люди будут работать в этой области.
Спокойнее надо быть. И подтверждать свои слова фактами.
-
-
Ну вот и подтверди мне, что есть ртом - врождённый инстинкт, ок?
-
-
Врожденные инстинкты-это аксиома, так что вы не правы. В обоих случаях, потому, что ссылку на стандарт так же не предоставили. Поэтому дальнейшее обсуждение этого вопроса с вами не целесообразно.
-
Автор, поправь шапку
sudo mkdir /home/scripts
Во-первых в шапке уоманда md, которой не существует
Во-вторых, более трушно сделать mkdir ~/.scripts
echo PATH="\$PATH:/home/scripts" >> ~/.bashrc
Лучше заменить на
echo 'export PATH=$PATH:/home/$USER/.scripts' >> ~/.bashrc
Т к я лично не понял смысла экранировать кавычки, да и слово export вроде нужно.
#к сожалению, у самого .bashrc давно удален случайно. Как-то живу без него ;)
-
Единственное что не поборол-это переключение языков...Использует язык по-умолчанию, и не хочет переключаться.
-
-
Там же новая сессия, придётся вручную/через скрипт запустить stexkbmap/gconf-daemon/kde-config-daemn/whatever.
-
-
Всетаки не понял. У меня гном. Можите привести пример скрипта?
-
-
Скрипт старый и в нём многабукаф, лень разбирться. ☺ Нужно добавить вызов gnome-settings-daemon перед загрузкой игры на соответствующем дисплее.
-
Запускаю в отдельном икс-сервере openbox, а из его меню нужную игру. Так же в меню добавил пункт "Logout", который убивает игровые иксы. Удобнее ничего не видел.
-
-
Я использую awesome, запускую игру в оконном режиме, с размером окна в размер экрана, на отдельном теге. Делаю его на весь экран и управляю им средствами вм. Никаких лишних сущностей. Удобнее ничего не видел. ☺
-
-
В большинстве случаев поступаю так же, но некоторые игры плохо уживаются с WM, особенно таким необычным, как awesome. Вот для них и приходится запускать отдельно голые иксы с игрой в качестве главного клиента.
|
|
|
  |
|
Последние посты
|
|
|
Последние комментарии
|
|
|
Изменения
|
   |
|
Черновики (все)
|
|
|
Избранное (всё)
|
|
|
