Nape 2 — Тест производительности создания некоторых структур

Этот пост есть небольшое дополнение к этому посту. Только тогда я не сделал замер производительности.
Когда открыл для себя Vec2.get() написал Луке мол классно он придумал запулить тип Vec2 и что хорошо было бы запулить другие типы (да и вообще все что возможно :) ).
Он ответил, что не видит в этом смысл, так как это единственный жирный служебный тип, который часто используется. Я ничего ему не отписывал — хозяин барин — но мысленно с ним не согласился подумав, что пула много не бывает и надо протестировать другие типы на скорость создания — так ли как он говорит или по-другому.

Итак, создание Vec2:

new Vec2()  // 474 ms

Теперь Vec2 достаем из пула и удаляем:

result = Vec2.get();  // 266 ms
result.dispose();

Теперь создание Vec3:

new Vec3();    // 463 ms

Далее перешел к тестированию создания тела и шейпов:

Body // 8500 ms
Polygon // 20000 ms
Circle // 5000 ms

Ну и напоследок тест некоторых стандартных типов флеш:

Array // 246 ms
Point // 184 ms

Также протестировал мной созданый класс Vertex.
Он содержит только две публичные переменные: x и y

Vertex // 150 ms

Выводы:
Как видно по сравнению с другими типа нейпа Vec2 еще не такой и сложный для создания. Конечно, возможно, другие типы не так часто создаются как Vec2, но это известно только Луке. Есть игры, где один раз уровень загрузил и больше ничего не добавляется, а есть, где куча динамических разрушений или физическая система частиц или и то и другое. Вот тут то и пригодится пул для того же Body или Polygon. А если игра делается для мобильных устройств?..

Решил объединить тест по созданию тела с шейпом.
Например, создадим ящик:

body = new Body(BodyType.DYNAMIC, new Vec2(100, 100));   
body.shapes.add(new Polygon(Polygon.box(50, 50)));

Ящик будет создаваться за 38324 ms

А теперь припустим у нас Body, Shape и Vec2 есть в пуле.

body.type = BodyType.DYNAMIC;               
body.position.setxy(100, 100);
polygon.localVerts.merge(Vec2List.fromArray(Polygon.box(50, 50)));
body.shapes.add(polygon);
 
body.shapes.clear();
polygon.localVerts.clear();
polygon.worldVerts.clear();

В этом случае создание происходит за 17000 ms, но как видно код еще можно оптимизировать (но при данной реализации нейпа можно сделать только так).

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

Поделиться в соц. сетях

