Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenGL 1.1 path appears not to work on actual OpenGL 1.x hardware. #194

Open
TheBoctor opened this issue Aug 1, 2020 · 2 comments
Open

Comments

@TheBoctor
Copy link

TheBoctor commented Aug 1, 2020

When trying to run either my own project, or the included demos, on a ThinkPad X60 with Debian (i386), I get a malloc() error as soon as GPU_Init() is called. When trying to run the Windows versions of these binaries through Wine, I get an immediate unhandled page fault at 0x00000000 with "glDeleteFramebuffersNOOP: Unsupported operation." Neither native nor wrapped Windows binaries can get past initialization.

I've even tried specifically requesting the OpenGL 1.1 code path, when requesting the renderer. The demos built with the CMake instructions in README.md produce identical issues, so I'm guessing it's not specific to my code. Am I linking something incorrectly, or missing dependencies for falling back to immediate mode?

Edit: I tried compiling my project under Windows 10 on a ThinkPad T61, where the driver should implement OpenGL 1.x as well. There is an access violation at 0x00000005, while executing 0x00000000, specifically at the line I call GPU_Init and assign it to a surface. With GPU_DEBUG_LEVEL_MAX, it appears that the correct renderer isn't being chosen:
Screenshot of debug spew

@grimfang4
Copy link
Owner

I'm going to keep this open, since I haven't had a chance to repro it and fix it. The GL 1 path is still officially supported, I just need to clear some time and dig out the hardware for it. If you identify a fix, please let me know!

@grimfang4 grimfang4 reopened this Aug 4, 2020
@TheBoctor
Copy link
Author

Will do. I was only ready to close this because I thought I was doing something wrong, or that specific computer's driver was busted. The specific project I was testing here has also been moved over to "raw" OpenGL, since this issue was opened, but that's beside the point as the demos (space.c, etc) seemed to have issues initializing, too.

What's not directly related, but a clue that it could be something more: On a ThinkPad X201 (which should provide at least GL 2.0 with the Windows driver) the VS2019 debugger warned of heap corruption, at some point during GPU_Init. However, the initialization continued to select the 2.0 path, and the game ran fine anyway, once I selected "Ignore."

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants