I have to disagree Tom (& I certainly know & understand the semantics involved in labelling something a bug)
In this case, however, one of the primary premises of working in 3D space is that nearer objects render in front of further objects This fails that primary premise. my 2 cents -Buzz At 1:48 PM -0700 8/2/02, you wrote: >Evan, > >> Just because developers understand a problem with an application, it >> doesn't necessarily mean it's not a bug with the application, >> does it? > >A bug is defined as _unexpected_ behavior, the semi-transparent >rendering problems are completely expected based on our particular >z-sorting algorithm. If instead we were of the opinion that it >shouldn't happen but it does, thus making this unexpected behavior, >then it would be logged as a bug. Our sorting algorithms are working >just as expected, the problem here is that they are not working just >as you (or others) desire and that is the critical difference >between this being a bug versus a feature request. > >NOTE: being as most folks don't know our sorting algorithms the >first and most natural instinct is to say "bug!", but I do have the >additional knowledge necessary and felt I'd share the fact that this >is an implementation limitation and not a bug. > >> Sure his algorithm is working as expected: it's losing money. >> And it's still incorrect for your broker to use an algorithm. > >Yes, it's incorrect for the broker to use the algorithm but you >wouldn't say the algorithm is behaving unexpectedly would you? In >fact you state that it's working as expected yourself (buying high >and selling low just like it was made to do) so the algorithm itself >is fine, the choice to use it is the problem for you (and me too if >that's my broker!). In our case our z-sorting algorithms are working >as expected (z-sorting on a model level), you disagree with our >choice to use it thus I label it as a feature request: change your >z-sorting algorithm, it's working as expected (now that Tom told me >how you z-sort - on a model level) but just not how would like it to. > > >Two final points: > >1. Bug vs. feature request is not a factor in determining the >importance of fixing such an "issue", we'd look at the user impact >and move from there, the classification is largely a semantics issue. > >2. My use of the word "incorrect" in my summary was coming from >_your_ perspective, the end user doesn't care whether it's expected >or not, it's just that polys that are behind other polys render in >front and that's "incorrect" based on your eyeball level experience >without knowing the code. I'll refrain from summarizing a bug or >feature request from your point of view to avoid further confusion. >;) > >Cheers, >Tom > > >[To remove yourself from this list, or to change to digest mode, go >to http://www.penworks.com/lingo-l.cgi To post messages to the >list, email [EMAIL PROTECTED] (Problems, email >[EMAIL PROTECTED]). Lingo-L is for learning and helping with >programming Lingo. Thanks!] [To remove yourself from this list, or to change to digest mode, go to http://www.penworks.com/lingo-l.cgi To post messages to the list, email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED]). Lingo-L is for learning and helping with programming Lingo. Thanks!]
