Патч игры «Аладдин» для Windows 95

daemolisher, Sleep как раз вставили для того, чтобы отвязаться от скорости процессора.
Мне кажется, там проблема в том, что накладываются друг на друга ожидание по таймеру и встроенная в игру саморегулировка скорости...

Кстати, о регулировке - может, её вообще отключить? По-моему, для этого будет достаточно не учитывать отстаток от предыдущего деления разницы счётчиков.

 

Без Sleep можно, просто зациклить да и все, но он точно не мешает, а без него будет 100% загрузка ядра. нехорошо это)

Такая же проблема со звуком у меня появилась, когда я как-то раз во время заставки с компаниями-разработчиками переключил в Realtek HD частоту звука (приходится это делать, когда звук на компьютере начинает сильно шуметь), тоже многие звуки пропали. После перезапуска игры все было нормально. Игра лежит по пути 8.3 (С:\Games\Aladdin). Попробовать не 8.3 не могу, под рукой сейчас только компьютер без звуковой карты.

Потестил в Windows 98 на Pentium MMX 233 MHz. Скорость непатченного экзешника сильно зависит от размера окна. Маленькое окно - очень быстро, играть невозможно; большое - очень медленно, играть тоже невозможно) В фуллскрине ощутимо быстровато. Патченные (пробовал свой и от Val07og последние) - в маленьком окне и фуллскрине скорость такая же, как и на Core2Duo c Windows 7, что в общем-то ожидаемо. Фуллскрин, кстати, тут тоже работает неправильно - изображение сжимается по вертикали в два раза и показывается в верхней половине экрана, а в нижнем - каша, и 8-битном режиме рабочего стола, и в 16-битном, и в 32.

Могу попробовать снизить частоту проца на тот, который указан в системных требованиях к игре, если кто-нибудь их подскажет, и записать видео для демонстрации скорости)

Игровую коррекцию скорости, имхо, убирать не стоит, как и вызов второго GetTickCount) По возможности лучше оставлять все оригинальные алгоритмы, даже если кажется, что можно сделать проще)

Строку ...statusbar32 можно поместить на место сообщения о 24-битном цвете (можно найти в exe по словам "256 colour"), после исправления iunnamed оно все равно теперь никогда не покажется)

---------- Сообщение добавлено в 23:21 ---------- Предыдущее сообщение размещено в 23:20 ----------

Извиняюсь, что без цитирования, уж очень тяжело это на моем телефоне делать.

 

AxXxB, здорово! Кстати, может, ещё игра синхронизируется по вертикальной развёртке? Просто пытаюсь сейчас регулировать задержку (уже без дополнительной корректировки), и при 14 и 10, например, скорость почти одинаковая.

Интересно, почему фуллскрин глючит. Устанавливается он там всегда 320x200x8, независимо от цветности рабочего стола.
Может, какой-то другой режим вместо него включается?
У меня работает, что на живой машине, что на виртуалке.

 

Val07og, кстати, очень может быть, что на вертикальную синхронизацию и рассчитано. Не могли же разработчики пропустить такой огромный баг, как очень разная скорость игры на разных компьютерах)

