GLQuake Bug: Nvidia Extension Limit must be off

[JasonX]

http://forums.steampowered.com/forums/s ... 894&page=2

Does anyone know how can this be fixed in the code? What's actually wrong?

[mh]

Code: Select all

Con_Printf ("GL_EXTENSIONS: %s\n", gl_extensions);

Code: Select all

#define    MAXPRINTMSG    4096
// FIXME: make a buffer size safe vsprintf?
void Con_Printf (char *fmt, ...)
{
    va_list        argptr;
    char        msg[MAXPRINTMSG];

What happens if the length of the extensions string (including terminating 0) is > 4096?

[Baker]

This stopped the GLQuake.exe has stopped working message.

GLQuake.exe should not be used. Has at least 12 severe issues on modern computers. This is just one of them.

Virtually all modern engines are not affected by that issue (extension list exceeding 4096 chars) ... DarkPlaces isn't, ProQuake/Qrack/JoeQuake/FitzQuake/etc are not, etc. etc.

[mh]

This stopped the GLQuake.exe has stopped working message.

GLQuake.exe should not be used. Has at least 12 severe issues on modern computers. This is just one of them.

Virtually all modern engines are not affected by that issue (extension list exceeding 4096 chars) ... DarkPlaces isn't, ProQuake/Qrack/JoeQuake/FitzQuake/etc are not, etc. etc.

Although asking what the problem is so that one can fix it in one's own engine is perfectly permissible.

Incidentally, and for the benefit of JasonX, the fix is NOT to increase the size of MAXPRINTMSG to something daft like 1000000, and it's definitely not to go diving into code trying to split the string into multiple substrings and handling them in chunks. The fix is to just not Con_Printf the gl_extensions list. As in comment out that line.

Think about it. Do you really need to see the extensions list? Or is there more useful info further back in the console (like your GL_VERSION and GL_RENDERER, or whether or not you got a network connection, and so on) that printing the extensions list will hide, and eventually make fall off the end of the buffer? Which is more important - knowing that you support GL_ARB_weenies_live_here or knowing that useful info? In fact does knowing that you support 25,000 proprietary extensions that GLQuake never even uses matter at all?

[JasonX]

GLQuake.exe should not be used. Has at least 12 severe issues on modern computers. This is just one of them.

Unfortunately, i'm not interested in using any other engine other than vanilla WinQuake and GLQuake. I want to know what's wrong, why and what's the solution. This way i can know more about C and overall graphics programming.

Exactly this:

Although asking what the problem is so that one can fix it in one's own engine is perfectly permissible.

[mh]

Off the top of my head:

• Extensions limit crash.
• Uses SGIS multitexture.
• Timer (also in WinQuake).
• GL_LoadTexture problem.
• Bad handling of water and sky polygons.
• R_DrawSequentialPolygon - all of it!
• No fullbrights or overbright.
• 8 bit texture crap.
• t-junction removal.
• LoadLibrary on opengl32.dll
• Underwater warp.
• Overlapping particles bug.
• Lower limits than WinQuake in many cases.
• glDrawBuffer (GL_FRONT)!!!!!!!
• Skin group and frame group intervals not respected.
• gl_max_size is a cvar!
• Startup gamma table hacking.
• Inability to change resolution.
• Handling of dynamic light updates is totally screwed (theRect, etc).
• Unnecessary memory usage and inefficient memory allocations all over the place.
• Potential status bar crash (not normally a problem as the face isn't shown if you're dead, but you need to be aware of it) (also in WinQuake).
• Doesn't release textures after loading so it will eventually run out and crash.
• texture_extension_number crap.
• Various HoM situations.
• Dead player bodies loose their colours when the player respawns.
• gl_ztrick - all of it!
• Z-fighting on brush polygons (more of a content problem IMO).
• gl_clear and sb_updates interaction (or lack thereof).
• Mesh files crap.
• Cache mismatches and false positive texture matches (load e1m1, look at the plat; load e1m5, look at the plat, do the same in WinQuake, see what I mean).
• Colormapping is broken.
• Incorrect MDL bboxes.
• Dedicated server crash.
• Unable to load a texture > 512 * 256 - down in flames we go!
• Runs out of video modes on modern hardware so higher res 32 bit modes are unavailable.
• Pink fringes on alpha textures.
• Inverted lightmaps.
• Fails to specify CS_HREDRAW | CS_VREDRAW | CS_OWNDC.
• Doesn't handle WM_ERASEBKGND.

There's most likely quite a lot more that I just haven't immediately thought of.

Remember that GLQuake was written in 1996, and was nothing more than an experiment in learning OpenGL for use in a game engine that ended up being released. It's neither Quake as it was meant to be nor OpenGL as it's meant to be.

It was also written to the OpenGL 1.0 spec, originally for SGI workstation cards, and then hacked around on for Voodoo cards. Some of the decisions made back then might have been valid on that kind of hardware, but they're not valid anymore today (some of them were never even valid in the first place, but that's a natural consequence of being the result of a learning experiment).

