gamedevlists-windows — List for discussing game development on the Windows platform

Re: [GD-Windows] Omega Drivers? (shudder)

[Neil S. <ne...@r0...>]

If the problem really is just a case of the official drivers not cleaning up
enough to make a revert to (or reinstall of) them work properly, then it
would be good to give the IHVs a chance to fix this problem. It would give
the old "install the latest drivers" line a well-needed boost. ;)

Of course, you might still want to detect the situation so you can give the
user a clue what to try before he calls support.

- Neil.


----- Original Message -----
From: "Jon Watte" <hp...@mi...>
To: <gam...@li...>
Sent: Tuesday, June 17, 2003 12:43 AM
Subject: RE: [GD-Windows] Omega Drivers? (shudder)



> You should probably contact the Omega guy and see what (if any)
> info he can
> provide to find out how to detect that his modified drivers are running,

So here's the problem with these drivers:

We can detect whether the last installed drivers are the Omega drivers.

However, when the user "reverts" to original drivers, by installing on
top of the drivers, every measure that we've taken to detect what drivers
we're running on show "factory" drivers. However, the bad behavior (black
textures) still shows up. Something's gotten hosed somewhere in the
system (bets are: registry :-) and isn't getting un-hosed by installing
regular drivers.

Let's see if the Omega guy is talkative; I have a feeler out.

Cheers,

/ h+



-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU5

RE: [GD-Windows] Omega Drivers? (shudder)

[Jon W. <hp...@mi...>]

> And .. if you can figure it out, you might try to detect that on=20
> install or=20
> execution and ask the user if they want to fix it automatically ;)

Yes, that's the general gist of it. We already do this for common=20
problems like old Internet Explorer versions, missing codecs,=20
missing AGP chipset drivers, graphics driver versions with known=20
bugs, etc.

Cheers,

				/ h+

RE: [GD-Windows] Omega Drivers? (shudder)

[Tom H. <to...@ve...>]

At 04:43 PM 6/16/2003, you wrote:
>Let's see if the Omega guy is talkative; I have a feeler out.

It certainly sounds an awful lot like there's something changed in the 
registry / settings for the card. I'd bug the guy and see if you can find 
out what registry settings are being dorked with. This might end up being a 
simple fix where you have the end-user un-dork one setting in the registry 
or delete a config file somewhere.

You _might_ even be able to get NVIDIA dev support to help you find out 
what he's tweaking and help you figure out what needs to be done to repair it.

And .. if you can figure it out, you might try to detect that on install or 
execution and ask the user if they want to fix it automatically ;)

Tom

RE: [GD-Windows] Omega Drivers? (shudder)

[Jon W. <hp...@mi...>]

> The only other thing I can think of is to perform a set of=20
> correctness tests
> at the start of the app (or during a 'safe mode' startup of the app) =
to

This is actually not a bad problem, if the bug is consistent (i e=20
happens with specific textures, texture formats, or something to=20
that effect). If it's one of those random wild pointer type bugs=20
I'd be out of luck, but this is worth investigating.

