Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 21
Плюсанул, конечно, но документация фреймворка (да и статья) плохо структурирована. Из-за этого вряд ли кто-то захочет повторить успех.
Критика принимается.
Никогда не писал туториалы, потому получилось в виде «на что смотрю — то и пою». Документация проектика — вообще больная тема, времени зачастую хватает только дыры латать. Этот пост — более логическое продолжение первого, чтобы была хоть какая логическая завершенность: описание вообще о проекте и небольшой рассказ в стиле «оно еще и работает».
Никогда не писал туториалы, потому получилось в виде «на что смотрю — то и пою». Документация проектика — вообще больная тема, времени зачастую хватает только дыры латать. Этот пост — более логическое продолжение первого, чтобы была хоть какая логическая завершенность: описание вообще о проекте и небольшой рассказ в стиле «оно еще и работает».
Диаграммы? Скрины? Архитектура? Что прошлый пост грешил этим, что этот.
Вместо всего этого текста аля «Файл->Новый проект...» лучше предоставить скрины, на которых отмечено будет, какие шаги делать)
Ну и да, показали бы хоть скрины получившейся игры или демо видео.
Вместо всего этого текста аля «Файл->Новый проект...» лучше предоставить скрины, на которых отмечено будет, какие шаги делать)
Ну и да, показали бы хоть скрины получившейся игры или демо видео.
… а картинки? :(
33 FPS… Рыдаю…
Нет правда обидно, у меня карточка конечно не ахти, GT220, но 2д инвайдерсы… 33 фпс…
Пора делать апгрейд… а то скоро и поиграть то будет невочто…
Нет правда обидно, у меня карточка конечно не ахти, GT220, но 2д инвайдерсы… 33 фпс…
Пора делать апгрейд… а то скоро и поиграть то будет невочто…
Люобознательный читатель посморел бы в настройки проекта и понял бы, что там стоит ограничение в 30fps. Это очень полезная настройка для игровой логики, даже если учитывать, что все завязываем на время между тиками.
В мире существуют два подхода для работы с частотой обновления логики игрового мира и скорости отрисовки кадров, посылаемых с конвеера. Один из них как раз основан на так называемой «жесткой fps». Вот именно его я и использую, так как, с моей точки зрения, в данном проекте это целесообразно.
В мире существуют два подхода для работы с частотой обновления логики игрового мира и скорости отрисовки кадров, посылаемых с конвеера. Один из них как раз основан на так называемой «жесткой fps». Вот именно его я и использую, так как, с моей точки зрения, в данном проекте это целесообразно.
Любознательный читатель не видит прямой связи с ограничением 30 фпс и рабочей частотой 33 фпс. Но так как вы на это указали, любознательный читатель сообщит вам, о том что у вас неверно работает таймер.
Тут все же осмелюсь утверждать, что все относительно. Мне важно знать сколько кадров в секунду отрабатывает логика, а не отрисоовывает видеокарта. Последнее мне куда менее важнее при разработке логики игры. Тут сразу поправлю себя: мы полагаем. что движок написан хорошо и оптимизирован (конечно, в реальности все куда хуже, но сейчас не об этом). По этому нас интересует именно работа той части, которую ми пишем, собственно логику игры.
И я как сторонний наблюдатель, отмечаю, что и кадры и логика работают не на 30 заявленных фпс, а на 33, что указывает, что у вас неверно работает таймер и возвращает наш разговор к моему предыдущему посту =) Только вот число ошибок нарастает. Теперь еще и логика.
Раз уж мы следуем букве, в настройках установленно 30мс на кадр. 1000/30 = 33.33… Почему именно так? Это исторически сложилось, геймдизейнер понимает куда более «30 миллисекунд длится один кадр, заказывай художникам анимацию, опираясь на эту цифру». А потом и я привык. Я еще с самого начала говорил, что идеология всего этого проекта немного не стандартная.
Да я вижу, что нестандартная =)
Хорошо допустим вы используете целочисленный вычисления для расчет фпс.
1000 / 30 = 33
откинем дробную часть и посмотри какова будет погрешность
33*30 = 990
как мы видим 10 миллисекунд (1000-990), что никак не 3 кадра суммарная продолжительность которых составляет 90 миллисекунд.
Итого: 3:0 в мою пользу, у вас неверно работает таймер, из за этого неверно (асинхронно) работает логика, вы не умеет считать…
Хорошо допустим вы используете целочисленный вычисления для расчет фпс.
1000 / 30 = 33
откинем дробную часть и посмотри какова будет погрешность
33*30 = 990
как мы видим 10 миллисекунд (1000-990), что никак не 3 кадра суммарная продолжительность которых составляет 90 миллисекунд.
Итого: 3:0 в мою пользу, у вас неверно работает таймер, из за этого неверно (асинхронно) работает логика, вы не умеет считать…
Возможно вы правы в своей арифметике. Я поступаю проще:
Есть функция, она вызывается вызывается постоянно из движка с дельтой времени.
void game_step(s32 ms)
{
fps_timer += ms;
}
Есть вторая функция, она вызывается калбэком по истечении указанного дизайнером времени (30мс)
void onUpdateObject(u32 layer, s32 iId, BOOL* const oDraw)
{
fps_tick++;
if(fps_timer >= 1000)
{
// вот тут у нас получается ~33fps
fps_tick = fps_timer = 0;
}
}
Есть функция, она вызывается вызывается постоянно из движка с дельтой времени.
void game_step(s32 ms)
{
fps_timer += ms;
}
Есть вторая функция, она вызывается калбэком по истечении указанного дизайнером времени (30мс)
void onUpdateObject(u32 layer, s32 iId, BOOL* const oDraw)
{
fps_tick++;
if(fps_timer >= 1000)
{
// вот тут у нас получается ~33fps
fps_tick = fps_timer = 0;
}
}
Не, мало кода.
Непонятно как исчисляется ваша дельта и откуда она берется.
Предположу, что это время которое было затрачено на выполнение итерации программного цикла.
Вторая фция какая-то обособленная и вообще выглядит так будто висит на отдельном таймере. Тогда непонятно зачем мы считаем fps_timer если гарантированно знаем, что onUpdateObject сработает раз в 30 мс…
вообще fps надо считать както так
#include
…
fps_timer = clock()+1000;
fps = 0;
while(не вышли){
… логика
… рисуем кадр
fps++;
if (fps_timer
Непонятно как исчисляется ваша дельта и откуда она берется.
Предположу, что это время которое было затрачено на выполнение итерации программного цикла.
Вторая фция какая-то обособленная и вообще выглядит так будто висит на отдельном таймере. Тогда непонятно зачем мы считаем fps_timer если гарантированно знаем, что onUpdateObject сработает раз в 30 мс…
вообще fps надо считать както так
#include
…
fps_timer = clock()+1000;
fps = 0;
while(не вышли){
… логика
… рисуем кадр
fps++;
if (fps_timer
ms из функции game_step() вычисляется, измеряя длительность кадра. В этом кадре происходит логика игры и логика движка, тут же вызываются калбеки типа onUpdateObject, все это в одном потоке. Длительность кадра я не могу предсказать, потому я собираю дельты в логике игры, ожидая, пока накопися секунда (>=1000ms). Функция onUpdateObject вызывается перед тем как поместить данные отрисовки в конвеер, потому считается, что новый кадр наступил (пока она не вызывается, рендер рисует буфер последнего кадра, с какой частотой он его рисует мне не очень интересно на этом уровне разработки игры). Поэтому целесообразно посчитать количество вызовов onUpdateObject за секунду, чтобы узнать, нужный мне fps
там немного недопостилось
вообще fps надо считать както так
#include
…
fps_timer = clock()+1000;
fps = 0;
while(не вышли){
… логика
… рисуем кадр
fps++;
if (fps_timer<clock()) {
вывод fps
fps = 0;
fps_timer = clock()+1000;
}
}
В отличии от вашего подхода это удалит одно сложение на кадр в работе вашего движка. Если же вам хочется лимитов привязанных к таймеру то можно както так сделать
#include
…
fps_timer = clock()+1000;
fps = 0;
limit = 1000/30;
limit_timer = clock() + limit;
while(не вышли){
… возможно какието системные действия
if (limit_timer<clock()
… логика
… рисуем кадр
fps++;
limit_timer = clock()+limit;
}
if (fps_timer<clock()) {
вывод fps
fps = 0;
fps_timer = clock()+1000;
}
}
вообще fps надо считать както так
#include
…
fps_timer = clock()+1000;
fps = 0;
while(не вышли){
… логика
… рисуем кадр
fps++;
if (fps_timer<clock()) {
вывод fps
fps = 0;
fps_timer = clock()+1000;
}
}
В отличии от вашего подхода это удалит одно сложение на кадр в работе вашего движка. Если же вам хочется лимитов привязанных к таймеру то можно както так сделать
#include
…
fps_timer = clock()+1000;
fps = 0;
limit = 1000/30;
limit_timer = clock() + limit;
while(не вышли){
… возможно какието системные действия
if (limit_timer<clock()
… логика
… рисуем кадр
fps++;
limit_timer = clock()+limit;
}
if (fps_timer<clock()) {
вывод fps
fps = 0;
fps_timer = clock()+1000;
}
}
как мы видим 10 миллисекунд (1000-990), что никак не 3 кадра суммарная продолжительность которых составляет 90 миллисекунд.
Вы какую-то глупость говорите. Отняли, поделили, где взялся рубль?
Кадр — 30 мс. Значит в секунде 33 кадра (990 мс), а каждую третью секунду ещё влезает 34-й. 100 кадров за 3 секунды. Если поставить. Время на кадр 33.3 секунды, а не 30, то будет 30 fps.
Счёт тут ни при чём. Вы просто изначально отстаивали ошибочный вариант.
Блин, ни одно картинки :(
Ждал видео в конце, после просмотра которого появится стимул осилить весь текст)
Может это хоть чуточку порадует: игра Grandmaster
Кодилось все на Unity3d, но уровни и все, что с ними связано, создавались на me3, описанном выше
Кодилось все на Unity3d, но уровни и все, что с ними связано, создавались на me3, описанном выше
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Создание небольшой игры с помощью tengine