CRUSIS 9000

[runewalsh]

Save/Load v1.0E-A(4, 4) (внимание на характерное расположение мухоморов и мини-карту).
За пятью несчастными мухоморами стоит граф объектов пятнадцати классов... F_F
Постепенно допиливаю остальные. Алсо, потом меню сделаю.

[Brainenjii]

[offtop]это Сырно? ^_^[/offtop]

[runewalsh]

Brainenjii
Yep :3
Подумал было, что у вас есть тег offtop.

Добавлено спустя 3 часа 22 минуты 17 секунд:
С полпинка скомпилировалось под Win64. Debug-версия может быть нестабильной, но это не я, а Newton (честно!)

Добавлено спустя 51 секунду:
Aww. Сообщения склеиваются. ._.

[runewalsh]

ЗАПИЛИЛ СЕРИАЛИЗАЦИЮ СТЕЙТА LUA!!! ^_^
Жмём F2/F3, внимание на test/campfire.sav — в файле, полученном в отладочном режиме, по кускам текста можно понять, что вообще происходит и кто сколько занимает... ~some~ — луашные объекты, <<some>> — нативные.

Фичи (конкретно сериализации скрипта, я только к ней не знал как подступиться, а без lua_upvalueid / lua_upvaluejoin и не подступился бы):

— скриптовые объекты хранятся по значению или по ссылке на выбор (например, короткие строки — по значению, длинные — по ссылке);

— дампы одинаковых Луа-функций, но с разными замыканиями, записываются лишь однажды (я не нашёл штатного средства установить их идентичность);

— окружения модулей задаются не содержимым таблицы, а именем файла. Это допустимо, т. к. в моей архитектуре их семантика не допускает изменения ни извне, ни изнутри, кроме как во время загрузки. И если внешний скрипт был изменён в оффлайне, а какая-нибудь сериализованная функция не додумалась замкнуться на отдельную функцию из него вместо всего окружения, она увидит эти изменения.

Ну а фича нативной сериализации — объект может быть "встроен" в другой объект , а не распределён в куче.

P.S. Сериализаторы:
— нативных объектов: https://sourceforge.net/p/rr-rr/code/39 ... zation.pas
— луашных (блоб с вложенными функциями, т. к. писал в не очень вменяемом состоянии, "зато работает"): https://sourceforge.net/p/rr-rr/code/39 ... .pas#l3067 (tScriptState.Serialize / tScriptState.Deserialize).

[runewalsh]

Запили~л сериализацию вейпоинтов короч. Не обычных, списком точек и рёбер — она-то давно была, а рантаймовых, тех, что получаются склеиванием фрагментов (в свою очередь вейпоинтов, но их уже по-другому и не сохранишь). В том же формате, что и фрагменты, это детище Франкенштейна занимало 150 Кб — может быть, и допустимо, но однозначно не круто.

Идея очевидная: для вейпоинтов, хоть раз приклеивших фрагмент из внешнего файла, вести вместе и сериализовывать вместо них РЕПЛИКУ (пожертвовал точностью мысли ради такого-то красивого слова :3) — действия, которые привели к текущей конфигурации. Получились 11 Кб (>100 фрагментов 12 разновидностей), из которых 10 приходятся на соединительные рёбра — для сравнения, файлы самих фрагментов в сумме дают 60. Такое уже и в сейв положить не зазорно.

[Mirage]

Не понятен ни способ решения проблемы, ни сама проблема в чём состояла, но все равно круто.

[runewalsh]

:D
Значит так.
Примем как данность две вещи:
— в соответствии с традициями рогаликов, уровень генерируется случайно; но из готовых фрагментов;
— для поиска пути фрагмент включает вейпоинты (граф путевых точек).

Приклеивание фрагмента присоединяет его вейпоинты к вейпоинтам всей сцены (добавляя рёбра для стыковки). Таких фрагментов в уровне получается под сотню (с "нормальными", возможно, будет меньше — всё-таки должны брать качеством, но не суть). При сохранении игры сохраняются и сгенерированные вейпоинты, но в "сыром" виде они занимают те не слишком впечатляющие 150 Кб. Остальное я написал.

P.S. Но сами по себе вейпоинты, мягко говоря, неэффективны (в чём можно убедиться по KKK), я ещё подумаю, что с ними сделать.
P.P.S. Придумал. Вейпоинты, занимающие целый объём (в моём случае AABB), можно убрать почти все, оставив крайние для связи с другими точками или такими же объёмами. Пока не буду этим заниматься. Может, осенью... :P

[runewalsh]

Переделал "действия" узлов сцены на сплайны, многомерные, сферические и в вакууме — т. е. в принципе для чего угодно, от координат-поворотов-etc. до параметров шейдеров (но к последним позже прикручу).

Добавлено спустя 3 часа 41 минуту 37 секунд:
Жарища. Я не могу кодить в такой жаре. Вы же программисты, сделайте дождик.

