Вторая проблема заключалась в неправильном подсчете длительности одного кадра. Когда я переписал часть кода, чтобы решить эту проблему, то оказалось, что я забыл об одной важной детали: движение персонажа и смена кадров анимации зависят непосредственно от фреймрейта. Когда на экране мало различных цветов, то фреймрейт вырастает, а скорость персонажа и анимации увеличивается, и наоборот. По-хорошему, я должен был привязать все изменения в течение кадра к временной дельте, но лень дала о себе знать. В конце концов я просто ограничил фреймрейт 12-ю кадрами в секунду (на деле показатель варьируется от 8 до 10 FPS, но об этом позже), чтобы перепады в скорости передвижения главного героя не так сильно бросались в глаза.
Комментарий недоступен
Это немного другая визуальная новелла=) Но аниме девочек можно добавить и сюда
Комментарий недоступен
Надо было это в экселе написать)
Комментарий недоступен
Рад что вы побороли, даже если от части, просадки отрисовки.
Вспоминая свои самые первые потуги в играх, где на java собирал очень примитивно по старым книгам, там был такой момент отрисовка и хранения предыдущего кадра. Возможно, вы думали о таком, но озвучу.
Есть сетка, массив пикселей, и перед отрисовкой проверять предыдущий кадр с следующим. Помечая в следующем только те пиксели, которые нужно перерисовать. Заполняя массив предыдущего кадра текущим. Чтобы меньше было обращений к таблице в Excel. Такой себе промежуточный рендер пикселей.
Спасибо вдвойне! Потому что я попробовал реализовать эту идею, и производительность выросла неплохо. 12 FPS теперь держит стабильно без просадок=) Но если ограничивать выше, то сильно скачет от 12 до 30, и играть не очень приятно становится.