Анимация в игре. Как лучше управляние многими объектами.

← →
OW © (2011-12-12 11:25) [0]

Пишу на досуге игрушку. Паучки должны бегать.
Есть картинка стоящего паука и две бегущего. Соотв., когда бежит, скрываю стоящую, меняю координаты left|top бегущих картинок и показываю по очереди. Как добежал, скрываю бегущего, показываю стоящего.
Для отладки базовых действий юнита у меня пока 1-2-5-10 бегают.

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

как бы лучше визуализировать, что бы не было жуткого тормоза?
(попробовал 100 сделать - тормозит-с :). Думаю, просто методы по оптимизации не прокатят, надо как-то логику поменять)

Сейчас есть класс, который двигает паука/ов
Паук, если хочет пойти, делает заявку, куда ему надо. Класс перемещает всех пауков, кто оставил заявку, по координатам куда им надо
Порциями (для создания иллюзии движения).

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

Короче, :)
Много объектов, все постоянно что-то хотят. Как уменьшить тормоза.

← →
Думкин © (2011-12-12 11:31) [1]

Тут надо все смотреть. 100 объектов само по себе немного. Но как ты рисуешь, как взаимодействия отрабатываешь.

← →
RWolf © (2011-12-12 11:33) [2]

где тормоза-то?
если в рисовании — можно посмотреть в сторону Direct2D.
если в обсчёте сцены — это что-то нездоровое, надо оптимизировать.

← →
OW © (2011-12-12 11:40) [3]

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

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

Ладно, спасибо, подумать надо, короче..

← →
OW © (2011-12-12 11:42) [4]

тогда уж еще спрошу

> посмотреть в сторону Direct2D.

а там не очень сложно ?

← →
RWolf © (2011-12-12 11:49) [5]

вовсе не сложно; графика программируется на уровне виртуальных экранов и спрайтов.

← →
Андреевич (2011-12-12 12:52) [6]

> OW © (12.12.11 11:25)

на чем пишешь? :)
что именно тормозит?

список экземпляров TPauk, в таймере на пересчет мира пробегаем по циклу и делаем методы move/rotate/, обрабатываем коллизии, всякие ситуации. потом циклом пробегаем и делаем draw() на буфер, буфер выводим.
В общем нужна конкретика, можно довольно быстро и на канвас рисовать, если конечно там область вывода не 1920*1200 =)

← →
OW © (2011-12-12 13:14) [7]

> на чем пишешь? :)
> что именно тормозит?

на delphi :)

function Action дает 70% времени.

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

if MyLife < 50 then -- если мало жизни
begin
if GetCountEatPlace(0,0) > 0 -- если есть еда
DoEat;
if GetCountEatPlace(-1,-1)
DoMove(-1,-1);
if GetCountEatPlace(-1,0)
DoMove(-1,0);
...
else begin
if GetLifePlace(-1,-1) = -1 -- стоит чужой паук, уровень своей жизни не говорит
DoAttack(-1,-1); --пойдем его бить, у нас жизни много
....
if GetLifePlace(-1,-1) > 50 -- свой стоит.
DoSex(-1,-1); -- пойдем размножаться, у него и у меня сил хватает для этого

ну и т.п.

MyLife - переменная, доступная для программирования, содержит уровень жизненных сил юнита.
GetLifePlace - функция, доступная для программирования
DoEat, DoMove - простейшие команды, доступная для программирования

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

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

уфф...

Собственно, первая версия игры
http://www.delphisources.ru/pages/sources/raznoe/2009-year/tipa-life.html

теперь будет все серьезнее :)

← →
Андреевич (2011-12-12 13:18) [8]

> function Action дает 70% времени.

ну это наверное в бесконечном цикле, или есть таймер на 25-30фпс?
скачать пока не могу, но как-то уж много она получается отжирает :) или там парсится при каждом пробеге цикла?

← →
Pavia © (2011-12-12 13:26) [9]

У меня более 100 гномов бегает и тормозов не заметно :D

http://forum.sources.ru/index.php?act=Attach&type=post&id=1629890&attach_id=0

А если серьёзно вечером гляну.

← →
OW © (2011-12-12 13:29) [10]

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

А теперь хочу с парсером своим, картинками, короче по человечески

> там парсится при каждом пробеге цикла?

да, при каждом. Ситуация может изменится и "переменные окружения" поменяться

← →
Андреевич (2011-12-12 13:38) [11]

