w23 / kapusha Goto Github PK

(истина где-то рядом)
Как удобно рулить состоянием?
Одна крайность -- дерево рендеринга, не пространственное, а где каждый узел -- установка какого-то OpenGL-параметра (от программы/юниформы до depth_test и что там ещё бывает).
Другая -- как у меня сейчас -- параметры просто идут хардкодной пачкой как батчу/материалу. Если надо добавить какую-то редкостню, то бдыщ уродство и хардкод в конкретное место.

Классы с мясом должны называться с большой буквы.
Классы-контейнеры -- с маленькой.

Что делать со структурами? Нужен ли им _t?

runtime capabilities

можно потрогать immediate mode ui, например

Надо:

• описание произвольных объектов в дебаге (перегрузка << или вообще ,), подразумевается C++-стиль, а не printf
• но при этом оставить возможность выводить в printf-стиле (что-нибудь такое: KP_LOG_DEBUG("I'm a message ", format("with a %s", message), " and an ", object);)
• сериализация в отладочную консоль (stderr, NSLog, OutputDebugString и т.п.)
• сериализация в файл или сокет (стрим, короче)
• маска подсистемы
• возможность полного безболезненного выпиливания логов вообще (KP_OPTIMIZE_SIZE)
• вывод имени модуля в релизе, и полной инфы "FILE:LINE(PRETTY_FUNCTION" в отладке

now kbd/mouse device names are hardcoded. this is retarded, don't you think?

