I suggested qsort simply because it would require no coding to make it b/c it is already made. If you have the time to write a sort, use radix i guess.
I suggested qsort simply because it would require no coding to make it b/c it is already made. If you have the time to write a sort, use radix i guess.
I actually think quicksort will be fine in this case. Z depth sorting is done once per frame so it's not necessarily the great bottleneck. If you were doing a sort once per polygon I'd have to insist on radix.
I'll probably eventually go with a radix sort (all of my values are positive, it's a 2d-hex tile game (simulated 3d)).
I've profiled my original generic little bubble sort on my laptop (read: my low-end, p2 233mhz 4MB vidram system) and there was no noticeble slowdown.
I say probably because this isn't an optimization that requires immediate attention, nor will it be much trouble to change it later (since it just involves changing one algorithm in a single function that will still take the same parameters and return the same result regardless of which sort I use).
Thanks again for all the suggestions.
Last edited by jdinger; 08-06-2002 at 04:01 PM.
Why not compare all the options? Here's a simple way to do it:
Overload the algorithms with - say - 100 to 10,000 times normal load. Before each sort begins:
start = clock();
RadixSort();
stop = clock();
radixTime = (stop - start) / 1000;
printf("Radix Sort Time Was %d Seconds.", radixTime);
...this would give you a good idea of which is superior...
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
