I should have continued & stated that this seems like prime Dev Center, Tech Note, reademe, release note material ...
At 2:31 PM -0700 8/2/02, you wrote: >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!] [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!]
