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

Bakura

Members
  • Content count

    147
  • Joined

  • Last visited

Community Reputation

139 Neutral

About Bakura

  • Rank
    Member
  1. With OpenGL3.x you can also use VAO (Vertex Array Object) in conjunction of VBO. It looks like "modern display lists" to me.
  2. That's a cool plug-in ;). Are you following GLSL 1.30-40-50 specs (using texture function instead of texture2D...) ?
  3. Thanks, great application. About the subject, I have some ideas about that. I have to do some work too and then I'll share it with you. There is a great thesis on the net that is called "Parallel Crowd Rendering" by Johannes Spohr (google it), it has a great architecture based on submission engines.
  4. I have to say also that the last two chapters are really interesting ;).
  5. I have read some more chapters and, as it was said before, the book is great. However, it won't teach you exactly how to create a game engine, nor it won't go to depth in how each sub-system of an engine are built (because there are very few source code, and the text is quite "high level" and don't go too deep). But, well, I have a far more better understanding of what there is in a game engine, and as RobMadisson said, the big diagram showing every components of a typical game engine is really great ;).
  6. I just receive the book this morning so I only read the first chapter, but yeah, the book looks really solid, much more than another book about architecture which is called "Ultimate Game Engine Architecture" and which is quite bad. This one (Game Engine Architecture) is written by a senior programmer from Naughty Dog, so it must be good ;). In all cases, the first chapter was really interesting, describing all the components of a game engine in a high level manner. There is a small review on the "Real time rendering blog" : Game Engine Architecture is about just that, how to make a professional-grade game rendering system, from soup to nuts (you can look inside). Eberly’s two books are the previous notable works in this area, but are quite different than this new volume. While they focus almost exclusively on algorithms, this book attempts to cover the whole task of developing an engine: what to use for source control, dealing with memory management and in-game profiling, input devices, SIMD, and many other practical topics. There is also algorithmic coverage of rendering, animation, collision detection and physics, among other areas. Naturally, the amount of information on each area is limited by page count (the book’s a solid 860 pages), but in my brief skim it looks like most of the critical areas and concepts are touched on. You won’t become an expert in any one area from this volume, but it looks like you’ll have some reasonably deep understanding of the elements that go into making a game engine. Quite an impressive work, and I know of nothing else in this area that is so detailed. I hope I get a chance to read it (who am I fooling? Though I do wish I had the time…) – well, at the least, it’s a place I’ll first go if I want to learn about a topic in game development that I know little about.
  7. std::unique_ptr is the way to go ^^ (or alternatively boost::scoped_ptr).
  8. I have also thought of keeping a list of uniform buffer objects (new extension of GLSL 1.40) for each object (but maybe the problem will move to binding buffer), so each object would have its own buffer. If, for example, the specular exponent never change for that object, the buffer will never bu updated. But this means having one buffer for each object... By the way, thank you for your answers, I think I'll go with the simple way at first ^^.
  9. Yes, but I think one great example is the specular exponant, for isntance. It can varies across each object that use the shader, and each object can have different values (while some objects CAN have the same value, so some calls are redundant). If there would be only one value it would be easy, just sort each object with that value, but it's not so simple when there are two or more variables like taht...
  10. Hi everyone, I have designed my shader system, which looks good to me. Sorting each shader is really easy, but I wonder if it is useful to sort uniform values, and if so, how to do it ? For instance, let's say I have two different shaders that do completely different things. I first sort all objects according to those two shaders, so I have two sets of working queue. Let's take the first shader, and... well, we're gonna say it has three variables : - Uniform float : specular exponent - Uniform vec3 : color - Uniform mat4 : WorldViewMatrix Many objects can have the same shader, but maybe different parameters. For now, what I do is this : - Object 1 has 1.0f for specular exponent, (1.0f ; 0.5f ; 0.3f) for color, and retrieve the world view matrix from a function). - Object 2 has 5.0f for specular exponent, (1.0f ; 0.5f ; 0.3f) for color, and retrieve the world view matrix from a function). - Object 3 has 1.0f for specular exponent, (0.0f ; 0.3f ; 0.3f) for color, and retrieve the world view matrix from a function). So the setup, each frame, is : SetShader (shader1); SetUniform (1.0); SetUniform (1.0, 0.5, 0.3); SetUniform (WorldMatrix()); Draw (object1); SetUniform (5.0); SetUniform (1.0, 0.5, 0.3); SetUniform (WorldMatrix()); Draw (object2); SetUniform (1.0); SetUniform (0.0, 0.3, 0.3); SetUniform (WorldMatrix()); Draw (object3); As you can see, some SetUniform calls are quite redundant, and I wonder if it is important to worry about that (and how to sort those data ?), or if glUniform calls are fast enough ? For the moment, I have just thought about setting one bool called IsShared, for instance for WorldMatrix, because it will be always the same for each object that are using this shader, so I can only specify it once, but... is it possible to do better ? Thanks
  11. Quote:Original post by Oxyd C++1x will add even more confusion to the mess that C++03 is. By the time you become good in C++03, C++1x will be widely supported (or dead and forgotten) -- you can then grab a C++1x-capable compiler and continue your education. Don't say that ! It will remains C++0x, the 0 won't become a 1 :I want to believe:. Appart from that, you can try some new features with GCC which implements some interesting things (RValue reference, variadic templates...). For me, one of the thing that can confuse novices is RValue references, but in fact it's pretty easy and can boost performance a lot ^^. auto is also a great great keyword ! I even think it's one of the best new features of C++0x ! So practical !
  12. Thank you guys =). I'm talking about static meshes for the moment, but I don't exclude them to move (I don't need animated meshes for the moment, but I will need them soon). So how handle this ? [QUOTE]For raytracing you just need the bounding volumes in world space, not all the vertex data. If you get a hit against the bounding volume of an instance of a mesh, you can just transform the ray into the object space of the mesh and do the intersection testing in object space.[/QUOTE] Oh yeah, didn't think of that. But I have some questions. I use a QBVH (some kind of BVH, but with 4 child nodes, check the paper on the Internet) and from now I add a triangle soup into the BVH (all the triangles are in world space), therefore it's quite easy to do the ray shooting. So, if I understand it well, it would be something like that : - Load the mesh (object space) - Create an instance, compute the bounding box (in world space) - And... what else ? I will only add the bounding boxes into the three. So when my ray hit a AABB of an object, I convert the ray into object space (that doesn't make too many world-object convertions ?). I can't test each triangle of the mesh. I really don't get it. Maybe do you mean some kind of 2-levels tree (the first level that would have each bounding boxes of each object and, in each of the bounding box, a smaller BVH that would contain each triangle in object space). Am I true ? It sounds really complicated :/... But I think it's the most efficient and cleanest method. And what about animated meshes ?
  13. Hi everyone, I'm currently thinking about an easy way for handling meshes (with OpenGL), but it gives me some headaches, and the solutions I find don't make me happy, so here I am ^^. From now on, I have a Mesh class that encapsulates a vertex array (which is, in my design, all the vertices data - position, normal, uv... - stored in memory) and a vertex buffer, which creates a VBO and initializes it with the data from the vertex array). A Mesh also contains one or several SubMeshes objects. Each SubMesh has an index array, which is quite similar to vertex array but stores only indices in the memory, as well as an index buffer, which is like vertex buffer but for indices. That way, the data that is in the graphics card memory and main memory is well separated. Each SubMesh also has a material object. The problem with that is that if I have several meshes that are shared, I can't use it easily (for instance, with instanced rendering). So what I have basically is : create a mesh, and then create an instance of the mesh. The instance of the mesh contains a reference to the mesh, so the data is not duplicated. The only thing I add to this instance of the mesh is some math data (for instance matrix transformation, because each instance of the mesh has different matrices) as well as different materials. From now on, do you think it is correct ? Or there is a better way to do that ? But the biggest problem is... that I have to use some raytracing. I mean, all the meshes are inserted into a BVH, and then I shoot rays each frame. So, I have to have all the vertices in world space (I think it's quite easy) so that ray shooting is easy, and each time a mesh moves, I update its vertices (I think that with optimized SSE matrix-vector multiplication it can be quite fast) in the main memory, while I keep object space vertices in the VBO that I update in the vertex shader. But I have several problems with that, and I really don't know a good architecture. I think, at the beginning, of something really simple, that is, duplicate everything. Different VBOs, different vertex array... But I don't think it's quite efficient. Second, I thought about keeping this "mesh and instanced", that is to say : - Create a mesh that loads a mesh from a file. Keep vertex data in object space in memory, send everything to the graphics card. - Then each instance of the mesh keep the VBO as well as IBO (because it will reamin the same), but duplicate the vertex data, transform everything into world-space (and then, only update when it moves). - Insert the instance in the BVH. Use also the instance for rendering. But it doesn't look clean anymore :/... Do you have better ideas ? ^^ Thank you very much !
  14. Ahaha, quite fun ^^. You know, I really think that we find the best ideas when we don't want. For instance, this morning I had a really hard test at school and while doing some maths on it... fuck, an idea about OpenGL came to my mind ^^. So I stopped my test and wrote it on a piece of paper :p. I think that you can find best ideas when you feel good. And I think you feel really good when you're with your girlfriend so... ideas come ^^. Great journal, indeed ;).