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

Doug Rogers

  • Content count

  • Joined

  • Last visited

Community Reputation

253 Neutral

About Doug Rogers

  • Rank
  1. I posted an FBX parser and viewer a while ago.   You can see how I did it here:  https://code.google.com/p/fbxviewer/
  2. // set all normals to zero for each vertex normal (n) n = 0,0,0 // add in each face normal to each vertex normal for each face fn = calculate face normal for each vertex normal in face (vn) vn += fn // normalize normals for each vertex normal (n) normalize(n)
  3. How about this? offset adjusts the world position forward or backward relative to the camera and is probably not necessary for what you need. float4 WorldToScreen(const float4& v, float offset, float4x4 &orientation, float4x4 &modelView, float4x4 &projection, float width, float height, float _near, float _far) { float4 result = modelView * (orientation * v); result.z -= offset; result = projection * result; // Homogeneous divide const double rhw = 1 / result.w; return float4( (1 + result.x * rhw) * width / 2, (1 + result.y * rhw) * height / 2, // or (1 - result.y * rhw) * height / 2, (result.z * rhw) * (_far - _near) + _near, rhw); }
  4. I agree with L. Spiro.   Export FBX from your art tool and convert that to your own internal format using the FBX SDK in a separate tool.  There are some things that do not convert well from FBX, but those are rare.  You also will not have to create your own exporter this way, just a conversion tool.   The issue with using FBX files directly is that the FBX format is not well suited to real time rendering.  It needs some processing that can be done offline.  Creating your own conversion tool frees you from having to use the FBX runtime in your app.
  5. In 3D, think of the dot product as the projection of one vector onto another:   Like this: http://www.c-jump.com/bcc/common/Talk3/Math/Vectors/const_images/v06_dot.png   Projecting u onto v results in a positive dot product if there is less than 90 degrees between them.  The dot product is zero if they are 90 degrees.     In your code, the angle is less than 90 degrees for each side, so each dot product is returning positive.     You can calculate the barycentric coordinates, then check the values.   http://gamedev.stackexchange.com/questions/23743/whats-the-most-efficient-way-to-find-barycentric-coordinates   https://msdn.microsoft.com/en-us/library/bb195068.aspx
  6. Don't just negate the Z, apply a left handed conversion matrix at the top of the hierarchy.  You can keep the rotations from Maya as they are. float4x4 leftHandedConversion( float4(1, 0, 0, 0), float4(0, 1, 0, 0), float4(0, 0, -1, 0), float4(0, 0, 0, 1));
  7.   Interesting.  I have never heard that index access bad either bad for nor dangerous.  I use both, depending on the structure.  For flat lists, I use indicies like above.  In debugging with indices, I get an bad index value (out of range usually).  A bad operator usually does not give much info.    Both should be about the same perf wise.  I agree that using iterators usually makes it easier to switch container types.  Occasionally, using iterators make it harder to switch, though.   I haven't made the leap to using auto yet.  We didn't use them on my last job, but they look very useful and cleaner.     I learned something here.   Thanks.
  8.   Yes, I did miss that.  I was suggesting a way to debug it, that is all. I don't think I did.  I just suggested a way to track it down.     Here is a way to keep the counters: for (size_t collideCounter = 0; collideCounter < projArray.size(); collideCounter++) { for (size_t collideCounter2 = 0; collideCounter2 < enemy.enemyArray.size(); collideCounter2++) { if (projArray[collideCounter].rect.getGlobalBounds().intersects(enemy.enemyArray[collideCounter2].enemySprite.getGlobalBounds())) { std::cout << "COLLIDE" << std::endl; } } }
  9.     It would have fired and shown that collideCounter2 was out of bounds.  I like SmkViper's suggestion, but a simple fix is to replace for (iter3 = projArray.begin(); iter3 != projArray.end(); iter3++){ with  for (iter3 = enemy.enemyArray.begin(); iter3 != enemy.enemyArray.end(); iter3++){
  10. collideCounter = 0; for (iter2 = projArray.begin(); iter2 != projArray.end(); iter2++) { collideCounter2 = 0; for (iter3 = projArray.begin(); iter3 != projArray.end(); iter3++) { assert(collideCounter2 < enemy.enemyArray.size()); if (projArray[collideCounter].rect.getGlobalBounds().intersects(enemy.enemyArray[collideCounter2].enemySprite.getGlobalBounds())) { std::cout << "COLLIDE" << std::endl; } collideCounter2++; } collideCounter++; } Try adding this assert against the size to see if it fires. collideCounter must be within bounds, but you should use the iterator to get projArray[collideCounter] and remove the collideCounter variable.   It is also recommended that you use ++iter, not iter++
  11. DirectX uses a left handed coordinate system.  
  12. In Visual Studio, you can associate the fxc compiler with your hlsl code so that when you hit build, hlsl code will compile just like your other other code. In the output window, you can then go to the error lines.
  13. [quote name='heh65532' timestamp='1346973329' post='4977411'] can anyone recommend math book or game programming book that teaches these things? thanks. or answer to this post will do as well [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] [/quote] Well, it depends on how you want them connected. Does it matter?
  14. If you decompose the arbitrary object into convex hulls which approximates the original model, then checking inside/outside of hulls is much simpler.
  15. DX11

    Try posting here: http://area.autodesk.com/forum/autodesk-fbx/fbx-sdk/