OpenGL Extensions Viewer quits silently in the middle of loading extensions.

Maybe my system just sucks - I had to "temporarily" install a shady Win 7 distro with some features disabled. The list of disabled features looked innocent, but I had some video driver installation problems. In the end, I just reinstalled everything with a driver that I knew worked fine, and left it at that.

All 3D games I tried so far worked fine, including Quake source ports (Quakespasm and mark_v.exe dated 2016/12/03).

I tried to reboot from an old HDD with Vista installed, and the latest mark_v.exe started without any problems. But I have different drivers there.

Can either of you post a qconsole.log where the error occurs?

Command line: [ ]
Log file: D:/Games/Quake/id1/qconsole.log
Fri Jan 20 00:02:40 2017
Mark V Windows (Build: 1033)
Exe: mark_v.exe (1327 kb)
Exe: 00:44:32 Jan 19 2017
Caches: C:/Users/User/AppData/Roaming/Mark V/caches
UDP4 Initialized: INADDR_ANY, 192.168.1.67
IPv6 Initialized: [fe80:0:0:0:9459:106d:2bee:97d8%12]
Exe: 00:44:04 Jan 19 2017
256.0 megabyte heap 

Maybe my system just sucks

If an earlier Mark V worked, I'm not going to be happy until this one works.

I did install DirectX June 10 SDK, which may have changed some libraries.

Need to meditate on this a bit. 

Fitz 0.85 works fine on my XP VM but MarkV fails with the same error.

It's XP on a Windows 10 host, but I believe the core guts of the driver are the same: VMWare Tools provided Mesa/Gallium driver.

I have a full development environment on this VM so I'll have the fix identified soon! 

Another thing going on here, you also have the problem with winquake_gl -- which doesn't even use Visual Studio to compile, it uses CodeBlocks/gcc/mingw and winquake_gl is an SDL build, so it uses SDL functions to set the pixel format and create the opengl context. 

The DX9 version works after installing that runtime package.


In the OpenGL Extensions Viewer:

- "System Info | Renderer" is "Gallium 0.4 on SVGA3D; build: RELEASE"

- "OpenGL | Version" is "2.1 Mesa 8"

- In the pixel formats, WGL_DOUBLEBUFFER_ARB is sometimes False, for some values of number in the spinner there (don't know what that number is). For 7-12 it's True, for 19-24 it's True, stopped looking at that point. For some of those, color bits or depth bits are 16, but others match all the desired values you mentioned.

Let me know if there's other digging around I should do in the extension viewer. I copied the text from the Report pane to https://dl.dropboxusercontent.com/u/11690738/temp/extensions_report.txt


qconsole.log from trying to run mark_v.exe:

Command line: [ ]
Log file: C:/Users/joel/Desktop/Quake/id1/qconsole.log
Thu Jan 19 13:16:05 2017
Mark V Windows (Build: 1032)
Exe: mark_v.exe (1327 kb)
Exe: 10:00:00 Jan 18 2017
Caches: C:/Users/joel/AppData/Roaming/Mark V/caches
UDP4 Initialized: INADDR_ANY, 172.16.229.128
IPv6 Initialized: [fe80:0:0:0:a48d:1a8a:5eb0:7e8b%8]
Exe: 09:59:32 Jan 18 2017
256.0 megabyte heap 

Fucking awesome!!

Yeah, since I can't experience the problem firsthand, I'm not able to get my hands dirty as I would like. 

qconsole.log from build 1033 is the same except for obvious differences in build number. 

An obscure change is that current Mark V uses /J compiler option - make char be unsigned char.

Wanted to mention that, although I do not believe this relates to the issue. 

Another small change is that Mark V uses /DELAYLOAD:opengl32.dll

I can't see how that would relate to this, but anything is possible with something odd like this. 

It's because you're delay-loading.

See https://groups.google.com/forum/#!topic/comp.graphics.api.opengl/AVqQjWFAIBI for a prior example; wglCreateContext fails with error 2000 which is exactly the same as MarkV does.

The quick 'n' dirty fix I did was to pop in this little line of code before setting up the pixel format:

GetProcAddress (LoadLibrary ("opengl32.dll"), "glBegin");

You'll probably want to #define it for the GL build, but that forces opengl32.dll to be loaded and then everything works. 

Thanks MH!

Where did you insert that line in your test? 

Let me know if it works! 

Build 1034 with DelayLoad fix.

http://quakeone.com/markv/older/1034_mark_v_opengl.zip

Let me know! Thanks! 

I put it just before the call to WIN_SetupPixelFormat in VID_Local_SetMode, but you could put it earlier if you wish.

I assume that you're delay-loading so that you can test for the 3DFX opengl32.dll? Maybe immediately after your test would be a good place.

Do you need a new wrapper code drop for 1034 or would integration delay you at this point in time? 

If you have a new wrapper drops, let's get that in there. 

Beer for Baker! 

I'm rather relieved that this obscure problem is resolved.

I hate it when I can't experience an issue. And this one ranked up there in the obscurity department. Fucking delayload.

Beer for MH! 

http://www.quaketastic.com/files/tools/windows/engines/Direct3D9-Wrapper-2017-01-19.zip

It's just the underwater warp stuff so no sweat if you can't get it in. 

I'll be integrating it here in a few minutes. Probably within an hour I'll post 1035. Need to update a zips, installer, etc.

This issue being resolved gives me great peace of mind! 

 

@dwere - Awesome!

@fifth - Is there is any particular reason you want the WinQuake GL build? The pure WinQuake performs better. 

1034 works for me. 

beer for MH and Baker ++ 

I dont think it did when I checked it last, weird...

You dont need to support it on my behalf tbh, I'm not likely to use it anyway 

I forced 640x480 stretch in WinQuake GL for higher fps than it would have had otherwise to somewhat compensate.

Still killpixel said every once in a rare while that it would stutter a little.