I wanted to end it at that. Now, however, I'm getting 8 again. I found a minimal.c here for Windows. Here's a dropbox link to the edited version I had to make to get it to work on VS 2015. (If you're doing VS 2015, don't forget to right click Project -> Properties -> Configuration Properties -> Linker -> SubSystem to Windows (/SUBSYSTEM:WINDOWS). Got me for a bit.)
I now know after a while that it's for Windows only because it's Windows API based. When I first found this while trying to work with the forums, it looked pretty daunting, but I found by changing some DC calls if I remember right and some strings that it worked again. Pretty neat, considering the code was written in 1997. That's the cool thing about Windows API, I see.
I don't have the original file for some reason, but back then, I found a display() function, guessed it was the exact same as GLFW's "while (!glfwWindowShouldClose(window)) {}" loop, and added this code snippet in to attempt to get stencil bits (lines 19 to 23).
Back then, when I opened the file, it returned 0. That's why I concluded it was a driver bug in the forums. But now when I run it again, it returns 8! No clue why, but that's great! But I'm now confused again. Maybe it could be a GLEW or GLFW bug now to conclude from? Or maybe I read it wrong for some odd reason back then?Anyways, ya, quite a surprise to get this when I'm writing this blog.
Anyways, ya, overall, wanted to put this entry in here about how in rare cases, weird results can actually be a hardware bug (or now, I'm seeing, maybe a library bug, surprisingly). I haven't reported it to Intel, I would've now, but with the proper 8 result, I'm not sure what to write now haha. I'll let it be for now. If it happens with another function, and trying it in a minimal.c like this doesn't work, then I'll definitely write it in.
Also, it was pretty cool to find that I was trying Windows API for the first time too. Really, that was awesome, getting working results out of a program written that long ago.
No comments:
Post a Comment