DirectX9 Beta3 released

Status
Not open for further replies.
DaveBaumann said:
Sorry - DC's post sticks out a little since it was a reply to a post that I removed that wasn't really of any value to the thread itself.
I see. So Derek talking about his IQ (irrelevance quotient), how many games he has made, his alleged Ph.D., the people who post here, and pretty much everything else, is right on topic? How about his comment about glue sniffing?

If moderators are going to go around and delete off-topic posts, they should do so indiscriminately.

Any time Derek makes a post, you can be sure that he'll have to bring up his opinions on ATi's driver quality. How is this suddenly relevant to every thread?

-FUDie
 
If moderators are going to go around and delete off-topic posts, they should do so indiscriminately.

Oh, this thread has had had a whole meriad of posts, from Derek and others, already but they've been removed because they served no useful purpose to the thread other than snipe at various people.

If Derek in his previous post wants to lord his credentials over everybody then thats not doing anyone any harm (other than making Derek sound like a bighead! ;) ) and there were some on-topic points there. Your previous post was purely there to attack Derek and served no useful purpose in this thread.

If posts are made attacking another person then we will do as we see fit to attempt to get the thread back on topic.

I've asked John to draw up a forum policy however, I'm saddened that I should even need to.

Now, please, can we get back on topic?
 
Dave,
I would argue that if someone's argument can't be accepted on the merits or logic of it and they must inject credentials into it, then other people are justified in subjecting those credentials to critique.

Imagine the following:

Code:
A implies B
A is true
Therefore B

Opposition: Why is A true?

Answer: Because I am a Phd and have an IQ close to God.

Opposition: Argument by authority. Where do your Phd come from?

Answer: Can't tell you.

Opposition: Can we see some of your published papers on your thesis?

Answer: Topsecret/codeword


I mean, I don't think it is a personal attack on Derek to ask these questions, after all, he brought his credentials into it. I have no wish to bash Derek. Other people have wasted way more time on it. Derek has done some respectible things and put in some hard work on his games, so I'll focus only on what he *has achieved* (as opposed to claims of brilliance or talking the talk) But none of that absolves a person from having to present a well reasoned argument and refrain from ad hominen, argument via authority, etc


Yes, part of the problem is other people in these forums feeding the fire, but Derek in many cases, starts the fire by responding to any disagreement with condescension and reference to his credentials. It's possible to respond to disagreement by writing a short, concise, logical reply containing mostly facts. Responding with "Your wrong, because I am a God" is not conducive to a discussion, which is the whole point of having a discussion forum.


The most egregious problem is the assumption that no one in this forum has credentials of similar caliber. We know that there are dozens of devs and hardware engineers in these forums who have shipped games and products, but who prefer anonymity and don't bring their supposed "expertise" as a hammer into discussions. ERP and Fafalada for example are well known console developers for example, but I have rarely to never seen them speak about their games or use their job as a way to win an argument.

Civil discussion is possible. My point is, if you try to inject your own hyper-intelligence or super-education into the argument as an authorative fact that backs up the foundation of an argument, then opposition has the right and logical imperative to fact-check those assertions.
 
Derek Smart [3000AD said:
]

LOL!!! Thats what glue sniffing will do to you :D :D :D
Yeah.. and flour and water are really difficult to get out of a nostril.
 
SirPauly said:
I read the whole post of DemoCoder thinking he was talking about IQ as in Image Quality

LOL!! Sorry, but this is truly funny from Humus.:)
must be a Euro thing, because so did I at first!

hmm

Oh and please people - whats good for consumers in drivers is different to whats good for developers.

Its no good telling everyone how great your games run when a developer is looking at a mess on screen as he is building his game!

The games that run great have already on the whole been worked around.
 
Simon F Wrote:

Derek Smart [3000AD] wrote:


LOL!!! Thats what glue sniffing will do to you

Yeah.. and flour and water are really difficult to get out of a nostril.

Yeah, add an egg and you end up getting battered, crime these days...
 
JohnH said:
Simon F Wrote:

Derek Smart [3000AD] wrote:


LOL!!! Thats what glue sniffing will do to you

Yeah.. and flour and water are really difficult to get out of a nostril.

Yeah, add an egg and you end up getting battered, crime these days...

ahahahaha!! You should be flogged for that corny, albeit funny, line!! :D :D
 
Derek,

(serious now) interrestingly enough the problem with clipping identical geometry that is submitted with different primitive types came up a while back for us. Basically triangle lists vs strips/fans can result in a different submission order, now if the HW doesn't place vertices at the input to the clipper in a consistent spacial order (irrespective of vertex submission order) then it will exhibit exactly the problem described as the clipper will produce slightly different results in each case. So, to me, sounds like they've got a small unwanted "feature" in their HW. I don't think we were able to come up with a good driver workaround for this so we just fixed the HW, might be a bit tough on the 9700 though...

Basically, I guess what I'm saying is that everyone always beets on the driver writers when there's a problem, and often it seems to be valid as subsequent releases fix problems. However whats really happening is that the driver writers are often having to work around deficiencies/bugs in the HW, its not true all the time but it does happen an awful lot.

