A simple screenshot

[Baker]

Here is a simple GL ProQuake screenshot of an experimental test I'm working on.

The screenshot above is actually amazing, although it doesn't look out of the ordinary.

The reason it is amazing is because it's running on my left monitor on my Intel display adapter.

My Intel display adapter can't run GLQuake (none of them, you name a GLQuake engine and it won't run)

Does this matter? Well, they ship more of those crappy things out than all the ATI and Nvidia cards combined. In fact, you can probably multiply that out by 20x or maybe 50x or so and it'd still be true.

If Quake is to have a 2nd coming, surely it must run perfectly on all of those video cards. I mean, Quake 3 runs on all of them just fine and you can't expect someone to buy a video card for a 10+ year old game when almost every other game not named Quake runs just fine.

[Baker]

It was a pain in the ass, but I've finally determined what those Intel graphics cards hate about GLQuake and why.

I can run GLQuake 100% of the time on my Intel display adapter now, heheheheheheheh.

This means in the near future, I'll be able to make an uber-compatible version of ProQuake.

d3dpro is "ok", but glpro kicks d3dpro's ass. I'd prefer glpro to work all the time and in any situation.

/Unfortunately, I'm not sure all or any of this applies to JoeQuakey style engines. But maybe it does. I've run into machines that run glquake and not JoeQuake, so I'm not sure that the things I've worked on here apply to those engines since it would seem that machines that won't run JoeQuake but run GLQuake must have some other type of problem.

[Baker]

/Unfortunately, I'm not sure all or any of this applies to JoeQuakey style engines. But maybe it does.

Nope. This doesn't apply to JoeQuake-style engines.

I just tried the fix with JoeQuake and it won't run on my Intel display adapter. "Fancy" engines must have something else going on.

/But it doesn't mean whatever this other problem is can't be solved. It just means that the fix for glquake doesn't cure every GL engine.

[Mr.Burns]

Keep up the good work Baker

Kind regards

Monty

[Baker]

Mostly for my benefit the next time I look at this ...

The problem goes like this:

1. The Intel display adapters appear to hate the Quake console, the Quake letters (including the crosshair) and the Quake menu.

2. The Intel display adapters like gl_clear 1 and hate gl_clear 0 and despise doing any 2D graphics without the slate cleared (hence gl_clear 1).

3. I think GLQuake does some *bad* things with console drawing and characters. I think it sends invalid x,y coords and other weirdness. Maybe most OpenGL drivers just ignore bad stuff, but maybe the Intel drivers take bad coordinates literally.

4. Quake also has some other "bad" behaviors. I think it draws the crosshair and *some* other 2D elements (not the sbar) even when it shouldn't and maybe lets the console draw over top of it to hide the sloppiness? In particular, I know the crosshair does (right? double check).

One consequence of #4 might be all kinds of invalid x,y coords or other oddness on startup. Quake treats a forced down console VERY differently than a "connected" client with the console down (i.e. "connected" = running single player, demo or playing multiplayer as a client) and actually treats it mostly as if you are "in-game" when you aren't (the drawing routines).

I think most of the issue is the startup when the in-console behavior is acting like "in-game" behavior with the drawing. And most of the rest of the problem is forcing the behavior of gl_clear 1. gl_ztrick *may* or may not play into this.

But this explains what I've read of problems with the Intel display adapters when they do work mostly and don't work at all. Someone once said "the problem doesn't exist when using a crosshair image", gl_ztrick 0 and other observations of different behavior when dead and when disconnected.

Considering Quake is just about the only OpenGL game that is messed up/incompatible with many Intel display adapters and all of the other most popular games tend to work, I think it was that Intel designed the OpenGL drivers according to the specification and Quake is doing some things very wrong.

At least this my interpretation going through and thru trial and error actually getting it to work.

Anyway, when time permits this problem is as good as DEAD. I've hated this problem for 5 years, ever since I had a Dell computer that every game worked EXCEPT Quake and had to buy a graphics card for a 10 year old game when the new games worked. Grrrrrr.