В общем, или я дуралей, или такое не настолько тривиально сделать. Уже часа полтора в сумме не получается :(.
Хочется: без копирования кода (64к же) и с минимальным оверхедом.
Мешает: в темлейтах нельзя задавать имена функций, адреса полей объектов не работают внутри определения самих объектов. Макросы будут генерировать копии кода и т.п.
Идеи:

1. Всё-таки сделать на макросах, пофиг на код. Может, потом оно будет понятно, как упрощать (или будет хорошо жаться -- фактически там просто будет меняться смещение, по идее). С каждыми кишками элемента-списка-члена-класса идёт указатель на этот самый класс.
2. Сделать темплейтно-макросовый бдыщ, который надо будет определять в куче мест. Грубо говоря, из кишок элемента списка можно сослаться на кишки элемента списка другого объекта через макросо-генерированную static функцию.

как

there are remnants of some old code that worked, but too much stuff changed since then

Чтобы иметь возможность (квази-)динамически менять материалы геометрии, надо уметь связывать атрибуты вершин геометрии с атрибутами вершин программы.
Для этого предлагается завести класс, например, Mesh, который будет хранить форматы атрибутов (тип, количество элементов, нормализация, vbo, смещение, страйд) и соответствующие им индексы или строковые имена (полные, или какой-нибудь FOURCC для таланта).
Программа со своей стороны может ссылаться на требуемые ей атрибуты по этим индексам/именам, а так же содержать значения по-умолчанию для атрибутов, которые не являются строго необходимыми.
Батч рождается в результате любви и совместимости этих структур.

because my own replacement would be better, right?

к проектам с капушей он привычно приделывается сбоку. но можно было бы и включить в коробку и 3p/

Итак, есть три варианта:

1. "Слыш, сложи своё говно мне сюда, да не перелей"
2. "Слыш, покажи, где говно лежит у тебя"
3. "Кидай в меня своим говном, пока есть"

Подробнее:

1. Стандартная херня -- буфер и управление у потребителя. Поскольку потребитель сам дёргает за производителя, получается синхронненький такой интерфейс (если не городить специальное).
2. Буфер (произвольных размеров) у производителя, управление -- у потребителя. Точно так же синхронота.
3. И буфер, и управление -- у производителя. Потенциально удобная штука для всякого асинхронного поноса, улетающего в потребителя по мере поступления.

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

В общем, надо бы вернуть вариант 2, а асинхронность пусть делается иначе -- треды, очереди (их надо тоже оформить, да).

prereq:

1. devise a way for separate render-only thread to be possible, while still keeping kapusha thread-unsafe and therefore simple
2. get an android device (steal or smth)

avoid unnecessary state switches (former Render class)

Do not shit where you eat.
Also, multiple builds in parallel

I shouldn't be allowed around keyboards, let alone writing code.

template <typename T>
core::string_t describe(const T &t);

Ещё можно бы подложить рядом что-нибудь вроде

template <typename T>
const char *type_name() { return __PRETTY_FUNCTION__; }

для сенсы

а то уже засрано!

Тоже давнее желание подружить материал как шейдерную программу+значения униформ с настройками конвейера (прозрачность, фреймбуфер и т.п.).
Можно настройки конвейера сделать внешней штукой по отношению к материалу -- слоем отрисовки.

Не совсем так, дружище. Материал в рендере -- это очень простая и пробко-тупая штука.
Только программы, только простые безобъектные стейты.
Даже униформы надо вынести.
Фреймбуфер и прочее -- это уже ближе к слоям отрисовки, которых устойчивой концепции пока нет.

Таким образом можно будет создавать временные строки на стеке, или что-то около того.

(вообще, такую хероту надо много с чем провернуть. общая идея: потенциально создаваемый на стеке объект делается _t, а потом уже оборачивается в рефкаунты, если надо {надо аккуратно конструкторами копировать или переносить, да})

там же сейчас нет glew и аналогов

Было бы хорошо знать, какие в системе есть экраны. Потенциально полезная инфа:

• Родное разрешение
• Родная частота
• DPI (или физический размер экрана)
• Глобальные координаты (относительно соседних экранов)
• Цветовые характеристики:
  • Гамма
  • RGB в CIE xy (можно взять из EDID)
• Специальное:
  • Является ли HMD (например, Окулус)

so that it would be possible to include kapusha.mk or whatever and build it inside a single instance of make

см. ooo::Material::value_t, например

buffer-oriented было интересно, но не в коня корм

some lightweight spatial tree would be nice

уметь сообщать о том, что есть в системе:

• клавиатура
• мышь и прочие указатели (тачи)
• джойстики
• hmd (oculus)
• leap motion
• razer hydra
• какая ещё наркомания бывает

как узнать об этом в x11? win? osx?
в rpi (linux) просто -- слушать udev

Варианты:

• свой формат шрифтов, конвертер из ttf, кроссплатформенный одинаковый код (большой минус: тащить за собой шрифт, не универсально, и т.п.)
• платформенно-зависимый вывод текста (плюс: любой шрифт, установленный в платформе, минус: очень много писать и биться головой о стену, будет везде по-разному выглядеть ещё)

Среди всего прочего хочется:

• распилить всё на понятные независимые части:
  • Ядро -- простые контейнеры для pod/stdlayout/sharedptr, логгер, стримы, математика и прочая муть
  • OpenGL-леса (вот эти все объектики-обёртки и да)
  • Система: инициализация, перебор доступных устройств ввода-вывода
  • ooo: сцена с иерархией, матрицами, системами отсчета и всяким таким

Those are pure embarrassment. Go read a doc on GNU makefiles and do them properly, you stupid me!!

что-нибудь такое:
static String *kapusha::core::String::create_with_format(const char *format, ...)

Надо поддерживать в первом приближении:

• %d -- (signed 32-bit int, dec)
• %u -- (unsigned 32-bit int, dec)
• %p -- (pointer, hex)
• %x -- (unsigned 32-bit int, hex)
• %s -- (const char *, null-terminated)
• %c -- (char)
• %f -- (float, не double)

Бонус трек: %o -- virtual String *kapusha::core::Object::description() const;

Вопрос: как поддержать удобный вывод всяких vec, mat и т.п.?

попробовать когда-нибудь. жаль, но полностью от xlib не избавиться, похоже.

да, возможно, ввод надо будет делать в отдельном от основного/рендеринга потока -- есть сообщения о том, что иначе лагает: http://stackoverflow.com/questions/19613790/xcb-mouse-motion-causes-input-lag

Make a reusable wsad+mouse camera controller for quick spectatorship