# Странность в поведении приложения в wine

## r90

Есть ситуация: игра запущенная под wine лагает, когда запущена одна её копия, и не лагает, когда запущено две копии. Интересно знать как выяснить в чём дело, и можно ли играть без лагов запуская лишь один процесс игры.

Чуть более подробно. Игра называется Carmageddon TDR2000. Система amd64, но для того чтобы запустить tdr'ку, я собрал 32-х битное chroot окружение. Куча mount -o bind, позволяет мне оттуда запускать X-приложения, в частности и tdr'ку. Видяшка у мну ati 4850, крутится на gallium r600 (media-libs/mesa-9.0). Что ещё может иметь отношение?... app-emulation/wine-1.5.15-r1.

Если запустить две копии игры, то игра идёт нормально, без лагов. FPS оставляет желать лучшего, но играть возможно. Если же запущена одна, то из-за лагов играть становится невозможно. Проверку того, что дело именно в двух процессах я проводил таким образом:

1. запускается TDR2000, начинается гонка. Лаги.

2. переключаюсь в терминал, запускаю вторую копию, переключаюсь обратно на #1 процесс. Лагов нет.

3. переключаюсь в терминал с процессом tdr200.exe #2, Ctrl-Z, bg; sleep 10; echo -e '\a'; kill %1. Переключаюсь обратно на TDR2000.exe#1, лагов нету десять секунд, затем бип и тут же лаги появляются.

Процессы #1 и #2 были запущены существенно в разных wine. То есть #1 из chroot'нутого wine с явно указанным WINEPREFIX=$PWD/tdr2000winedir, #2 запускался без всяких chroot'ов и WINEPREFIX я не трогал, то есть использовалось значение по умолчанию $HOME/.wine. Не знаю, играет ли это роль, не проверял ещё. Если у кого-нибудь есть подозрения что это важно, я могу попробовать позапускать под разными пользователями или из одного терминала.

Да, и насчёт других способов избавиться от лагов: я не знаю других способов. Запуск второго процесса для избавления от лагов был жестом отчаяния. У меня кончились идеи на тему "что ещё может влиять". Со всеми настройками графики, звука, игрового процесса, записи replay, etc-etc-etc, я игрался достаточно долго и не заметил никаких корреляций. Я прибивал boinc, firefox, fluxbox вообще всё прибивал, оставлял лишь urxvt запущенный командой "xinit `which urxvt`", это не помогало. Пару раз, игра запускалась без лагов, причём, как минимум один из этих разов, всё происходило при запущенном firefox и boinc. У меня возникло подозрение, что чем больше загружена система, тем меньше лагов, и я запустил второй процесс. Оглядываясь назад, я не возьмусь утверждать что когда TDR2000.exe запускался без лагов у меня не было второго процесса TDR2000.exe. Дело в том, что иногда я находил в ps aux недобитые TDR2000.exe (хрен знает как так получалось) и прибивал их. Но тогда я был твёрдо уверен что чем больше процессов, тем больше лагов, и поэтому специально не отслеживал корреляций.

Теперь собственно вопрос, точнее их два:

1. сугубо практический вопрос, как бы сделать так, чтобы не запускать второй процесс?

2. вопрос порождённый любопытством: есть идеи как можно выяснить мотивы такого поведения TDR2000.exe?

----------

## burik666

Вы извращенец.

Соберите wine с флагом win32

```
#!/bin/bash

export WINEPREFIX="~/wine_32"

export WINEARCH="win32"

wine /path/to/carma.exe
```

----------

## r90

 *burik666 wrote:*   

> Вы извращенец.

 Сказал бы я кто тут извращенец. Я иду простейшим путём.  :Wink: 

 *burik666 wrote:*   

> Соберите wine с флагом win32
> 
> ```
> #!/bin/bash
> 
> ...

 Он и так собран с флагом win32. На платформе amd64 TDR2000 не пашет как надо из-за устарелости содержимого emul-linux-x86-opengl. Я пытался подключая всякие разные оверлеи исправить это, но прям так "искаропки" оно не заработало, и я решил что chroot проще.

Если же на emul-linux-x86-opengl, то там просто убитая графика. Но... Я раньше не подумал, но вероятно при таком подходе лагов мне наблюдать не удавалось. Попробую навести "статистику" запусков так и в chroot, чтобы посмотреть зависимость.

А с чем это может быть связано? Я это спрашиваю к тому, что не считаю извращением использование chroot для запуска wine32. wine32 регулярно требует каких-то 32-х битных библиотек, а пакеты emul-linux-x86-* -- это достаточно уродливое решение проблемы, и, что хуже, не всегда работающее. Так что chroot -- это один из двух "правильных" способов. Второй "правильный" -- это оверлей multilib. Но на деле, этот второй лишь кажется "правильным", поскольку multilib бажный, не обновляется месяцами и вообще suxx. Ну и на фоне всего этого, возникает вопрос: чем так отличается приложение под wine в chroot от того же приложения без chroot, что одно лагает, а второе нет? Если знать ответ на этот вопрос, то может удастся исправить ситуацию?

Да и вообще, мы видим совершенно неправильное поведение приложения в chroot. Которое следует исследовать по-максимуму и доложить ответственным за такое поведение. Но я не знаю кто ответственен: wine? mesa? Xorg? anyone else? То есть я начинаю склоняться к мысли что во всём виновата mesa, что-то там видимо не так инициализируется или типа того, если проводить все манипуляции из chroot. Но этого подозрения мало для багрепорта. В идеале было бы неплохо получить сорец строк на двести, который сможет воспроизвести баг, заменяя собой TDR2000.exe. С этим сорцом уже будет не стыдно соваться в списки рассылки.

Да, chroot я собираю так:

```
#!/bin/bash

NEWROOT=/path/to/chroot/installation

# Mount the following directories to their appropriate area within your chroot.

mount -t proc none $NEWROOT/proc

mount -o bind /dev $NEWROOT/dev

mount -o bind /dev/pts $NEWROOT/dev/pts

mount -o bind /usr/portage $NEWROOT/usr/portage

mount -o bind /usr/src/linux $NEWROOT/usr/src/linux

mount -o bind /lib/modules $NEWROOT/lib/modules

mount -o bind /sys $NEWROOT/sys

cp /etc/resolv.conf $NEWROOT/etc/resolv.conf

# Finally, if you want one /tmp for both

mount -o bind /tmp $NEWROOT/tmp

mount -o bind /home/rgo $NEWROOT/home/rgo
```

При этом файлики /etc/passwd и /etc/groups были скопированы в chroot из основной установки.

----------

