1) Примеры очень нужны. И желательно в самой статье. Не обязательно их подробно расписывать. Можно просто спрятать исходник под спойлер — кому нужно, тот почитает.
2) Также хотелось бы пример с доступом к элементам вектора как к элементам обычного массива. Т.е. могу просто сделать family[i].Name = "Batman"?
Эм. Чтобы встроить библиотеку в свой код вам нужно использовать функции. Они где-то описаны. Да, иногда есть документация. Но многое приходится читать прямо в комментариях прямо в коде…
И я не призываю вас изучать полностью исходники Nuklear. От этого действительно можно свихнуться. Но вот демки скорее всего обойти не получится. А вот они вовсе не так страшны, как вы их рисуете ;-)
Но это естественно не отдельное решение и добавить в свой движок вы его не сможете.
Вот-вот. Лучшего встраиваемого, чем Nuklear, я так и не нашёл...
1) Помните, что это OpenSource. Вы получаете решение абсолютно бесплатно, можете использовать его как хотите. Но при этом вам никто ничего не должен.
2) Предложите лучшие альтернативы. С удовольствием использую в своей игре что-нибудь другое, если оно будет лучше.
3) По моему опыту, с документацией обычно всё ещё хуже :-( Здесь есть хоть какая-то. И относительно много простых примеров, на многие случаи жизни.
4) Если нашли какой-то фатальный баг, то есть много путей решения: а) пофиксить самому; б) заплатить кому-нибудь, чтоб исправил его; в) сидеть и ждать, пока кто-нибудь возможно захочет исправить ваш баг бесплатно.
5) Не следует ожидать от микро-библиотеки супер-функционала и его мега-стабильности. Те же ноды — скорее пример, ЧТО можно закодить на этой мелочи. Собирать на этой библиотеке аналог Matlab вам никто не предлагает. Судя по скринам в документации библиотека делалась, чтоб на ней можно было быстро создать главное меню, настройки, и сфокусироваться на написании игры, а не интерфейса.
6) Что вы подразумеваете под словами "полотно мутного текста"? Простая формочка из публикации занимает 20 строк кода, работает одинаково и стабильно. Если вы встраиваете GUI в свою игру, то остальные строки (создание окна, инициализация OpenGL и пр.) у вас уже есть.
7) Если делаете с нуля — то просто берёте demo с удобной технологией и работаете с ней.
От себя добавлю, что сейчас делаю коммерческую игру на чистом Nuklear: Wordlase. Да, есть далеко не всё. Не всё так красиво, как могло быть. Да, есть некоторое количество багов. Но всё преодолимо. Получить на этой библиотеке игру — реально.
Исполняемые файлы и под Linux и под Windows у меня меньше 300кб, хотя содержат в себе декодеры PNG, TTF, OGG, JSON, TAR, GUI.
Есть. Но какова вероятность, что компилятор для микроволновки будет поддерживать свежие стандарты? Или какие-нибудь KolibriOS/MenuetOS? В которых основным компилятором TCC, да ещё и лохматых годов выпуска, да ещё и сурово допиленный напильником. А С89 будет работать везде. Потому, что стандарт относительно простой, и при создании компиляторов Си в первую очередь стремятся к нему.
А почему не преимущество? Да, в таком стандарте не очень комфортно писать. Но C89 почти гарантирует, что проект успешно скомпилируется в любом современном компиляторе, начиная от Clang и заканчивая восьмибитными микроконтроллерами. Писать свой проект можно на чём угодно, хоть на "Super-mega-boosted-python-java#". Но если есть желание использовать чужую библиотеку, и при этом она написана на C89, то есть приличная вероятность, что она без проблем подключится.
Кроме того, Си есть Си. Т.е. отличная производительность за счёт низкоуровневости языка.
Чтобы избежать хэшей и редактировать эти ресурсы напрямую? В JSON у меня ссылки вида "effects/snow.png", "sprites/girl.png". Загрузчик смотрит файлы в открытом виде, если нет, то пытается грузить из архива. В котором лежат по этому же пути.
Ниже отписали, что отображение в память будет проблемно использовать с компрессором. Мне же нужно сначала распаковать gzip, а потом уже из результата читать tar.
Да, здесь согласен. Получается, что у меня в оперативке хранятся лишние картинки в виде сырых данных. Так получилось, что JSON-строки сразу конвертирую в дерево объектов, а память после tar и gzip освобождаю. Но это только из-за того, что JSON нужен весь и сразу. Попробую в своём проекте переделать логику менеджера спрайтов, чтобы сразу при инициализации грузил все картинки в формат текстуры, тогда tar-архив можно будет сразу освободить.
По стандарту GNU tar — 512 байт ровно. Очень длинный путь внутри tar не учитывается. Точнее, если будет больше 100 символов — то всё сломается. Если где-то такой вариант и учли в реализации, я об этом не в курсе.
Именно! Это и пытался описать. Лично меня когда-то очень удивило, что архив — это не обязательно сжатие. Попытаюсь как-нибудь перефразировать, спасибо за замечание.
Я один раз читаю cжатый файл. Затем распаковываю архив. Это и есть пик, когда загружены и архив и его распакованная версия. Далее сжатый файл удаляется из памяти, во время работы приложения занято памяти ровно на распакованные tar-данные. Пример: data.tar 1000kb, data.tar.gz 250kb. Итого на диске хранится 250kb, пиковое потребление памяти 1250kb, потребление памяти в рабочем режиме — 1000kb. Другое дело, что если tar-файл будет большим, то грузить его весь в оперативку не рационально. Для таких случаев лучше присмотреть другое решение, а не dxTarRead.
Спасибо. С беспарольным доступом раньше было лень разбираться для домашних машинок (тех же виртуалок). Теперь вижу, что всё очень не сложно.
Да? Ну буду рад увидеть на Хабре туториалы с картинками как в Lazarus сделать:
Хех. А я уж по названию подумал, что Delphi ожил :-)
1) Примеры очень нужны. И желательно в самой статье. Не обязательно их подробно расписывать. Можно просто спрятать исходник под спойлер — кому нужно, тот почитает.
2) Также хотелось бы пример с доступом к элементам вектора как к элементам обычного массива. Т.е. могу просто сделать
family[i].Name = "Batman"?Эм. Чтобы встроить библиотеку в свой код вам нужно использовать функции. Они где-то описаны. Да, иногда есть документация. Но многое приходится читать прямо в комментариях прямо в коде…
И я не призываю вас изучать полностью исходники Nuklear. От этого действительно можно свихнуться. Но вот демки скорее всего обойти не получится. А вот они вовсе не так страшны, как вы их рисуете ;-)
1) Помните, что это OpenSource. Вы получаете решение абсолютно бесплатно, можете использовать его как хотите. Но при этом вам никто ничего не должен.
2) Предложите лучшие альтернативы. С удовольствием использую в своей игре что-нибудь другое, если оно будет лучше.
3) По моему опыту, с документацией обычно всё ещё хуже :-( Здесь есть хоть какая-то. И относительно много простых примеров, на многие случаи жизни.
4) Если нашли какой-то фатальный баг, то есть много путей решения: а) пофиксить самому; б) заплатить кому-нибудь, чтоб исправил его; в) сидеть и ждать, пока кто-нибудь возможно захочет исправить ваш баг бесплатно.
5) Не следует ожидать от микро-библиотеки супер-функционала и его мега-стабильности. Те же ноды — скорее пример, ЧТО можно закодить на этой мелочи. Собирать на этой библиотеке аналог Matlab вам никто не предлагает. Судя по скринам в документации библиотека делалась, чтоб на ней можно было быстро создать главное меню, настройки, и сфокусироваться на написании игры, а не интерфейса.
6) Что вы подразумеваете под словами "полотно мутного текста"? Простая формочка из публикации занимает 20 строк кода, работает одинаково и стабильно. Если вы встраиваете GUI в свою игру, то остальные строки (создание окна, инициализация OpenGL и пр.) у вас уже есть.
7) Если делаете с нуля — то просто берёте demo с удобной технологией и работаете с ней.
От себя добавлю, что сейчас делаю коммерческую игру на чистом Nuklear: Wordlase. Да, есть далеко не всё. Не всё так красиво, как могло быть. Да, есть некоторое количество багов. Но всё преодолимо. Получить на этой библиотеке игру — реально.
Исполняемые файлы и под Linux и под Windows у меня меньше 300кб, хотя содержат в себе декодеры PNG, TTF, OGG, JSON, TAR, GUI.
И мне больше понравился формат Cpio. В бинарной версии формата заголовок всего 26 байт + название файла. Реализация также на GitHub.
Есть. Но какова вероятность, что компилятор для микроволновки будет поддерживать свежие стандарты? Или какие-нибудь KolibriOS/MenuetOS? В которых основным компилятором TCC, да ещё и лохматых годов выпуска, да ещё и сурово допиленный напильником. А С89 будет работать везде. Потому, что стандарт относительно простой, и при создании компиляторов Си в первую очередь стремятся к нему.
Добавил читалку Ar на GitHub
А почему не преимущество? Да, в таком стандарте не очень комфортно писать. Но C89 почти гарантирует, что проект успешно скомпилируется в любом современном компиляторе, начиная от Clang и заканчивая восьмибитными микроконтроллерами. Писать свой проект можно на чём угодно, хоть на "Super-mega-boosted-python-java#". Но если есть желание использовать чужую библиотеку, и при этом она написана на C89, то есть приличная вероятность, что она без проблем подключится.
Кроме того, Си есть Си. Т.е. отличная производительность за счёт низкоуровневости языка.
Если честно, не особо. Tar мне был просто интересен для исследования. А готовое решение надеялся что в комментах на хабре подскажут толковое.
Чтобы избежать хэшей и редактировать эти ресурсы напрямую? В JSON у меня ссылки вида "effects/snow.png", "sprites/girl.png". Загрузчик смотрит файлы в открытом виде, если нет, то пытается грузить из архива. В котором лежат по этому же пути.
Покрутил немножко. Я не вижу поддержки директорий, а без них совсем грустно.
И длина имени файла всего 16 символов.
Ниже отписали, что отображение в память будет проблемно использовать с компрессором. Мне же нужно сначала распаковать gzip, а потом уже из результата читать tar.
Спасибо! Вроде бы формат не сильно отличается от tar. Позже попробую добавить и этот формат в свой "архиватор" на гитхаб.
Да, здесь согласен. Получается, что у меня в оперативке хранятся лишние картинки в виде сырых данных. Так получилось, что JSON-строки сразу конвертирую в дерево объектов, а память после tar и gzip освобождаю. Но это только из-за того, что JSON нужен весь и сразу. Попробую в своём проекте переделать логику менеджера спрайтов, чтобы сразу при инициализации грузил все картинки в формат текстуры, тогда tar-архив можно будет сразу освободить.
По стандарту GNU tar — 512 байт ровно. Очень длинный путь внутри tar не учитывается. Точнее, если будет больше 100 символов — то всё сломается. Если где-то такой вариант и учли в реализации, я об этом не в курсе.
Именно! Это и пытался описать. Лично меня когда-то очень удивило, что архив — это не обязательно сжатие. Попытаюсь как-нибудь перефразировать, спасибо за замечание.
Я один раз читаю cжатый файл. Затем распаковываю архив. Это и есть пик, когда загружены и архив и его распакованная версия. Далее сжатый файл удаляется из памяти, во время работы приложения занято памяти ровно на распакованные tar-данные. Пример: data.tar 1000kb, data.tar.gz 250kb. Итого на диске хранится 250kb, пиковое потребление памяти 1250kb, потребление памяти в рабочем режиме — 1000kb. Другое дело, что если tar-файл будет большим, то грузить его весь в оперативку не рационально. Для таких случаев лучше присмотреть другое решение, а не dxTarRead.
Кхм. А почему именно Mplab, а не более современная Mplab X от того же микрочипа?