Добрый день форумчане.

Немного представлюсь: меня зовут Станислав и я программист. Программированием я занимаюсь, не только на профессиональном уровне, но так же это является моим хобби. Именно поэтому я почти не отдыхаю... На данный момент в моей личной жизни нет постоянной работы, поэтому у меня есть денежные проблемы. А так же, все силы уходят на проект, при котором "постоянное место работы" должно появится, как только этот проект начнет приносить доход. Тем не менее, примерно один раз в 1-3 недели я уделяю программированию на PSP.

Помимо основных примеров, которые имеются в PSPSDK мною написано куча других примеров. В первую очередь это связано с более полным пониманием всех аппаратных возможностей PSP. Например: последний пример, который я начала прорабатывать, но не доделал до конца - это "Скелетная анимация", которая должна сильно уменьшить выделяемый объем под одну 3D модель, и которую PSP поддерживает на аппаратном уровне.

Но я осознал, что время разработки без хорошего отладчика под PSP увеличивается. Именно поэтому я отложил в сторону все, что нарабатывается под будущий движок, и начал работать над расширением "PSP отладчика" под Visual Studio Code.

Т.к. на форуме до сих пор находятся люди, которым интересна тема с "PSP", поэтому все выше мною расписанное связано лишь с одним вопросом: где лучше мне вести, хоть и редкую, но все же новостную ленту о этапах разработки?

Например прямо здесь.

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

Совершенно недавно был заложен "первый камень" в будущий движок оптимизированный спец. под PSP платформу под названием Light-Source. Пока делаются только предварительные наброски, чтобы выделить основную структуру.

Планируется:
- выделение памяти по МАХ. в момент инициализации движка, а в дальнейшем распределение необходимой памяти по компонентам движка (сложно реализуемое)
- добавление скриптового языка под "игровые сценарии" вроде Lua или Pawn
- использование intraFont
- профилирование, чтобы отслеживать равномерную нагрузку между всеми аппаратными частями PSP
- выделение собственных 3D и промежуточных форматов, чтобы МАХ. не вычислять промежуточные значения матричных координат в пространстве и предельного использования VFPU
- дополнительный инструментарий World Editor, чтобы можно было импортировать всевозможные форматы 3D моделей и редактировать "игровой мир на лету"
- поддержка формата .collada, т.к. это открытый XML стандарт и используется практически всеми программами по 3D моделированию

Одновременно вместе с движком будет писаться демо версия игры, которая будет основана на Half-Life.

На момент написания этого сообщения (23.08.2019) на github был выложен первый тестовый шаблон будущего движка. Далее будет придумываться новая система сущностей и в связи с этим полностью изменяться структура взаимодействия, как между компонентами ядра, так и между "игрой" и ядром. Планируется максимально оградить код игры, чтобы разработчикам игр не приходилось "изобретать велосипед", но при этом не отделить функционалом.

Были продуктивные выходные.

Написал 4 тестовых примера:
- проверка template компилятора
- проверка Variadic templates компилятора
- выделение памяти с psp
- Allocator под Entity Component System

(изображение результата выделения памяти из "Линейного Allocator'а")

Написано малая часть Entity Component System и тестовый пример по распределению памяти по компонентам системы из заранее выделенного общего блока.

Был проведен первый стресс тест. Как оказалось, чтобы выдавать 25-28 FPS количество отображаемых объектов в текущий момент должно быть в пределах 100. При 150 объектах FPS падает до 17.

Добрый день pspinfo. Сделал еще несколько тестов. Видимо все не так "радужно", как хотелось бы...

Из-за того, что это "воссозданный" SDK, а не нормальные "инструменты разработчика", то похоже в самом SDK заложена эта проблема...

Поэтому, чтобы получить приемлемые 27 FPS необходимо уложится в 100 вызовов отрисовки примитивов (sceGumDrawArray).



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



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

Внимание: ложная тревога!

Причиной такого быстрого падения FPS при таком маленьком количестве объектов на рендер была потому, что перед этим у меня в тестовом варианте стоял расчет вращения объекта и назначение матрице модели этого самого вращения, через sceGumRotateXYZ(&rot).

Перепроверил без "искусственного вращения" и получил след. результаты:

- 60 FPS при 250 объектах
- 30 FPS при 1200 объектах

Были добавлены *.obj и .*png загрузчики.



PS: модель взята из GTA San Andreas

Наконец-то дописан первый пример скелетной анимации.

Ссылка на патреон.

Добавлено спустя 3 часа 38 минут 9 секунд:

Написан wireframe пример, который даст возможность визуально отлаживать проблемы с моделью и коллизией.

Соскучились по мне?

Работа не оставляет мне свободного времени, поэтому прогресс над light-source заметно притормозил.

Планируются следующие этапы разработки:

1. изменяю структуру light-source под кроссплатформенность (текущий этап разработки)
2. буду создавать простенький (стартовый) UI под World Editor, который и будет изменять\компоновать основные форматы, которыми и будет управлять ядро light-source
3. далее будет писаться парсинг с .collada формата именно в World Editor'e. Туда же перенесется чтение .obj и .png формата, т.к. скорее всего большая часть форматов будет изменятся под особый. Это нужно в первую очередь для того, чтобы обеспечить большую производительность. Например: будут промежуточные форматы, которые будут хранить скажем заранее рассчитанные смещения до необходимой структуры данных, чтобы не читать весь файл полностью
4. будет наконец-то определена структура моделей и возможность манипуляции данных через World Editor. Например: у конкретной модели "ученый" добавить к голове коллизию для определения взаимодействия, скажем выстрел в голову

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

World Editor: alpha build ver. 000001

Очень много времени ушло на то, чтобы выбрать GUI библиотеки для создания полноценного, простого графического интерфейса под light-source.

Qt показался слишком громоздким и имел ошибки при попытке использовать FileDialog на Windows 10. Но до этого нужно было его скачать, установить, собрать библиотеки и немного попользоваться, а это время...

wxWidgets - другой популярный кроссплатформенный GUI. С ним так же пришлось помучаться, но пока серьезных недостатков в нем я не вижу. Он довольно простой и весит не так много. Поэтому сейчас World Editor будет собираться именно на нем.

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

Написан один из важных примеров поддержки DXT1 сжатия текстур на уровне железа. Как оказалось PSP имеет эту поддержку, правда специфическую из-за чего нужно будет переводить ассеты текстур в бинарные файлы при создании "игры" через World Editor.

Ссылка на новость.

Добавлено спустя 4 часа 41 минуту 13 секунд:

Mipmap test

После создания примера поддержки DXT1 сжатия было грех не проверить текстурные уровни в самом *.dds файле.

Специально под свои нужны был обновлен компилятор на PSP у Windows с GCC 4.3.5 до GCC 8.2.0.

https://darksectordds.github.io/html/MinimalistPSPSDK/index.html