[=peg=]

One thing I seem to remember (but am not 100% sure on) is that Intel Integrated Media Accelerator does not like 60 HZ vertical refresh rate on TFT screens -> frames flickering / drawing one frame on top of the other. I had this problem running Qrack.. but it was cured by setting the TFT screen to 75 Hz.. (when rotating the screen 90 degrees it would force 60 Hz, then after rotating it back it would still be 60 Hz unless i manually set it to 75 Hz again..)

This issue may or may not be partially connected to the problems Intel's I.M.A. has with (gl_)quake.

anyways.. keep up the good work baker

[Baker]

I've got this to the point that it now only crashes when the console is forced up.

Actually, at the moment I simply have the screen refuse to update when the console is forced is up (Console forced up = no map running, just sitting at the console).

Something that is annoying to me is I have yet to determine what bad thing is occurring when the console is forced up. I know where it is crashing, it is crashing when it draws the actual console. I just don't know WHY it is crashing.

What sucks is that there isn't that much going on with drawing code when the console isn't up. I tried replacing the drawing of the console graphic with a black box using Draw_Fill which does a simple GL_QUADS and that crashes too.

Something is not being "setup properly" with the 2D rendering when the console is the only thing being drawn.

Hrrrrmmmmm.

[Baker]

Alright, it's done!

It looks like the console can't be properly displayed until after some ambiguous point in the initialization, and then after that it's happy.

So I just don't let the console draw until that point.

I'm not sure precisely why. I'd rather know, but I'll take "works, reason it does is slightly vague" over "doesn't work" any day of the week.

[Baker]

Final notes on this before making something available:

I now have Quake running 100% reliably on my Intel display adapter with absolutely no issues whatsoever, as if it were natural for it to run on it. I'll have to lock the video mode in place for this experimental version, the Intel display adapter that "won't run GLQuake" isn't fond of in-game video mode switching.

Part of the solve:

1. gl_clear forced to on.
2. gl_ztrick forced to off.
3. Don't draw the console until later on and don't allow it to be drawn anywhere; use Con_SafePrintfs instead of Con_Printfs during startup.
4. Don't draw the "discs" (the thing in the top right corner when something is loading).

/If you are reading this and thinking it is boring (and it is!), the significance of this is that GLQuake will now run on almost 100% of computers made since 2001, as those Intel display adapters are almost ubiquitous.

[vegetous]

Baker,

Last week I ran ezQuake (1.8.2) in a core 2 duo laptop equipped with a Intel® Integrated GMA950 Graphic Engine, and I didn't got any errors or problems. Thought I also ran Qrack but I'm not sure.

[Baker]

Baker,

Last week I ran ezQuake (1.8.2) in a core 2 duo laptop equipped with a Intel® Integrated GMA950 Graphic Engine, and I didn't got any errors or problems. Thought I also ran Qrack but I'm not sure.

Yeah, it's true!

I ended up independently discovering what Rook and ezQuake people already had discovered.

I was going to post this at Quakeworld.nu and ran ezQuake and noticed it ran fine on my intel, so I dug through the source and found that it already had an Intel workaround.

And, of course, Rook had already implemented an Intel fix.

I think the ezQuake people should have made more noise about the Intel fix because I don't think that people who previously had problems would have any reason to expect ezQuake 1.8 worked whereas ezQuake build 1517 didn't.

So yeah, this turned out to be me rediscovering the wheel.

Regardless, I'm absolutely pleased that the Intel issue has been nailed once and for all.

/But at least I learned a great deal reverse engineering the problem.

[MH]

I think you'll get the most mileage out of gl_clear 1/gl_ztrick 0 with these cards. I've also had my own code working on Intel cards for quite some time, just by completely removing these two items (as well as the disc). An interesting experiment would be to just clear the Z buffer each frame, leaving the colour buffer alone (in most cases it's going to be completely overwritten by the 3D refresh anyway) - you can definitely get a few extra frames from doing this (always good to have if you're on an Intel).

The console bug is a new one to me though. Interesting stuff.