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

HypnotiC

Members
  • Content count

    18
  • Joined

  • Last visited

Community Reputation

162 Neutral

About HypnotiC

  • Rank
    Member
  1. Add some details to cadjunkie's answer:   Assume the path of center is C(t) = (x(t), y(t)), line equation is L: ax+by=0, and the current time is t0. "Translate" the line to find the intersection at t0, say it's P1(x1,y1). Then at any time t, position of P1 would be P1(t) = C(t) + (x1-x(t0), y1-y(t0)) = (x1(t), y1(t)) Now solve the equation for t1:  a * x1(t1) + b * y1(t1) = 0 And t1 - t0 is the answer   Note we need special handling if line equation is y=0
  2. Do you really have a need to work on the generated "binary" file at all, e.g. somehow modify or inspect the file through your Hex editor? If no then why not just store the binaries as std::uint8_t and later read them back as std::uint8_t and convert to 0s and 1s as needed?
  3. slope being close to 90 degree means almost all gravity is applied to y direction, in which case you should directly use Fz = (0,-1,0) 
  4.   How do you differentiate spaces from coordinate systems? I feel they are not 2 distinct entities but rather one is based on the other. When I see people talking about spaces, I always think of those spaces being backed by some coordinate systems and this is essentially how we construct the matrices to transform something from one space to another.
  5. First I think you need to handle the case where there is not collision between the point and the rotating line...   Back to your question. Here is one naïve way (some what similar to what you are doing though): - Since the line is rotating around a fixed point, you should be able to pre-compute the closed area by this rotation (maybe approximated by a circle). - If the point is not in this area then no need to test collision. Once the point is in the area, compute the time when it enters the area and when it leaves the area. Call them T0 and T1. - We know equation of the rotating line and the trajectory of the point (also a line). - Divide interval [T0, T1] into N sub intervals that are small enough according to your desired precision. Call Ti = T0 + i*N; - For each Ti, compute the point position, if it's "on" equation of the rotating line at Ti then done.
  6. Should you also change "y^2" in your partial direvative to "z^2"?
  7. I think the vector r in your gradient equation needs to be normalized
  8. Shouldn't either U or V be sampled from y component of height? You are sampling both of them from x component: float hL = height.Sample(pointSampler, texCoord - float2(recTexDimensions.x, 0.0f)).x; float hR = height.Sample(pointSampler, texCoord).x; float hB = height.Sample(pointSampler, texCoord - float2(0.0f, recTexDimensions.y)).x;   // change to .y? float hT = height.Sample(pointSampler, texCoord).x;  // change to .y?
  9. I don't know what vorticity is so I can not really understand your equation (e.g. in what space is your problem defined? what does pi mean? Does wi stand for weight?...).   I am wondering does it ever make sense to translate this into 2D? - Does Vorticity make sense in 2D? - In 3D, a cross product produces another vector while in 2D a cross product produces a scaler. However, if wi means some kind of weight in a direction, then in 2D you should be able to do something similar with tangent.
  10. I think I should take my previous answer back... That check is indeed quick but doesn't cover all possible collision cases, e.g. your triangle and rectangle can still collide when none of the triangle vertices are inside the rectangle.   Maybe it's only useful as a fast first-round check and if the test fails you then want to fallback to the normal line-line intersection test.
  11. For rectangle and triangle collision detection, I think you don't really need to calculate the edges. You can simply check whether or not any of the 3 vertices of the triangle is in the rectangle. If yes, then it's a collision. This method is simpler and faster, which may also solve your problem no.3 maybe?
  12. I think smart pointers are meant to help manage (long-live) heap objects. If the variables are on stack why bother with smart pointer? Would reference be a better choice? In your case, maybe you can reference to the vector that contains the scenes.
  13. I have not used Boost serialization library yet. But I know you can specify the input/output file to store your archive. Can you group your objects or containers before you serialize them? Then when you desterilize you can simply choose the archive you need instead of loading everything from a giant archive.
  14. I think a simple but somehow less manageable approach is just to use template and typedef:   template<class GraphicBackEnd, class VideoBackEnd> class MyGameEngine { public:   MyGameEngine() : graphic(new GraphicBackEnd), video(new VideoBackEnd) {} private:   GraphicBackEnd* graphic;   VideoBackEnd* video; };   And somewhere you do a typedef: #ifdef _MSC_VER   typedef DXGraphicBackEnd MyGraphicBackEnd;   typedef WindowVideoBackEnd MyVideoBackEnd; #elseif __GNUG__    typedef GNUGraphicBackEnd MyGraphicBackEnd;   typedef GNUVideoBackEnd MyVideoBackEnd; # else    typedef OSXGraphicBackEnd MyGraphicBackEnd;   typedef OSXVideoBackEnd MyVideoBackEnd; #endif   Finally in you game.cpp: int main() {   MyGameEngine<MyGraphicBackEnd, MyVideoBackEnd> gameEngine;   ... }    
  15. I don't quite understand why you were bothered...   1) when user hit jump button, you can simply give velocity a positive y value, and everything else remains the same.    2) I think you don't need to clamp velocity.y, but need to check for position.y so if you hit ground then velocity.y should be set to zero.   Do I understand your question correctly or completely wrong?