Кодерский уголок

Рыжий Тигра, какой вопрос - такой и ответ, сколько раз тебе ещё объяснять ? Задавай вопрос правильно. Удивительно, что в моём ответе только одно неправильное слово... учитывая, что он вообще неправильный, относительно ситуации в целом, как выяснилось по приведённым логам:

Ну, судя по логу, ты умудряешься выводить через свой обработчик уже сформированную игрой картинку (вместе с текстом). И рисуешь конкретно поверх неё. Тут ты ничего поделать не сможешь - сколько раз она выводится самой игрой, столько раз и будет вызван твой обработчик.

Лекарство: убери свой обработчик с данной функции. Ищи вывод строк на этапе формирования картинки. И рисуй в тот самый буфер, который потом выводится на экран только строки и только в тот момент, когда они выводятся. Но ! Это не гарантирует, что игра сама не рисует их такое же количество раз по новой.

 

Абзац. :-( А по вчерашней фразе "перехватываю вывод на экран (вызов gdi'шной функции StretchDIBits()" никак нельзя было сделать вывод, что картинка игрой уже сформирована? :-)

Это не обработчик, это перехватчик winapi'шной функции через таблицу импорта. Я такие уже год юзаю и ты про это в курсе.

А теперррь (барррабанная дррробь, сводный оркестр Военно-космических сил Конфедерации за сценой дует "Прррощание славянки") внимание, пррравильный (ну, почти) ответ:

отрисовывай своё токо один раз в сколько то вызовов. Остальное немедленно отдавай вызвавшей программе.

И оно работает! Правда, есть одна закавыка: если что-то произойдёт и про это будет выведено на экран и вывод следующих кадров прекратится, то пользователь с вероятностью (N-1)/N (где N - кратность вывода) про это никогда не узнает. :-(
Поэтому совсем правильный ответ будет звучать так:

Код:

int WINAPI wc4_stretch_dib( ....... ) { [COLOR="Sienna"]// перехватчик StretchDIBits()'а[/COLOR]
.....................
  rc = StretchDIBits( ....... );
  [COLOR="Blue"][B]Sleep ( 1 );[/B][/COLOR]
  return ( rc );
}

И частота кадров сползает с заоблачных многих сотен и даже тысяч в секунду до жалких 63 (или 64, точно не помню) кадр/с - на играбельности это ну никак не сказывается, а прорисовку субтитров поверх картинки резко облегчает. Это раз.
Два - прелюбопытнейшая побочка: резко падает нагрузка на процессор - со вполне резонных 100% до одного-двух %. Это особенно приятно, если на тачке кроме геймы крутится что-то ещё (например, операционная система :-) ).
Три - побочка побочки: заметно стихает рёв вентиляторов и несколько уменьшается квартплата в графе "электроэнергия".
Вот такое вот комплексное решение. И всё это навеяно одной-единственной твоей гениальной строкой: "Остальное немедленно отдавай".
(оркестр за сценой немузыкально наяривает из Высоцкого - "Вот та строка! он гений, прочь сомненья - даёшь восторг и лавры и цветы!")

PS. (пыхтя, задом слезает с трибуны) Кстати, а что была за идея насчёт hDC?

 

Ну, вся винда построена на принципе: "Жадность фраера сгубила. Делиться надо было."

А кончилось, для проблемы, всё, как всегда: оркестр за сценой немузыкально, но с чувством, наяривает "Мурку" - "Ты зашухерила всю нашу малину и за это пулю получай !"

 

