Advertisement Jump to content
  • Advertisement

Randy Gaul

Member
  • Content Count

    431
  • Joined

  • Last visited

Community Reputation

2807 Excellent

2 Followers

About Randy Gaul

  • Rank
    Member

Recent Profile Visitors

9581 profile views
  1. Randy Gaul

    SAT OBB-OBB - collision normal

    http://www.randygaul.net/2014/05/22/deriving-obb-to-obb-intersection-sat/
  2. https://docs.microsoft.com/en-us/windows/desktop/dlls/about-dynamic-link-libraries OK I found a good link that describes various DLL behavior on Windows. My assumption about DLL reference counting was correct, and I am indeed using the "load time linking" via import libs. So there are two options I see: Link to the DLL in question in the executable, so that the reference count for that DLL for the entire process can never hit zero. Hitting zero will flush the DLL, causing any function pointers to be invalidated (and other stuff too). This can cause all kinds of problems (and it does), depending on how the internals of DX/DS are implemented. Manually load/unload function pointers/vtable pointers from the DLL itself (with dlsym or GetProcAddress). This still might not work if the DLL gets flushed, since DX/DS objects can contain vtables or pointers to static vtables (not implemented as a jump table, like you mentioned above). The first option is probably the only good one. Though I imagine it might get a little bit tedious to *make sure* the executable references the DLL in question -- for example I would be inclined to not even include DirectX headers in the executable, since I only want to use DirectX in my DLL. But, I don't want to mess with the linker stripping out the "dead references" to d3d9.dll or dsound.dll, so I'll probably just initialize DX/DS in the executable and call it good enough.
  3. Thing is with OpenGL I’m loading up all functions with GLAD (a bunch of loadprocaddress calls). This seems to work just fine. But with DX and DS I’m not really sure how one would pull out all the functions, since they’re all these wacky COM interfaces. And even if this succeeded, there still might be some static memory used within the APIs that had been cleared to zero due to the DLL reload. This would all be simpler to test out if I knew how to loadprocaddress on all the DX/DS functions I need. Or maybe even worse if the code address changes for the DX/DS virtual functions. I’m not exactly sure how Windows considers DLL dependencies. If d3d9.dll is linked by my DLL, and mine is reloaded, would d3d9.dll also get reloaded? This would invalidate the vtable of any virtual C++ objects from the DX/DS APIs. I’ve been trying to read up on all the shared lib dependency rules, but am having trouble finding good information on the topic. It seems like if the executable depends on dsound.dll, then when my personal DLL is reloaded the process does not release dsound, since the executable still holds a dependency reference. So my workaround seems a little like working around reference counting... And that seems silly to me. For now I’m pulling in the appropriate functions with pragma dll (which I suppose deals with import symbols at link time? I’m not exactly sure how import libs and the like work on Windows and what the implications are for DX/DS dependent libs being reloaded), and haven’t done anything special when hotloading my DLL.
  4. Does anyone have any insight or experience with DirectX or Directsound in terms of hotloading C/C++ code? I have a lot of code running inside of a DLL that gets hotloaded at run-time frequently. I've noticed that if I attempt to initialize and setup either DirectX or Directsound within the DLL I seem to hit undefined behavior. My best guess so far is that these APIs are using some static memory somewhere to implement COM interfaces (like pointers sitting in static memory, but initialized at run-time). For example if I reload my DLL DirectX seems to mostly work, at least locally, until Present is called, which results in a strange NULL pointer access violation within d3d9.dll (from one of my GPU vendor's driver threads). So far the only workaround I've been able to get working is to initialize DirectX/Directsound from within my main executable and pass along associated pointers to my reloadable DLL. This sort of sucks though, since personally I was hoping to keep these technologies localized to the DLL and avoid extra header inclusions for the executable. Anyone tried experimenting with this sort of thing before?
  5. Randy Gaul

    Continuous GJK for Linear Translations

    You're right, I was just referring to the triangle case. I suspect a common thing to do for TOI solvers is to apply a buffer radius around each shape for the GJK function to work with. This can give GJK some breathing room. In effect, this applies a tolerance buffer zone around shapes that counts as colliding as far as the TOI solver goes. I personally haven't tried getting into this kind of tuning very in-depth yet, so maybe Dirk can have some more specific advice for you.
  6. For sphere to triangle you can use GJK to compute closest points between the sphere's center and the triangle. Given these, computing a manifold becomes trivial. For other convexes to triangle, I have used SAT between convex meshes. It's also possible to store adjacency information between triangles in your heightmap, and collide convex meshes against these (this way you can avoiding "interior edge" collisions by properly representing the Voronoi regions of shared edges between triangles). Be sure to look up Dirk's resources from GDC 2013-2015 at box2d.org/downloads. I would recommend to stop reading Ian Millington's book. It's not state of the art and uses a lot of out-dated technology. It's an OK book for an introduction to collision detection, but as you are noticing in your post, it must quickly be retired in favor of other resources.
  7. Randy Gaul

    Continuous GJK for Linear Translations

    Oh my old 3D code doesn't do that snapping thing. I suggest looking at my 2D stuff I linked earlier -- it does the snapping thing there. My old code is nice to see as a general idea of what 3D can look like, but I haven't touched it for a long time. Actually not that long ago (like 5 months ago) someone pointed out a bug in my old 3D code! The bug was like 3 years old. So to reiterate, I would put trust in Erin's resources, and then expand from there (which sounds like what you're doing, so that's great). I still need to do more testing with my linear CA implementation, like checking for 0 velocity bound, make sure the end conditions are strong. My tolerance can also probably be reduced further. I might want to shrink or expand the collision shapes by a radius factor. I'm not sure yet.
  8. Randy Gaul

    Continuous GJK for Linear Translations

    In colliding cases my implementation snaps the vertices together and manually sets the distance to zero. GJK is perfectly good at detecting intersection. It does get a little difficult in the “almost intersecting with a tiny distance”, but this kind of problem can be successfully mitigated.
  9. Randy Gaul

    D3D9 Shader Constant Update Frequency

    Got the answer: https://twitter.com/grumpygiant/status/1059705960162197504 Gotta update them every time. The constants are just in a table, no special caching.
  10. In OpenGL a shader uniform can be in a program, and then never updated. If the program is unbound, another shader is used, and then rebound, the old uniform value will stay in-tact. This was the behavior I expected from D3D9. Unfortunately I'm mostly referencing Frank Luna's DX9 book, which covers FX and not the HLSL alternatives. So I'm at a lack of information a lot of the time. If anyone has a suggestion on better resources/references let me know! I had this terrible problem in another thread, and it came down to setting shader constants once for each shader, and then never updating them again thereafter. My shader constant updating code cached values on the CPU with a dirty flag, sort of like this: for (int i = 0; i < uniform_count; ++i) { uniform_t* u = uniforms + i; if (u->dirty) { update_shader_constant(u); u->dirty = 0; } } Is this kind of caching not valid when swapping between different shaders from one draw call to another? Is this because constants are mapped to registers, and those register values are not saved/associated with specific shaders? Any links on advice for optimized ways to update constants? I'm assuming SetVertexShaderConstantF is the best thing to do each frame?
  11. Randy Gaul

    D3D9 Render to Texture Problem

    Well. No idea what the problem is, but I made an entirely new repo and reimplemented everything, and it all works. Thanks everyone for popping in and trying to help! Consider this thread mostly finished, since I'll eventually find the exact difference between the isolated repo and my bigger project. Here's the working repo: https://github.com/RandyGaul/d3d9-Render-to-Texture Edit: Found the culprit. I was caching shader constants and not updating them every frame. I suppose caching them is not a valid thing to do when switching between different shaders, overriding register values. Made followup question:
  12. Randy Gaul

    D3D9 Render to Texture Problem

    I took apart one of Frank Luna's example source for rendering terrain as a minimap via render to texture. I replaced his render target code with mine, and it all worked. I'm pretty convinced the problem is just in my do_draw_calls_d3d9 function. So I'll post up the source for that here. Still tinkering with things, but if anyone spots something odd, please let me know.
  13. Randy Gaul

    D3D9 Render to Texture Problem

    I've already written texture out to file in a few ways. For now strategy I'm going to go with, is to get an old SDK sample building, and then change out their DrawPrimitiveUP to DrawPrimitive, and see if that works. There's got to be a subtle difference somewhere... Like I noticed the SDK samples are constantly freeing up references to surfaces all over. I think they are just trying to make their sample code "generic" by preserving whatever previous surface was bound as render target, but it's worth a try. Also Mitton just suggested on twitter to use Intel's frame analyzer, since he said it probably still works with D3D9: https://twitter.com/grumpygiant/status/1059530944531521536 This might be worthwhile. Any other ideas? I'm open to try anything at this point.
  14. Randy Gaul

    D3D9 Render to Texture Problem

    There is no depth buffer, it's just a color buffer. Setting to 1.0f doesn't change any behavior. Just tried unbinding all textures after each draw call -- no dice. Plus, if I couldn't bind the texture as render target I would get an error code return value, or I wouldn't have been able to render anything to screen. But OP shows I was able to render to screen, but only once.
  15. Randy Gaul

    D3D9 Render to Texture Problem

    Oh gotcha. That makes total sense. I'll try round-robin on this tomorrow and see how that works... Usage flag for the texture is D3DUSAGE_RENDERTARGET, and pool is D3DPOOL_DEFAULT. One thing I don't really understand, is that none of the DirectX SDK samples are cycling through double/triple buffered textures, and they seem to run fine. Also Mitton isn't doing any buffering in his tigr library: https://bitbucket.org/rmitton/tigr/src/be3832bee7fb2f274fe5823e38f8ec7fa94e0ce9/src/tigr_d3d9.c?at=default&amp;fileviewer=file-view-default#tigr_d3d9.c-169:248 So I'm not exactly sure why I would need to.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!