Hang on, can anyone remember what was this thread about originally, something about making batter pudding and the dangers of getting it stuck up your nose...

John.
 
JohnH said:
Basically, I guess what I'm saying is that everyone always beets (simon: What's Kristof got to do with it?) on the driver writers when there's a problem, and often it seems to be valid as subsequent releases fix problems. However whats really happening is that the driver writers are often having to work around deficiencies/bugs in the HW, its not true all the time but it does happen an awful lot.
Bugs in HW, John? What on earth are you saying?
Hang on, can anyone remember what was this thread about originally, something about making batter pudding and the dangers of getting it stuck up your nose...
And I thought it was a Goon Show script
 
DaveBaumann said:
JohnH said:
So, to me, sounds like they've got a small unwanted "feature" in their HW.

I thought these types of things were referred to as 'Undocumented Features'. ;)

Nah, to the rest of the sane free world, its just a bug. Whether its in the HW or in the driver, is irrelevant. A bug is a bug is a bug.
 
JohnH said:
Derek,

(serious now) interrestingly enough the problem with clipping identical geometry that is submitted with different primitive types came up a while back for us. Basically triangle lists vs strips/fans can result in a different submission order, now if the HW doesn't place vertices at the input to the clipper in a consistent spacial order (irrespective of vertex submission order) then it will exhibit exactly the problem described as the clipper will produce slightly different results in each case. So, to me, sounds like they've got a small unwanted "feature" in their HW. I don't think we were able to come up with a good driver workaround for this so we just fixed the HW, might be a bit tough on the 9700 though...

Indeed. And to think that it worked fine on all HW, but my only solution (until these recent drivers) was to, yet again, add another workaround in my code for ATI HW. Thats the thing that irks me the most. I've had so many ATI specific code (not additional features, as one would think e.g. Truform) in my code at some point or another, its just plain silly.
 
I don't mean this as some sort of absolute excuse ATi driver development in the past, but I do mean it to clarify the accuracy of your statement:

What cards were in your development machine when you first wrote the code for which you later had to write "work arounds"? I mean historically, since you allude to this as a long standing situation.
 
demalion said:
I don't mean this as some sort of absolute excuse ATi driver development in the past, but I do mean it to clarify the accuracy of your statement:

What cards were in your development machine when you first wrote the code for which you later had to write "work arounds"? I mean historically, since you allude to this as a long standing situation.

My primary dev machine has hosted all manner of cards. When the 8500 came out, I replaced the GF3 with it. Then when the 9700 came out, I replaced the 8500.

It worked fine with the 7500/8500 and every other video board. Then came the 9700 and it didn't work.

Why are you asking?

Don't even THINK of starting an argument about this because I can just see where this is going. It was a FRIGGING bug. OK? Thats it. They've fixed it.

Earlier today, while I was composing email to send to them asking them to tell me exactly what is fixed in these drivers and that this problem seems to have been fixed, I uninstalled these drivers, put back in the previous 777 - 6178 set and the problem came back.

And its not the first time crap like this is happening either. Send me on wild goose chase for weeks on end, looking for something thats supposed to be in my code. Then a driver release shows up and fixes it.
 
Send me on wild goose chase for weeks on end, looking for something thats supposed to be in my code. Then a driver release shows up and fixes it.

It strikes me that it could well be your code (as well as the code in other titles that have similar issues, thus needing this fix) however ATI have had to patch it in the driver to meet then demands of gamers - perhaps the most desired/optimal route as far as ATI are concerned would be to have the game code changed to better suite their hardware but they have to do it the less optimal way and stick a change in the driver to stop titles exhibiting the issue.

Again, for the other titles that have been fixed this just seems to be the old GF3/4 is developers primary development platform issue.
 
Changing the primitive type shouldn't affect how the scene looks at all. I don't think you can blame developers for that one.
 
Crusher said:
Changing the primitive type shouldn't affect how the scene looks at all. I don't think you can blame developers for that one.
How the scene looks to the eye and how the scene looks to the hardware are completely different things.
 
Crusher said:
Changing the primitive type shouldn't affect how the scene looks at all. I don't think you can blame developers for that one.

That's silly, of course it can. If an array of vertices is sent down, meshing up a surface, the same vertices using a t-fan or t-strip will be interpreted differently by the hardware. The triangle (v0,v1,v2) is not the same as (V1,V2,V0). How can the hardware decide which is the "correct" triangle? When clipping, the clipping algorithm will be applied to the two triangles (same vertices) in a different way, and slight numerical errors will show up. Having a large guard band can limit the effects of this.

If you want the same exact geometry, you need to send exactly the same vertices, in exactly the same order (which also implies the same primitive type). Otherwise, you might need to offset the next set of geometry, if you want it guaranteed "above or equal", or use multi-texture, or some other method.

Same thing applies to colinear geometry -- There's no guarantee it will be in the same plane as the previous geometry -- Numerical errors, even slight ones (can translate to small single bit sometimes) differences.
 
Status
Not open for further replies.
Back
Top