Уменьшение загрузки ЦП и увеличение скорости программы.

[Shadow_1329]

Мой мозг это не переварит...

Это не весь код=)

[Вадим Буренков]

Это не весь код=)

А почему такая привязанность к canvas? Ведь как бы ты не старался, какой сумасшедший код не писал все равно останется мелькание и подтормаживание. И спрайты на определенный угол нельзя повернуть . К тому же чем больше код тем больше в нем ошибок. Не легче ли получится перейти на какой либо движок?

[JTG]

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

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

(перед использованием сделай копию всего проекта на всякий случай

[Shadow_1329]

Я перейду на BitBlt когда будет нужно. Насчет движков я уже сказл нет нет и еще раз нет! Я буду писать собственные движки. Мне не столь важен конечный результат сколь желание выучить все аспекты игрового прогрмиирования, чтобы потом начать делать все самому. На движки перейти легко. А самому сделать что-то хорошее интересней. Насчет тормозов - я знаю где они=). Просто метод оптимальнее своего не знал. А щас попробую что-либо исправить.

[Вадим Буренков]

Я буду писать собственные движки.

Canvas по сути уже и является графическим движком т.к умеет делать с графикой почти все что нужно. Нужно понять что движок это только графика, а игра на ней не завязана. Игра будет хорошей или плохой вне зависимости на чем она сделана: на DX или OpenGL, на Delphi или C++.
Ты противоречишь сам себе:

Мне не столь важен конечный результат сколь желание выучить все аспекты игрового прогрмиирования

И далеко ты уже ушел? Вместо того чтоб заниматся программированием: изобретать новые алгоритмы, познавать что либо, делать игру а потом радоваться результатам ты уже X дней Y часов и Z минут пытаешься сделать код прорисовки карты который в движке был бы написан за 5 минут. Лично я делаю гонки и то что они на OMEG'е не имеет значаения. Просто вместо TBitmap.LoadFromFile есть процедура Tex_LoadFromFile, вместо Canvas.draw есть SSprite_Draw и все! Для работы анимаций в омеге мне пришлось писать собственный класс как и в канвасе. А теперь забыв про тормоза я занимаюсь только игрой. Пока ты думал как рисовать перса я доделал свой первый редактор объектов для игры при этом поняв основы создания визуальных редакторов.

На движки перейти легко.

Кто сказал что легко? Например в канвасе существует куча инструментов по работе и выводу текстов а в OMEGе все сложнее. А например для текстурирования ландшавта в игре я сейчас частично работаю с чистым OpneGL.Что он тоже легче канваса и знаний никаких не прибавится при работе с ним?

. А самому сделать что-то хорошее интересней.

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

[Пепел Феникса]

Насчет движков я уже сказл нет нет и еще раз нет! Я буду писать собственные движки.

ты все равно юзаешь движок(Canvas, OpenGL,DirectX это все графические либы иначе говоря графические движки...но всетаки будем звать это либами/библиотеками)

или ты сам все на АСМе пишешь?

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

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

игрового или графического?
тебе полюбому придется перейти на OpenGL или DirectX
сожалею но это так...разработка собственной графической библиотеки(с нуля) себя не оправдает.
согласен с Вадимом, ты тратишь время на одно, а мог бы давно пройти дальше.

На движки перейти легко.

твои б слова, да IDE б в уши

А самому сделать что-то хорошее интересней.

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

[Beermonza]

Друзья мои! Давайте не будем передвигать тему в сторону выбора движков/библиотек. Если человек хочет разобраться с примитивами и выжать из них максимум, то ему за это честь и хвала. Большинство игроделов понятия не имеют как там в движке все происходит - они не программисты, они сборщики, ...и с движком нет разницы какой ты язык знаешь, можно не знать никакого, просто соблюдать правила, ...да простят меня так не считающие.
Shadow_1329, хочет программировать на Delphi, изучить его классические библиотеки, применить их с максимальной отдачей, может и за счет дополнительных вставок, там где код работает медленно, научиться оптимизировать код, ...это ли не бесценный опыт?
Если человеку хочется чем-то заниматься, он этим занимается, советы давать можно, но "нажимать" ни в коем случае, ...поосторожней товарищи, уважайте желание автора топа.
Вы думаете это он от незнания пишет игру таким образом? ...на страницах форума полно информации по движкам и библиотекам, и он ее наверняка уже проштудировал, и сделал свой выбор - начать с начала. Вот и пусть шагает путем, которым шагали все любознательные программисты. А если он сдастся, то мы об этом рано или поздно узнаем