> Although (d) could be seen as a non-issue ("if they work, then what's =
the
> problem?"), there are also cheating issues such as wireframe mode for =
FPS

The only things that matter in our product are made server-side=20
authoritative, so we luckily don't have that problem.

Cheers,

				/ h+

RE: [GD-Windows] Omega Drivers? (shudder)

[Jon W. <hp...@mi...>]

> You should probably contact the Omega guy and see what (if any)=20
> info he can=20
> provide to find out how to detect that his modified drivers are =
running,=20

So here's the problem with these drivers:

We can detect whether the last installed drivers are the Omega drivers.

However, when the user "reverts" to original drivers, by installing on=20
top of the drivers, every measure that we've taken to detect what =
drivers=20
we're running on show "factory" drivers. However, the bad behavior =
(black=20
textures) still shows up. Something's gotten hosed somewhere in the=20
system (bets are: registry :-) and isn't getting un-hosed by installing=20
regular drivers.

Let's see if the Omega guy is talkative; I have a feeler out.

Cheers,

				/ h+

Re: [GD-Windows] Omega Drivers? (shudder)

[Neil S. <ne...@r0...>]

I expect drivers must be signed in some way, even if they are not WHQL
certified. If they are signed by NVIDIA, ATI, etc., then there might be some
way to check that the certificate is valid. I don't know if this is easy or
even possible, but it might be the only reliable way of being certain you
are dealing with official drivers.

If there is no current way to do it, it might be possible to get the IHVs to
provide something in the future, especially if they also perceive this as a
serious problem that needs to be solved.

Pretty much any other method is going to be useless, as it will depend on
information that these 'alternative driver teams' can spoof easily.

The only other thing I can think of is to perform a set of correctness tests
at the start of the app (or during a 'safe mode' startup of the app) to
check that everything is working as expected. The problems with this are:

a) the tests are not guaranteed to find stuff that actually goes wrong in
the game (unless your game *is* the test)
b) some official drivers may fail the tests but otherwise be OK
c) user driver options such as texture performance will make the tests hard
to measure
d) the 'alternative' drivers may pass the tests and may even work fine in
your game.

