Quick and dirty Intel Fix

[Baker]

Some of the Intel display adapters made longer ago, but produced in the untold millions and millions, crash on glquake.exe

A crappy way and quick way to fix this is simply to not draw the discs in gl_draw.c.

1. Open gl_draw.c

Code: Select all

/*
================
Draw_BeginDisc

Draws the little blue disc in the corner of the screen.
Call before beginning any disc IO.
================
*/
void Draw_BeginDisc (void)
{
#if 0 //Baker: Intel display adapter fix
	if (!draw_disc)
		return;
	glDrawBuffer  (GL_FRONT);
	Draw_Pic (vid.width - 24, 0, draw_disc);
	glDrawBuffer  (GL_BACK);
#endif
}

A better way is to detect Intel display adapters in gl_vidnt.c,
create a variable, and modify gl_draw.c to not draw the discs if it is Intel display adapter.

Engines with this issue fixed that I know of:

ezQuake, FTEQW, Qrack, ProQuake 3.99 (and DarkPlaces does not have the problem).

Engines known to have this problem in the current version:

JoeQuake, FitzQuake, aguirRe GLQuake, likely every other GLQuake engine.


Related URL:

http://www.intel.com/cd/ids/developer/a ... htm?page=7

Comments in the ezQuake source:

// Intel cards, most notably Intel 915GM/910GML has problems with
// writing directly to the front buffer and then flipping the back buffer,
// so don't draw the I/O disc on those cards, it will cause the console
// to flicker.
//
// From Intels dev network:
// "Using two dimensional data within a 3D scene is sometimes used to render
// objects like scoreboards and road signs. When that blit request is sent
// to or from a buffer, the data contained within must be updated, causing
// a pipeline flush and disabling Zone Rendering. One easy way to generate
// the same effect is to use a quad or a billboard that is aligned to the
// view frustrum. Similarly, a flip operation while rendering to a back buffer
// will cause serialization. Be sure you are done altering the back buffer
// before you flip.

[r00k]

Code: Select all

void Draw_BeginDisc (void)
{
	if (!draw_disc)
		return;
	
	if ((strstr(gl_vendor, "Intel"))||(strstr(gl_vendor, "intel")))
		return;

	glDrawBuffer  (GL_FRONT);
	Draw_Pic (vid.width - 24, 0, draw_disc);
	glDrawBuffer  (GL_BACK);
}

WAY too blatent but until intel starts making x100 gfx cards, f*ck'em!

[mh]

The front buffer is not directly exposed in the Direct3D API for DirectX 9.0. As a result, applications cannot lock or render to the front buffer.

The moral of the story is that even OpenGL developers need to be aware of what cannot be done under Direct3D, and if something cannot be done under Direct3D - no matter that the OpenGL API supports it - it should not be done, because chances are that it will blow up sometime.

One way of fixing it in a compatible manner would look like this:

Code: Select all

void Draw_BeginDisc (void)
{
	if (!draw_disc)
		return;

	Draw_Pic (vid.width - 24, 0, draw_disc);
	GL_EndRendering ();
}

[Spike]

calling GL_EndRendering will do a buffer swap...
that's not going to be pretty. you'll get flickering each time a file is loaded. if you're running on an engine with a small hunk (and small model cache) you'll end up swapping buffers mid-frame, and that's not going to be pretty. And if vsync is active, you'll limit loading to 60 files per second or so. If you really really want to keep this feature, create a child window with the image in it. :)

The 'correct' way is to do disk access in an entirely separate thread from the renderer. If you have such a thread running at the time you finish a frame, draw a disk, if not then don't. But then that's a major overhaul of most of the engine. :)

Tbh, if you're loading stuff, then show the qplaque. if you're not loading stuff, then don't. You shouldn't really be loading stuff mid-level, which is what the disk icon is there. The same reason as the turtle. And I don't remember seeing the turtle for ages now.
The point of that icon is to tell the user that its going slow because its loading stuff from the disk. Just make it appear for the next half a second (after the access), rather than for the frames it was shown in, and you get something with the same intended effect, without flickering, which lasts longer than a fraction of a second.
But if you consider the disk icon to be there because it genuinely takes a while to access the disk, then you're trying to play quake with your data set the other side of an isdn connection - which is what id did briefly or something. And I really have no idea what to say to that, other than 'ARE YOU CRAZY?!?'. But hey, each to their own.

Or get the user to type -intelsucks on the commandline in order to run your engine.

[r00k]

What's the point of drawing to the front/back buffers? I dont see it being used elsewhere why is it required here? Is it because the scene isnt initialized during this display of this icon? If so, as Spike suggests its also during the "LOADING" display so... i think the little disk i/o flashy is a retro artifact of games during the 80s and something that idsoftware left in.

[Spike]

its drawn to the front buffer so it appears instantly (next vsync), rather than waiting to the end of the frame.
As its not drawn into the back buffer at all, it'll vanish the next time buffers are swapped.