[Shadow_1329]

Ну здаваться я не собираюсь. Я понимаю что нужно будет использовать грфические библиотеки в 3д но в 2д это мне не нужно. Хотя была мысль и для 3д свою библиотеку написать. И кто сказал что я стою на месте??? Как раз таки я двигаюсь. Просто не всегда все получается или просто иногда нужно очень хорошо подумать головой.

[Beermonza]

Shadow_1329, вот смотри. Первые строки в процедуре:

For MMH := MapH downto 1 do
  Begin
    For MMW := 1 to MapW do
      Begin
        If map[MMW, MMH] = 1 then FullMap.Canvas.Draw(MMW*100-100, MMH*100-100, Grass);
      end;
  end;

Это алгоритм сбора подложки. Его тут быть не должно в открытом виде. Т.е. каждый такт (буду называть интервал тактом, если не против) у тебя подложка собирается заново и при том по всей карте, хотя на экран вмещается в некоторой точке персонажа только ее часть. Значит, нужно посчитать, сколько тайлов влезает на экран по-горизонтали и по-вертикали, и производить вывод только такого диапазона. Дальше, этот код нужно запрятать в условие, в котором проверяется флаг сбора подложки, если он true, значит собираем подложку и флаг в false, если и был false, значит просто перекидываем в кадр готовую прежнюю подложку. Вот так:

  If UpdateTerr then
    Begin
      For MMH := MapUp to MapDown do
        Begin
          For MMW := MapLeft to MapRight do
            Begin
              If map[MMW, MMH] = 1 then TerrBuf.Canvas.Draw((MMW-MapLeft)*100-100, (MMH-MapUp)*100-100, Grass);
              UpdateTerr := False;
            end;
        end;
    end
  else Buf.Canvas.Draw(MapDispX, MapDispY, TerrBuf);

Здесь TerrBuf - TBitmap, размером с область карты, видимой на экране, плюс 1 тайл по периметру, чтобы не видеть обрезки, при смещении подложки. Buf - TBitmap, основной буфер кадра, где производится построение кадра, он такого же размера, что и TerrBuf.
MapDispX и MapDispY - это переменные сдвига подложки под ногами главного персонажа.
MapUp, MapDown, MapLeft и MapRight - переменные, указывающие диапазон выбора участка карты в полном массиве карты. Они переназначаются при переходе персонажа на следующую клетку, где идет указание еще и флага обновления подложки. Вот так:

  If Pc[plco].SPX >= 100 then
    Begin
      Pc[plco].Spx := 0;
      Pc[plco].Ux := Pc[plco].Ux + 1;
// смещаем диапазон фрагмента на 1 клетку -----------
      Inc(MapLeft);
      Inc(MapRight);
// если справа предел, укажем что MapRight = граница карты
      If MapRight > MapW then MapRight := MapW;
// у нас перс в следующей клетке, обновляем подложку
      UpdateTerr := True;
// ------------------------------------------------------
      Mapobj[Pc[plco].Ux,Pc[plco].Uy] := 3;
      Mapobj[Pc[plco].Ux-1,Pc[plco].Uy] := 0;
    end;

Вообще прием смещения на клетку Pc[plco].Ux := Pc[plco].Ux + 1; не универсален. Гораздо удобнее вместо 1, применить переменную MapStep типа ShortInt, чтобы при нажатии клавиш ей присваивались значения 1 или -1, в зависимости от направления. Кода будет сразу меньше и он будет более глобальный, описывающий сразу все направления движения. Я показывал пример, посмотри там внимательно.

Теперь, что делает вот эта запись в конце процедуры UpDatelevel()?

Updatelevel;//обновление уровня

...вызывает сама себя?

[JTG]

там 2 разные процедуры. вроде бы