Опубликовать в LiveJournal
Опубликовать в Google Plus
  • Dmitriy

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

  • Dmitriy

    Кстати, вот Вы очень большое внимание уделяете производительности, что правильно.
    Не знаю, тестировали вы или нет, но по моим тестам использование функции Нейп graphicUpdate, для объектов не наследуемых от DisplayObject сразу ведет к увеличению времени выполнения space.step() на 25%.
    Выход — наследовать свои объекты, например, от flash.display.Shape даже если они никак не связаны со стандартным списком отображения. Чтобы нейп сам вращал и присваивал координаты, без вызова лишних функций. Мне это дало существенны

  • Dmitriy

    й выигрыш производительности.
    Но только для версий Nape <= Milestone 10.1. В следующих версиях такая хитрость будет невозможна.
    Поэтому я, предварительно, думаю байкотировать более новые версии. :)

  • Dmitriy

    Вообще, Nape постепенно становится более навороченным и более медленным. Что мне не нравится. Он может потерять свое основное преимущество — скорость. :(

  • VirtualMaestro

    Не совсем так. Как то я уже писал в комментариях, что методы для работы с графикой оно конечно удобно, но концептуально не правильно, так как физ. движок не должен заниматься проблемами графики.
    На счет DisplayObject. Что касается меня, то я почти забыл что это :) Так как для графики использую Genome2d (то есть Stage3d). Все рисуется во флеше (то есть) вектором, а во время выполнения движок делает с этого текстуры.
    Я считаю, по-хорошему, этим должен заниматься игровой движок (ну или какая то внешняя система). При таком подходе можно сделать кучу оптимизаций, например, прекратить симуляцию физ. объектов и не рендерить их графику, если они не попадают в область видимости, либо еще, что то типа этого. В текущей версии Нейп, со стандартной обработкой графики через graphics нет возможности этого сделать (то есть есть, но тогда все-равно невозможно будет использовать graphics). Игровой движок стоит уровнем выше физ. двига, потому ему виднее какой объект игры как должен себя вести — должен ли отображаться, симулировать, обновлять отображение или нет, а также вообще существовать :)
    В Нейпе появляются новые фичи, но он от этого не медленнее. Новые фичи это хорошо, так как дают возможность сделать вещи много проще, да и вообще дает возможность иметь то чего нету в других физ. двигах. Да, если мы делаем какой-нибудь простенький физ. пазл, где у нас происходит симуляция кружков и квадратов, то все что есть в Нейпе не нужно, но ведь не все такие игры :)
    На самом деле с момента написания первой версии он не стал медленным (может быть самую кроху), но зато стал намного стабильнее и мощнее (особенно соединения).
    Если проект находится на стадии завершения или хотя бы на середине, то да, не стоит переходить на новую версию (новая версия будет содержать изменения ламающие обратную совместимость). Но если это только начало, то стоит, ведь в новой версия будет такая бомба как CCD (да и кучу других изменений), что для меня является последним гвоздем в крышку гроба Box2D.
    Тут можно почитать, что добавиться/изменится в новой версии http://pastebin.com/ifqGbLvZ
    Если разобраться, то у нас нет альтернатив, так как Box2D, это ниразу не альтернатива, а других вменяемых двигов нету. В Нейпе проделана очень большая работа, чтобы придти к текущему положению дел.
    Тут немного дело в другом — Нейп написан и спроектирован на Haxe и потому много вещей под хекс работают намного быстрее чем в AS3 (хотя бы те же листы, в хексе они работают на порядок быстрее чем в AS3. Инлайнинг и все такое…)

    Если разобраться, то для флеша нету солидной среды разработки игр. Свои велосипеды устал писать. Не то, чтобы оно мне не нравилось (люблю думать над разными архитектурами и оптимизациями), просто хочется окунуться в сам процесс создания, а не думать постоянно что и где оптимизировать, чтобы работало быстро и толково. Поэтому в последнее время посетила меня мысль-вирус обратится за помощью к Unity3d. Я вижу только плюсы:
    — над системой работает серьезная команда с капиталом и для них это бизнес, это значит, что этот продукт не заброситься завтра;
    - они решают за меня низкоуровневые (и не только) задачи, отдавая только оптимальный результат и я смогу сосредоточится исключительно на моих задачах;
    - баги/импрувменты/фичи — это не моя забота. Я просто говорю на форуме, чтобы я хотел видеть или что не работает и ребята будут это делать, а если не хватает какой нибудь фичи, я могу поставить плагин, который будет решать данную задачу;
    - это мощный движок с мощным редактором. Да что там движок, это целая фабрика;
    - система за меня решает мультиплатформенные задачи — я могу экспортировать игру под Win/Lin/Mac/Android/iOS/Flash и другие платформы;
    - изучив двиг единожды я могу делать на нем любые игры — 2D/3D/single player/multi player и благодаря системности это будет сделать намного проще чем писать самому;

    Что для этого нужно:
    - изучить C# (другие языки для меня не вариант);
    - обучится работать с Unity3d;
    - заплатить за Unity3d;

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

  • Dmitriy

    Насчет Unity3d — возможно. Но я вернусь к той теме с которой начал.
    У меня сейчас движок использующий растровый рендер (copyPixels) как основной + в принципе поддерживает Genome2D переключением 1-й переменной при инициализации. Хотя работу с Genome еще нужно протестить, но не в том суть.
    В двиге есть класс графического объекта AActor который расширяет flash.display.Shape.
    Работа с ним аналогична работе с DisplayObject. Большая часть свойств проверяется и учитывается во время рендера. В том числе x,y,rotation и т.д. И поскольку он наследует один из стандартных объектов Флэша — то я могу передать его в body.graphic и знать что Nape повернет его как нужно и будет это быстрее чем двигать самому.
    Конечно, решение о рендере и т.п. принимается в другом месте.

  • Dmitriy

    А насчет Unity… я почему-то не задумывался об 3D. А о разработке 2D игр в нем слышал что не удобно.
    Жал если забросите флеш. Хороший блог, долго читал. :) С другой стороны тогда будут хорошие статьи по Unity. :)

  • VirtualMaestro

    Я тоже не думал о 3d :) Разработка в 2d осуществляется платными плагинами сторонних разработчиков. Также ведущий разраб сказал, что они решают вопросы удобного 2d девелопинга.
    Флеш, конечно, не бросаю и блог тоже, просто появилась такая идея и она мне кажется хорошей.
    Однозначно, надо сделать хороший обзор Unity. Я, например, не знаю есть ли там хорошая 2d физика. Не просто библиотека определения столкновений, а аналог нейпа.
    Эх, если бы для флеша была хорошая среда разработки игр (с физической основой), я бы даже не думал об этом.

  • Dmitriy

    А что понимается под средой разрабоки игр? Некий визуальный редактор?
    А примеры хороших 2д сред можно посмотреть?

  • VirtualMaestro

    Я специально взял такой термин, потому как я не имею ввиду графический движок или физический или даже игровой и даже не визуальный редактор.
    Это все-равно что современные IDE. Мы не говорим о подсветке кода, о возможности рефакторинга, интеллектуального поиска ошибок, о компиляторе, дебагере, профайлере и т.д. Мы говорим — Среда разработки. Это комплекс для создания, если хотите фабрика, а не один станок.
    Тоже и с играми.
    Я реально знаю только одну среду — это Unity3d.
    У меня есть списки кучи разных движков, конструкторов игр — но это все либо просто движок, либо что то не серьезное.
    Сходу несколько движков-конструкторов:
    GameMaker
    Stencyl
    Construct 2