directdraw функция blt

[sashonk]

Сообщение от Kostia

Возможно
1. Текстуры слишком большие
2. Может вы во время процесса игры подгружаете дополнительные ресурсы с жесткого диска
3. 300-400 многовато, хотя если куча маленьких картинок ~ 16*16, то должно быть норм

Как оптимизировать
1. Сокращайте число спрайтов
2. Уменьшайте размеры текстур
3. Тестируйте и ищите в каком месте ваша программа работает медленнее всего и пытайтесь оптимизировать.
4. Переходите на Direct3D или OpenGL, но лучше попытаться оптимизировать то что имеется.

1. текстуры имеют размер 60x60, соответственно по спрайту в каждой клетке карты.
2. с диска ресурсы подгружаются 1 раз по первому требованию, затем хранятся в менеджере.
4. уже давно задумываюсь о переходе на HGE, но все никак не могу отвязаться от своего творения. Уж больно много времени потрачено на разработку, да и что говорить - игра-то уже написана. Просто есть понимание того, что производительность ограничена, и создать карту в несколько тысяч клеток уже невозможно, что неприятно

[sashonk]

Сообщение от phomm

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

phomm, мысль хорошая!

[sashonk]

есть еще вопрос. реально ли сделать полноценный альфа-блендинг на ddaw? Так чтобы рендерился весь полный экран. Сейчас я использую ассемблерные вставки, но скорость их работы оставляет желать лучшего (
Уже несколько спрайтов (до 10) приводят к сильным затормозам, я уже
молчу про фул-скрин. В идеале вообще бы хотелось использовать текстуры с переменным альфаканалом

[phomm]

Дак выкладывай куски кода, которые отвественны за всю рисовку, поглядим, покумекаем.
Кстати, размерчик текстур неплохо бы довести до 64, и вообще кратные 2 лучше обсчитываются (хотя лично я не проверял говорю как слышал от умных людей)

[sashonk]

Код я сам не писал, а взял когда-то с какого-то сайта. Там у чувака был рабочий пример, который рендерил полноэкранную картинку при разрешении 800x600 и глубиной 16 бит с завидной скоростью. Сколько я ни старался, у меня не получилось добиться такой производительности. То ли дело в разрешении, то ли в том, что у меня картинки проклятые. В общем, решил что дело это гиблое) Выкладывать все бессмысленно, могу выложить функцию рендера пов-ти, написанную с использованием mmx. Она довольно большая, т.к. там раздельный код для разных форматов пикселя, поэтому прикреплю аттачем.

[sashonk]

Сообщение от phomm

Дак выкладывай куски кода, которые отвественны за всю рисовку, поглядим, покумекаем.
Кстати, размерчик текстур неплохо бы довести до 64, и вообще кратные 2 лучше обсчитываются (хотя лично я не проверял говорю как слышал от умных людей)

да, я тоже где-то читал, что это лучше, но руки проверить так и не дошли)

[sashonk]

Сообщение от phomm

Дак выкладывай куски кода, которые отвественны за всю рисовку, поглядим, покумекаем.
Кстати, размерчик текстур неплохо бы довести до 64, и вообще кратные 2 лучше обсчитываются (хотя лично я не проверял говорю как слышал от умных людей)

phomm, посмотрел код?

[Warn]

Знаю, что была пейпера от амд по поводу как написать быстрый memcpy основные моменты, на которые они обращали внимание это выравнивание, потом нужно пользоваться преффечером процессора и соблюдать локальность данных в пределах кеша проца, пользовать mmx и sse. Тут я думаю на те же моменты следует обратить внимание, что бы ускорить ф-ю.

[phomm]

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

Слова насчет буферов и менеджеров, думаю всё равно в силе, хоть на каком ЯП и АПИ

[Beermonza]

sashonk, я в свое время тоже пытался использовать DDraw, но бесполезно. Как только требуется вывод полноценных альфа-канальных текстур (а не с ключом прозрачности) вся сила блиттинга испаряется. Тоже пытался задействовать ассемблерные вставки, но причина лежит ниже. Обработку данных текстуры по рукописной процедуре на ассемблере выполняет процессор. Ему нужно взять данные из видеопамяти (у тебя) обработать и положить обратно. Как известно, такой метод слаб в скорости из-за меньшей частоты шины между CPU и видеопамятью. Оно не предназначено для такого использования, ...тут быстрее будет CPU + оперативная, но опять же, нужно результат как-то отправлять в видеопамять, и снова всплывает слабое звено. Советую бросить эту затею, если действительно нужна скорость, или если почти устраивает - переписать процедуру блиттинга на конкретную битность текстур.

Скорость копирования зависит от того кратны ли данные (в байтах) четырем. Стандартная операция копирования данных в памяти работает на обычных регистрах. Если применяется MMX или SSE, то обработку и копирование можно выполнять, соответственно, по 8 и 16 байт. Если данные не кратны этим числам, то будет тратиться время на обработку "хвоста", которая просто пропускается если условия кратности выполнены.