[JasonX]

What are the most critical ones, that make newer hardware crash? I want to fix what makes the game unplayable.

[mh]

The critical ones would be the extensions limit, glDrawBuffer (GL_FRONT), gl_ztrick, the GL_LoadTexture thing will cause problems on any hardware, you definitely need CS_HREDRAW | CS_VREDRAW, but CS_OWNDC is optional these days, get rid of the 3DFX extensions and call glBindTexture directly, and replace SGIS multitexture with ARB. In fact, completely get rid of GLQuake's multitexturing altogether. Delete all the code relating to it, and file it away somewhere marked "what NOT to do".

The timer needs fixing in both Win and GL too, that's very important.

[JasonX]

One big bug that i'm having is that all textures are white, including menu sprites.

[mh]

That's the 3DFX extensions. I don't remember the exact code, but look in GL_Init (in gl_vidnt.c) for the comment about loading the 3DFX extensions and delete the function call.

[frag.machine]

Check if running quake with the -nomtex option works.

[mh]

My mistake, it's VID_Init. Find these lines:

Code: Select all

    // Check for 3DFX Extensions and initialize them.
    VID_Init8bitPalette();

And delete them.

[Baker]

Off the top of my head:
* Extensions limit crash
* Uses SGIS multitexture
* Timer (also in WinQuake)
* GL_LoadTexture problem.
.
.
.

Nice list MH.

I wasn't saying there is a problem understanding or exploring issues, obviously. More I was expressing the broken record frustration I feel every time a Steam user has the same glquake issues again and again and again and again and again ....

[mh]

Nice list MH.

You could probably add twice as much more to it yourself!

[mh]

OK, here's source code for what I'd consider to be a minimal "fixed" GLQuake. Compiles clean in Visual C++ 2008 Express; I've just focussed on the Windows version to avoid confusing matters more than they need be.

http://www.sendspace.com/file/immmgc

I haven't tackled everything (obviously) but most of the main crashers and performance degraders should be done, as well as a few "GLQuake specials". It runs fast and solid on Intel graphics so I guess it must be OK.

There's room for a LOT more improvement in it; one of the problems is that GLQuake's code is so badly broken in places that I really would have needed to rewrite the whole thing in a manner that is so completely different from the original that it would be utterly useless for comparison/learning purposes.

Multitexture is disabled in this; please read my comment at the top of gl_rsurf.c for an explanation of why R_DrawSequentialPoly is evil incarnate, and why it does just about everything you should NOT do. Multitexture is one of those things that would need a fairly extensive rewrite.

All my changes are marked "#ifdef MHGLQFIX" so you should be easily able to find them. I've commented liberally on what I've done and why I've done it, and have also left the original code in but #ifdef'ed out, so please read the comments, compare the code, and try to understand what's going on before asking me any questions, OK?