Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / Создание контекста OGL 3.x

Создание контекста OGL 3.x

Поделиться

Страницы: 1 2 Следующая

Daniil PetrovПостоялецwww29 окт. 20173:59#0
Решил закинуть на обсуждение вопрос: стоит ли создавать второе окно и устанавливать формат пикселя?
const int iPixelFormatAttribList[] =
{
  WGL_DRAW_TO_WINDOW_ARB, GL_TRUE,
  WGL_SUPPORT_OPENGL_ARB, GL_TRUE,
  WGL_DOUBLE_BUFFER_ARB, GL_TRUE,
  WGL_PIXEL_TYPE_ARB, WGL_TYPE_RGBA_ARB,
  WGL_COLOR_BITS_ARB, 32,
  WGL_DEPTH_BITS_ARB, 24,
  WGL_STENCIL_BITS_ARB, 8,
  0 // End of attributes list
};
int iContextAttribs[] =
{
  WGL_CONTEXT_MAJOR_VERSION_ARB, iMajorVersion,
  WGL_CONTEXT_MINOR_VERSION_ARB, iMinorVersion,
  WGL_CONTEXT_FLAGS_ARB, WGL_CONTEXT_FORWARD_COMPATIBLE_BIT_ARB,
  0 // End of attributes list
};

int iPixelFormat, iNumFormats;
wglChoosePixelFormatARB(hDC, iPixelFormatAttribList, NULL, 1, &iPixelFormat, (UINT*)&iNumFormats);

if (!SetPixelFormat(hDC, iPixelFormat, &pfd)) return false;

Для чего это нужно и нужно ли вообще?
FuntikПостоялецwww29 окт. 20177:45#1
Daniil Petrov
> Решил закинуть на обсуждение вопрос: стоит ли создавать второе окно и
> устанавливать формат пикселя?
Без временного окна ты не сможешь получить расширенный формат пикселя (wglChoosePixelFormatARB).
Основная проблема в том, что для окна в Windows нельзя вызвать SetPixelFormat больше 1 раза. В Linux'ах с их XWindow такой проблемы нет.
Другими словами, про MSAA можно забыть, если так не делать ))))))
Daniil PetrovПостоялецwww29 окт. 20179:23#2
Funtik
> Другими словами, про MSAA можно забыть, если так не делать ))))))
У меня off-screen сглаживание в FBO, вот я и интересуюсь, нужен ли по большому расширенный формат пикселя???
FuntikПостоялецwww29 окт. 201710:15#3
Daniil Petrov
> У меня off-screen сглаживание в FBO
Тогда можно и не делать.... Тут на твоё усмотрение, помню programina использовала обычный формат пиксела
gammakerПостоялецwww29 окт. 201713:28#4
Funtik
> Другими словами, про MSAA можно забыть, если так не делать ))))))
А можно не забывать, а рендерить в MSAA текстуру, а её уже на экран. Всё равно для постэффектов так придётся делать.
gkv311Постоялецwww29 окт. 201720:03#5
Daniil Petrov
Решил закинуть на обсуждение вопрос: стоит ли создавать второе окно и устанавливать формат пикселя?
Для чего это нужно и нужно ли вообще?

wglChoosePixelFormatARB не нужен для доступа к OpenGL3.2+ на Windows, т.к. все вендоры реализовали OpenGL 3.2+ Compatilble Profile на Windows. Это не так на других платформах (Linux, macOS), где приходится выбирать Compatible Profile до OpenGL 3.0 или что-то по-свежее, но без старых OpenGL функций.

На Windows промежуточное окошко нужно для создания контекста:
- Core Profile (если хочется иметь чистый контекст без устаревшей функциональности, или просто чтобы проверить, что код их не использует).
- Debug Context - очень полезная штука для дебага и вообще
- MSAA в оконном буфере (что бесполезно для offscreen rendering с использованием FBO).

Правка: 30 окт. 2017 10:53