Although (d) could be seen as a non-issue ("if they work, then what's the
problem?"), there are also cheating issues such as wireframe mode for FPS
games which these people may see fit to include, even though the IHVs have a
self-imposed ban on such things.

- Neil.


----- Original Message -----
From: "Jon Watte" <hp...@mi...>
To: <gam...@li...>
Sent: Monday, June 16, 2003 11:22 PM
Subject: RE: [GD-Windows] Omega Drivers? (shudder)

Re: [GD-Windows] C++ decorated names

[<cas...@ya...>]

Jon Watte wrote:
> I wouldn't assume that exception tables, RTTI, vtable layout,
> or even calling conventions would be the same between different
> C++ compilers. Basically, C++ in shared libraries is a really
> scary concept, because the standard didn't at all anticipate
> (or want to deal with) those issues.

That's scary, but after some little googling I've found some nice pieces of
info.

http://www.bcbdev.com/articles/vcdll.htm
http://mywebpage.netscape.com/yongweiwu/stdcall.htm

It seems that mingw has an option to support msvc vtable layout, so that you
can use COM objects. So, as long as you only export pure interfaces, you
should be safe.

However, I'm not on using pure interfaces only. I also use interface
inheritance and virtual destructors... I don't know how those affect the
layout of the vtables and if they will still be compatible. Does somebody
know what can and can't be done?


Ignacio Castaño
cas...@ya...

RE: [GD-Windows] Omega Drivers? (shudder)

[Tom H. <to...@ve...>]

At 03:22 PM 6/16/2003, you wrote:
>Would you say that if your customer support spent their evenings
>fielding support calls related to this issue? It's apparently the
>l33t in thing to do among all the top gamers these days.

I originally wrote a long tirade about how I hate that segment of the gamer 
community .. but decided it wasn't worth it ;)

>I wouldn't install these. You wouldn't. But alienating people who
>don't know as well as you or me doesn't feel like great business
>to me.

There's limits to how far you have to go to deal with this kind of stuff, 
and I'd certainly treat it on a case by case basis.

But really .. there's already enough driver specific issues out there that 
things like this just make things a living hell for the developer. Sadly, 
this has been going on for ages and will continue to happen.

>  Thus, I'm looking for a better solution. Extreme end: help
>the guy fix his drivers so they don't break our app ;-) Hopefully
>we won't have to do that.

Just let him know that things are screwed up. Maybe send him a copy of your 
game (demo?) for testing.

>Doing that on the phone, with a high loaded cost per call, is not
>ideal.

Agreed.

>I'd be happy with an automated way of detecting that this problem
>has happened, and re-directing to a web site, and prevent
>installation of the product until the problem is fixed. We already
>do that for other un-supported configurations, such as Voodoo3
>cards, and we're getting pretty good at managing that.

You could look for specific CRCs of the installed drivers, or compare file 
modification dates with known version numbers for the drivers.

You should probably contact the Omega guy and see what (if any) info he can 
provide to find out how to detect that his modified drivers are running, 
and what versions are in use. If they really appear as NVIDIA drivers, then 
I'm surprised that NVIDIA is going after him with both legal barrels 
blaring. Maybe if he isn't doing anything like this now, you can convince 
him to do it in the future.

Also ... I'd spend a great deal of time trying to educate the public 
through your own web site, and places like Voodoo Extreme, Blues News, etc 
about the hazards of installing these kinds of drivers. Not only to try to 
keep the end users from installing them, but also to explain the pain it 
puts developers through trying to deal with the support headaches the 
crappy things end up causing. I suspect you could probably get the various 
sites to run an article or two about it. The hope would be that the number 
of people that make these things might be reduced.

Tom

RE: [GD-Windows] Omega Drivers? (shudder)

[Jon W. <hp...@mi...>]

> >Our customers aren't entirely happy about this situation,
>=20
> Then they shouldn't be installing crap like this. I mean really,=20
> if someone=20
> is stupid enough to install hacked up drivers from a site like that, =
then=20
> they deserve what they get.

Would you say that if your customer support spent their evenings=20
fielding support calls related to this issue? It's apparently the=20
l33t in thing to do among all the top gamers these days.

I wouldn't install these. You wouldn't. But alienating people who=20
don't know as well as you or me doesn't feel like great business=20
to me. Thus, I'm looking for a better solution. Extreme end: help=20
the guy fix his drivers so they don't break our app ;-) Hopefully=20
we won't have to do that.

> Understandable, but I think the best you can do is offer your =
condolences=20
> tell them what you've learned must be done to rid themselves of the =
mess=20
> they've put themselves in, and send them on their way.

Doing that on the phone, with a high loaded cost per call, is not=20
ideal.

I'd be happy with an automated way of detecting that this problem=20
has happened, and re-directing to a web site, and prevent=20
installation of the product until the problem is fixed. We already=20
do that for other un-supported configurations, such as Voodoo3=20
cards, and we're getting pretty good at managing that.

> Hopefully it  won't be that common.

The reason I'm posting is that we're actually seeing a surprising=20
number of them. Has anyone else seen this? Are you, generally, in=20
close contact with the customer service/support people, or is that=20
something which you pawn off on the publisher, who in turn pawns it=20
off on a third-party contract call center somewhere, and issues=20
never make it back to engineering? I can see the appeal in that :-)

Cheers,

				/ h+

Re: std::vector::clear (was: [GD-Windows] VS.net rants, was Re: VC++ lag)

[Neil S. <ne...@r0...>]

> Or you could follow these simple steps:
> 
> 1. File a bug report with MS.
> 2. Use STLPort on all the platforms you support.
> 3. Let others know of the problem (and blast MS in the process if that's 
> what you feel like doing)
> 4. Get on with your life, write code, finish your game.

Only step 4 seems 'simple', so I think I'll do that, thanks.

- Neil.

Re: [GD-Windows] Omega Drivers? (shudder)

[Tom H. <to...@ve...>]

At 12:23 PM 6/16/2003, you wrote:
>Our customers aren't entirely happy about this situation,

Then they shouldn't be installing crap like this. I mean really, if someone 
is stupid enough to install hacked up drivers from a site like that, then 
they deserve what they get.

>  and
>neither are we.

Understandable, but I think the best you can do is offer your condolences 
tell them what you've learned must be done to rid themselves of the mess 
they've put themselves in, and send them on their way.

>  Does anyone have any brilliant ideas about what to
>do here? I'd be happy if I just knew how to detect that this
>problem is happening on the machine...