> Pavia © (12.12.11 13:26) [9]
> У меня более 100 гномов бегает и тормозов не заметно :D

а у меня тысячи - http://antonn.com/xlam/reli_2.zip =)

> да, при каждом. Ситуация может изменится и "переменные окружения"
> поменяться

ну и поставить флаг смены текста, после парсинга флаг сбрасывать

← →
RWolf © (2011-12-12 13:40) [12]

> да, при каждом.

интерпретация исходника — в общем случае затратное занятие, надо бы компилировать в байт-код.

← →
OW © (2011-12-12 13:41) [13]

ну а если скачает кто, там надо создать \factory
куда положить
dcc32.exe
System.dcu
SysInit.dcu
они и копилят в dll всю писанину игрока. Работало быстро.
готовый то код :)

С парсером сложнее..
И правила навернул. Теперь жизнь не увеличивается, а наоборот, уменьшается.
Надо есть, что бы восстановить. И тактика стояния на месте не оправдает себя, т.к. еда появляется чуть меньше, чем надо для поддержания жизни.
Короче, задумал намного круче :)

← →
Андреевич (2011-12-12 13:41) [14]

LUA прикрутить...

← →
OW © (2011-12-12 13:42) [15]

> Андреевич (12.12.11 13:38) [11]

Класс!

Это как?

← →
Андреевич (2011-12-12 13:45) [16]

как тут http://forum.sources.ru/index.php?showtopic=314767&st=60&#entry2721725 , но вывод графики немного покруче, не сканлайн. Если брать сторонний движок с видяхой то еще меньше грузить будет (на больших размерах картинки сильнее тормозит софтварный)

← →
Андреевич (2011-12-12 13:48) [17]

А по LUA это не ко мне, нужен кто-то умный :) Но вещь серьезная и гибкая

← →
OW © (2011-12-12 13:50) [18]

> Андреевич (12.12.11 13:38) [11]
с параметром 600, примерно дает картинку, как думаю, у меня может быть.
Но это у тебя по кол-ву объектов и скорости неплохо, это.. очень даже неплохо :)

← →
Андреевич (2011-12-12 13:54) [19]

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

← →
OW © (2011-12-12 13:55) [20]

> интерпретация исходника — в общем случае затратное занятие,
> надо бы компилировать в байт-код.
>

се ля ви

, блин :)

← →
RWolf © (2011-12-12 14:12) [21]

http://wiki.freepascal.org/Pascal_Script ?

← →
Anatoly Podgoretsky © (2011-12-12 14:15) [22]

> Pavia (12.12.2011 13:26:09) [9]

Гномов, попробуй великанов

← →
Pavia © (2011-12-12 18:59) [23]

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

По поводу скорости, да оптимизацией тут надо заняться.
А ещё графику переделать.
И решить насчёт скриптового языка. Как его планируешь дальше развивать.

По поводу графики отказаться от StrinGrid.

Анатолий Подгоретский заметил, что если гномов сделать крупнее, то моя демонстрашка будет тормазить.
Да это так поэтому во многих играх идут на хитрости. Тормаза у меня идут из-за того что в один пиксель записываются много солдат(юнитов, гномов, домов и тд).
Во всех играх идёт строгое разграничение по пикселям поэтому солдаты(юниты) не пересекаются. Либо пересекаются незначительно.
Если так сделать то мои гномы не будут тормозить.
А вторых если их сделать большими то они такие страшные, пугающие. То слева то справа выскакивают.

Вернёмся к вашей игре жизнь. У вас всё сделано квадратиками. Дальше надо решить как вы будете делать дальше квадратиками или спрайтами с анимацией.

Потому что тут тоже можно сделать оптимизацию если спрайтами, то можно загнать картинки в видео память что быстрее.
Способов это сделать много. GDI, OpenGL, DirectX (Diretc Show, Direct3D)

Логику программы тоже надо оптимизировать. Хотя тут еще надо посмотреть что именно тормозит логика или вывод. Смотреть лучше в профилировщике.
Средств море.
http://en.wikipedia.org/wiki/List_of_performance_analysis_tools

> pole.Cells[Soldiers[i].PosX,Soldiers[i].PosY]:=Soldiers[i].
> Who+floattostr(Soldiers[i].Life);

Так делать нестоит. Для внутреннего представления данных используй машина ориентированные типы такие как real.
А строковые используй для ввода и вывода пользовательских данных.

