• Content count

  • Joined

  • Last visited

Community Reputation

379 Neutral

About Melekor

  • Rank
  1. Big integer (128 bit++)

    I had this same idea back in 2001 I actually got some code working to enumerate all images of a given size, but quickly found out that it was far too slow.. and is usless without a way to automatically screen out the good images. I also thought about enumerating different JPEG files, since they are a lot smaller, but that was pretty far beyond my abilities at the time. Now that I think about it 10 years later, conjuring images out of nothing is still a tantalizing idea. If I were to try it again today, instead of enumeration I would work backwards: start with some metrics/statistics for what an image looks like, then treat it like an optimization problem - do hill climing until the objective function says you have a 'good' image. I suppose it doesn't need to start with an empty image either, you could seed it with anything. An interesting experiment might be optimizing a cartoon image into a natural (photographic) one or vice versa. (Sounds like an interesting thesis project )
  2. Anyone remember this site?

    Yup, that's it! Thanks! I agree there is a nintendo bias, I guess somehow the membership is not approximating random sample of the internet. In theory it's a good idea though. The most surprising thing to me is mass effect 2 at #2, wow! IMO ME2 is to ME1 as 'reloaded' is to the matrix.. Anyway, thanks again.
  3. Anyone remember this site?

    About a year or so ago I found this cool site where you could create your own top 10 game list (or top N, don't remember exactly) list for each platform or genre. The site would then aggregate all the user lists together to create global rankings. I thought this was pretty cool and arguably more useful than critic based rankings like metacritic. Lost my bookmarks a while back and Google is utterly failing me here, so I was wondering if anyone remembered the URL for this site. Thanks in advance.
  4. Hi Momoko Fan, Thanks for the reply. That code seems to be converting from the newer EAXREVERBPROPERTIES structure (I guess since it is defined as float[28] which matches size, and the code looks right too). I need to convert from the small structure described in the OP. I did find this:, which confirms fVolume<=>flGain and fDecayTime_sec<=>flDecayTime. It also assigns fDamping directly into flDecayHFRatio, but I'm not sure if this is correct because it still sounds a bit different than it does under dsound.
  5. Also, if anyone could suggest a forum or mailinglist where someone might be more likely to know the answer, that would be appreciated too.
  6. I have an old game that uses the old EAX 1.0 reverb parameters for DirectSound: typedef struct { unsigned long environment; // 0 to EAX_ENVIRONMENT_COUNT-1 float fVolume; // 0 to 1 float fDecayTime_sec; // seconds, 0.1 to 100 float fDamping; // 0 to 1 } EAX_REVERBPROPERTIES; I'm rewriting it with OpenAL's EFX EAX extension and I'd need a method to convert the old parameters into the new ones (see below) so that it sounds the same (or as close as possible). I can use the "environment" member in the old struct to fill in most of the members in the new struct (using the table of pre-defined environments in OpenAL's EFX-util.h), and I guess fVolume and flGain go together (correct?), as well as fDecayTime_sec and flDecayTime. But fDamping doesn't seem to have an obvious correspondence, and I don't know what most of these parameter names actually mean. Does anyone know how to do this conversion? This is the new structure: typedef struct { float flDensity; float flDiffusion; float flGain; float flGainHF; float flGainLF; float flDecayTime; float flDecayHFRatio; float flDecayLFRatio; float flReflectionsGain; float flReflectionsDelay; float flReflectionsPan[3]; float flLateReverbGain; float flLateReverbDelay; float flLateReverbPan[3]; float flEchoTime; float flEchoDepth; float flModulationTime; float flModulationDepth; float flAirAbsorptionGainHF; float flHFReference; float flLFReference; float flRoomRolloffFactor; int iDecayHFLimit; } EFXEAXREVERBPROPERTIES, *LPEFXEAXREVERBPROPERTIES; Thanks, Mel
  7. [C++/Win32] Can't stop!

    I believe I was the first one to mention that possibility.
  8. [C++/Win32] Can't stop!

    Just wanted to add that while your problem may or may not be thread related, simply having other threads running cannot cause the process to not exit. This is because after WinMain returns, and after the C runtime library has done its cleanup, ExitProcess is called. ExitProcess doesn't care how many threads you have running. Quote:From MSDN The ExitProcess function ends a process and all its threads.
  9. [C++/Win32] Can't stop!

    Click the pause debug command and see what is executing. WinMain isn't the very last thing, there is a bunch of stuff below that. For example, destructors of globals are called after main returns. You might have an infinite loop or a deadlock in one of those.
  10. Efficient way to find same pixel?

    Quote:Original post by swiftcoder The typical std::sort implementation is quicksort [with an average case of O(N log N)], and fallbacks to heap sort for bad cases, yielding a worst case of O(N log N) as well. By contrast, radix sort is always O(k N), where k is the number of bits in the key. Therefore Radix sort performs better than std::sort then when log(N) is greater than k. For 8-bit RGBA pixel data, k=32, so we need log(N) > 32. For a given base, b, than means we need N > b^32, and for pretty much any value of b, that is a darn big number. Correct me if I am reasoning incorrectly, but that makes std::sort faster for most any reasonable image sizes. Well, strictly speaking radix sort performs better when c * log(N) > k, for some unknown constant c. But let's ignore that for now. The most important thing is that k in O(k N) isn't the number of bits, it's the number of digits. We can split the keys into any number of digits we think would be most advantageous. For example with 32 bit integers, we can write them in base 2048 (11 bits for each digit) so that k = 3. (This is what is implemented in the above code.) Now radix sort is starting to look much better isn't it?
  11. Efficient way to find same pixel?

    OK, here are the results: Quote:Total time elapsed to sort 64 MB of random 32-bit integers 5 times: std::sort: 3.71s RadixSort: 1.50s Conclusion: RadixSort is the winner (2.48x as fast as std::sort) And the source code: #include <cstdlib> #include <cstring> #include <cstdio> #include <algorithm> typedef unsigned int uint; typedef unsigned int uint32; typedef const char *cpointer; #include <windows.h> // radix sort code based on // #define _0(x) (x & 0x7FF) #define _1(x) (x >> 11 & 0x7FF) #define _2(x) (x >> 22) static void RadixSort11(uint32 *data, uint32 *sorted, uint32 count) { unsigned int i; // 3 histograms on the stack: const uint32 kHist = 2048; uint32 b0[kHist * 3]; uint32 *b1 = b0 + kHist; uint32 *b2 = b1 + kHist; memset(b0, 0, sizeof(b0)); // 1. parallel histogramming pass // for (i = 0; i < count; i++) { uint32 x = data[i]; b0[_0(x)] ++; b1[_1(x)] ++; b2[_2(x)] ++; } // 2. Sum the histograms -- each histogram entry records the number of values preceding itself. { uint32 sum0 = 0, sum1 = 0, sum2 = 0; uint32 tsum; for (i = 0; i < kHist; i++) { tsum = b0[i] + sum0; b0[i] = sum0 - 1; sum0 = tsum; tsum = b1[i] + sum1; b1[i] = sum1 - 1; sum1 = tsum; tsum = b2[i] + sum2; b2[i] = sum2 - 1; sum2 = tsum; } } // byte 0: read/write histogram, write out flipped for (i = 0; i < count; i++) { uint32 x = data[i]; uint32 pos = _0(x); sorted[++b0[pos]] = x; } // byte 1: read/write histogram, copy // sorted -> data for (i = 0; i < count; i++) { uint32 x = sorted[i]; uint32 pos = _1(x); data[++b1[pos]] = x; } // byte 2: read/write histogram, copy // data -> sorted for (i = 0; i < count; i++) { uint32 x = data[i]; uint32 pos = _2(x); sorted[++b2[pos]] = x; } } void CheckSorted(const char *method, uint32 *data, uint32 count) { for(uint i = 1; i < count; i++) { if(data[i-1] > data[i]) { printf("%s is incorrect!", method); exit(0); return; } } } struct Timer { LARGE_INTEGER t0; double elapsed; Timer() : elapsed(0) {} void start() { QueryPerformanceCounter(&t0); } void stop() { LARGE_INTEGER freq, t1; QueryPerformanceCounter(&t1); QueryPerformanceFrequency(&freq); elapsed += double(t1.QuadPart - t0.QuadPart) / freq.QuadPart; } }; // Simple test of radix int main(int argc, char* argv[]) { // Make sure background processes don't mess with our test results. SetPriorityClass(GetCurrentProcess(), ABOVE_NORMAL_PRIORITY_CLASS); uint32 i; const uint32 count = 1<<24; // 64 megabytes worth of 32-bit integers. const uint32 trials = 5; uint32 *data = new uint32[count]; uint32 *a = new uint32[count]; uint32 *b = new uint32[count]; enum { STDSORT, RADIXSORT }; Timer timers[2]; for (i = 0; i < trials; i++) { // generate a random array for (i = 0; i < count; i++) { data[i] = rand() ^ (rand()<<15) ^ (rand()<<30); } // test both methods on the array for(uint test = 0; test < 2; ++test) { memcpy(a, data, count*sizeof(uint32)); if(test == STDSORT) { timers[STDSORT].start(); std::sort(a, a+count); timers[STDSORT].stop(); CheckSorted("std::sort", a, count); } else { timers[RADIXSORT].start(); RadixSort11(a, b, count); timers[RADIXSORT].stop(); CheckSorted("RadixSort", b, count); } } } printf( "Total time elapsed to sort %d MB of random 32-bit integers %d times:\n\n" "std::sort:\t%.2lfs\n" "RadixSort:\t%.2lfs\n\n", count*sizeof(uint32)/(1024*1024), trials, timers[STDSORT].elapsed, timers[RADIXSORT].elapsed); if(timers[STDSORT].elapsed < timers[RADIXSORT].elapsed) { printf("Conclusion: std::sort is the winner (%.2lfx as fast as RadixSort)\n", timers[RADIXSORT].elapsed/timers[STDSORT].elapsed); } else if(timers[STDSORT].elapsed > timers[RADIXSORT].elapsed) { printf("Conclusion: RadixSort is the winner (%.2lfx as fast as std::sort)\n", timers[STDSORT].elapsed/timers[RADIXSORT].elapsed); } else { printf("It's a tie! That's quite a coincidence.\n"); } return 0; }
  12. Efficient way to find same pixel?

    Quote:Original post by pbryant Quote:Original post by Melekor Just take Brother Bob's solution, but use Radix Sort (or some other non-comparison-based method) instead of std::sort. That's O(n) complexity. Radix sort is slower than std::sort (a heavily optimized quicksort). See This is untrue. For random 32-bit integers, the only reason radix would be slower is with a poor implementation. But don't take my word for it. I have some optimized radix code lying around, let me just whip up a small benchmark to prove my point.
  13. floorcaek, bears, and EAT ROPE

    Quote:Original post by cowsarenotevil There's a reason the usernames on that page are the same as the ones in the gamedev thread. And what thread would that be?
  14. floorcaek, bears, and EAT ROPE

    Quote:Original post by tstrimp Also, "There is always the single player campaign." No luck finding the OP on that one though. It was probably deleted, is was quite distasteful (but very funny in an I'm going to hell kinda way). I believe that one comes from, not gamedev. Link: EDIT: In a similar vein:
  15. Efficient way to find same pixel?

    Just take Brother Bob's solution, but use Radix Sort (or some other non-comparison-based method) instead of std::sort. That's O(n) complexity.