По поводу фуллскрина - я его не увидел ни на живых компьютерах, ни в виртуалке (Windows 98 на Virtual PC). На семерке (#1 в профиле) режим не переключается, но игра все равно пытается что-то выводить, однако в результате только черный экран, который, мерцая, показывает за собой заголовок развернутого окна) На XP (#2 в профиле) режим меняется на правильный, но изображение выглядит так: в верхней где-то шестой части экрана очень сильно искаженная и уменьшенная картинка повторяется по горизонтали несколько раз, остальная часть экрана черная. Мерцает так же, как и на семерке, и так же показывает за собой заголовок развернутого окна. В виртуалке вообще виснет после смены режима, хотя, возможно, это результаты моих извращений над виртуальной виндой) Пробовал менять в коде и разрешение на 640х400, и цветность на 16 бит - бестолку, все остается по-прежнему.

 

Кстати, насчет экспериментов без сохранения остатка от деления - как твой алгоритм выглядит? Не может ли быть такого, что скорость при разных значениях задержки почти одинаковая из-за гранулярности счетчика (timeBeginPeriod)?

 

Примерно так?



Это вот как раз видеорежим не 8-битный, по-моему.
В 32-битном режиме, например, пиксели идут RGBA RGBA RGBA RGBA, а игра пишет 8 8 8 8, из-за чего вместо 4 палитровых пикселей получаются 3 цвета+альфа одного RGBA пикселя.
Т. е. строки, сжатые в 4 раза:
1,2,3,4
5,6,7,8
9,10,11,12
и т. д.
Странно - выходит, что у тебя при полном экране тоже включается не 8-битный видеорежим, а 16/24/32 - смотря сколько раз повторяется картинка по горизонтали.

Алгоритм - старый, насколько я понял, такой.

Код:

delta = GetTickCount - oldTicks
oldTicks = GetTickCount

delta = delta + oldReminder
i = delta / 14
oldReminder = delta mod 14

if i <> 0 then
  cPlus = cPlus + i
  cMinus = cMinus - i
  if cMinus < 0 then cMinus = 0
end if

У меня сейчас так.

Код:

a = oldTicks
c = 14
b = a + c

do
  Sleep(1)
  d = GetTickCount()
  if d < a then exit do
loop while d < b

oldTicks = d
delta = d - a

delta = delta + oldReminder
i = delta / c
oldReminder = delta mod c

if i <> 0 then
  cPlus = cPlus + i
  cMinus = cMinus - i
  if cMinus < 0 then cMinus = 0
end if

Если просто убрать "delta = delta + oldReminder", начинает очень быстро мигать надпись "старт" в начале.
Если ещё вместо i добавлять/вычитать просто единицу, то всё нормально.
Но скорость остальной игры в обоих случаях почему-то перестала зависеть от времени задержки.
Вот, например, вообще с 1 миллисекундой: Посмотреть вложение Al95_1ms.rar - и нормально у меня идёт.

 

Изображение выглядит не совсем так. Похоже, но цвета видно, а контуры чего-либо различить невозможно, одни какие-то короткие горизонтальные линии. И сама повторяюшаяся картинка меньше и умещается по горизонтали большее количество раз, около 6-8 где-то. Приеду домой и заскриншотю.

А таймер, похоже, действительно не влияет на скорость из-за гранулярности системного счетчика - Sleep задерживает поток на самом деле на большее количество миллисекунд. Для проверки этой гипотезы можно сделать вот что - написать отдельную консольную программу, в которой вызвать timeBeginPeriod(1) и уснуть навеки через Sleep(-1), и пока она спит, запустить игру с миллисекундным интервалом в таймере.

 

AxXxB, я вот подумал - а что если какой-нибудь программист-приколист в совершенно далекое от геймдева приложение, например в калькулятор или блокнот, встроит вызов timeBeginPeriod, например со значением скажем 10000. (ну или сколько там оно максимум принять может)

Вот люди будут сидеть гадать почему у них компьютер спонтанно производительность меняет

Ещё не известно - не запущена ли у вас прямо сейчас такая программа, например какой-нибудь инстант-мессенджер сидит в фоне, и периодически в цикле вызывает timeBeginPeriod

 

daemolisher, от этого как раз сейчас у нас небольшая страховка - не просто Sleep вызывается, а каждый раз сравнивается время - прошло или ещё нет - это AxXxB ещё в самом начале поменял.

 

Val07og, а впрочем там вроде больше 15 миллисекунд не ставится и даже если какая-то программа это установит - то ничего страшного не произойдёт:

15 миллисекунд - это вполне достаточно что бы измерить "дельту" для игры с частотой 60 кадров в секунду - ну и уж точно хватит для игр с 30 fps


кстати, насчёт сравнений - у этой игры куча всяких версий на консолях - как там у них со скоростью игры?

я-то на ПК вообще эту игру не играл - только на NES ( - возможно она несколько урезанная)

---------- Сообщение добавлено в 20:43 ---------- Предыдущее сообщение размещено в 20:34 ----------

а и ещё - попробуйте при запуске .exe игры - задать ему принудительно однопоточность - что бы Windows произвольно не перекидывала исполнение игры с ядра на ядро - она это любит делать при вызове Sleep (1), особенно Vista/7

сходу не скажу как делается через WinAPI, но должно легко нагуглиться
добавление в приложение Sleep(1) - это уже как бы работа с потоками - это вообще не пауза, а две команды для того, что бы поток усыпить и разбудить через не меньшее время.

 

Вернулся из глухомани)

