Z Expansion XP v1.7 beta 3 (Страница 1 из 6)

Брат, невозможно выразить словами, как круто то, что ты делаешь.
Может быть ты все же разберешься, в чем там проблема с Вистой?
Если принципиально невозможно сделать оконную версию, может можно сделать так, чтобы оно запускалось как любая другая игра под directx -- то есть у меня есть опция without scaling, и многие игры запускаются в родном разрешении, а по краям черная рамка. С Z такого не происходит: постоянно игра fullscreen, что на моем 24-дюймовом мониторе практически не играбельно.
Сейчас игра запускается в окне, но при этом мышь не работает.
То есть либо изменить то, как этот враппер (или как это назвать, оболочка) масштабируется, либо пофиксить мышь.

А это нормально, что в этой тест-версии не работает протокол TCP/IP?
Его просто тупо нет в списке.
Попробовали 1.6.5 -- и странное дело: у меня все отлично заработало на XP SP2, а у приятеля не запускается оконный режим -- раз, и два -- не видно курсор мыши.
Ну и три, у нас обоих были непонятные притормаживания при скролле правой кнопкой. Там как бы ведь надо быстро и точно перемещаться, а тут хоп -- и затык легкий.
И четыре -- грузилось все почему-то очень долго при старте мультиплеера. То есть реально долго, мы даже подумали, что совсем не будет счастья.

Ну а что еще можно добавить к багрепорту? Версии одинаковые, железо плюс-минус одинаковое. Ну не запускается в окне и все тут. Скажи, мы добавим )
И затыки со скроллом -- тоже вещь неясная. Либо сама прога тормозит, либо может быть лаги в сети (хотя у нас общий провайдер и районы близко, то есть мы не в разных городах на модемах).

Антарес, очень приятно, что Вы не оставляете работы над своим прекрасным дополнением к Z95. Сейчас поиграл с помощью новой тестовой версии zxp под WinXP- проблем не было. Звук нормальный, но он и был у меня нормальным на 3х компьютерах, где я запускал ZXP - и под XP, и под Вистой. Видео тоже нормальное, пропорции сохраняются. По сети не играю. Вообще, проблем с ZXP не больше (по-моему, даже меньше), чем с оригинальной Z expansion pack. Так что здесь предолжений не имею - на мой взгляд, всё и так хорошо.

Имею предложение доработать редактор уровней, который идёт с Z95. Он ещё более недоработанный, чем оригинальный Z expansion pack. Сейчас пользоваться им очень неудобно (требует 16 бит цвет), а создать уровень для одиночной игры - практически невозможно. Есть попытка доработать этот редактор для создания одиночных уровней, автор - наш (юный, судя по всему) соотечественник. Но то, что я видел, выглядит очень сыро и по-дилетантски. Можно только мечтать, чтобы этим проектом занялись Вы.

@Antares:

Ну что ж, будем ждать и надеяться. А пока - тестировать новую версию ZXP. Сейчас играл на ней в уровень 14. У меня процессор Core2Duo T7500, 2.2 GHz, WinXP SP3. Загрузка одного ядра была ~ 70%, второго ~ 20%. Интересно, а что в основном грузит процессор - игровая логика, или что-то другое?

добавлено: прошёл на тестовой версии 20 основных уровней игры, всё в порядке, никаких ошибок и вылетов не было.

beta 2
Что нового?
- исправлена ошибка, допущенная в первой бете, которая не позволяла играть в новые уровни
- новый параметр командной строки "/vga", позволяет запускать игру в vga режиме, как оригинал в DOS версии
- добавлена поверка аппаратной поддержки DirectDraw
- улучшена плавность перемещения курсора (без заметных рывков и притормаживаний) и прокрутки экрана
- практически сведены на нет моргания экрана
- экраны загрузки стали более плавно отображаться
- прочие исправления или изменения

ссылка на скачивание в первом сообщении

Да, в ХР почему то сбоило, проблему убрал .

beta 3
Нововведения:

- Убран разрабатываемый мною алгоритм AMEC (automatic mode error correction) и заменён на разработку BugTrap, созданную вероятно нашим бывшим соотечественником Максимом Пятковским. Данная разработка применяется в игре СТАЛКЕР и предназначена для отлова ошибок, генерации "креш-дампа" и отсылки на сервер разработчикам. Если кто играл в S.T.A.L.K.E.R, то наверняка видел, как при падении игры появляется небольшое окошко с зелёным жучком. Вот такая же штука теперь применяется и в новом патче. Надеюсь всё же, что вам не придётся ею воспользоваться .

- Включена система подключения плагинов. Для тех кто смыслит в программировании и имеет хотя бы небольшой опыт в ассемблере, имеется возможность самим вносить изменения и править ошибки в игре. От использования так называемых "hot-patch", о которых сообщалось в первой бете, я решил отказаться, ввиду их узконаправленности и невозможности писать на других языках отличных от FASM.

Вкратце опишу процесс создания плагина
===============================

Для написания плагина, нужно создать DLL, и экспортировать одну функцию UPMStart. Эта функция должна иметь два входных параметра CInter (содержит указатель на COM интерфейс патча) и hInstance (содержит хендл загруженного плагина).

На ассемблере это выглядит так

proc    UPMStart, CInter, hInstance
.
ваш код
.
ret
endp

На С++ это вероятно будет выглядеть как то так (никогда не программировал на HighLevel)

static void UPMStart(CInter, hInstance)
{
ваш код
}

Далее, эта экспортируемая функция выполняет две задачи:
А) Проверяет содержание любого из двух параметров CInter или hInstance и если они содержат NULL, то возвращает временной штамп игры. Для Z Expansion это 0x34FAE468. Патч таким образом узнает для какой игры предназначен плагин.

Б) Если параметры CInter и hInstance не пусты, значит функция UPMStart вызывается для "патчивания" игры.

hInstance - содержит (как это было описано выше) хендл загруженного плагина. Он редко используется, но инога может пригодится для каких-нибудь функций.
CInter - содержит указатель на COM интерфейс патча. Этот интерфейс содержит несколько функций для удобства "патчинга".

На FASM этот интерфейс выглядит так

       interface UPInter,\
                  null,\
               gen_call,\
               gen_jump,\
               gen_nop,\
               HookProc

Каждая из перечисленных функций имеет по два параметра
null - зарезервирован
gen_call, адрес_в_игре, адрес_вашей_функции - генерирует CALL вызов (занимает 5 байт)
gen_jump, адрес_в_игре, адрес_вашей_функции - генерирует JMP команду (занимает 5 байт)
gen_nop, адрес_в_игре, количество_нопов - генерирует NOP (пустышки)
HookProc, адрес_WInAPI, адрес_вашей функции - перехватывает WinAPI (локальный "хук")

Не смотря на то, что всё вроде бы довольно просто, уверен почти на 100% что многие ничего не поняли. Приведу фрагмент кода на ассемблере, ну и если что, задавайте вопросы, постараюсь ответить.

proc    UPMStart uses esi edi ebx, CInter, hInstance
       xor    ebx, ebx
       mov    eax, 34FAE468h    ; возвращаем в eax штамп времени файла, для которого предназначен патч
       cmp    ebx, [CInter]         ; смотрим что в параметре CInter, если 0, на выход
       jz    .exit

       mov    edi, [CInter]         ; засунем в edi указатель на интерфейс патча
       mov    esi, [hInstance]    ; засунем в esi хендл этого плагина

       stdcall [edi+UPInter.gen_jump], MyFunc, 401000h   ; сгенерируем JMP по адресу 401000h на нашу функцию MyFunc
       stdcall [edi+UPInter.gen_call], MyFunc, 401000h   ; сгенерируем CALL по адресу 401000h на нашу функцию MyFunc
       stdcall [edi+UPInter.gen_nop], 401000h, 10         ;сгенерировать 10 NOP-ов по адресу 401000h
       stdcall [edi+UPInter.HookProc], [UpdateWindow], MyFunc_UpdateWindow   ; перехватить системную функцию UpdateWindow (библиотеки USER32.DLL), обработкой будет заниматься наша функция MyFunc_UpdateWindow