Добавлено спустя 1 час 24 минуты 25 секунд:
И сразу сериализация действий (с поддержкой скриптовых колбэков, естественно — у меня на них вся логика основана). Save/Load никогда не был столь близок...

[Сквозняк]

Save/Load никогда не был столь близок...

До сих пор ещё нет? В процедурщине это то с чего надо начинать раскрутку прототипа.

[runewalsh]

До сих пор ещё нет?

Ну да, я медленный ._.
+ параллельно переделываю вещи, которые без сериализации работают, но с ней могут возникнуть проблемы или просто архитектурный нонсенс. Пример. Из объектов остались (вроде как) только персонажи со скелетами (т. е. 3 класса из ~60), но я слишком поздно заметил, что засунул переходы между анимациями в класс персонажа вместо скелета. Ну да, работает. Но так же не круто. И если данные скелета изменятся в оффлайне, то всё рухнет, т. к. не всё его состояние хранится в нём самом. Ну и т. п. Новые-то я сразу буду писать с оглядкой. ._.

P.S. Догадываюсь, что такое "раскрутка прототипа", но почему именно процедурщина?

[Сквозняк]

А нельзя было сделать объекты которые хранят свои данные в массивах глобальных переменных?

P.S. Догадываюсь, что такое "раскрутка прототипа", но почему именно процедурщина?

Потому что позволяет делать почти всё и если например код вынести в другую процедуру то стек не поломается. Для проектов имеющих сложную логику процедуры практичнее. Классы хороши для копипасты кода но если копировать нечего то и польза от них неочевидна.

[runewalsh]

хранят свои данные в массивах глобальных переменных

↓↓↓

А если серьёзно, то:
— Лучшая форма для данных в памяти — та, с которой удобно работать, а не только сериализовывать. (К.О.)
— Когда искал идеи, видел на гд.ру эту среди прочих. Вроде такой: настроить аллокатор объектов игровой логики на фиксированный адрес в памяти и сбрасывать в сейв дамп этой области (возможно, пожатый). Это всё даже интересно, но блин, смахивает на сиюминутные решения. И я бы даже не сказал, что сильно проще той очевидной и универсальной идеи, которую я выбрал по образцу .NET/Java (и этого вашего Che.Persy тоже) — пройтись по объектам, сопоставляя им уникальные ID. [spoiler]Я же медленный не потому, что сложно, а потому, что лентяй.[/spoiler] С кострами вот работает, а в них все основные грабли задействованы.

код вынести в другую процедуру то стек не поломается

С Луа я бы ещё понял, там легко ошибиться с балансировкой стека, а здесь эммм... ладно, проехали.

[Сквозняк]

— Лучшая форма для данных в памяти — та, с которой удобно работать, а не только сериализовывать. (К.О.)

Не иметь доступа к любым данным в любой момент, не мочь понять в сохранке хоть что-то в текстовом редакторе. Для графики сойдёт.

и сбрасывать в сейв дамп этой области (возможно, пожатый).

Сохранять кусок памяти некроссплатформенно и ненадёжно. Добавишь какую-то переменную которую и сохранять то не нужно или поменяешь их местами и получи несовместимость сохранок. Нет, нужно сохранять каждый массив поштучно а перед загрузкой данные сбрасывать в умолчание тогда сохранки можно смешивать. Хотя тоже можно делать и с классами если они не воспротивятся.

[Mirage]

Когда искал идеи, видел на гд.ру эту среди прочих. Вроде такой: настроить аллокатор объектов игровой логики на фиксированный адрес в памяти и сбрасывать в сейв дамп этой области (возможно, пожатый). Это всё даже интересно, но блин, смахивает на сиюминутные решения. И я бы даже не сказал, что сильно проще той очевидной и универсальной идеи, которую я выбрал по образцу .NET/Java (и этого вашего Che.Persy тоже) — пройтись по объектам, сопоставляя им уникальные ID.

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

[runewalsh]

Сохранение/загрузка как-в-.NET очень бажно, но работают. Всё равно без меню с оригинальным артом в релиз не выложу. >:3

Неверующие — можете пожмякать F5/F6 в версии с SVN, но докладывать о багах не нужно, по крайней мере пока они и так видны невооружённым взглядом: вам сильно повезёт, если на выходе или после нескольких итераций сохранения/загрузки не словите AV, удвоение (но не более и обычной утечки нет; по-видимому, утечка в терминах управляемых языков) памяти, занятой Lua — и вовсе норма, я пожадничал с 3 байтами на кватернион, ну и так далее.

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

Внезапно, ты прав. Я думал, обход будет сравним по скорости со сбросом дампа, и с сохранением так и есть, но загрузка почему-то занимает аж секунду (при том, что в мире-то ничего и нет толком). Хотя причина может быть банально в увеличении размера массива на единичку вместо x2 или списка (сохранение список и юзает — не знаю, зачем здесь понадобился массив... эххххх, позже перепишу).

Короче, долавливаю баги @ оптимизирую загрузку @ пилю меню.