There's probably a way to do it by comparing modification dates and file 
sizes to version numbers or something.

As for removal .. you should be able to set the machine to the default VGA 
driver .. then delete all the offending files (though it might take a bit 
of searching to get all the copies, INF files, etc).

I suspect the best you could do is figure out a set of instructions for 
removal then email/fax that to customers who install the mess. Hopefully it 
won't be that common.

You should also contact ATI/NVIDIA and bring the site to their attention.

Also, I would contact the site itself and let them know that their 
modifications are broken and cause problems in your game and that customers 
are having problems removing their drivers and getting back to the 
ATI/NVIDIA ones. If they're really intending on helping people, then they'd 
probably take these things to heart and try to resolve them.

Tom

Re: std::vector::clear (was: [GD-Windows] VS.net rants, was Re: VC++ lag)

[Tom H. <to...@ve...>]

At 02:14 PM 6/16/2003, you wrote:
>So write your own, boys and girls, because the lunatics took over the
>asylum.

Or you could follow these simple steps:

1. File a bug report with MS.
2. Use STLPort on all the platforms you support.
3. Let others know of the problem (and blast MS in the process if that's 
what you feel like doing)
4. Get on with your life, write code, finish your game.

Tom

Re: std::vector::clear (was: [GD-Windows] VS.net rants, was Re: VC++ lag)

[Neil S. <ne...@r0...>]

> Right.  This is why I was saying you should do resize(0) if you want
> to retain the memory.  I'm not a C++ language lawyer, but resize(0)
> more explicitly tells me as a reader of the code that they wanted to
> retain the current allocation but forget all the elements.  clear() to
> me says that its OK to delete the current allocation as well as forget
> all the elements.

Well, if you have followed the last few messages on this subject, you will
be aware that doing resize(0) is also no use (in terms of avoiding
allocation & deallocation), as there is nothing in the standard that says
that the implementor cannot realocate the memory elsewhere, so long as
capacity() is greater or equal to what it was previously. You might say that
it's illogical for them to do that, but I would have said that (and still
*do* say that) about making clear() deallocate, and I'm far from the only
one.

Oh, and they can format drive C while they're at it. ;)

So write your own, boys and girls, because the lunatics took over the
asylum.

- Neil.

RE: [GD-Windows] Omega Drivers? (shudder)

[Jon W. <hp...@mi...>]

> In article <HEE...@mi...>,
>     "Jon Watte" <hp...@mi...>  writes:
>=20
> > Our customers aren't entirely happy about this situation, and=3D20
> > neither are we. Does anyone have any brilliant ideas about what =
to=3D20
> > do here? I'd be happy if I just knew how to detect that this=3D20
> > problem is happening on the machine...
>=20
> I'd report the problem to the original vendor of the driver.  Surely
> they didn't make their driver license open to modifications without
> their consent?

I believe the web site is outside of the jurisdiction of the=20
country that the vendor is operating it. I e, I believe the=20
companies are ATI (Canada) and NVIDIA (US) and the web site=20
might be in Russia.

The web really DOES change the behaviour of information, no=20
matter what you do to the laws...

Cheers,

					/ h+

RE: [GD-Windows] C++ decorated names

[Gareth L. <GL...@cl...>]

Use extern "c" and don't try to mix C++ like that :)

> -----Original Message-----
> From: Ignacio Casta=F1o [mailto:cas...@ya...]
> Sent: 16 June 2003 20:29
> To: gam...@li...
> Subject: [GD-Windows] C++ decorated names
>=20
>=20
> Hi,
> I'm building a few dlls with both msvc and mingw. Both work=20
> fine, but the
> name of the dll exports of the C++ methods is different, so I=20
> cannot mix the
> dlls. Does somebody knows if it's possible to change the name=20
> generation
> scheme on msvc or mingw, to match the other?
>=20
> Thanks in advance,
>=20
> Ignacio Casta=F1o
> cas...@ya...
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.NET email is sponsored by: eBay
> Great deals on office technology -- on eBay now! Click here:
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=3D555
>=20

