Фундаментальное непонимание варкрафта 2
|
|
|
|
il |
Re: Фундаментальное непонимание варкрафта 2 |
Добрый Админ
Регистрация: 10.5.06
Сообщений: 2470
Откуда:
|
|
Цитата: Если можно выводить текущее внутриигровое "время",(где-нибудь под apm?) если оно доступно. В его абсолютном числовом выражении, а не в секундах, т.к. для разной скорости - "секунды" уже разные.
Не поверишь! Думал именно об этом, как раз размышлял, не будет ли это читом, дающим преимущество тому, у кого оно есть. Может, посоветоваться еще с буржуйскими админами... Я правда думал именно про секунды, потому как откуда вытаскивать эти внутриигровые тики - понятия не имею. Секунды где-нибудь под АПМ вывести легко, тики - надо поискать... |
|
» 9.1.17 04:17 |
|
|
Zelya |
Re: Фундаментальное непонимание варкрафта 2 |
Владыка
Регистрация: 11.2.07
Сообщений: 191
Откуда:
|
|
Цитата: Читает данные из памяти. Причем, я был уверен, что перехватывает данные ddraw, оказалось - нет.
Так это же прекрасно! Главное вытянуть из программы набор адрессов (модули и оффсеты). Тогда можно делать любые навороченные утилиты.
А что касается передачи изображения, то GIF - это мертвый номер. Вам не удасться синхронизировать Гифки, и все бюудет дергано и глючно. Вижу такие варианты:
1. Самый лучший. Передавать данные из памяти игры, и формировать картинку на стороне клиента. Если данные слишком большие, то либо архивировать, либо передавать только разницу з предыдущим состоянием.
2. Самый легкий. Генерить на лету потоковое видео из картинок. Для этого должны существовать 3rd-party либы под любой активный нынче язык. И передавать потоковое видео на клиент.
3. Самый неоднозначный. Можно пробовать передавать покадрово, но кадры слишком болшые даже для каких-нибудь 4 кадра в секунду, причем в сжатых форматах. Поэтому нужно опять же передавать только разницу с предыдущим состоянием. Но это сроди по сложности написанию собственного кодека, еще и синхронизировать правильно надо. А граблей будет нмеерянно.
Цитата: Я правда думал именно про секунды, потому как откуда вытаскивать эти внутриигровые тики - понятия не имею. Секунды где-нибудь под АПМ вывести легко, тики - надо поискать...
Как я понимаю утилитка АПМ считает сама. Т.е. меряет, скажем, секунду системного времени, считает за это время нажатие клавиш мыши, а потом выдает АПМ. Не думаю, что в Вар2 заморачивались таким параметром. А вот тики Вар2 считать должен. Там был забавный баг, поправленный в патче 2.02 http://web.archive.org/web/20050405155853/http://www.blizzard.com/support/?id=mwb0482p
Цитата: "Исправлена проблема, из-за которой экран меню не отвечал на клики, если компьютер был оставлен на 24 дня или больше"
Объяснение этому забавному багу, одно, количетво тиков, в знаковом 32-битном int, ограничено как раз 24-ю днями (с копейками).
Но я уверен, что та минимальная разница, которая может возникнуть, если считать тики не в игре, а в самой программе, не сделает серъезной погоды.
[ Редактировано Zelya в 10.1.17 11:41 ] |
|
» 10.1.17 13:39 |
|
|
lesnik |
Re: Фундаментальное непонимание варкрафта 2 |
Полубог
Регистрация: 4.12.16
Сообщений: 448
Откуда:
|
|
Цитата: Вам не удастся синхронизировать Гифки
И не собирались. Это сырой промежуточный формат кадра, имеющий, при соответствующей палитре, минимальный размер, лучшее качество и небольшую нагрузку на проц. Из этих кадров уже и можно лепить конечный мультик.
Цитата: 1. Самый лучший. Передавать данные из памяти игры, и формировать картинку на стороне клиента. Если данные слишком большие, то либо архивировать, либо передавать только разницу с предыдущим состоянием.
Фантастика, с диким забиванием канала...
Цитата: 2. Самый легкий. Генерить на лету потоковое видео из картинок. Для этого должны существовать 3rd-party либы под любой активный нынче язык. И передавать потоковое видео на клиент.
Название либы в студию :)
Цитата: 3. Самый неоднозначный. Можно пробовать передавать покадрово, но кадры слишком болшые даже для каких-нибудь 4 кадра в секунду, причем в сжатых форматах. Поэтому нужно опять же передавать только разницу с предыдущим состоянием. Но это сроди по сложности написанию собственного кодека, еще и синхронизировать правильно надо. А граблей будет немеряно.
Написать кодек под 256 и с перерисовкой самому - хороший путь, если ты программер со свободным временем :))
Цитата: если считать тики не в игре, а в самой программе
Зачем их считать параллельно, если в игре счётчик уже есть? Поясню, что речь идёт не о тиках реального времени, а о собственных внутриигровых, которые на разной скорости игры должны отличаться. |
|
» 10.1.17 14:53 |
|
|
il |
Re: Фундаментальное непонимание варкрафта 2 |
Добрый Админ
Регистрация: 10.5.06
Сообщений: 2470
Откуда:
|
|
Цитата: Насчёт "читов", врядли. Разве что, это чуть поможет игрокам с плохим чувством времени. Но такие и сами могут себе внешний секундомер сделать. В какой-то теме я предлагал FX-у ставить будильник рядом с монитором :)
Одно дело - будильник с монитором, другое - часы прямо в игре. Как раз-таки чуть поможет с чувством времени, про это и сомнения. Паузы я бы смог отрулить модификацией обсерва, лаги - вряд ли. Неидеально, но погрешность в пару секунд за игру набежать может, вряд ли критично. (Раз в полсекунды смотреть, не нажата/отжата ли пауза).
Если вдруг сделаю, думаю с буржуями посоветуюсь, чит или не чит.
Цитата: Так это же прекрасно! Главное вытянуть из программы набор адрессов (модули и оффсеты). Тогда можно делать любые навороченные утилиты.
да-да, вот и я о том же. Все оказалось гораздо проще, чем я рассчитывал. Другое дело, что можно и взять прямо готовый варвидео и уже его дорабатывать до навороченной проги - его исходник вполне читаем.
Цитата: А что касается передачи изображения, то GIF - это мертвый номер. Вам не удасться синхронизировать Гифки, и все бюудет дергано и глючно. Вижу такие варианты:
1. Самый лучший. Передавать данные из памяти игры, и формировать картинку на стороне клиента. Если данные слишком большие, то либо архивировать, либо передавать только разницу з предыдущим состоянием.
2. Самый легкий. Генерить на лету потоковое видео из картинок. Для этого должны существовать 3rd-party либы под любой активный нынче язык. И передавать потоковое видео на клиент.
3. Самый неоднозначный. Можно пробовать передавать покадрово, но кадры слишком болшые даже для каких-нибудь 4 кадра в секунду, причем в сжатых форматах. Поэтому нужно опять же передавать только разницу с предыдущим состоянием. Но это сроди по сложности написанию собственного кодека, еще и синхронизировать правильно надо. А граблей будет нмеерянно.
Я так понимаю, что вариантов всего 2: либо передавать данные в сеть, упакованные уже реализованным в варвидео механизмом (читай, кодеком), либо писать/приспосабливать другой кодек. Данные из памяти игры это и есть неупакованный видеопоток, в виде пикселей 640 на 480. Так что передавать надо каким-то образом пожатые данные. Либо, если кто поможет с библиотекой на си для упаковки видео - я с радостью воспользуюсь. Надо: на входе - поток кадров - 8-битных картинок, 640 на 480, в виде пикселей, плюс палитра. На выходе - кино в любом удобном вам формате.
Сам я конечно никакие кодеки писать не буду.
Можно в принципе и набор кадров в гиф, но разве что как промежуточное решение для лесника, чтобы он что-нибудь с ними поколдовал и придумал, что делать дальше. Для других целей такое решение вряд ли подойдет.
Цитата: Как я понимаю утилитка АПМ считает сама. Т.е. меряет, скажем, секунду системного времени, считает за это время нажатие клавиш мыши, а потом выдает АПМ. Не думаю, что в Вар2 заморачивались таким параметром.
Да, секунды считает программа и показывает число действий за последнюю минуту. Приблизительно так. Точнее - там как-то мудрено, но если я буду делать, но скорее всего сам буду пересчитвывать так. Главное, чтобы совпало с оригиналом.
Цитата: Объяснение этому забавному багу, одно, количетво тиков, в знаковом 32-битном int, ограничено как раз 24-ю днями (с копейками).
Очень похоже на правду, хотя я не прикидывал количество чего-нибудь в 24 днях...
Цитата: Но я уверен, что та минимальная разница, которая может возникнуть, если считать тики не в игре, а в самой программе, не сделает серъезной погоды.
Там штука в том, "тики" игровые это не тики таймера, генерирующего прерывание. Думаю, что речь о параметре "Tw" из вот этой статьи: HАУКА О ПЕОHАХ.. Ну либо величина с ней коррелирующая. Она и вместе со скоростью игры меняется, и какими-нибудь еще интересными свойствами наверняка обладает. И вот где в памяти искать этот счетчик тиков - я если честно ума не приложу. А так бы это было проще и лучше всего. Если наткнусь - приделаю. |
|
» 10.1.17 15:07 |
|
|
Zelya |
Re: Фундаментальное непонимание варкрафта 2 |
Владыка
Регистрация: 11.2.07
Сообщений: 191
Откуда:
|
|
Цитата: Это сырой промежуточный формат кадра, имеющий, при соответствующей палитре, минимальный размер, лучшее качество и небольшую нагрузку на проц.
Если Вы не используете анимированный гиф, то это приводится к моему варианту 3. Любой сжатый формат рисунка будет от около 100 до 300 КБ, что составляет около одного мегабита траффика для кадра в секунду! Так что слать покадрово не выйдет. Я думал, Вы предлпгаете сжимать сразу кадров по 10-20 в Гифу. Но тогда встанет неразрешимая проблема синхронизации изображений из разных гифок.
Цитата: Фантастика, с диким забиванием канала...
Я не знаю сколько там полезных данных в вар 2. Например, очень критично какой переменной кодируется тайл карты. Инт в 4 раза больше байта :). Но, во-первых, этот формат должен хорошо поддаваться сжатию. Во-вторых, как я писал выше, можно пересылать лишь разницу. Т.е. мі держим в памяти перыдущее состояние, и хотя бы даже простым XORом определяем разницу с текущим состоянием. Теперь больше половины данных будут составлять нули, которые сожмутся в сотни раз.
Цитата: Название либы в студию :)
AVIFile, например :)
Цитата: Написать кодек под 256 и с перерисовкой самому - хороший путь, если ты программер со свободным временем :))
Нет, это самый плохой путь - изобретать велосипед. Люди которые пишут кодки имеют тонны знаний, где можно схалтурить, а где, скажем, нужно быть в два раза внимательнее. Десятки лет собрался список "граблей", по которым новому девелоперу придется пройтись снова. Да чего уж там, простой казалось бы вопрос, какой кадр считать ключевым, мне, без дополнительной литературы, уже совершенно незнаком, и делался бы "на глазок".
Цитата: Зачем их считать параллельно, если в игре счётчик уже есть?
Его еще нужно найти. И в отличие от "полезных" данных, тут простым ArtMoney уже не обойдешься. Легче написать свой. Хотя... теоретически можно написать утилитку, которая мониторит всю память и отсеивает только 4-х байтные значения, которые растут. Но стоит ли игра свеч?
Цитата: Поясню, что речь идёт не о тиках реального времени, а о собственных внутриигровых, которые на разной скорости игры должны отличаться.
Даю 90%, что в игре считается абсолтное вермя, с параметром скорости. Т.е. тики всегда одинаковые, а обраобтка кадра вызывается при достижении параметра скорости. Найти приблизительный параметр можно замерами, точный - дебаггером/дизассеблером. Ну, или просить у Близзов :). |
|
» 10.1.17 15:15 |
|
|
ПраваВы не можете начинать темы. Вы не можете редактировать свои сообщения. Вы не можете создавать опросы. Вы не можете вкладывать файлы в сообщения.
| Вы не можете отвечать на сообщения. Вы не можете удалять свои сообщения. Вы не можете голосовать.
|
|
|
|
|