По поводу скриптового движка. Так и планируешь оставить его в виде DLL?
Или сделать свой интерпретатор, компилятор?
Для оптимизации всяк надо компилировать хотя бы в байт-код это будет в 10-100 раз быстрее чем интерпретировать.

По поводу управления многими объектами. Быстрее будет работать если одно действие будет выполняться сразу над всеми.

> Пауков в логике игры может быть много (крайний случай -
> весь экран, 100х100 ориентировочно),

У тебя что паучки 10 на 10 пикселей? Это слишком мелко
А во вторых при построении изображения у тебя всёравно будет только ~2 прохода по изображению. Первый это задний слой трава, песок, камни и второй слой уже деревья пауки дома. Если будут летающие то еще и третий.
Так что число пауков не важно.

Вывод изображений так делать не стоит.

procedure tBoard.OnDraw(Sender: TObject; ACol, ARow: Integer; Rect: TRect; State: TGridDrawState); begin If GetSolByXY(ACol,ARow)<>nil then begin Pole.Canvas.Brush.Color:=GetSolByXY(ACol,ARow).Color; pole.Canvas.FillRect(Rect); end; exit; If GetSolByXY(ACol,ARow)=nil then begin Pole.Canvas.Brush.Color:=$FFFFFF; pole.Canvas.FrameRect(Rect); exit; end; Pole.Canvas.Brush.Color:=GetSolByXY(ACol,ARow).Color; pole.Canvas.FrameRect(Rect); end;

Вывод должен быть коротким.
begin Pole.Canvas.Brush.Color:=map[ACol,ARow].Color; pole.Canvas.FrameRect(Rect); end;
Иначе это плохо скажется на производительности.

> Так делать нестоит. Для внутреннего представления данных
> используй машина ориентированные типы такие как real.

с целочисленными вычисления быстрее

> Да это так поэтому во многих играх идут на хитрости. Тормаза
> у меня идут из-за того что в один пиксель записываются много
> солдат(юнитов, гномов, домов и тд).
> Во всех играх идёт строгое разграничение по пикселям поэтому
> солдаты(юниты) не пересекаются. Либо пересекаются незначительно.
>

не понятно как-то..

> не понятно как-то..

Танк на танк обычно в танталовой игре не налезает. А у меня гном на гнома налезает.
Но дело не в этом, а в том если пересчитать число скопированных пикулей на экран.
То в обычных танчиках он будет порядка ~2 экранов.
У меня 100 гномов. по 80х80 пикселей 100х80х60/800х600=1 экран плюс ещё один экран.
Если гнома сделать больше раза в 4 по вертикали и горизонтали, то будет
100х320х240/800х600=16 экранов. Если я бы запретил перекрытия больших гномов, то тогда я бы всего навсего рисовал не 100 больших гномов, а всего 100/16=~8
Запрет как таковой возникает когда мы делаем игру и вводим клетки в которой может находиться только один юнит(гном или здание).

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

> методов можно нарисовать пару тысяч раз в секунду, не заморачиваясь
> насчет пересечений

ДА ты чё?
У меня там без тормозов рисуется около 100-500(просто точную цифру трудно назвать) за кадр в секунду будет 1000-5000.
10 000 в секунду(1000 за кадр) тоже рисует отлично, но немного притормаживает.
И ты мне предлагаешь ещё что-то изобретать?

> И ты мне предлагаешь ещё что-то изобретать?

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

> Pavia © (12.12.11 19:05) [24]

ты не понял
tipalife - это только идея
OW пишет вторую, на основе этой :)

> По поводу графики отказаться от StrinGrid.

так было проще следить за юнитами

в остальном - думаю, OW стоит сказать спасибо за советы :)

http://zaycev.net/pages/7929/792922.shtml?miniplayer=true

саундтрэк к игрушке

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

Для игры типа warcraft 2 хватает с запасом в 2-5 раза. Но соглашусь что альфа покрасивее будет. Вот если будет не хватать, тогда можно заняться оптимизацией.
Кстати а что именно предлагаешь взять?

Конкретно не скажу, мне мое нравится, но никому не даю. Когда-то пользовался FastLib"ом и SpriteUtils"ом.
Кроме альфы еще есть повороты, причем со сглаживаем, тоже сильно могут убить скорость.

Анимация в игре. Как лучше управляние многими объектами. Найти похожие ветки