Daniil PetrovПостоялецwww30 окт. 20172:23#6
gkv311
Благодарю за информацию, что-то подобное мне и хотелось выяснить :) я использую только Win64 + FBO, а вот на счёт Core Profile и Debug Context, если приспичит, сделаю дополнительное окно.
Но мне лень компилировать кучу используемых библиотек ещё и под Debug, так что разрабатываю сразу под Release + никогда не связывался с дебагерами, догоняю всё своим умом :)
gkv311Постоялецwww30 окт. 201711:00#7
Daniil Petrov
Но мне лень компилировать кучу используемых библиотек ещё и под Debug, так что разрабатываю сразу под Release + никогда не связывался с дебагерами, догоняю всё своим умом :)

Во-первых, Debug Context никак не привязан к тому, в каком режиме вы собираете приложение - его вообще можно передавать флагом при запуске приложения.
Во-вторых, получить полезную информацию в дебаггере можно не только в Debug сборке, но и в сборке с Release with Debug info (причём собирать просто Release имеет смысл только для экономии места на диске).
В-третьих, не представляю как можно разрабатывать сколь-либо крупный проект, никогда не используя дебаггер и отладочных сборок (при этом вовсе необязательно собирать ВСЕ зависимые библиотеки в Debug - достаточно только то, что необходимо отладить).
ShadowTeologПостоялецwww30 окт. 201711:11#8
>>ВСЕ зависимые библиотеки в Debug - достаточно только то, что необходимо отладить).
вот так не надо. будет больно.
Не надо смешивать отладочные или обычные библиотеки, это чревато боком. Список возможных вариантов того что может пойти не так, настолько обширен, что проще забить и собирать две отдельные ветки добавляяя дебажным бинарникам и либникам постфикс d.

Если надо отладиься в релиз сборке- то действительно нужно вырубить оптимизацию и включить отладочную инфу. Но это состояние ненормально, и если не плевать на производительность по завершении танцев должно быть возвращено в обратный зад.

Правка: 30 окт. 2017 11:13

Daniil PetrovПостоялецwww30 окт. 201711:40#9
gkv311
> В-третьих, не представляю как можно разрабатывать сколь-либо крупный проект, никогда не используя дебаггер и отладочных сборок
Я и сам не представляю, так как спокойно разбираюсь и без них, если что-то тупо не работает, вставляю в качестве точки прерывания всплывающее окно и гоню его по коду до тех пор, пока оно не перестанет / начнёт появляться, правлю ошибку и ковыряюсь дальше.
Вопрос встаёт там, где мне попадается незнакомый код, на данный момент = это связка математики с программированием, но такие вещи дебаггер не спасает, чаще всего у меня в коде возникают подобные ошибки, против которых, как я понимаю, дебаггер бессилен :)
Обычно разбираюсь просто ручками и головой - очень полезная привычка, так как в жизни дебаггеры не помогают, особенно ночью на улице :)))

Правка: 30 окт. 2017 11:42

gkv311Постоялецwww30 окт. 201711:52#10
ShadowTeolog
ВСЕ зависимые библиотеки в Debug - достаточно только то, что необходимо отладить).

вот так не надо. будет больно.
Не надо смешивать отладочные или обычные библиотеки, это чревато боком. Список возможных вариантов того что может пойти не так, настолько обширен, что проще забить и собирать две отдельные ветки добавляяя дебажным бинарникам и либникам постфикс d.

Если не знать, как оно устроено, то да - можно легко получить нерабочую сборку. Но это, как правило, становится очевидно очень скоро после запуска.
Только не стоит путать полностью Debug сборку (которая убивает производительность напрочь - желаю успехов дебажится в приложении, которое запускается 10-15 минут вместо одной минуты в Release до момента, где надо отладится) и выбор версии MSVCRT.
gkv311Постоялецwww30 окт. 201711:57#11
Daniil Petrov
Вопрос встаёт там, где мне попадается незнакомый код, на данный момент = это связка математики с программированием, но такие вещи дебаггер не спасает, чаще всего у меня в коде возникают подобные ошибки, против которых, как я понимаю, дебаггер бессилен :)
Обычно разбираюсь просто ручками и головой - очень полезная привычка, так как в жизни дебаггеры не помогают, особенно ночью на улице :)))

