Jump to content
The Dark Mod Forums


  • Content Count

  • Joined

  • Last visited

Community Reputation

23 Good

About NagaHuntress

  • Rank
  1. If you're trying to use OSS for sound out on Ubuntu, you're probably running into the problem of Pulse Audio monopolising /dev/dsp . You could disable the Pulse Audio service, but you'll run into sound not working in other applications, or sound not being shared. A better solution is to use a OSS emulation wrapper that outputs to a sound system compatible with Pulse Audio. Install OSS emulation for ALSA with: sudo apt-get install alsa-ossOnce installed, run the game with: aoss ./thedarkmod.x86
  2. Well, I finally got some time to try the map moved to an X,Y of 10k,10k with fixes disabled, and I'm afraid to report that the player can get stuck on that ridge. The normal fix stops get the player from getting stuck as expected, but the player still stumbles (possibly less often, but that's very subjective at the moment). Adding the epsilon fix stops the stumbling (again, expected).
  3. In plain C, NULL is actually defined as ((void *)0), but in C++ it can be defined as 0, as C++ uses 0 as a null pointer. However, in GCC it defines NULL as "__null", as tested by the following code: #include <stdio.h> #define STRINGIFY(x) #x #define STRINGIT(x) STRINGIFY(x) main () { printf("A NULL is: " STRINGIT(NULL) "\n"); } $ gcc -g nulltest.c && ./a.out A NULL is: ((void *)0) $ gcc -g nulltest.cpp && ./a.out A NULL is: __null__null is internal to GCC and used to help generate warnings. Typically NULL is used when you want a null pointer (i.e. a pointer to not
  4. I saw this when doing my 64 bit patch. The problem is that there is documentation out there say that NULL should be used for Open AL's integer handles. In practice people should be using AL_NONE instead.
  5. The game is locked down to single precision in the sense that it's locked down to 32-bits. With enough time and effort baked in floating point assumptions can be overcome. With a general conversion of floating point types to double, there will be a need to have it converting from double to float when the game engine passes data to the renderer. Hmm... When I get time, I'll have to try the test map at an X,Y of 10k,10k and see if it glitches on me when the fixes I've done are disabled. I suspect the fix is good enough for your needs, but it nags in my mind that this is not the corre
  6. I haven't looked closely at how the renderer is structured yet, but ultimately things will need to be converted to single precision floats by the time it hits OpenGL. Unique structures that are used for just the render can be kept as float, but if they use Vec3 and other similar structures then those uses will need to be replaced with a float only equivalent.
  7. Ideally you'd increase precision for just the collision, but the difficulty is keeping all the extra precision isolated to just that section without lots of re-engineering. You might get improvement by changing idPluecker to use doubles and its use seems to be isolated to just collision detection. Some floats in cm/CollisionModel_* files could be modified to use doubles instead of float. However, it's possible that won't be enough and you'll need to start changing Vec3 classes, which can have carry on effects to the rest of the code base, or creating a "DoubleVec3" and add extra code to conver
  8. I installed "libx11-6:i386" to get X11 libraries. If you already have a required library installed, check that the symlinks are setup correctly. I remember one library was missing it's symlink for the .so file.
  9. Interesting. I wouldn't have expected the performance penalty to of been sever, as it's already working double precision already but just reducing its results down to floats when done. I suppose the extra data transfers from the larger data types are causing a performance hit. Moving the whole world around the player strikes me as a rather processor intensive way to do things (unless they're referring to moving it in blocks, which is not quite the same as being at 0,0,0 all the time). I imagine what's more likely happening is that collision and other localised geomtry operations are moved
  10. Well, as you can see above, the fixes used were a bit of logic and a bit of constant tuning. However, I think the proper fix is adjusting the coordinate space to be closer to zero when doing a collision trace, but such a fix is likely to mean extra calculation steps, and will require touching a lot of code to make sure it's done right. Plus in the back of my mind, I have a nagging thought that there maybe lingering artifacts due to distorted normals and plane equations being calculated at such extreme coordinates. I've been thinking on this and been trying to figure out a good way to solv
  11. I've gone and tested that map with everything moved to around 0 in the X and Y coordinates (Z remains unchanged), and have witnessed no problems, even after reverting both the CONTACT_EPSILON and the edge normal fixes described previously. This does indicate that the problem ultimately stems from distortions introduced by such large coordinates and the limited storage precision used. I'm more worried about them falling off that small platform.
  12. It's the one that's enabled in the patch ("// make sure the collision plane faces the direction of the trace"). I haven't witnessed any problems with AI in regular FMs with these changes, but I haven't tried testing anything against the ridge. I suspect that the AI would have been vulnerable to original problem of getting stuck. I'm not sure if they would have stumbled, as I think player movement is handled by a different class from AI movement, which might not react to these glitches.
  13. Okay, I've looked at it a bit more, and certainly stemming from it jumping back and forth between thinking it's on the ground and in the air. I've fixed this behaviour in the test map by changing "CONTACT_EPSILON" to "CONTACT_EPSILON * 4" in "game/physics/Physics_Base.cpp". This makes it test a bit furter downwards for gravity based contacts on the ground. I've play-tested the Thief's Den with this change and have not observed any problems due to it. I'm not sure if it's the proper fix, as it might only patch over this test case but fail again at even larger coordinates, or under different
  14. I've done some more testing and found that I could get in the Thief's Den when using the polygon plane method. I switched to the direction of movement method I didn't get stuck. (The point I got stuck on was on top of Creep's house, right before crossing over the peak of the roof top and falling off of the map.) I think this bug manifests where there are only (or mostly) edge on edge collisions. The only time you see that normally is when you have a topside edge, like in the ridge of the test map. I haven't debugged it deeper yet, but that does seem to be a likely cause. The other poss
  15. It's Python. I think Import() and Return() are regular functions provided by SCons, and don't do what 'import' and 'return' do.
  • Create New...