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


  • Content count

  • Joined

  • Last visited

Community Reputation

399 Neutral

About GFalcon

  • Rank

Personal Information

  • Location
    Rambouillet, FRANCE
  1.   Do you know why they gave up on it ? Voxel cone tracing seemed very promising to me, even for the  incoming "next gen".
  2. Thanks for the reply. That is what I thought ... well ... time to review my mesh reader then, to split those vertices ;) By the way thanks for the link in your signature (on transparency in deferred shader), I'll soon need it I think
  3. Hi, First here is a picture to present my problem : [sharedmedia=core:attachments:9558] I have two triangles (A, B, D) and (B, C, D) with the following texture coordinates (red arrows illustrate the texture "direction") : A = (0, 0) B = (1, 0) C = (0, 0) D = (1, 1) I am calculating the tangent vector for these four vertices, for which i find (W used to store information about handedness) : Tangent at A = (1, 0, 0, 1) Tangent at B = (0, -1, 0, -1) Tangent at C = (-1, 0, 0, -1) Tangent at D = (0, -1, 0, -1) (I am using the method described at [url="http://www.terathon.com/code/tangent.html"]http://www.terathon....de/tangent.html[/url]) My problem is for B and D vertices. I understand why I found these tangent vectors (because of the changing direction of the texture at these vertices my tangents), but how can I resolve this issue. Do I have to "split" B vertex into B1 and B2 (and D vertex also) so that they can each have a correct tangent vector ? Or is there another solution (maybe I am missing something here ?). (The objective is to do normal mapping, I have it working quite well but problems appear on those vertices where texture is changing direction. I am using Sponza Atrium model from CryTek).
  4. [quote] I'm not intensly familiar with SVO, but really, whoever you quoted above has no grasp of reality it seems. Not using multiplication and division does not make it impressive by itself, also note, the core algorithm. Meaning, going along a ray and traversing an octree. Going along a ray can be done using a variation [url="http://en.wikipedia.org/wiki/Bresenham"]http://en.wikipedia.org/wiki/Bresenham's_line_algorithm[/url] ... and holy shit! It doesn't use division and multiplication other than for precomputing some values! Bresenham's line algorithm sure is modern day rocket science it seems. So, let's step back, and look at the problem... we have a RAY and an OCTREE, and our intention is to find the first node in the octree the ray hits, to get the pixel color... so: 1. Step along the ray using some algorithm (bresenham's line algorithm perhaps?) 2. For each step, check the corresponding octree node, if empty go to 1, exit if solid 3. Recurse one level down into the octree, go to 1 A bit simplistic yes, but unless I'm missing something, then that is the "core algorithm"... and no I don't see any unicorn in there. Just to be clear though, this is one way of implementing it, there are likely a lot better ways, but it wouldn't suprise me if this is what they actually use, just a bit optimized. [/quote] I also thought about Bresenham's algorithm applied to it yesterday, but it might need a lot of (small) steps along the ray to check the octree nodes ... but why not. For sure, if their "core algorithm" is done this way there are no unicorn here, I agree on that Well even if they say they are not using ray casting, I begin to think that in fact they are. Maybe, they just call it differently because they are not doing it the usual way.
  5. [quote name='bwhiting' timestamp='1313138141' post='4848136'] here is my take on this thing having also now watched the interview.. 1. forget the "unlimited" bit... nothing in the universe is so just see it as just a "AWESOME AMOUNTS OF" instead, which is what he means methinks. so don't waste your energy on that, we all know its not actually unlimited. That is if you are taking the word unlimited to mean infinite.... but the two are different, unlimited could be the same as when another engine says it supports an unlimited number of lights.... which it true... the engine supports it.... your machine might just not be able to handle it (not a limit imposed by the engine but by the users computer) either way I wouldn't get hung up on it. 2. he is the guy who came up with the technology and he was a hobby programmer, this could explain how he gets some terms wrong (level of distance??!) and why he may seem quite condescending... if he has no background in traditional graphics then that would make sense. His lack of knowledge of current methodologies is what I think lead to him going about it however he has done. 3. I am more and more thinking that this will lead somewhere and may indeed be the future of graphics (the guy who interviewed him was blown away) and from the sounds of it its only going to get better and faster 4. It still "boggles my mind"!!! 5. - 10. not included as I should really be working [/quote] That boggles my mind also, so I did some research over internet about their algorithm. Didn't find much, but this post is quite interesting : [url="http://www.somedude.net/gamemonkey/forum/viewtopic.php?f=12&t=419"]http://www.somedude.....php?f=12&t=419[/url] To quote the post : [quote][i] I'd like to mention Unlimited Detail, a technology developed by Bruce Dell, which does in fact do exactly what he claims it does... Render incredibly detailed 3D scenes at interactive frame rates... without 3D hardware acceleration. It accomplishes this using a novel traversal of a octree style data structure. The effect is perfect occlusion without retracing tree nodes. The result is tremendous efficiency. I have seen the system in action and I have seen the C++ source code of his inner loop. What is more impressive is that the core algorithm does not need complex math instructions like square root or trig, in fact it does not use floating point instructions or do multiplies and divides![/i][/quote] So it seems they are relying on some "octree like" data structure (as many supposed). What is boggling me the most is the fact their algorithm isn't using multiplies or divides or any other floating point instructions (as they say). Is there a way to traverse an octree (doing tree nodes intersection tests) only with simple instructions ? I don't see how (I only know raycasting, and it seems difficult for me to do this without divides, I know that other ways to render an octree exist but I do not know how they work).
  6. OpenGL

    The way I see the difference between glBegin/End, glDraw and VBO : - glBegin / glEnd : A lot of function calls is needed - glDraw : It is the same as glBegin, but reduce considerably the number of function calls - VBO : Reduce bus activity (only if your geometry is static maybe ? because if it is dynamic you'll have to transfer data each time) I've seen some interesting bechmarks about it, for geometry composed of hundreds of thousand (and more) polygons, you can esperate a ratio of 3 to 4 time faster. However, for a lower count of polygons you will not see great performance differences.
  7. OpenGL

    Hi, glDrawArrays and glDrawElements work fine, but VBO is another way to do it, and more efficiently. Here is an article about it (in French s'il vous plait ;)) : http://www.game-lab.com/index.php?section=tutorials§ion_id=1&p=tutorial&action=showtut&id=244 Bye
  8. You might also be interested by function-try-blocks if you want to use exceptions in constructors, see this for example: http://www.gotw.ca/publications/mill13.htm Hope it helps you ;)
  9. Hi, what kind of errors do you want to handle in constructors ?
  10. It is as Erik said, and it is also used to initialize members which are references : class MyClass { public: MyClass(std::string& myRefToObj) : m_myRefToObj(myRefToObj) {} std::string& m_myRefToObj; };
  11. I like it. Not too long and not too short. Nice one.
  12. Check if you have included windows.h before gl.h
  13. Quote:Original post by GFalcon Maybe your problem is inside IGroup destructor. I had a good intuition. Happy that you solved your problem.