Цитата: Насчёт "читов", врядли. Разве что, это чуть поможет игрокам с плохим чувством времени. Но такие и сами могут себе внешний секундомер сделать. В какой-то теме я предлагал FX-у ставить будильник рядом с монитором :)
Одно дело - будильник с монитором, другое - часы прямо в игре. Как раз-таки чуть поможет с чувством времени, про это и сомнения. Паузы я бы смог отрулить модификацией обсерва, лаги - вряд ли. Неидеально, но погрешность в пару секунд за игру набежать может, вряд ли критично. (Раз в полсекунды смотреть, не нажата/отжата ли пауза).
Если вдруг сделаю, думаю с буржуями посоветуюсь, чит или не чит.
Цитата: Так это же прекрасно! Главное вытянуть из программы набор адрессов (модули и оффсеты). Тогда можно делать любые навороченные утилиты.
да-да, вот и я о том же. Все оказалось гораздо проще, чем я рассчитывал. Другое дело, что можно и взять прямо готовый варвидео и уже его дорабатывать до навороченной проги - его исходник вполне читаем.
Цитата: А что касается передачи изображения, то GIF - это мертвый номер. Вам не удасться синхронизировать Гифки, и все бюудет дергано и глючно. Вижу такие варианты:
1. Самый лучший. Передавать данные из памяти игры, и формировать картинку на стороне клиента. Если данные слишком большие, то либо архивировать, либо передавать только разницу з предыдущим состоянием.
2. Самый легкий. Генерить на лету потоковое видео из картинок. Для этого должны существовать 3rd-party либы под любой активный нынче язык. И передавать потоковое видео на клиент.
3. Самый неоднозначный. Можно пробовать передавать покадрово, но кадры слишком болшые даже для каких-нибудь 4 кадра в секунду, причем в сжатых форматах. Поэтому нужно опять же передавать только разницу с предыдущим состоянием. Но это сроди по сложности написанию собственного кодека, еще и синхронизировать правильно надо. А граблей будет нмеерянно.
Я так понимаю, что вариантов всего 2: либо передавать данные в сеть, упакованные уже реализованным в варвидео механизмом (читай, кодеком), либо писать/приспосабливать другой кодек. Данные из памяти игры это и есть неупакованный видеопоток, в виде пикселей 640 на 480. Так что передавать надо каким-то образом пожатые данные. Либо, если кто поможет с библиотекой на си для упаковки видео - я с радостью воспользуюсь. Надо: на входе - поток кадров - 8-битных картинок, 640 на 480, в виде пикселей, плюс палитра. На выходе - кино в любом удобном вам формате.
Сам я конечно никакие кодеки писать не буду.
Можно в принципе и набор кадров в гиф, но разве что как промежуточное решение для лесника, чтобы он что-нибудь с ними поколдовал и придумал, что делать дальше. Для других целей такое решение вряд ли подойдет.
Цитата: Как я понимаю утилитка АПМ считает сама. Т.е. меряет, скажем, секунду системного времени, считает за это время нажатие клавиш мыши, а потом выдает АПМ. Не думаю, что в Вар2 заморачивались таким параметром.
Да, секунды считает программа и показывает число действий за последнюю минуту. Приблизительно так. Точнее - там как-то мудрено, но если я буду делать, но скорее всего сам буду пересчитвывать так. Главное, чтобы совпало с оригиналом.
Цитата: Объяснение этому забавному багу, одно, количетво тиков, в знаковом 32-битном int, ограничено как раз 24-ю днями (с копейками).
Очень похоже на правду, хотя я не прикидывал количество чего-нибудь в 24 днях...
Цитата: Но я уверен, что та минимальная разница, которая может возникнуть, если считать тики не в игре, а в самой программе, не сделает серъезной погоды.
Там штука в том, "тики" игровые это не тики таймера, генерирующего прерывание. Думаю, что речь о параметре "Tw" из вот этой статьи: HАУКА О ПЕОHАХ.. Ну либо величина с ней коррелирующая. Она и вместе со скоростью игры меняется, и какими-нибудь еще интересными свойствами наверняка обладает. И вот где в памяти искать этот счетчик тиков - я если честно ума не приложу. А так бы это было проще и лучше всего. Если наткнусь - приделаю. |