Alex2013 писал(а): можно ли грузить текстуры напрямую из "HDC" (то бишь "дисплейного контекста" )?
Никогда этим не задавался, т.к. оно платформеннозависимое.
Если DC позволяет получить указатель на сырые пикселы - то, наверно, возможно.
Скорей всего, жопа (и глубокая) в подборе формата пиксела: у DC он аппаратно зависимый, а ГЛ требует конкретного, который нравится ей.
Я бы копал в сторону захвата из DC в DIB и заливки в текстуру прямо из неё - но это всё равно тормозная операция.
Если надо скриншот всего десктопа - я сам быстрых способов ленился изучать, у себя в движке наскоро слабал через еретическую glReadPixels. Ибо запись в png всё равно во много раз толще.
Если надо рендерить в текстуру и быстро - тогда *только* FBO, альтернативы нет.
Если надо заливать в текстуру из всяких странных источников - в помощь
glPixelStore, особливо GL_UNPACK_ALIGNMENT . У гля он по умолчанию 1, а у глеса - сюрприииз! - 4. Сколько столов лбом пробито...
Алсо, glEnable(GL_TEXTURE_2D); - атавизм, который современные драйверы терпят ради совместимости, но при миграции на более продвинутое г-но мамонта типа GL ES 2, начинают плеваться GL_INVALID_ENUM
Про цветные вершины совсем не понял
runewalsh писал(а):Частичным исключением могут быть кэши@пулы и прочее, что реально осмысленно в единственном экземпляре в рамках процесса.
Это
компромисс. Реализовать моё громадье с поддержкой многопоточности - просто не хватит жизни. Поэтому пришлось сказать себе "хватит" и самую главную часть движка - логику/физику оставить строго single-threaded, а лишние ядра процессора - только для рендера и для фоновых загрузок всяких.
В теории, если я всё правильно сделаю, оно по любому упрётся в память и плоскопараллельно, сколько там ядер.
Соответственно, весь механизм БД, включая диспетчер памяти - однопоточный, без расходов на блокировки.
Для повышения производительности предназначены две фичи, призванные сделать просчёт физики кеш-фриндли:
1. Просчёт физики каждым объектом на N тиков вперёд, зато редко: образно говоря, моб представляет собой не капсулу, а квантовое состояние из 8 капсул просчитанных в будущее. Любые операции чтения - включая те, что сами для будущего - интерполируют между ними. Если незапланированное внешнее - воздействие - моба будят, схлопывая его квантовое состояние в единственную капсулу и добавляя в очередь просчёта физики. Но когда его не будили - а таковых 99% случаев - моб спит, а движение идёт. ИЧСХ, записи в память при этом нет, а чтение - только когда кто-то ещё прётся через то же место, что тоже не всегда.
2. Ускоренные поля. Что-то типа нищебродской ECS. Уже используется обходчиками графа для индексов, ускоряя их. Все ускоренные поля определённого индекса диспетчер памяти хранит в отдельном массиве (индекс вычисляется простыми побитовыми операциями над Self инстанса). Если, скажем, инстансы - 128 байт, а упакованные поля - 4 байта, получаем 32-кратную экономию на загрязнении кеша. А сброс индексов - вообще бесплатный, массивы просто освобождаются, не надо елозить по содержимому. В старых версиях сброс индексов засирал кеш страшно: ведь надо было обойти все объекты графа и записать ноль во все инстансы. А это 64 байта на каждый.
Именно это я кодил в 2019-м на Карибах, попивая пиво с видом на море. Так увлёкся, что был пожран комарами, которые налетели из соседнего болота с крокодилами, когда морской бриз стих.
Обидно, что так ни одного крокодила не встретил - а ведь одному нашему туристу там же, в Канкуне, руку откусили! А вот нефик ей в воде болтать, когда тебя катают по болоту с крокодилами.