• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

madRenEGadE

Members
  • Content count

    138
  • Joined

  • Last visited

Community Reputation

190 Neutral

About madRenEGadE

  • Rank
    Member
  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. [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. 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. 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. [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. 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. [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. Ok for the cross product it makes sense. But normalize?
  9. 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. 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

    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

    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. 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. 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...