Is it just me, or are Matrox GL drivers utterly useless?

I’ve got this simple game, see, and after about 9 public alphas, it works on just about every proper OpenGL compatible system there is. Unfortunately not Voodoo yet but they’ve got known dubious drivers so I’m not so bothered. And to get it to work on Intel chipsets I’ve had to remove my display list code because they simply don’t work. (Are they allowed to get away with that and still call it OpenGL compatible? I don’t think so…)

One thorn remains in my side. Matrox.

Most of the scene renders correctly. But none of the sprites. They’re just … blank.

Well, some of them are, and some of them aren’t. They’re by and large rendered with GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA; they were constructed using GL_RGBA images and put into GL_RGBA destination textures. They’re rendered appropriately on all sorts of different specs using VAR, glDrawRangeElements, glDrawRangeElementsEXT, glDrawElements and glLockArraysEXT. They’ve got vertex, colour, and texture coordinates, no normals. There’s no depth buffer or face cullings. They’re all quads.

And still I can’t get a Matrox card to render them. AAAAARGH!

How on Earth do I get to the bottom of this? I’m not getting error states or anything. Just … strange results which are different from everyone else’s cards.

Cas

Are you talking about the older cards or the newer Parhelia?

Have you talked to Matrox about this?

Hi Cas-

Do you have a simple app you can send me that can reproduce your display list problems? If not, can you send me a link to your alpha with display lists enabled on Intel graphics?

I’ll be happy to take a look at it to see if I can figure out what’s going on.

Thanks,
– Ben

Hi Ben,
could you download Alien Flux from http://www.puppygames.net/downloads/AlienFlux.zip and give it a go.

I’ve removed the display list code from it which makes it work on the Intel chipsets - haven’t the time to put it back in I’m afraid.

Matrox cards are the only cards I can’t get it to work on now. Unfortunately I’ve never seen it running on Matrox in the flesh so I don’t really know for sure but I’ve heard descriptions of the problem and seen a screenshot.

Apparently the cute fluffy blobs are visible for just a moment and then vanish. What this looks like to me is that I upload some more textures at that point and then you discard the existing ones for some reason.

(To see what it’s meant to look like just run it on some Nvidia or ATI rig)

TIA,
Cas

Originally posted by cix>foo:
Unfortunately not Voodoo yet but they’ve got known dubious drivers

When trying my code on Voodoo cards, I found out that every time there was a bug, it was caused by myself. In my opinion Voodoo drivers are not that dubious, they just “stick too much” to the sepcs. I mean that I had some code that for example should not be between glbegin/end, or stuff like that. After correction, everything run smoothly.

Originally posted by tfpsly:
When trying my code on Voodoo cards, I found out that every time there was a bug, it was caused by myself. In my opinion Voodoo drivers are not that dubious, they just “stick too much” to the sepcs. I mean that I had some code that for example should not be between glbegin/end, or stuff like that. After correction, everything run smoothly.

That’s nice but you should be using glDrawElements or better.

BTW, Voodoo shut down a long time ago.

Originally posted by cix>foo:
I’ve removed the display list code from it which makes it work on the Intel chipsets - haven’t the time to put it back in I’m afraid.

It’s the problems you’re seeing on Intel chipsets that I’m interested in (I don’t have a Matrox either ).

Do you have an earlier version available that doesn’t have display lists disabled?

Thanks,
– Ben

hi Cas,

it’s not you. it’s the matrox GL driver.
i have never seen a stable GL driver for matrox cards. the best one did run for 10 min. and crashed everytime after this time.
(G400)

i simply do not suggest to use any matrox card for openGL. this company seems to focus theirs driver development on DirectX drivers only.

usualy, our hotline-answer for frustrated matrox users(gamers) is: buy any other card.

don’t get me wrong. the matrox cards have excelent display quality but their GL support is horrible…

Originally posted by V-man:
[b] That’s nice but you should be using glDrawElements or better.

BTW, Voodoo shut down a long time ago.[/b]

Of course I’m doing so =)

That was just an example, I do not remember exactly what the mistake was, but I do remember it was something that was breaking the specs. So the drivers was “correct”. It was just that other cards’ drivers did not complain about the bug so I did not see it previously.

Ben - no, I’m afraid the DL code is deleted now and I haven’t got the time to dig it back up and do a rebuild right now. Maybe when I get back from hols at the end of the month.

Cas

I haven’t seen more problems with Matrox drivers than with other drivers. Also, once I could isolate the issues and send a report to Matrox devrel with reproducible test cases, they weren’t any slower to fix things than other vendors.

Granted, this was for the Parhelia; I had all kinds of issues with a G400/RT-2000 video editing system a few years back, but from what I gather, that’s an entirely different product and, because of the complexity of Adobe Premiere, not a fair comparision at all.

When I 1st learned GL, I tried to render some textured quads on a G200, and it wouldn’t clip the vertices correctly. I had to use triangles instead, or the uv’s completely messed up.

Yeah, I had a G200 too. My first card that accelerated GL and it was pretty sweet but too many bugs (no clipping problems but texgen and a few other bugs). Driver updates introduced more bugs …

I did send a a couple of bug reports but no answer. Then a representative posted a message on the board that they will not be updating drivers for all cards previous to the G400.

Forget it my friend, they are not the best.