А почему не преимущество? Да, в таком стандарте не очень комфортно писать. Но 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.
1.) Using your own implementation without vertex buffer output
So first up the easiest way to do font handling is by just providing a nk_user_font struct which only requires the height in pixel of the used
font and a callback to calculate the width of a string. This way of handling
fonts is best fitted for using the normal draw shape command API where you
do all the text drawing yourself and the library does not require any kind
of deeper knowledge about which font handling mechanism you use.
IMPORTANT: the nk_user_font pointer provided to nuklear has to persist
over the complete life time! I know this sucks but it is currently the only
way to switch between fonts.
2.) Using your own implementation with vertex buffer output
While the first approach works fine if you don't want to use the optional
vertex buffer output it is not enough if you do. To get font handling working
for these cases you have to provide two additional parameters inside the nk_user_font. First a texture atlas handle used to draw text as subimages
of a bigger font atlas texture and a callback to query a character's glyph
information (offset, size, ...). So it is still possible to provide your own
font and use the vertex buffer output.
NK_INCLUDE_DRAW_TEXT_CUSTOM_FUNCTION
Ну рисовалку картинок оно точно на драйвер перекладывает. Разве со шрифтами не так же? По-моему, это уже есть в Nuklear. GDI+ явно не использует стандартную рисовалку шрифтов от Nuklear.
NK_INCLUDE_UNICODE_SUPPORT
Не подскажете, почему не UTF8?
А Nuklear что, уже не существующая библиотека? ;-)
IUP когда-то пробовал. Претендует на полность — много компонентов, свойств, конфигураций. И жирный исполняемый файл на выходе, несколько мегабайт. С тем же успехом можно wxWidgets взять, только писать код будет приятнее.
libui значительно лучше, даже называют похудевшим wxWidgets. Только libui написана на С++, а не на Си. Так что как минимум несколько сотен килобайт прибавит. А то и больше, всё-таки компоненов там значительно больше, чем в Nuklear. Но за ссылку спасибо, как-нибудь помучаю эту библиотеку.
Добавил читалку 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 от того же микрочипа?
Тогда всё отлично, спасибо! Прошу прощения, изначально не правильно понял смысл. Жду эти изменения в master'e Nuklear
Nuklear.h, 1156:
NK_INCLUDE_DRAW_TEXT_CUSTOM_FUNCTION
Ну рисовалку картинок оно точно на драйвер перекладывает. Разве со шрифтами не так же? По-моему, это уже есть в Nuklear. GDI+ явно не использует стандартную рисовалку шрифтов от Nuklear.
NK_INCLUDE_UNICODE_SUPPORT
Не подскажете, почему не UTF8?
(написал выше)
А с решением Björn Höhrmann не сравнивали? Его код выглядит гениально коротким и быстрым.
Да сейчас и на сотни гигабайт софт можно найти. Только что в этом хорошего?...
Спасибо за идею, помощь и подсказки. Для примера собрал свою веб-демку Nuklear:
https://dexp.github.io/nuklear-webdemo/
Уже добавлена в публикацию.
А Nuklear что, уже не существующая библиотека? ;-)
IUP когда-то пробовал. Претендует на полность — много компонентов, свойств, конфигураций. И жирный исполняемый файл на выходе, несколько мегабайт. С тем же успехом можно wxWidgets взять, только писать код будет приятнее.
libui значительно лучше, даже называют похудевшим wxWidgets. Только libui написана на С++, а не на Си. Так что как минимум несколько сотен килобайт прибавит. А то и больше, всё-таки компоненов там значительно больше, чем в Nuklear. Но за ссылку спасибо, как-нибудь помучаю эту библиотеку.