Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Everything posted by Mercenarey

  1. I have made a class to launch threads like this: #include <boost/thread.hpp> class BaseThreadObject { protected: //---------- Protected Properties ----------------- boost::thread* m_thread; //------------ Protected Methods ------------------ public: //-- Constructors, Destructor & Support Methods --- BaseThreadObject(); virtual ~BaseThreadObject(); void Startup(); void Shutdown(); //-------- Get's -------------------------- //-------- Set's -------------------------- //---------- Public Methods ----------------------- void operator()(); virtual void ThreadMain() = 0; }; // ------------------------------------------------ // ------------------------------------------------ // ------------------------------------------------ void BaseThreadObject::operator()() { ThreadMain(); } // ------------------------------------------------ // ------------------------------------------------ // ------------------------------------------------ void BaseThreadObject::Startup() { m_thread = new boost::thread(boost::ref(*this)); // m_thread = new boost::thread(*this); } // ------------------------------------------------ // ------------------------------------------------ // ------------------------------------------------ void BaseThreadObject::Shutdown() { m_thread->join(); } // ------------------------------------------------ // ------------------------------------------------ // ------------------------------------------------ void BaseThreadObject::ThreadMain() { // whatever } The Startup launches the thread with the class as a ref, to prevent it from being copied (boost takes 10(!!) copies when launching). Also, I hoped that with a ref, that I could have preserved the inheritance, so I could call derived classes through virtual methods. However, when I call a virtual method, even if it is implemented in the base class, like the operator()() calls ThreadMain() (which I hoped I could then freely derive for new classes, while preserving basic threading functionality in this baseclass alone), it will fail with this message: "Unhandled exception at 0x00000000 in [prog-name].exe: 0xC0000005: Access violation reading location 0x00000000" I have similar problems when I don't use the ref and allows it to copy. It will only copy the class, that is directly inputted, not the classes it derives from. Is there any way I can create a class like this with boost, that retains an inheritance structure?
  2. I made a BaseCollisionObject because I want it to be a base for both 2D and 3D collision. Im developing an RTS atm, and the world is rendered in 3D, while the collision system will run in 2D. So instead of CollisionObject it will be Collision2DObject and Collision3DObject. Also, I wished to isolate the duplication of MoveObject's interface in the BaseClass. A MoveObject does not necessarily have to be in the collisionsystem. It can be a light or a camera. Notice that BaseCollisionObject is *not* a base class of MoveObject. The diamond symbolizes an aggregation, not inheritance.
  3. Let us start with a diagram of the structure, so you know what the hell I am talking about: I have designed a SceneManager, that I use for my world. It is divided into quadrants, which each hold the objects belonging there. When I want a list of visible objects, I call a GetVisibleObjects()-method, which takes the "seeing" camera as argument, and which returns a list of visible objects. So far, all I have used the scenemanager for, has been for rendering. And therefore, the objects I have been storing, had rendering in some form (a Render()-method) attached to them. I knew when I designed my RenderObject, that it would give problems conceptually, because the RenderObject derived from a more basic object, and I was forced to derive again from it with classes, for which rendering was irrelevant. My problem now is, that I want to use the SceneManager for more. For example, I could imagine integrating it with a collision system (or rather, let it become a collision system as well). Now I have this stupid render-class stuck in the middle of my object-hierarchy, and all it is good for, is rendering, and it is not directly relevant to other objects, that have to derive from it, to participate in the SceneManager, and that irks me. For instance, in my structure, StaticCollisionObject now derives from RenderObject, and that is an eye sore to me. Also, on the server-side, I don't need rendering at all, meaning RenderObject becomes completely obsolete here. But then I have thought about the alternatives. If I return a list of BaseObjects, how will I be able to get to rendering in any form? I came up with different solutions: - virtual bool BaseObject::Render() = 0; By moving this method from RenderObject to BaseObject, I would maybe be able to get rid of the RenderObject (at least at a so low level as I have it now). But it is ugly to have it at that level. I would prefer to have methods only directly relevant to each object. - virtual bool BaseObject::RegisterInformation(ENUM informationnature=RENDERING) = 0; This will call the virtual method until it hits the object that acknowledges RENDERING, and this object will place itself in a singleton register as itself (RenderObject), and from there, the caller can retrieve the list of that specific object. But it will mean, that through the ENUM informationnature, render-information will again have leaked through. Also I don't like the elaborate registering system. - put an object's render-information (BaseObjectGraphics, this class would need a link to the BaseObject) in a seperate table, retrieve all the visible objects from SceneManager, and thereafter retrieve the corresponding render-information from the table with the BaseObject::GetID(). It is a possibility. The object will be completely fragmented. - leave it as it is. -------------- Right now I am leaning towards either keeping the information seperately in another table and linking through ID or leaving as it is. -------------- Have any of you encountered this problem? And what was your solution to keep the objects logically intact, and to avoid superflouous classes/methods?
  4. I have looked into quadtrees for my dynamic collision system, but I seem to find solutions for static (overlapping) tests only. Has it been done with dynamic collision detection, where you have to take velocities into consideration, when finding nearby objects? Thanks in advance.
  5. Quote:Original post by SiS-Shadowman Quote:Original post by Mercenarey As for the case of 'alot', why isn't that good enough for you? Don't you trust me to evaluate what I need? You are asking for the right algorithm (or if quadtrees are of use) for collision detection, yet you don't see that it highly depends on the number of objects in the scene... No I wasn't. I asked how it is done with Quadtrees when used with a dynamic system. Ok guys, this is my last reply on this thread, this nitpicking leads nowhere.
  6. Quote:Original post by phresnel But you only see the worst expected behaviour in us. Again, you need a lesson in empathy. o/ I don't see the worst expected behaviour in people, not even here. But when I see bad behaviour, I recognize it.
  7. Quote:Original post by Mercenarey Quote:Original post by phresnel Lastly: You are an ingrate person without manners for which investing time is not worth the effort. Go help yourself and seek enlightenment in the vastness of your own infinity. You are the one dishing out google lessons, and you call me without manners?? That is not the kind of "effort" I want anyway, so maybe you should think about that next time you give "advice" in the form of google lessons, that don't even lead anywhere. Just so you know, I edited my last post to include a reply to your flame. As for the case of 'alot', why isn't that good enough for you? Don't you trust me to evaluate what I need?
  8. Quote:Original post by phresnel Firstly: your thread was done right after the first reply. Your original question was Quote:Has it been done with dynamic collision detection, where you have to take velocities into consideration, when finding nearby objects? I expected some kind of pointer as to how. Most people come here because they need a problem solved. Quote:Original post by phresnel Secondly: What mature help do you expect for such a vague problem descriptions that says "alot" if there are infinite definitions of "alot" (ranging from 3 to INF). For some definitions of "alot", a list is superiour. For other definitions of "alot", a bounding volume hierarchy is better. When did you ever play an RTS with 3 units? Quote:Original post by phresnel Thirdly: You are not the one who decides when a thread is closed. That is why I said: "I was done with this thread". Did you notice the "I"? You can stay here and argue the "alot" as long as you want, I just choose to stop now. Quote:Original post by phresnel Lastly: You are an ingrate person without manners for which investing time is not worth the effort. Go help yourself and seek enlightenment in the vastness of your own infinity. You are the one dishing out google lessons, and you call me without manners?? That is not the kind of "effort" I want anyway, so maybe you should think about that next time you give "advice" in the form of google lessons, that don't even lead anywhere.
  9. Quote:Original post by theOcelot Maybe other OO languages, but C++ is not really an OO language. It just supports OOP, among other paradigms. In fact its multi-paradigm-ness is one of its strengths: I don't have to use just OOP in my C++ program. I can use a mix of OOP and whatever else, as it fits the problem. C++ is an OO language with backwards compatability to C.
  10. I was done with this thread, as I believe that we more or less covered it. But I can't notice - which I also notice around on other threads - this mad fight for being right. If it isn't achieved on one front, a new one is simply opened. Or some detail is taken and blown completely out of proportions. Why is that? What the hell is the relevance of discussing the number of collisions, to solving the problem I pose (Even after I say 'alot', lol)? Even if in some scenarios, it would be overkill with so and so many objects, there will exist some, where it is relevant with spatial partitioning. I advise that you argue to solve the problem posed, instead of arguing for the sake of arguing.
  11. Quote:Original post by phantom OOP is not a language; OOP is a design and modeling paradigm. C++ is not an OO language; it is multi-paradigm. OOP is possible in C, you just have to write code the compiler would take care of for you in in something like C++. OOP also has a tendancy to fail horribly in cases where you need high data throughput as instead of designing for the data people design towards objects (ie struct Particle vs chunks of memory for each particle). Functional better expresses concurreny systems due to lack of global side effects, something which is becoming increasingly common in games. OOA and OOD are design and modelling paradigms, OOP is not. OOP stands for "Object Oriented Programming", and is a programming paradigm "that uses "objects" – data structures consisting of data fields and methods" (http://en.wikipedia.org/wiki/Object-oriented_programming). It is not strictly a programming language itself, but is usually carried out in one. But that is going into extreme semantics IMO. For all rational purposes, you can chain together C++ (and other OO-languages) and OOP.
  12. Quote:Original post by frob I hate quoting myself, but it looks like it must be done: Quote:Usually it is easier and faster to keep dynamic objects in a list. It takes a lot of work to keep a moving spatial tree current, but sometimes it makes sense.For moving objects, it is almost always the best option to go with a simple list. Unless you have hundreds of moving objects (which I doubt) then the overhead of managing a dynamic spatial tree will be far greater than the cost of queries. That is why most of the current literature and research covers either static spatial trees or massive offline solutions. The other case (small real-time solutions) simply aren't necessary in the general case. I have potentially alot of moving objects. I am working on an RTS. I agree, that the Quadtree is overkill, and wayyy too hard to keep up-to-date with dynamic objects, and that is why I will go with the cell system instead.
  13. The answer is yes, OOP is better than procedural languages. The procedual language has nothing but a tiny amount of speed over OO-languages like C++. Games get very complex, and to manage this complexity, you need good abstraction, and OOP does that the best nowadays. I would never advice a procedural language over an OO one, not even for speed.
  14. My solution will be to drop the quadtree. It gets too complicated, when neighbouring quads of differing resolutions need to interact. Instead I will go with a cell system, with cells big enough to make sure, that only objects in neighbouring cells need to be considered, that means cells big enough to contain the maximum object and it's maximum velocity times two, to make sure that an object two cells away cannot intervene.
  15. Quote:Original post by phresnel Then, about static/dynamic intersection: Consider that you have a velocitiy, so you prolly have linear movement, i.e. you have a moving bounding box or bounding sphere. You could hence use the bounding sphere enriched with time, forming a ... cylinder. I don't think that a cylinder is wasteful. No it is not. But what do you propose then? That I take each object every timestep, create a cylinder (I would call a capsule since a cylinder does not have rounded ends) from it and put it back into the tree? What happens with response, if one object bounces or slides off another and therefore changes direction in the middle of the timestep? That is gonna be some funky looking capsules, and you cannot up-front anticipate what collision is going to happen. So you see, it is not only not wasteful, it is also impossible. Quote:Original post by phresnel Also, the wiki-page contains many pointers to open source physics engines. Have you thought about studying what they do? I looked at Box2D and they use the static method. So yes, I did exactly that. Quote:Original post by phresnel As you probably don't want to collide walls with houses... The techniques used with quadtrees, that I have seen, use timesteps and then do an overlap test. They move the scene forward, test for intersection (statically), and if there is collision, they resolve it. I want to do a dynamic test, where I move the entire scene forward with velocities, find the first collision, resolve the collision (often resulting in a changing velocity-vector), then move forward to next collision etc. Those are dramatically different approaches. I was then asking if it was possible to combine the spatial partitioning technique of quadding - which I have only seen done with timestep+static - with a dynamic test. And then I got the reply from you, which I found severely lacking in respect.
  16. Phresnel: Thanks for the google lesson. Now, can you point to me anywhere in your two links, where my problem is considered? Your wiki-link says the following about spatial partitioning: "Alternative algorithms are grouped under the spatial partitioning umbrella, which includes octrees, binary space partitioning (or BSP trees) and other, similar approaches. If one splits space into a number of simple cells, and if two objects can be shown not to be in the same cell, then they need not be checked for intersection. Since BSP trees can be precomputed, that approach is well suited to handling walls and fixed obstacles in games. These algorithms are generally older than the algorithms described above." But how can you know, by just looking at cells in a dynamic system, that they will not potentially intersect, when velocities are involved? Exactly. What they treat is static collision detection, I don't have problems with that. Can you point me to ONE SINGLE resource in your google search link, that treats the problem at hand? No, I dont think so. The problem is "spatial partitioning" and "moving collision detection" (I use dynamic instead of moving when I search), not "moving collision detection" alone. [Edited by - Mercenarey on August 11, 2010 6:38:45 AM]
  17. My biggest problem is how to make certain, that I get all objects, that may influence, just from the tree alone (not looking at each neighbouring object's radius/velocity). I thought of making a temporary sphere around the object-in-question, with a radius corresponding to the object radius+velocity+object-max-radius+object-max-velocity, and then do a standard static query, since such a sphere would cover the entire possible area of colliding objects. But the problem is, that if I have to every time test with max-velocity, that the temporary sphere will be alot bigger than what is necessary. So how is the problem of finding the relevant neighbours in the tree, while taking their possible velocities into consideration, without querying an excessive area? I don't suppose there are some sources on it? I have looked around alot on the internet the last days.
  18. Sorry for the late reply from me. After a week or so with no reply, I gave up on this thread. Yes, sadly I have to admit, that what you pointed out was exactly my problem :) I created a new structure like this: Here BaseCollisionObject will have to replicate what is needed of the Base-/MoveObject interfaces. In return I get a completely independent CollisionObject, that can take the place of the old RenderObject.
  19. Mercenarey

    HLSL: I "scorch" my alpha transparency!

    Shanee, yes, that bar is from UO :) I played that game for many years and was a big fan of it, so when I made a demo to use with job applications, I put the UO bar in, as homage to the old game, which IMO is the best MMO (at least in the old version) ever made, even to this date. --- Im not sure how it is related. Maybe it cancels out another renderstate, that "scorches" my alphas? Not sure, but if I don't have it in, it will look scorced again. What do you mean with "trying to write alpha color"? From my shader-code (see above), you can see I do this: l_basecolor.w = l_layeralphafactor; return l_basecolor; Not sure if that qualifies as "trying to write alpha color"?
  20. Once upon a time, I used shader ver. 2.0 when rendering terrains. That meant, that I had to use multipass rendering. Then I upgraded to shader ver. 3.0 at some point, without bothering with maintaining the ver 2.0, but now I want to support ver. 2.0 again. The new version blends 6 layers in one pass, without using alpha blending, since it based on the alphavalues on the layers, blends everything itself directly in the shader for the final result. I hauled up my old version of the program to re-implement the multipass version, where each layer is rendered with an alpha-value, but of some reason, the alpha'ed areas get "scorched" (see image). As you can see, the new version is blackened out, compared to the old one, which transitions nicely. I use the following renderstates: SetRenderState(D3DRS_ALPHABLENDENABLE, true) SetRenderState(D3DRS_SRCBLEND, D3DBLEND_SRCALPHA) SetRenderState(D3DRS_DESTBLEND, D3DBLEND_INVSRCALPHA) Has anyone encountered something, that will result in this problem? Do I need another renderstate? Or is an already set state foiling my attempts? It has been three years since I created the old version, and after having looked extensively through both versions, I simply cannot find the error.
  21. Mercenarey

    HLSL: I "scorch" my alpha transparency!

    I added these, as a blind shot. I have no idea why it works, but it does. I never used those before, not in my version from three years ago either. SetRenderState(D3DRS_DESTBLENDALPHA, D3DBLEND_ONE); SetRenderState(D3DRS_SEPARATEALPHABLENDENABLE, TRUE); I really would like to know, why I have this problem, so if anyone has more input, as to why this happens, I would be glad.
  22. Mercenarey

    HLSL: I "scorch" my alpha transparency!

    It is the same system. The only reason why it is butt-ugly in the lower version, is because I have turned off everything, that could interfere, like lighting etc. The shader in the new implementation has been reduced to this: float4 PS_light_normal_standard(float2 a_texcoord0: TEXCOORD0, float3 a_normal : TEXCOORD1, float4 a_world_position : TEXCOORD2, float3 a_tangent : TEXCOORD3, float3 a_binormal : TEXCOORD4, float4 a_worldview_position : TEXCOORD5, float a_positiondistance : TEXCOORD6) : COLOR { float2 l_texcoord = a_texcoord0; float4 l_basecolor = tex2D(g_layer1_texturemap_sampler, l_texcoord); float l_layeralphafactor = tex2D(g_alphamapsampler, a_texcoord0)[g_alphachannel_index]; l_basecolor.w = l_layeralphafactor; // "pode" the pixel with the alpha value return l_basecolor; }
  23. Thanks alot for the help guys. This has been hands-down my most severe problem to date. Took me two full days of work to finally crack. GameDev to the rescue every time :)
  24. I don't know what happened yesterday, but when I tested the code again today with a fresh machine and compilation, it worked as it is supposed to, with Red Ant's implementation. So now it works perfectly! SiS-Shadowman, Bind() is a possibility as well, if you don't like the operator()(), and creating thread on the heap is also a possibility. Personally I prefer to create it dynamically, I feel I have more control over it, as I can call Shutdown() and have it destroyed, instead of relying on the destructor (maybe I want to reuse the object and use Shutdown() to reset the object for a new Startup()?). I have tested it with inheritance as well, and it works fine. Final implementation: // ------------------------------------------------ // ------------------------------------------------ class BaseThreadObject { // ---------------------------------------- // Red Ant's version modified to my code // standard. Inlined as implementation is // irrelevant to outsiders. // ---------------------------------------- struct BaseThreadObjectFunctor { BaseThreadObject* m_basethreadobject; BaseThreadObjectFunctor(BaseThreadObject* a_basethreadobject); void operator()(); }; protected: //------------ Protected Properties --------------- int m_testdata; boost::thread* m_thread; MyFunctor* m_myfunctor; //------------ Protected Methods ------------------ public: //-- Constructors, Destructor & Support Methods --- BaseThreadObject(); virtual ~BaseThreadObject(); void Startup(); void Shutdown(); //---- Get's ---------------------- //---- Set's ---------------------- //-------------- Public Methods ------------------- virtual void ThreadMain(); }; // ------------------------------------------------ // ------------------------------------------------ class TestThreadObject : public BaseThreadObject { protected: //------------ Protected Properties --------------- //------------ Protected Methods ------------------ public: //-- Constructors, Destructor & Support Methods --- TestThreadObject(); virtual ~TestThreadObject(); //---- Get's ---------------------- //---- Set's ---------------------- //-------------- Public Methods ------------------- virtual void ThreadMain(); }; // ------------------------------------------------ // ------------------------------------------------ // ------------------------------------------------ BaseThreadObject::BaseThreadObjectFunctor::BaseThreadObjectFunctor(BaseThreadObject* a_basethreadobject) : m_basethreadobject(a_basethreadobject) { } // ------------------------------------------------ // ------------------------------------------------ // ------------------------------------------------ void BaseThreadObject::BaseThreadObjectFunctor::operator()() { m_basethreadobject->ThreadMain(); } // ------------------------------------------------ // ------------------------------------------------ // ------------------------------------------------ void BaseThreadObject::Startup() { m_testdata = 11; m_myfunctor = new MyFunctor(this); m_thread = new boost::thread(boost::ref(*m_myfunctor)); } // ------------------------------------------------ // ------------------------------------------------ // ------------------------------------------------ void BaseThreadObject::Shutdown() { m_thread->join(); } // ------------------------------------------------ // ------------------------------------------------ // ------------------------------------------------ void BaseThreadObject::ThreadMain() { // m_testdata will correctly be 11 in the thrown thread int dd = m_testdata; } // ------------------------------------------------ // ------------------------------------------------ // ------------------------------------------------ void TestThreadObject::ThreadMain() { // m_testdata will correctly be 11 in the thrown thread - also here // in the derived thread int dd = BaseThreadObject::m_testdata; } [Edited by - Mercenarey on June 25, 2010 9:19:56 AM]
  25. Red Ant, good suggestion. I tried it, and put a breakpoint in MyFunctor::operator()(), to inspect the values. m_ptrToThreadObject had the same address as the BaseThreadObject, but the values inside BaseThreadObject were wrong (uninitialized). The same was true when another breakpoint stopped in BaseThreadObject::ThreadMain() (which I implemented directly in BaseThreadObject, to not have inheritance make it even more complex). How is this possible? Since there is only one class, how can it be sliced? Im completely lost at what is going on with boost::thread... Edit: Just for the record, I created a test variable (an integer) and gave it a value in Startup(), before launching. It is this value that does not show up in the threaded version.
  • 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!