Re: [GD-Windows] Omega Drivers? (shudder)

[Rich <leg...@xm...>]

In article <HEE...@mi...>,
    "Jon Watte" <hp...@mi...>  writes:

> Our customers aren't entirely happy about this situation, and=20
> neither are we. Does anyone have any brilliant ideas about what to=20
> do here? I'd be happy if I just knew how to detect that this=20
> problem is happening on the machine...

I'd report the problem to the original vendor of the driver.  Surely
they didn't make their driver license open to modifications without
their consent?
-- 
"The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ:
          <http://www.xmission.com/~legalize/book/>
        izfree: Open source tools for Windows Installer
                <http://izfree.sourceforge.net>

RE: [GD-Windows] C++ decorated names

[Jon W. <hp...@mi...>]

I wouldn't assume that exception tables, RTTI, vtable layout,=20
or even calling conventions would be the same between different=20
C++ compilers. Basically, C++ in shared libraries is a really=20
scary concept, because the standard didn't at all anticipate=20
(or want to deal with) those issues.

Cheers,

				/ h+



> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Ignacio Casta=F1o
> Sent: Monday, June 16, 2003 12:29 PM
> To: gam...@li...
> Subject: [GD-Windows] C++ decorated names
>=20
>=20
> Hi,
> I'm building a few dlls with both msvc and mingw. Both work fine, but =
the
> name of the dll exports of the C++ methods is different, so I=20
> cannot mix the
> dlls. Does somebody knows if it's possible to change the name =
generation
> scheme on msvc or mingw, to match the other?
>=20
> Thanks in advance,
>=20
> Ignacio Casta=F1o
> cas...@ya...
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.NET email is sponsored by: eBay
> Great deals on office technology -- on eBay now! Click here:
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=3D555
>=20

[GD-Windows] Omega Drivers? (shudder)

[Jon W. <hp...@mi...>]

We've recently noticed that there's a brand of hacked-up graphics=20
drivers known as "Omega Drivers" (from omegacorner.com) which are=20
regular vendor drivers, hacked up to "make them better".

Well, they don't. In fact, they cause textures in our product to=20
come up black. What's worse: once installed, even an uninstall and=20
clean vendor driver install won't cure the problem; you have to=20
format and reinstall Windows, or use a safe-mode-only special=20
utility to clean out the problem.

Our customers aren't entirely happy about this situation, and=20
neither are we. Does anyone have any brilliant ideas about what to=20
do here? I'd be happy if I just knew how to detect that this=20
problem is happening on the machine...

Cheers,

                    / h+


--
  I am speaking only in the capacity of myself and am=20
  not representing any company or organization.
  Jon Watte - http://www.there.com/

  "Q: Why did the chicken cross the Moebius Strip?
   A: To get to the same side."

[GD-Windows] C++ decorated names

[<cas...@ya...>]

Hi,
I'm building a few dlls with both msvc and mingw. Both work fine, but the
name of the dll exports of the C++ methods is different, so I cannot mix the
dlls. Does somebody knows if it's possible to change the name generation
scheme on msvc or mingw, to match the other?

Thanks in advance,

Ignacio Castaño
cas...@ya...

RE: [GD-Windows] Re: VS.net rants, was Re: VC++ lag

[Jon W. <hp...@mi...>]

> >This one shows up multiple times -- answer: double-click on a=20
> result in find-
> >in-files window to start things going, then f8. Dunno why it=20
> works differently=20
> >now, but it still does work.

This means you have to click in the window. That means=20
reaching for the mouse. How do I do this without the mouse?

Cheers,

				/ h+

Re: [GD-Windows] Re: VS.net rants, was Re: VC++ lag

[Rich <leg...@xm...>]

