BomberMan на Delphi 7

[Гром]

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

Да нет, как раз это правильно. Вы в оригинал играли? Если бомба взрываясь задевает другую, то они взрываются вместе.

Действительно, если первая не задевает вторую, то взрываются по очереди. Значит, тут все хорошо. Просто в оригинал почти не играл и не помню, а проблема синхронных событий у объектов одного типа мне знакома по реализации анимации, вот и заподозрил)

[Odinok]

Жаль, что ни кто не поможет с оптимизацией

[Odinok]

Хотя бы литературы подскажите, ли кда копать, что бы оптимизировать

[phomm]

я бы посоветовал НЕ генерить карту из тайлов за каждый прогон.

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

ещё замени везде trunc (что-то / 64) на (что-то div 64). для round также. всё равно у тебя не используются нигде вещественные числа, и загружать проц лишней кучей операций с точкой , да потом ещё округлением - неслабо ест...

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

пример работы с Timagelist'ом могу тебе подогнать, но полагаю, и сам можешь разобраться.

[Odinok]

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

я бы посоветовал НЕ генерить карту из тайлов за каждый прогон.


ещё замени везде trunc (что-то / 64) на (что-то div 64). для round также. всё равно у тебя не используются нигде вещественные числа, и загружать проц лишней кучей операций с точкой , да потом ещё округлением - неслабо ест...


пример работы с Timagelist'ом могу тебе подогнать, но полагаю, и сам можешь разобраться.

а вот у меня почему то с дивом проблемы были, не так округлял, но попробую заменить
примерно можешь с можешь показать, проще будет разобраться

[Beermonza]

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

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

Это в РАЗЫ быстрее. Для любой процедуры отрисовки проще и быстрее один раз получить параметры и отправить данные в видеопамять, чем затрачивать время на многочисленные куски. Это проверялось неоднократно так и этак. Пока нет изменений на карте, весь сборный задний фон должен быть одной картинкой, отображаемой сразу с буфера заднего фона. Когда будут изменения этот буфер обновится.

phomm, для начала предложения существуют прописные буквы (А, Б, В, Г и т.д.)

[phomm]

Простите, я уже почему-то привык к написанию с маленькой, знаю, что надо исправляться, буду стараться и исправлюсь))

Я написал вполовину - ибо подразумевал, что при постоянном смещении персонажа, а в данной игре так происходит почти всё время, будет выполняться смещение вида карты и отрисовка картинок, в первом(нынешнем) варианте всех, а во втором часть браться из готового, а часть всё равно рисоваться, ну вот этакая "половина" ))
Тем более , я считаю, большинство операций с канвасом и так съедают многое... и здесь не получится существенного роста (в разы) по графике, потом опять же TTimer, он же вроде 18,6 Гц - т.е. 54 мс - значит быстрее всё равно не добиться перерисовки, надо и таймер менять. Вобщем, много тут узких мест...

Пример на TimageList - только пример, ни разу ни рабочая поделка (чтобы не ругали за такое, писал очень давно, проводил пробы... сейчас так криво не пишу...)
Основное, что там нужно смотреть, это Imglstar - массив имейджлистов, каждый лист соотвествует определенному игрообъекту, коих много )

[Beermonza]

TTimer может работать и на 1 мс, все зависит от быстроты кода внутри него. У меня, например, TTimer поддерживал 30 мс, и 15 мс (сравнивалось с быстрыми таймерами), но между ними вариантов нет, это связано с тормозностью некоторых функций. Он оттягивает время, если код не успевает выполниться, и вроде накидывает по 15-16 мс, пока не узнает, что код выполнен. Отчетливо я видел разницу 16, 32, 48, 65 и т.д., а промежуточные значения на скорость анимации никак не действовали. Но, если в таймер этот запихнуть только счетчик, то он с интервалом 1 мс насчитает 1000 как и положено за 1 с.

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

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

Поясню, почему в разы, а не половина. Если грамотно провести анализ сдвига карты, то можно заметить, что попиксельное смещение идет постоянно, но поклеточное только по прошествии некоторого времени, которое равно {Интервал таймера} * {Число пиксерей в клетке}. Т.е. обновление заднего фона требуется гораздо реже, чем кажется на первый взгляд. Мы просто делаем буфер больше чем вмещается на экране на 1 клетку, и двигаем вывод буфера по-пиксельно (выводить все равно каждый такт), а как только сдвиг насчитает размер клетки - перерисовывать буфер по данным массива, но уже применив сдвиг координат по карте, смещение заднего фона снова установить в 0 по нужной оси.

От Canvas нужно уходить, если дело касается масштабного сбора задника через малые промежутки времени, с учетом большого количества анимированных объектов.

[phomm]

Спасибо, действительно идея теперь мне ясна, прирост налицо. Можно ли развить мысль и пробовать заводить больше буфер, чем на одну клетку ? Ведь так можно вообще просто весь задник выводить, но будет уже медленнее, конечно, ибо вывод дольше. Так ли это ?
И ещё такое уточнение, ведь есть принципы, по которым происходит обрезка вывода, если он не входит в экран, тот же ClipRect у Canvas? Может быть, они спокойно позволили бы оперировать выводом всего буфера (задника всей карты) без потерь производительности ??

[Beermonza]

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

Можно ли развить мысль и пробовать заводить больше буфер, чем на одну клетку ? Ведь так можно вообще просто весь задник выводить, но будет уже медленнее, конечно, ибо вывод дольше. Так ли это ?

Карты могут быть достаточно большие, что буфер TBitmap просто откажется загружать такой объем памяти в себя. Если брать по нескольку клеток, то обновление карты будет менее адекватным. Чтобы по ходу увидеть изменение, нужно топать несколько клеток, кроме того отслеживая события обновления на каждой.

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

И ещё такое уточнение, ведь есть принципы, по которым происходит обрезка вывода, если он не входит в экран, тот же ClipRect у Canvas? Может быть, они спокойно позволили бы оперировать выводом всего буфера (задника всей карты) без потерь производительности ??

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