Pull to refresh

Comments 32

Статья хорошая, по делу и без буллшита.
Толькот вот __declspec(naked) — чисто Microsoft-specific, в GCC например работать не будет.
И да, опечатка в статье — «играет тушь» :)
Спасибо, исправил.
Подозреваю что в gcc и *.def файлы работать не будут и много что ещё.
Да, я в начале статьи указал, что работа ведётся в Visual Studio 2010. К сожалению, в таких мелочах производители различных компиляторов не договорились между собой о единых стандартах.
Будет очень полезно, если вы приведёте аналогичные по действиям участки кода для GCC :)
В GCC нет такой возможности (для х86), только через асм.

С другой стороны, такие переходники лучше вообще сразу генерировать на асме (под фасм или ясм) автоматически.
Ух, спасибо за статью, интересно получилось. А главное ничего усложнённого излишне нет.
Круто, надо будет попробовать.
Лично я добавлю еще возможность включать\выключать принудительное удерживание мыши в окне.
За это отвечает параметр UseCursorClip :)
Проверил на Героях III, работает, НО курсор мышки не соответствует действительности, т.е. бегает на пол окна и исчезает.
Поиграйтесь с параметрам UseCursor — должно помочь в случае, если игра берёт координаты от угла экрана, а не своего окна (что бывает часто).
Возможно помогут какие-то другие параметры, либо уже нужно будет дополнительно немного поправить код в самом бинарнике. Как правило, там не сложные модификации.
Вопрос не программиста, но игрока: в теории это позволит играть в оконном режиме во всю «классику» — Arcanum, Baldur’s Gate, Fallout, Icewind Dale, Planescape?.. Это же прекрасно, спасибо вам большое!
По поводу Baldur's Gate: есть сборки все-в-одном, вроде Baldur's Gate Trilogy. Обычно туда включают www.gibberlings3.net/widescreen/, который позволяет или играть в окне, или подстроить игру под ваше разрешение экрана.

Замечательно! Задумывался о создании подобной библиотеки т.к. xsplit не поддерживает стрим при фулл скрине, а тут все готовенькое, спасибо.
Это очень круто, спасибо! Как раз была одна идейка, Ваша статья очень поможет.
А с новыми играми не пойдет? Попробовал со Steam CS 1.6. Вылетает ошибка при разных комбинациях параметров. Так и не удалось запустить.
CS 1.6 вроде как сама умеет в окне работать:
тыц
Да это я в курсе, не дурак :) Интересует именно окно без рамки.
Спасибо, интересная статья. А не знаете, вот Detours для подобного использовать возможно?
Если вы пишете proxy-dll, то смысла дополнительно перехватывать проксируемые методы через Detours нет, поскольку вы и так можете писать свою реализацию этих методов. Если же вы хотите дополнительно отлавливать вызовы из других библиотек, то Detours здесь верный помощник.
Еще на тему прокси-dll есть полезная библиотечка Proxocket netresec.com/?b=1119573
Подменяет Winsock и дампит весь трафик в файл.
Но надо отметить, что работать будет только с действительно старыми играми, которые используют ddraw. А более новые работают напрямую с D3D9!Direct3DCreate9, и там подменять придётся не столько функции, сколько целый интерфейс.
Статья хорошая, но для Windows DLL такие чудеса — не новость. А вот кто-нибудь знает о подобном решении для Linux ELF? Причем не в принципе как сделать, это-то понятно, а именно готовое reusable решение — на изобретение всех велосипедов самому не хватит жизни. LD_PRELOAD не предлагать, интересует именно proxy решение.

А чем LD_PRELOAD не решение? Тут же подвох в том, что Windows ищет сначала в директории приложения, а потом уже в системных. В Linux такого нет, а значит и не получится без явного использования LD_PRELOAD.
Что значит не получится? Как может не получиться следующий финт: оригинальную libfoo.so переименованием в libfoo2.so, создаем proxy-so libfoo.so которая форвардит вызовы на libfoo2.so?

Проблема с LD_PRELOAD в том, что он очень fragile: его нужно установить, кто угодно может его сбросить, он имеет ограничения по правам. Мой usecase: злые вендоры не хотят обновлять Android на пользовательских девайсах. Пользователи пытаются делать это сами. Корпорация добра Google подыгрвает вендорам, постоянно меняя API/ABI, в основном, именно ради изменений (ну там тип переименовали, C++ ABI). Основная проблема с интерфейсом EGL, связывающим вендоровский OpenGL и графическую подсистему Android. Пользователи хотят выразить свое отношение к происходящему написанием ABI-адаптера, чтобы OpenGL из предыдущих версий можно было использовать с новыми версиями Android. Причем парадигматически верно, чтобы решение всех этих гугло-вндоровских закавык было простое, как бублик и прозрачное, аки слеза, чтобы даже ребенок мог понять, как плохо стараются делать хорошо гугловендоры со своей стороны.

;-)
Заменить оригинальную, понятное дело, можно, но тогда эта подмена будет работать для всех программ её использующих, а не «избранных», как это делается в статье.
Возможно ли зуммировать игру в окне в X раз, в пропорции? Например, в 1.4 раза.
Многие игры, поддерживающие только 640х480 смотрятся на больших экранах слишком мелко.
Sign up to leave a comment.

Articles

Change theme settings