.exit:
       ret
endp

Для тех, кто осилил материал, завершающим штрихом будет переименование вашего плагина с расширения DLL на UPM.

Согласен. Не зная этого невозможно даже планировать плагин, не то что реализовать
Думаю, было бы полезно просто составить список возможных модификаций, который поделить на 2 части:
а) реально осуществимые на данный момент (т.е. известно где, что и как менять)
б) теоретически осуществимые (т.е. известно что менять можно, но надо разобраться что и как)
Исходя из этого списка мы могли бы планировать геймплей для нового дополнения, или хотябы собственные плагины (консультируясь с Antares'ом).

К примеру, можем ли мы добавить в игру новые типы юнитов? Можем ли мы исправить алгоритм поиска пути (оригинальный оставляет желать лучшего)?
Можем ли мы исправить итоговую статистику -- подсчёт очков, чтобы он был "честным" и осуществлялся по понятным правилам?

Если работа не оплачивается, то зачастую в качестве движущей силы, основным побудительным мотивом становится признание результата твоей работы со стороны окрущающих или коллег. Полагаю, именно по этой причине разработчики OpenSource в качестве условия пользования продуктом просят на видном месте поместить о себе упоминание. Всё это, конечно, очень попахивает тщеславием, но, чтобы работа приносила удовольствие, она должна каким-то образом вознаграждаться.
Но есть еще один важный момент: если в любом большом деле каждому кто за него ни возьметься придется начинать с самого начала, то конца так никто и не увидит - без передачи накопленных новых знаний прогресс просто невозможен. Посмотртие сколько постов zzone.lewe.com начать новую разработку заканчивались ничем - человек, поработав немного на запале энтузиазма, понимал, что одному ему с этим не справиться, терял интерес и исчезал...

Именно это и может помочь в развитии проекта, а не сырцы inject-кода на FASM'е, так что выкладывай

Реально осуществить около-игровые возможности, то, что не связано с самим игровым процессом. Добавить сетевой режим новый, изменить формат музыки, изменить формат заставок и т.д. Но и это, как вы понимаете, очень не просто. Набавление очков, поиск пути и пр., это уже игровые функции, тут нет никаких WinAPI и я не понимаю за что можно ухватится что бы найти их. Предвидя что рано или поздно мне надоест этим заниматься я и решился на разделение монолитного кода на две части, загрузчик и подключаемые плагины, что бы каждый мог продолжить писанину. Собственно главный плагин находится внутри загрузчика, наверное я действительно открою его.

Именно так. Мне, думаю как и большинству людей, приятно если уж не получать деньги за свой труд, то хотя бы знать что им пользуются (как можно большее количество людей) и моё авторство закреплено за ним. А когда тебя лишают и этой возможности, да ещё и приписывают эту работу себе, то пошло это в... Поэтому я не против открытия исходников, я против отсутствия культуры у людей. А то "умельцев" полно развелось, берут готовенькое, логотипы перешлёпали, копирайты свои проставили, добавили сомнительных функций, и опа, новая версия, это я сделал! Если берёшь чьё то, то будь добр сохрани автора, добавь себя и напиши какой вклад внёс сам. Вот моё видение такое.

Хорошо, но что выкладывать то? "Дизасм" публично не выкладывают, закину на почту если нужно. Исходники же главного модуля (плагина) у меня всё равно на FASM, так что... со всеми вытекающими.

Эмм... насколько я знаю, подобное касается только перехвата оконных процедур. Чтобы реализовать это, нужно писать диспетчер через который будут проходить вызовы, а не напрямую как это происходит сейчас. Я очень сомневаюсь что подобное будет востребовано, так-как в реале почти не приходится ею пользоваться, обычно надёжней и лучше переписать всю функцию целиком или её часть.