оооо, как я Вас понимаю!
самым моим долгоиграющим, но, к сожалению нынче умершим хобби-проектом был именно проект, вдохновение которого черпалось именно с Метроида.
Кстати, вот такая еще инфа, у nintendo ds в поставке разработчика был middleware прослойка nitro-system над их sdk, основана на оригинальном движке именно метроида. Было прикольно спортировать свои наработки метроидоподобного проекта на метроидовский движок
Привет. я вот какраз сделал функционал, который потенциально облегчит проблему интеграции нуклеар в некий движок, но он еще ревьювится, как я понимаю, результат будет не скоро. Идея такая: колбеком высыпаются полигоны, а ты уже делай с ними что хочешь и добавляешь в свой opengl/directx ренделист.
Изучать nuklear.h нужно, как для меня, там все интуитивно понятно. Есть примеры, с них можно начать. То, что код получается «мутным» — это идейная часть нуклеара, все строится динамически. Может когда-то кто-то напишет редактор для нуклеара, который генерит с-код, но пока только так, вручную.
А всякие недочеты можно чинить самому и реквестить автору. Базовый функционал, который обычно используется в играх (ползунки, кнопки, окна, меняющие размер, привязка контролов к окну и тд) работает, имхо, отлично.
ps я уже выкладывал пример, как можно подружить игровой движок и нуклеар, повторюсь: http://casualgum.com/public/nuklear_gui.html
есть пока противная бага с тачскрином, nuklear почему-то адаптирован только под «непрерывный инпут», а также где-то я напартачил с редактированием текстовых полей. работаемс, в общем, пока
Так точно, я читал это. Но что, если нужно использовать vertex buffer, но абсолютно нет нужны инициализировать и загружать шрифт? Он уже загружен средствами другой подсистемы, и все, что нужно знать nuklear — это id шрифта, размер шрифта и имплементация функции float your_text_width_calculation(nk_handle handle, float height, const nk_tchar *text, int len)
Все остальное, такое как texture atlas, query callback и тд, не нужно.
Тем не менее, NK_INCLUDE_DRAW_TEXT_CUSTOM_FUNCTION требует от пользователя заполнить структуру nk_user_font:
font->userdata.id = font id стороннего шрифта
font->height = размер стороннего шрифта
/* имплементация your_text_width_calculation */
font->width = nk_custom_font_get_text_width;
/* инитиализация nuklear с nk_user_font */
nk_init_default(инстанс_nuklear.ctx, font);
/* функция рисования текста в vertex buffer стороннего движка */
инстанс_nuklear.ctx.draw_list.draw_text = nk_custom_draw_list_add_text;
Другими словами, новый ключ NK_INCLUDE_DRAW_TEXT_CUSTOM_FUNCTION расширяет возможности nuklear, без избыточности, более того, при этом ключе удаляется весь «ненужный» код работы с шрифтами в nuklear. Правда, использование этого ключа максимально эффективно в работе с ключом NK_INCLUDE_DRAW_VERTEX_CUSTOM_FUNCTION, так как в такой завязке мы получаем доступ к вертексам извне
NK_INCLUDE_DRAW_TEXT_CUSTOM_FUNCTION
в GDI+ переделан полностью весь механизм работы с NK_COMMAND*
а при этом ключе просто выключается все, что связанное с текстами при стандартной работе с nk_convert()
нужно только определить функцию для рендера текста:
typedef void(*nk_query_font_glyph_f)(nk_handle handle, float font_height,
struct nk_user_font_glyph *glyph,
nk_rune codepoint, nk_rune next_codepoint)
и функцию определения ширины для логики лайоута
typedef float(*nk_text_width_f)(nk_handle, float h, const nk_tchar*, int len);
NK_INCLUDE_UNICODE_SUPPORT
ибо не utf единым, юникод является типом текстовых данных по умолчанию для многих библиотек, тем более тип wchar_t и работа с ним — нативная часть c/c++, а utf — это все-таки чужеродное, хоть и удобное
Библиотека очень хорошо подходит под геймдев, потому, как и обещал, забрал библиотечку к себе.
Сделал модификации, подключаемые ключами:
NK_INCLUDE_DRAW_VERTEX_CUSTOM_FUNCTION
не использовать штатный механизм буферизации данных меша
в этом режиме, каждый раз, когда вычисляется данные по вершине полигона, вызывается функция
typedef void*(*nk_draw_vertex_f)(void *dst, const struct nk_convert_config *config, struct nk_vec2 pos, struct nk_vec2 uv, struct nk_colorf color);
что делать с этими данными уже решает пользователь
(режим более заточен для отрисовки меша функцией glDrawArrays(GL_TRIANGLES))
NK_INCLUDE_DRAW_TEXT_CUSTOM_FUNCTION
не использовать штатный механизм отрисовки текста и генерации фонта.
режим сделан для движков, у которых есть собственный механизм отрисовки текстов
NK_INCLUDE_UNICODE_SUPPORT
поддержка юникода вместо utf8
то, чего я вно не хватало библиотеке
NK_INCLUDE_DISABLE_KEYBOARD_EDIT
отключает клавиатурный ввод и отображение курсора/селекшина
также были добавлены мелкие полезные мелочи
Это все уже работает, вот пример интеграции библиотеки в мой игровой движочек: http://casualgum.com/public/nuklear_gui.html
Сейчас занимаюсь исправлением багов и стабилизацией для пулл реквеста.
Изменений очень много, могут и не канонизировать, так что, кому интересно, пока все наработки тут: https://bitbucket.org/pascualle/nuklear
Проекты разные и требования разные. А также сюда можно добавить бюджет и время. Кому-то 2Гб не проблема в браузере грузить а кому и 640кб хватит на все задачи. Но все замечу, что тема топика «идеальный GUI для микро-проектов», что какбэ должно намекать…
насчет sdl не знаю для меня он слишком громоздкий в разрезе emscripten. А вот пример работы с glfw3, все там отлично рабоатет, как пример моя демка http://casualgum.com/test/mun.html
зачем это? ну все та же мутиплатформенность, например ты сделал тулзовину или приложение, а в веб версии ее демо-версия… навскид идейка
так точно. Nuklear поддерживает glfw и sdl, а это означает, что с emscripten проблем не будет. я сам увлекаюсь этой технологией, прям магия с --> llvm --> js
ну… судя по коду все можно сериализировать, под капотом все пушается в буфер и рисуется. так что потенциально читать лайоут с какого-то редактора сделать не сложно. был бы редактор, кстати, можно попробовать использовать .dfm файлы Borland ide как вариант, редактор там норм
мне проект понравился, думаю может утащу к себе, я какраз люблю когда никаких зависимостей
код смотрел, вижу что редактора нет, но может где-то существует и редактор под все это?
Ого! Вот это зачет!
Помню, сколько я часов провел на форумах, применяя всякие уловки против мерцания… Честно признаюсь, я в то время так и не нашел годного решения. Потому данная статья вызвала лично мне приятную ностальгию, а автору — реальное уважение.
Я когда-то около трех лет работал с VCL, правда на CBuilder. Задачей было организовать автоматизацию с красивым интерфейсом быстрыми темпами в одном банке. На то время лучшего решения чем Delphi5/CBuilder5 (кому что нравилось) попросту не было. Вот, столько лет прошло, а наши программы до сих пор нормально и успешно там работают без всякого саппорта.
Теперь же, работая чуть в другой сфере, отойдя от оконных приложений, мне лично, особенно когда надо «нафигачить что-то под винду с окнами побырику» кроме RADStudio я ничего не хочу знать, он меня устраивает всем. На CBuilder, к примеру, я пишу редактор уровней для своего движочка. Правда, чтобы избавиться от мерцания основного поля, я полностью отказался от TCanvas в его классическом применении, рендерю в него прямо OpenGL контекст.
я думаю авторы колибри ОС конкурс устроили не для соревнований игроделов...
Как ниже написал yogev_ezra, конкурс был организован ради пиара ОС. Но я бы не согласился с вашими утверждениями, в первую очередь это конкурс, для участия в конкурсе нужно было написать что угодно, хоть «угадай число», главное, чтобы приложение соответствовало правилам (http://habrahabr.ru/company/kolibrios/blog/243081).
Мне кажется, если авторам ОС охото видеть игры на своей системе, нужно открыть проект 3D/2D движка для создания игр
Вы не поверите, это направление тоже развивается. На мой взгляд, преобладание «логических миниигрушек» в ОС — это результат того, что сейчас сообщество, развивающее ОС, состоит более из core-программистов, чем из прикладных программистов. Всему свое время, как говорится, спрос порождает предложение.
самым моим долгоиграющим, но, к сожалению нынче умершим хобби-проектом был именно проект, вдохновение которого черпалось именно с Метроида.
Кстати, вот такая еще инфа, у nintendo ds в поставке разработчика был middleware прослойка nitro-system над их sdk, основана на оригинальном движке именно метроида. Было прикольно спортировать свои наработки метроидоподобного проекта на метроидовский движок
Изучать nuklear.h нужно, как для меня, там все интуитивно понятно. Есть примеры, с них можно начать. То, что код получается «мутным» — это идейная часть нуклеара, все строится динамически. Может когда-то кто-то напишет редактор для нуклеара, который генерит с-код, но пока только так, вручную.
А всякие недочеты можно чинить самому и реквестить автору. Базовый функционал, который обычно используется в играх (ползунки, кнопки, окна, меняющие размер, привязка контролов к окну и тд) работает, имхо, отлично.
ps я уже выкладывал пример, как можно подружить игровой движок и нуклеар, повторюсь: http://casualgum.com/public/nuklear_gui.html
Все остальное, такое как texture atlas, query callback и тд, не нужно.
Тем не менее, NK_INCLUDE_DRAW_TEXT_CUSTOM_FUNCTION требует от пользователя заполнить структуру nk_user_font:
font->userdata.id = font id стороннего шрифта
font->height = размер стороннего шрифта
/* имплементация your_text_width_calculation */
font->width = nk_custom_font_get_text_width;
/* инитиализация nuklear с nk_user_font */
nk_init_default(инстанс_nuklear.ctx, font);
/* функция рисования текста в vertex buffer стороннего движка */
инстанс_nuklear.ctx.draw_list.draw_text = nk_custom_draw_list_add_text;
Другими словами, новый ключ NK_INCLUDE_DRAW_TEXT_CUSTOM_FUNCTION расширяет возможности nuklear, без избыточности, более того, при этом ключе удаляется весь «ненужный» код работы с шрифтами в nuklear. Правда, использование этого ключа максимально эффективно в работе с ключом NK_INCLUDE_DRAW_VERTEX_CUSTOM_FUNCTION, так как в такой завязке мы получаем доступ к вертексам извне
в GDI+ переделан полностью весь механизм работы с NK_COMMAND*
а при этом ключе просто выключается все, что связанное с текстами при стандартной работе с nk_convert()
нужно только определить функцию для рендера текста:
typedef void(*nk_query_font_glyph_f)(nk_handle handle, float font_height,
struct nk_user_font_glyph *glyph,
nk_rune codepoint, nk_rune next_codepoint)
и функцию определения ширины для логики лайоута
typedef float(*nk_text_width_f)(nk_handle, float h, const nk_tchar*, int len);
NK_INCLUDE_UNICODE_SUPPORT
ибо не utf единым, юникод является типом текстовых данных по умолчанию для многих библиотек, тем более тип wchar_t и работа с ним — нативная часть c/c++, а utf — это все-таки чужеродное, хоть и удобное
Сделал модификации, подключаемые ключами:
NK_INCLUDE_DRAW_VERTEX_CUSTOM_FUNCTION
не использовать штатный механизм буферизации данных меша
в этом режиме, каждый раз, когда вычисляется данные по вершине полигона, вызывается функция
typedef void*(*nk_draw_vertex_f)(void *dst, const struct nk_convert_config *config, struct nk_vec2 pos, struct nk_vec2 uv, struct nk_colorf color);
что делать с этими данными уже решает пользователь
(режим более заточен для отрисовки меша функцией glDrawArrays(GL_TRIANGLES))
NK_INCLUDE_DRAW_TEXT_CUSTOM_FUNCTION
не использовать штатный механизм отрисовки текста и генерации фонта.
режим сделан для движков, у которых есть собственный механизм отрисовки текстов
NK_INCLUDE_UNICODE_SUPPORT
поддержка юникода вместо utf8
то, чего я вно не хватало библиотеке
NK_INCLUDE_DISABLE_KEYBOARD_EDIT
отключает клавиатурный ввод и отображение курсора/селекшина
также были добавлены мелкие полезные мелочи
Это все уже работает, вот пример интеграции библиотеки в мой игровой движочек:
http://casualgum.com/public/nuklear_gui.html
Сейчас занимаюсь исправлением багов и стабилизацией для пулл реквеста.
Изменений очень много, могут и не канонизировать, так что, кому интересно, пока все наработки тут:
https://bitbucket.org/pascualle/nuklear
зачем это? ну все та же мутиплатформенность, например ты сделал тулзовину или приложение, а в веб версии ее демо-версия… навскид идейка
— а почему не unity
— а почему не qt
код смотрел, вижу что редактора нет, но может где-то существует и редактор под все это?
Помню, сколько я часов провел на форумах, применяя всякие уловки против мерцания… Честно признаюсь, я в то время так и не нашел годного решения. Потому данная статья вызвала лично мне приятную ностальгию, а автору — реальное уважение.
Я когда-то около трех лет работал с VCL, правда на CBuilder. Задачей было организовать автоматизацию с красивым интерфейсом быстрыми темпами в одном банке. На то время лучшего решения чем Delphi5/CBuilder5 (кому что нравилось) попросту не было. Вот, столько лет прошло, а наши программы до сих пор нормально и успешно там работают без всякого саппорта.
Теперь же, работая чуть в другой сфере, отойдя от оконных приложений, мне лично, особенно когда надо «нафигачить что-то под винду с окнами побырику» кроме RADStudio я ничего не хочу знать, он меня устраивает всем. На CBuilder, к примеру, я пишу редактор уровней для своего движочка. Правда, чтобы избавиться от мерцания основного поля, я полностью отказался от TCanvas в его классическом применении, рендерю в него прямо OpenGL контекст.
set QEMU_PATH=[путь]\qemu < — эмулятор qemu
set KOLIBRIOS_IMG_PATH=[путь]\kolibri.img < — образ kolibri
set HDD_IMG_PATH=[путь]\c100.img < — опционально, вспомогательный образ
set HDD_PATH=.
%QEMU_PATH%\qemu-system-i386.exe -L %QEMU_PATH% -m 128 -drive file=%KOLIBRIOS_IMG_PATH%,if=floppy,media=disk,format=raw -boot a ^
-drive file=%HDD_IMG_PATH%,if=ide,media=disk,format=raw -localtime -vga vmware -net nic,model=rtl8139 -net user -soundhw hda -usb -usbdevice tablet ^
-usb -usbdevice disk:format=raw:fat:%HDD_PATH%
самое крутое тут то, что эта конфигурация монтирует папку (в данном случае ту, из которой запускается батник) из win в kos в виде накопителя usbhd0
(как только newlib финализуется, обновлю статью на хабре)
Я обожаю пиксел-арт и просто хочется сказать спасибо автору за то, что он один из НИХ
(для тех, кто хочет раскрыть для себя мощь и силу пикселей, советую сходить сюда probertson.tumblr.com)
Как ниже написал yogev_ezra, конкурс был организован ради пиара ОС. Но я бы не согласился с вашими утверждениями, в первую очередь это конкурс, для участия в конкурсе нужно было написать что угодно, хоть «угадай число», главное, чтобы приложение соответствовало правилам (http://habrahabr.ru/company/kolibrios/blog/243081).
Вы не поверите, это направление тоже развивается. На мой взгляд, преобладание «логических миниигрушек» в ОС — это результат того, что сейчас сообщество, развивающее ОС, состоит более из core-программистов, чем из прикладных программистов. Всему свое время, как говорится, спрос порождает предложение.
Есть заготовочка board.kolibrios.org/viewtopic.php?f=4&t=2918&hilit=зачем+kolibrios
А вообще, заходите в гости и попробуйте сами!
bitbucket.org/pascualle/tengine/src/a443eb8de407a358fbc7f5f4d750b6618df554d7/samples/scroll_map/_kolibrios/readme.txt?at=master