Фуллскрин на №2 в профиле выглядит не так, как я описывал. Запомнилось по-другому почему-то) Вот фотка (скриншот не делается - черный экран):


Эксперименты с time[Begin/End]Period на семерке показали, что Sleep и timeGetTime не зависят от timeBeginPeriod и считают все точно, GetTickCount тоже не зависит и считает всегда с разрешением в 15 мс) Программу приложил, исходный код на С тут.

Код:

int main(int argc, char* argv[]) {
    long (_stdcall *_timeBeginPeriod)(long);
    long (_stdcall *_timeEndPeriod)(long);
    long (_stdcall *_timeGetTime)();
    char str[512];
    long time, tick, err, res, wait;
    HMODULE lib = LoadLibrary("WINMM.DLL");
    _timeBeginPeriod = GetProcAddress(lib, "timeBeginPeriod");
    _timeEndPeriod = GetProcAddress(lib, "timeEndPeriod");
    _timeGetTime = GetProcAddress(lib, "timeGetTime");

    res = 20;
    if (argc > 1) res = atoi(argv[1]);
    wait = 20;
    if (argc > 2) wait = atoi(argv[2]);
    
    err = _timeBeginPeriod(res);
    time = _timeGetTime();
    tick = GetTickCount();
    Sleep(wait);
    time = _timeGetTime() - time;
    tick = GetTickCount() - tick;
    _timeEndPeriod(res);
    sprintf(str, "Time: %d ms; tick: %d ms; wait: %d ms; res: %d ms; err: %X", time, tick, wait, res, err);
    if (MessageBox(0, str, "Oh", MB_OKCANCEL) == IDOK)
        Sleep(-1);

    FreeLibrary(lib);
    
    return 0;
}

В командную строку можно передать 2 параметра: аргумент к timeBeginPeriod и аргумент к Sleep. В появляющемся диалоговом окне можно увидеть результаты. Если нажать в нем ОК - программа зависнет по Sleep(-1), если Отмену - выйдет.

 

AxXxB, а обычные досовские игрушки (не требующие звука, джойстика или чего-то такого) - просто с экраном 320x200 - на этой машине запускаются?

Или, может, в x64 выпилили этот видеорежим как "устаревший"?

В принципе, если выяснить, какой именно видеорежим ставится при полном экране, можно попробовать использовать процедуру отрисовки для окна - она там аж отдельная для каждой цветности есть - своя для 8, своя для 16 и т. д. (404A81).

 

для надёжности надо как бы сделать вид, что это игровой цикл

PHP:

цикл (1000 раз) {
    time = _timeGetTime();
    tick = GetTickCount();
    Sleep(wait);
    time = _timeGetTime() - time;
    tick = GetTickCount() - tick;
    тут внести значения time, tick в массив в памяти; //перед циклом его создать
}
еще один цикл для вывода (1000 раз) {
    тут читать значения time, tick из ранее заполненного массива;
    sprintf(str, "%d\t%d\n", time, tick); //значения разделить табом, и новой строкой
}
ну и где-то вывести остальное (wait, res, err);

запускать приложение .bat файлом, и перенаправить вывод в текстовый файл

а потом .txt можно открыть в Excel, он преобразует в таблицу и по ней можно построить график.
импровизированное профилирование

AxXxB, для чистоты - эксперимент проводить 3 или 4 раза, можно для интереса в фоне запустить архиватор или видео-плеер с фильмом.

 