Это не конец, это только начало. :-( Самое интересное впереди - как выводить строку субтитра, каким шрифтом (чем-то системным или притачать какой-то из штатных WC4'шных для пущего правдоподобия), как разбивать если по ширине не вписывается, как выводить сквозь 256-цветную палитру, как угадать - 256 цветов это свойство игры или это только на моей тачке (а у кого-то м.б. и truecolor'ом будет), как прекратить вывод при досрочном выходе из loadout terminal'а, где добыть тексты звучащих подсказок...
Так что всё-таки за идея у тебя была про hDC?

 

не прокатит. Ибо выводится уже вся картинка. Вот если бы она выводилась по частям, ты мог по hDC контролировать принадлежность вывода именно к нужной тебе картинке игры, а по координатам - текст выводится или что то другое.

Но картинка, видимо, формируется где то в недрах игры в отдельном буфере... (???)

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

лучше свой приатачить (ну или внутреигровой). Избавит от ситуации, когда пользователь видит "крякозябров".

целыми словами с центрированием обеих подстрок относительно центра экрана.

не понял.

свойство игры. Иначе бы это чудо вообще выводило что и как попало.

ну, если они текстом нигде не выводятся - то только прослушиванием.
Иначе - ловишь, где они там грузятся из файла и... смотришь как это делается.

 

Ну ты и выдал. :-( Ни разу не приходилось воевать с неизвестно где неизвестно кем изменёнными глобальными переменными? Таким bdsm'ом я перестрадал ещё в начале 90-х и больше не хочу.

А он их ещё в двух классах мест увидит - на роликах с прыжком в другую систему и на внутрироликовых менюшках, и там и там гейма выводит строки через DrawText().

Это-то понятно. Я имел в виду "технически как", я такое никогда не писал.

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

Ну, StretchDIBits() получает отдельно картинку в виде массива 8-битных номеров цветов в палитре, отдельно палитру. Чтобы вывести кусок текста заданным набором цветов (фон, буквы, тень и разные переходные цвета на сглаженных краях), надо чтобы эти цвета в палитре уже были; если нету - подбирать ближайшие похожие; и тут начинается такая психоматематика нейрофизиологии цветовосприятия... :-((((( Имел счастье, мы в начале 90-х чуть не сделали программный тест на дальтонизм - теперь что, опять рыть эти три пуда медучебников? :-(

Не уловил. Для этого перехватывать winapi'шные функции какие?
Кстати, а этот самый hDC случайно не позволяет "интеллектуально" (хотя бы с центровкой и разбивкой на подстроки, а в идеале - ещё и с играми палитрой) выводить текстовую строку? Чтобы не париться накладывая текст на картинку, я такого тоже раньше никогда не делал.

А нету текста, вместо которого надо всунуть свой. Вообще нет. Все эти некрологи и подсказки - только войсом. И если в сцене со склеиванием ласт можно тупо вывести пару строк понизу с понтом обычные субтитры, то на боекомплектопогрузочном терминале придётся ещё и интеллектуально потрахаться в поисках хоть как-то подходящего места. :-(

Уже - в логе колонка после "call from". Обыск по дизассемблу .exe'шника нашёл два вызова, обыск по логам - столько же.

Фигушки. :-( По одной из веток всплыл аж на пять уровней и только-только нашёл ветвление - выводить через окно или через directdraw, по другой - подвсплыл всего на два уровня и вляпался в длиннющий цикл, выход из которого только прекращением игры. :-(
Это C++, а по нему отладчиком пешком мотаться хуже чем по минному полю. :-( По крайней мере мне. Или опять намекаешь, что те трассировки, которые у меня занимают недели, у тебя - считанные минуты? :-)

 

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

Ты просто мыслишь канонами линейного DOSпрограммирования. А тут те ООПа.

 

Уже. Лет пять назад по работе. Через примерно полгода на отдельном отделовском собрании был признан начисто неокноплюсплюснопригодным. :-(((
Короче, есть маленькая трассировочная сверхзадачка. Суть вкратце: всё, что гейма читает из своих .tre-файлов, на некоторое время кэшируется и если понадобилось опять - на диск уже не лезет. Перехватчик чтения из файлов есть. Надо найти точку входа в функцию ВзятьДанныеИзКэша() и выяснить её аргУменты. Чтобы узнавать про факт доступа к данным с известным смещением в файле даже в случае если в файл за ними гейма не полезла.

---------- Сообщение добавлено в 14:55 ---------- Предыдущее сообщение размещено в 14:22 ----------

PS. Чтобы не засорять ветку - прошу по WC4 отзываться в специальной для этого моей теме.

 

Интересный метод задавать вопрос и лишать возможности ответить...
Поэтому отвечу здесь, может кому будет полезно:

HDC hdc=CreateCompatibleDC(NULL);

Так вот, ты снова спросил про "сферического коня в вакууме" и поменял на ходу формулировку вопроса, получив совсем другую задачу...

Но даже в этом случае решение сводится к поиску в коде игры нужного hDC...

Если его нет (да-да - тот самый готовый битмап) то всё сводится к созданию функцией CreateDIBitmap() или CreateCompatibleBitmap() временного битмапа, копированию в него того самого битмапа, вызову DrawText() и... если очень надо, копированию обратно в битмап. Но можно обойтись и без последнего пункта, если очень сильно пошаманить.

Тут есть пример кода проделывающего такое действие.

Ну, если снова чего не понял - это ты уже издеваешься. Однозначно.

P/S. На сём прекращаю своё участие в переводе. Это уже через край.

 

Есть желание быть главным (и, вероятно, единственным) тех. специалистом в других возможных проектах по переводу?
Если Вас и правда ведет желание помочь, а не что-то иное... Я был бы рад Вашей помощи.

 

:-((((((((( И третье копирование - при отрисовке. В Жмеринку через Юпитер. Полторы миллисекунды только на встречные сракоперевозки. :-(((((

---------- Сообщение добавлено 29.06.2014 в 00:47 ---------- Предыдущее сообщение размещено 28.06.2014 в 22:59 ----------

Ё, и ты вторые сутки жевал мочалку, не мог сказать сразу??? (одним прыжком кидается к MSDN'у и дизассемблеру, потом минут 10 колотит по клавиатуре, наконец компилирует и запускает) ЕСТЬ!!!

Код:

00:12:03.531 000007c8 call from 0047727C: [COLOR="Blue"]CreateDIBSection[/COLOR]( [COLOR="Teal"]8f011466,[/COLOR] 01969E44, 00000000, 004C5078[=[COLOR="Red"]01980000[/COLOR]], 00000000, 0 ) = 41050bfc 
.................
00:12:05.296 000007c8 frame     5; call from 00477C2E: [COLOR="Blue"]StretchDIBits[/COLOR]( cf011795, dst[0,0,640,480], src[0,0,640,480], [COLOR="Red"]01980000[/COLOR], 01969E44[40,640,-480,1,8,0,307200,100,100,256,256], 00000000, 00cc0020 ) = 480

Вот он, красненький: массив пикселей. Готово: если красненькие совпали - значит, из перехватчика StretchDIBits() можно просто вызывать DrawText() с зелёненьким в качестве hDC.
Урррааа!!!!!!!!
(густо покраснев) А сказал бы сразу внятно - и никто б ни с кем не погыркался и ещё позавчера бы всё забегало. "Предсказамус настрадал", блин. :-(

 

Вопрос.

Какой язык программирования(кроме QuickBasic'а и Assembler'а) наиболее удобен для написания игры под DOS? Нужна возможность работы со спрайтами.

 

Andreus778, много их. Turbo Pascal, Turbo C, Turbo Basic, тоже самое от майкрософта. Туда же ещё кучи вариаций C, включая Watcom. На всём этом написано множество игр.

ага. И с различными большими разрешениями. Как правило, у большинства перечисленных языков, есть библиотеки для этого.

 

Языки сами по себе со спрайтами не работают, нужны соответствующие библиотеки, как правильно замечают выше. Хорошая под DOS: Allegro (4-я версия).

 

Спасибо за подробный, адекватный ответ. Остались ещё хорошие люди. Большое спасибо. Совсем недавно открыл для себя форум любимого сайта.

 

А хрен тама. Не работает. Опять "слышал звон"... :-(

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

Andreus778, обрати при случае внимание на SPHINX C--. Автор - Peter Cellik. Его плюс - именно шустрая как электровеник графика.

 

делать надо правильно. Во всех программах виндовс это работает, а у тебя вдруг перестало... Именно, что ты "слышишь звон", но не знаешь, как делать правильно. Сам же признал, что в ООП и MSDN "дуб-дубом" - так чего меня то крайним делаешь ?

ЗЫ. Блокировка в теме каждый раз, как у тебя что то не получилось - свидетельствует не только о неуравновешенности и неблагодарности, но и неуважении к другим людям и их мнению.

 

Балабол. И единственный программист, который показывает вместо своего кода - нагугленный. :-(

 

Думаю, что вот эта новость заинтересует драйверописателей и интересующихся "как программировать видеоускоритель напрямую", ну и владельцев сего чудо-девайса тоже:

Открыт исходный код стека драйверов графической подсистемы Raspberry Pi


Прямая ссылка на документацию.

Прямая ссылка на исходники драйвера.