• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

190 Neutral

About madRenEGadE

  • Rank
  1. Hello all, long time since I was last active here but now I want to do some engine programming again after a long absence. My engine should be based on jobs which are executed by Intel's TBB. My design is similar to the one Intel uses in Smoke. The job system itself is working but there are two things I want to do in 2 separate threads. The first one is creating textures etc. (With a shared OpenGL context) and the second one is rendering. Now to my questions: 1. Are such job systems in general state of the art? I ask because I was out of engine programming for some time. 2. Is it a good idea to make the 2 extra threads? My thoughts behind this idea were that using dedicated threads for those two tasks reduces permant calls to MakeCurrent because in the "normal" job system I would not know in which thread the task is running the next time. 3. Is the performance of TBB's job scheduling affected by my custom threads? The number oft threads TBB creates is based on the number of CPU cores so my two tasks "steal" some processing power. But I think that the job stealing in TBB will handle this, am I right?
  2. Cleaning up a vector of pointers?

    [quote name='KymikoLoco' timestamp='1336678139' post='4939098'] Seeing as OP has commented multiple times they are not very strong with programming, this may be pointing them to a completely different direction, especially when I am under the impression that if they figure out this problem, they will learn more about memory management than they will from the moving to the new C++ standard. [/quote] You are totally right! The hard way is sometimes better (that's why we c++ nerds are often better programmers ;)
  3. Cleaning up a vector of pointers?

    If you want to avoid manual deletion of the pointers you could use a vector of smart pointers instead of raw pointers. C++11 offers you std::shared_ptr.
  4. Is this a valid usage for unions?

    Really good explanation!!! So best choice for e.g vector normalization would be a free function in the Math namespace which takes a const reference to a vector and to have a member function which does not take parameters but normalizes the vector instance itself?
  5. Is this a valid usage for unions?

    [quote name='Radikalizm' timestamp='1336592708' post='4938745'] Inlining would work, but IMO you're going to end up doing lots of work wrapping all the functions provided by glm without any real purpose [/quote] The purpose for me is that all my code looks consistent and that I could change the math library later on. And fortunately is is not that much work because I would just wrap the functions I actually need. Thanks to both of you for the help [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]
  6. Is this a valid usage for unions?

    Member functions would fit better to the rest of my code. But for the free functions I would rather like to use something like Vector3::normalize(v). So I would need to use inheritance + static methods?! The typedefs would also be fine but Is it possible to typedef the free functions of glm (never done something like that)? I think of: [CODE] namespace Math { typedef glm::dvec3 Vector3; typedef glm::normalize Normalize; }; [/CODE] Maybe I could just write inline functions for my desired "renaming": [CODE] namespace Math { inline Vector3 Normalize(const Vector3& v) { return glm::normalize(v); } } [/CODE]
  7. Is this a valid usage for unions?

    [quote name='edd²' timestamp='1336591011' post='4938734'] Same reasoning (IMO). One input, one output, no dependency on the private state. [/quote] I think you are right, at least if normalize creates a new vector. But when I really want to normalize the instance normalize is invoked on, it needs access to the state. But maybe that is not the problem as the state is public... [quote name='Radikalizm' timestamp='1336591033' post='4938735'] I don't think you want to be using a union here, it might work one way or another, but I can't see this as being considered good practice [/quote] "Good practice" is enough of a reason for me to not use unions for this [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] So decision has to be made between "inheritance" and "typedef + free functions"
  8. Is this a valid usage for unions?

    Ok for the cross product it makes sense. But normalize?
  9. Is this a valid usage for unions?

    Using [CODE] typedef glm::dvec3 Vector3 [/CODE] was my first idea BUT I want things like the cross product to be used as member functions. GLM implements them as normal functions taking the two vectors as parameters. But when the inheritance I have suggested does not have any performance penalties I will go that way.
  10. Is this a valid usage for unions?

    Partially answering myself. of course [CODE] double x, y, z [/CODE] does not work. So I have to use something like this: [CODE] union Vector3 { public: Vector3(double x, double y, double z) : v(x, y, z) { } inline double x() { return d[0]; } inline double y() { return d[1]; } inline double z() { return d[2]; } private: double d[3]; glm::dvec3 v; }; [/CODE] Actually I wanted to avoid the method calls for accessing the data members... Are compilers smart enough to optimize this code (this post) so that it performs as fast as the first one (previous post)?
  11. Hello all, recently I decided to discard my hand-written math library code and use the GLM library. Because I want to make it "feel" like my own code need some thin wrapper around it. Because performance matters I don't want to write the wrapper using inheritance like this: [CODE] class Vector3 : public glm::dvec3 { }; [/CODE] Now I have the idea to use a union and write code like this: [CODE] union Vector3 { public: Vector3(double x, double y, double z) : v(x, y, z) { } double x, y, z; private: glm::dvec3 v; }; [/CODE] Is this valid code (using C++11)?
  12. OpenGL FX Composer issues with cgfx

    Sry for that... just tried to copy the code from the shader code. In short: change the order of the parameters in the calls to "mul"
  13. OpenGL FX Composer issues with cgfx

    Maybe this is because DX and OpenGL use different coordinate systems? If this is the case try to change [color=#000000][size=2][/size][/color] [CODE] [color=#000000][size=2][left]oPosition [/left][/size][/color][color=#666600][size=2][left]=[/left][/size][/color][color=#000000][size=2][left] mul[/left][/size][/color][color=#666600][size=2][left]([/left][/size][/color][color=#000000][size=2][left]world[/left][/size][/color][color=#666600][size=2][left],[/left][/size][/color][color=#000000][size=2][left] position[/left][/size][/color][color=#666600][size=2][left]);[/left][/size][/color] [color=#000000][size=2][left]oPosition [/left][/size][/color][color=#666600][size=2][left]=[/left][/size][/color][color=#000000][size=2][left] mul[/left][/size][/color][color=#666600][size=2][left]([/left][/size][/color][color=#000000][size=2][left]viewProjection[/left][/size][/color][color=#666600][size=2][left],[/left][/size][/color][color=#000000][size=2][left] oPosition[/left][/size][/color][color=#666600][size=2][left]);[/left][/size][/color] [/CODE] to [CODE] [color=#000000][size=2][left]oPosition [/left][/size][/color][color=#666600][size=2][left]=[/left][/size][/color][color=#000000][size=2][left] mul[/left][/size][/color][color=#666600][size=2][left]([/left][/size][/color][color=#000000][size=2][left]position[/left][/size][/color][color=#666600][size=2][left],[/left][/size][/color][color=#000000][size=2][left] world[/left][/size][/color][color=#666600][size=2][left]);[/left][/size][/color] [color=#000000][size=2][left]oPosition [/left][/size][/color][color=#666600][size=2][left]=[/left][/size][/color][color=#000000][size=2][left] mul[/left][/size][/color][color=#666600][size=2][left]([/left][/size][/color][color=#000000][size=2][left]oPosition[/left][/size][/color][color=#666600][size=2][left],[/left][/size][/color][color=#000000][size=2][left] viewProjection[/left][/size][/color][color=#666600][size=2][left]);[/left][/size][/color] [/CODE]
  14. Problem with deferred rendering

    Finally solved it... I fixed the overlapping (second screenshot) by enabling the depth test and disabling the depth mask in the shader passes after the geometry pass.
  15. Problem with deferred rendering

    Ok I found out why my depth buffer was not correct. At first I forgot to set the VertexProgram in my CGFX shader. So nothing got rendered to the depth buffer ;) The second thing was that the depth buffer was not cleared because DepthMask was set to false from the previous frame... Now the depth buffer looks alright when rendered to the screen. But the final image still looks like the first two screenshots from my initial post...
  • Advertisement