Заметил одну проблему с нынешним порядком использования OpenGL. Не знаю, осталась ли она в renders_updated или нет.
Суть её в том, что сейчас для работы с OpenGL мы используем стандартные модули GL и GLext. Они подключаются в
/nogl/noGLuses.inc, который в свою очередь, несмотря на название, включается в
e_graphics.pas.
Однако модуль GL загружает библиотеку opengl и получает адреса функций оттуда непосредственно в секции
initialization, то есть задолго до создания самого окна и контекста OpenGL. Это работает в GLX, но под Windows такое противоречит семантике WGL, где указатели на функции OpenGL специфичны для конкретного контекста и потому должны получаться сугубо при нахождении в нём. Именно поэтому в SDL существует функция
SDL_GL_GetProcAddress() (по ссылке есть более подробное пояснение по особенностям семантики поведения в Windows). Особенного внимания заслуживает вот эта ремарка, которую я здесь даже процитирую:
Quote:
This is (currently) a Windows-specific limitation, and in practice lots of drivers don't suffer this limitation, but it is still the way the wgl API is documented to work and you should expect crashes if you don't respect it.
Заметил я эту проблему, запустив игру под Windows через
gDEBugger 5.8.1, который её частично ловит:
Quote:
Debug String: Detected error: The debugged process asked for an extension function pointer (wglChoosePixelFormatARB) from one render context, but called this function pointer in another render context (context #2)
Debug String: Detected error: The debugged process asked for an extension function pointer (wglGetPixelFormatAttribivARB) from one render context, but called this function pointer in another render context (context #2)
Ещё вот описанное здесь может оказаться полезным:
wglGetProcAddress is broken · Issue #282 · opentk/opentk - GitHubК слову, у меня почему-то ощущение, что
DeaDDooMER тему написания собственного загрузчика OpenGL уже поднимал, вот только я сейчас не могу вспомнить, когда и где именно.
Login
Register
FAQ
Search