Тьфу, я почему-то думал, что у меня вторым указан ХР. Это на первом такое, на втором режим вообще не меняется (описывал тут).

Там точно 320х200х8 выставляется. Когда делаешь скриншот, HyperSnap показывает палитру, и размер картинки - 320х200.

Лучше вообще переделать процедуру фуллскрина, раз она такая глючная. Можно делать так - не менять режим, а разворачивать окно и применять к нему стили, скрывающие меню и помещающие поверх все окон:

Код:

LONG lStyle = GetWindowLong(hwnd, GWL_STYLE);
oldStyle = lStyle;
lStyle &= ~(WS_CAPTION | WS_THICKFRAME | WS_MINIMIZE | WS_MAXIMIZE | WS_SYSMENU);
SetWindowLong(hwnd, GWL_STYLE, lStyle);
ShowWindow(hwnd, SW_MAXIMIZE);

Вот в этой версии я пытался так делать, но есть два затыка - во-первых, стиль не применяется, пока не свернешь/развернешь окно (возможно, получится через SetWindowPos, но ее нет в импорте), а во-вторых, игра не хочет растягивать изображение по вертикали, поэтому в режимах 4:3 внизу остается область черного экрана (что интересно, на 16:9 изображение по вертикали все-таки сжимается).

А можно, например, оставить оригинальный алгоритм, но убрать топорное включение 320х200х8, а сделать по уму и перечислить доступные видеорежимы через EnumDisplayModes, и по какой-нибудь комбинации клавиш переключать их. Только тогда придется реализовать еще и сохранение выбранного режима в INI-файлике.

Еще бы вот придумать какую-нибудь возможность сохранять пропорции 16:10 в фуллскрине на не 16:10 мониторах...)

---------- Сообщение добавлено в 23:13 ---------- Предыдущее сообщение размещено в 23:12 ----------

daemolisher, а нафига это все делать?)

 

Что наводит на мысль - а может, отключить вообще полный экран (обработка Alt+Enter в 404EC8)? Для этого достаточно в 42CB поставить 90 E9 вместо 0F 85.
Разворачивать-то и так можно кнопкой окна.

 

Val07og, ну, в принципе, можно

 

AxXxB, вообще, странно это. У меня и на основной системе работает полный экран, и в VirtualBox'е на всех системах без глюков - проверил на XP, ME, 98, 95, в т. ч. с разными режимами рабочего стола. Только до 7-ки ещё никак не могу добраться.

Может быть, из-за того, что видеокарта сравнительно старая...

 

- что бы найти момент, когда полученные результаты эксперимента не совпадают с ожидаемыми результатами эксперимента.


а если странностей не обнаружилось, то приткните туда вот этот код (так же собирайте его значения) из сообщения Val07og:

- может странности проявятся на нём, вдруг где-то ошибка закралась?
очень уж этот код подозрительно выглядит

 

Val07og, а FX 5200, которая у меня, не старая? А S3Trio 2МБ на MMX 233, на котором тоже неправильно выводилось?)

Кстати, просто отключить фуллскрин не очень хорошо хотя бы потому, что на том же MMX в 800х600 в развернутом игре игра тормозит. Конечно, на таких системах будут играть единицы, но все-таки.


daemolisher, да приблизительно и так понятно, что происходит. Разрешение GetTickCount в любом случае около 15 мс, значит, цикл там, где Sleep, в любом случае задержит игру на 15 мс. Поэтому скорость и не меняется.

 

В общем, покумекал я немного, и родил такой алгоритм:

Код:

const wait = 14;
static int offset = 0;
static int tick = 0;
static int oldTick = GetTickCount();

while ((tick = GetTickCount()) < (oldTick - offset + wait)) do
  Sleep(1);

offset = tick - oldTick - wait + offset;
oldTick = tick;

cPlus++;
cMinus--;
if (cMinus < 0) cMinus = 0;

Тогда становится наплевать на разрешение Sleep и GetTickCount - в среднем игра будет задерживаться ровно на wait миллисекунд.