Got this back through the MVP forum:

>> [2] Keyboard shortcuts: I was so used to doing a "Find in Files" in VC6
>> and then stepping through the reuslts with F4. Why did they have to take
>> that away? Now I *have* to use the mouse to step through search results,
>> because F4 is exclusive to the compiler output list.
>
>This one shows up multiple times -- answer: double-click on a result in find-
>in-files window to start things going, then f8. Dunno why it works differently 
>now, but it still does work.

-- 
"The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ:
          <http://www.xmission.com/~legalize/book/>
        izfree: Open source tools for Windows Installer
                <http://izfree.sourceforge.net>

Re: std::vector::clear (was: [GD-Windows] VS.net rants, was Re: VC++ lag)

[Rich <leg...@xm...>]

In article <005e01c33214$9c9b8b40$0100a8c0@r0x0rz>,
    "Neil Stewart" <ne...@r0...>  writes:

> 2. While the standard does not appear to say that erase() must not
> deallocate memory, it very explicitly states that insert() will allocate
> memory if required, and it is also very clear that resize() and reserve()
> should never reduce capacity() (i.e. deallocate memory).

Right.  This is why I was saying you should do resize(0) if you want
to retain the memory.  I'm not a C++ language lawyer, but resize(0)
more explicitly tells me as a reader of the code that they wanted to
retain the current allocation but forget all the elements.  clear() to
me says that its OK to delete the current allocation as well as forget
all the elements.
-- 
"The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ:
          <http://www.xmission.com/~legalize/book/>
        izfree: Open source tools for Windows Installer
                <http://izfree.sourceforge.net>

RE: std::vector::clear (was: [GD-Windows] VS.net rants, was Re: VC++ lag)

[Neil S. <ne...@st...>]

> It does specify the runtime behavior of push_back(), and it specifies 
> what program-visible state (using the standards library) is changed 
> through the function. If the contents of drive C is not program 
> visible using only the standards libraries, and you can format that 
> in the expected amortized runtime of push_back(), then that would be 
> a conformant (though useless) implementation.

So it seems like the best thing you can do is give up any hope of this
ever being sorted out and just write your own containers, and pretty
much everything else. What a waste of effort...

> Anyway, C++ is the new COBOL.

How do you figure?

- Neil.



________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs Email
Security System. For more information on a proactive email security
service working around the clock, around the globe, visit
http://www.messagelabs.com
________________________________________________________________________

RE: [GD-Windows] Re: VS.net rants, was Re: VC++ lag

[Tom F. <to...@mu...>]

> From: Enno Rehling [mailto:en...@de...]

[snip]

> Yes, it can. Options/Environment/Projects_and_Solutions has a 
> checkbox for 
> "Track Active Item in Solutions Explorer". Not sure if it had 
> that in the 
> first one, but it's in 2003.

This is new for 2003 - added by popular demand!

[snip]
> In the same Option dialog, "Show Task List window if build 
> finishes with 
> errors", seems to be new with 2003.

That one is in 2002.

> Enno.


Tom Forsyth - Muckyfoot bloke and Microsoft MVP.

This email is the product of your deranged imagination,
and does not in any way imply existence of the author.

Re: [GD-Windows] Another VC problem

[Mickael P. <mpo...@ed...>]

Pierre Terdiman wrote:
>> I assume you installed Service Pack 3 of W2K,
>
> Yes.
>
>> and the Service Pack 5 of VSS
>
> Do you mean of VC ? Then yes.

Oups, yes, MSVC, not VSS ;)

Well, then I have absolutely no idea :)

Are you sure your Norton is recent and works fine under W2K ?
I know we've got a hell lot of troubles with the old version of McAffe when
W2K was released, and we had to wait 6 month before having a version that
work fine. Same for firewalls and things like this (close from system I
mean).

Are you using things like VisualAssist, Workspace Whiz, Windows Tabs ?