XaeroX, походу это можно через виртуальные сканкоды сделать. В SDL есть такая штука https://wiki.libsdl.org/SDL_Scancode
Нажатие на A на azerty клавиатурах возвращает SDL_SCANCODE_Q. Глянул сорцы - там маппинги на коды в ОС. Так что ты прав, хардвар-коды тут лишние.
Вопросики скорее не про саму либу, а про организацию взаимодействия её с OpenGL. Вот сделал я подкласс Fl_Gl_Window и реализовал триде-вьюпорт для геометрии. Всё зашибись, но теперь я хочу ещё один подкласс, который будет дваде-вьюпортом для ювишек.
Все данные на отрисовку доступны через один и тот же VBO — и для 3D, и для 2D. Надо ли предпринимать что-нибудь особенное, чтобы обе разновидности вьюпорта работали одновременно? Как лучше поступить с шейдерными прогами: создавать под каждый тип вьюпорта свою или юзать общую (и вкорячивать дополнительные условия и униформы в шейдеры)? Не будет ли гонок из-за общего доступа к VBO?
nemyax писал: Надо ли предпринимать что-нибудь особенное, чтобы обе разновидности вьюпорта работали одновременно
Нужно расшарить ресурсы между контекстами обеих вьюпортов.
Не могу сказать, как это делается в FLTK, увы.
Цитата:
nemyax писал: Не будет ли гонок из-за общего доступа к VBO?
Что именно ты собираешься писать в VBO каждый кадр? Нельзя обойтись стейтом и униформами?
Цитата:
nemyax писал: Как лучше поступить с шейдерными прогами: создавать под каждый тип вьюпорта свою или юзать общую (и вкорячивать дополнительные условия и униформы в шейдеры)?
Нужно профилировать и сравнивать. Я бы (при отсутствии времени на профилирование) предпочёл первый вариант.
nemyax
Тебе надо расшарить идентификаторы между двумя OpenGL-контекстами. Это делается по-разному в зависимости от ОС. Например, под виндой это wglShareLists. В FLTK должно быть что-то такое в API (в Qt, допустим, есть).
Цитата:
nemyax писал: у меня содержимое будет перезаписываться только при выполнении команд в основной проге.
Тогда в чём может заключаться гонка?
Добавлено 09-06-2018 в 17:42:
Судя по коду, FLTK по дефолту шарит все контексты с первым.
Ну тогда вообще ничего специально делать не надо.
XaeroX писал:
Тебе надо расшарить идентификаторы между двумя OpenGL-контекстами. Это делается по-разному в зависимости от ОС.
Ага, благодарю, буду копать.
Цитата:
XaeroX писал:
Тогда в чём может заключаться гонка?
Мало ли, вдруг при чистом чтении она тоже может происходить. Я как-то glVertexAttribPointer-ом насовал вершинам атрибутов с соседних вершин дальше по массиву, чтобы не дублировать. Так у меня рендерилось то ожидаемое, то кокаета хрень, как повезёт. Вот теперь дую на воду.
Карочы надо взять у первого GL-окошка контекст через void *my_shared_context = first_good_gl_win->context(); и потом явно задавать его другим нужным окошкам через other_gl_win->context(my_shared_context);. Тогда будет шариться.
nemyax писал:
Карочы надо взять у первого GL-окошка контекст через void *my_shared_context = first_good_gl_win->context(); и потом явно задавать его другим нужным окошкам через other_gl_win->context(my_shared_context);. Тогда будет шариться.
Идиотский оказался совет, не делайте так. Лучше рисовать несколько glViewport-ов в одном окошке.
Можно набацать виртуальные вьюпорты, через проходы, например. Да мало ли. Через контексты, КМК не очень удобно. Особенно если мы рисуем что-то одно но с разных сторон. Я бы эти вьюпорты рассматривал как частный случай зеркал, например. Ну или через FBO.
Добавлено 10-07-2019 в 16:55:
ЗЫ. я вот с этим моментом никогда не сталкивался, пусть Ксерокс поправит, но помоему память выделяется под конкретный контекст и чтобы нарисовать ту же карту четыре раза, надо её и загрузить четыре раза, то есть займет вчетверо больше памяти, но чтобы этого избежать контексты шарят, но тут-то кроются всякие подводные камни.