Вопрос не в том, что это невозможно - я люблю отлаживать код с помощью std::cerr сообщений в Release, но в эффективности.
Сборка большого проекта может занимать существенное количество времени, а количество std::cerr, необходимых для локализации проблемы, может быть несоизмеримо велико, по сравнению с информацией, которую может показать отладчик - в некоторых случаях он может выдать точное место ошибки практически мгновенно, тогда как копание в коде может затянуться (особенно если код писали не вы, или вы, но уже давно).
Daniil PetrovПостоялецwww30 окт. 201713:10#12
gkv311
Ну как говорится на вкус и цвет товарищей нет :) я не программист и не хочу слишком глубоко в это залазить, мне пока хватит такого уровня, который позволит на своём движке создать игру качества Half-Life 2, Black Mesa и S.T.A.L.K.E.R. Зов Припяти без персонажей, а для этого хватит разобраться в большинстве уроков для OGL и программировании без знания последней версии C++ :))) то, что не касается сторонних SDK и API, я в принципе пишу сам, например, обработку файлов локаций и игрового сценария, даже наоборот = специально не смотрю, как это делают другие, чтоб иметь именно свой движок и самостоятельно его оптимизировать.
Как я уже сказал, я далёк от таких вещей, как дебаггинг и отладка, и более того, не желаю в это лезть, я предпочитаю тратить время и ловить ошибки сам, так как это тренирует в разы быстрее, нежели когда программа тебе всё показывает сама :))) я могу задать вопрос здесь, когда он касается вещей, не зависящих от программирования, а, например, как оказалось в двух последних проблемах я задавал поворот посредством glm::rotate не в радианах, а в градусах, или znear у камеры задавал слишком маленький - 0.001, а всё остальное - говно :))) всё, что касается ошибок в коде, можно найти и самому, ведь нужно развиваться, а не становиться помощником компьютера!!!
barnesПостоялецwww30 окт. 201717:23#13
Лол я тоже не программист. Точнее совсем не программист) Но ковыряю, для саморазвится и удовольствия, народу нравится, на моддб давно первая тыща или сотня)) Но задач плана перепюнуть какой нить крайзис итд не ставлю)))  Я насмотрелся на кучу таких заяв за последние лет 20 столько,  что давно пришел к выводу - вы не говорите, а делайте, ваша работа - это лучшее мерило вам.
В баласт вам - куча почивщих проектов с не менее громкими обещаниями)))

nonamezeroxПостоялецwww1 ноя. 201714:47#14
Daniil Petrov
> который позволит на своём движке создать игру качества Half-Life 2, Black Mesa
> и S.T.A.L.K.E.R. Зов Припяти

Хоспаде.

Движок сам по себе не позволит тебе создать  игру качества Half-Life 2, Black Mesa и S.T.A.L.K.E.R. Зов Припяти.

Для этого тебе нужен штат работников как минимум в количестве девелопмент-команды  тех контор,которые делали вышеупомянутые тобой игры.

Основной затык в производстве игр - это не код, а контент. И игру на 80% (по объему работ) делают именно текстурщики/художники/моделлеры, которые моделят каждый, сука, камень, каждое дерево, каждый домик деревянный набигает. Времена мапившего в жало джона ромеро уже давно ушли в историю вместе с уровнями дума и самим думом. И именно количество контента на экране и определяет возрастающую год от года стоимость разработки игр. И именно потому, что все уперлось в контент, эпики и крайтековцы и раздают на шару/условную шару  свои движки, тупо потому что дело стало давно не в них и не в ихних технологических наворотах. И собственно, эти движки конкретно overpowered, по сравнению с возможностями их нынешней аудитории.

Правка: 1 ноя. 2017 14:49

Страницы: 1 2 Следующая

/ Форум / Программирование игр / Графика

2001—2017 © GameDev.ru — Разработка игр