Jump to content
  • Advertisement

ItsDoh

Member
  • Content Count

    112
  • Joined

  • Last visited

Community Reputation

162 Neutral

About ItsDoh

  • Rank
    Member
  1. Vorpy, I'm aware you can maintain lists at each level, but going back to the original problem he seemed to be thinking there was no reason to check beyond the root node, or he didn't realize the root node encompassed the entire region, I'm not sure which. And I thought I'd explained that bounding spheres were only as first-stage intersection test, you should of course then continue with more accurate to the geometry tests if the sphere-sphere checks come out true.
  2. ItsDoh

    SVN Help

    In TortoiseSVN (windows plugin) you can use the RepoBrowser to delete the entire directory and just start over.
  3. Does it fit into the current node (start at the root) You may be missing part of how quadtrees work. Every point should fit in the root node.
  4. Typicall in quad-trees your nodes contain EITHER child nodes OR object lists. I believe a node containing child nodes is a 'branch' and a node containing objects is a 'leaf'. And you don't just check the object list for the node your Object A is in, because as I think you were hinting at, objects can straddle multiple nodes. When I want to know how many objects are potential collision candidates I'll start with the bounding sphere for that object. I pass that into the root node of my quad tree. Each quadtree node has its own sphere (remember sphere-sphere checks are very cheap to do) and I move down the list with some simple logic. If a quad-tree sphere was entirely inside the object's sphere (ie, large object w/small quadtree nodes) then ALL the children of that node are potential candidates (you could choose to optimize out further checks down the tree, but I tend not to). If the node's sphere just intersects the object's sphere, or the object's sphere is inside the node's sphere (assuming you make that kind of distinction) then further testing is necessary. At that point I'll do a sphere-box check (still pretty cheap if you're using AABB) since the sphere checks produce more positives than needed, especially when your tree nodes are more rectangular than square. Same rules apply on that level, if it intersects then all the children are analyzed, and that is where the recursion comes in. Hope I explained that well.
  5. Unless super-accurate physics was required and a 'good-enough' solution wasn't good enough, couldn't you just update a portion of the particles per-frame? Meaning you check say 1/3rd of the particles per frame, but when the particles are updated use 3x the attractor/repulsor force? The effect would be that the particles would be just slightly off a physics-accurate position, but unless they were moving really fast I can't see it affecting it... Just food for thought. I'm no particle system expert and haven't done any real implementation stuff on it yet. [Edited by - ItsDoh on January 28, 2007 2:06:03 PM]
  6. ItsDoh

    A Render Cycle

    You should only be filling index/vertex buffers each frame if the data changes from frame to frame such as animation if/when it can't be done on the graphics hardware itself.
  7. ItsDoh

    "artifact" using DirectX 9

    Try clearing your stencil buffer?
  8. I just typed up an 8 paragraph summary of what I was doing. As I was typing up the order in which I disassemble the graphics subsystem in my engine, I noticed while I had done the IsUsingEventHandlers bit before the Graphics system was Disposed of, I hadn't done it prior to disposing the textures. I moved it to immeditately after I remove the hooks and I think it's working. I have to sort out the Sprite object whining about not being Disposed of first, then I can run a test.
  9. I was using DoEvents, removed it but that doesn't seem to have affected anything. I also set the IsUsingEventHandlers property to false after I'd removed the event mapping, again no change. I'm not using render targets, index/vertex buffers, etc. This is a very early test of the engine I've been writing and I'm shocked I'm having these issues at this point. I'll have to go through it again as suggested, but the only things being used at the moment are 2 textures and a copy of the D3D sprite object, all 3 of which are being disposed. Also to be clear, it's when I dispose a texture that it hangs (not any texture either, just one of them in this case). I understand if you don't release objects then it might hang when it releases the graphics device, I'm curious what would hang a Texture disposal.
  10. I'm using VS2005 and MDX 1.1. I'm attempting to sort out the cleanup portion of my application. The program is very simple at this point and uses precisely 2 loaded textures. I have a resource-manager system in place so although 1 of those textures is used 10 times, it's only ever loaded once. Anyways when the engine is told to shutdown it disables its 'lost device auto-restore' functionality, then tells the texture manager to dispose all it's objects. The texture objects then simply call the .Dispose method of their internal texture object references. That's where the problem comes in. Oddly enough the more sprites I use one of the textures in (one of the textures is a simple "cloud" picture that I use a few places in the screen) the longer it takes to unload. I've already confirmed that the texture manager is working and that all the sprites which request the cloud texture get references to a single object and not a duplicate. When the project closes it appears to freeze. If I've made 1 or 2 uses of the texture it takes maybe 15 seconds to close, if it's more like 8 or 9 it seems to never close. Anyone know any quirks to MDX unloading that might cause this? The oddest thing I've seen by profiling the application is that while they don't seem to take up a lot of the actual execution time, there are 5 million calls to IntPtr::ctor which seems suspicious.
  11. Cookies most likely.
  12. ItsDoh

    RTS movement

    You'll have to determine if the destination is unreachable, and if so determine a 'close enough' point.
  13. ItsDoh

    High Definition

    Keep in mind PC games have been doing resolutions similar to and higher than 'HDTV' resolutions for awhile.
  14. If I'm remembering correctly, most of those things are optional too, meaning you can specify the entire vertex buffer as the length and it would still render correctly, it's just an optimization technique.
  15. ItsDoh

    Game Design 101

    See I've never bought into the 'good design is language agnostic' arguement, I've always felt good design makes use of your specific language's strengths, and avoids its weaknesses.
  • 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!