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

Cydriic

Members
  • Content count

    49
  • Joined

  • Last visited

Community Reputation

174 Neutral

About Cydriic

  • Rank
    Member

Personal Information

  • Location
    Montreal, Quebec Canada
  1. Thank Apoch,   I followed your advice and went to work! Fixed it, now it works awesome here is the code.   So basically I compute all my potential intersection point Ts.    Then I test the potential itersection points on the Box collision mesh, discarding all point related to a negative T, because that would mean my Ray is colliding with a Box that is behind the character firing.     So here is the fixed code for my Ray Vs Box, thanks everyone.   Note that the collision test is different depending on the Rotation of the Box around the Y (up vector) Axis. Because, this code applies for Boxes that are Aligned with the Grid (where Y is the Up vector). Therefore, my box will only have two possible Rotations in the world 0.0f and 90.0f.   I use it for outside containers, crates, tables and walls in my game. Other objects use a Ray vs Sphere Collision test for now.     bool CWall3x3::FastProjectileCollisions( GLfloat x, GLfloat y, GLfloat z, GLfloat Rotx, GLfloat Roty ) {   if(m_Roty == 0.0f) {   //COMPUTE Ts GLfloat T0x = (m_x - 300.0f - x)/( -(float)sin(Roty*piover180) ); GLfloat T1x = (m_x + 300.0f - x)/( -(float)sin(Roty*piover180) );   GLfloat T0y = (m_y - 300.0f - y)/( -(float)sin(Rotx*piover180) ); GLfloat T1y = (m_y + 300.0f - y)/( -(float)sin(Rotx*piover180) );   GLfloat T0z = (m_z - 10.0f - z)/( -(float)cos(Roty*piover180) ); GLfloat T1z = (m_z + 10.0f - z)/( -(float)cos(Roty*piover180) );   //COMPUTE COLLISION COORDINATES     if(T0x > 0) { m_Cx = x - (float)sin(Roty*piover180) * T0x; m_Cy = y - (float)sin(Rotx*piover180) * T0x; m_Cz = z - (float)cos(Roty*piover180) * T0x;     //RAY INTERSECTS RETURN TRUE if(m_Cx >= m_x - 300.0f && m_Cx <= m_x + 300.0f && m_Cy >= m_y - 300.0f && m_Cy <= m_y + 300.0f && m_Cz >= m_z - 10.0f && m_Cz <= m_z + 10.0f) return true; }     if(T1x > 0) { m_Cx = x - (float)sin(Roty*piover180) * T1x; m_Cy = y - (float)sin(Rotx*piover180) * T1x; m_Cz = z - (float)cos(Roty*piover180) * T1x;     //RAY INTERSECTS RETURN TRUE if(m_Cx >= m_x - 300.0f && m_Cx <= m_x + 300.0f && m_Cy >= m_y - 300.0f && m_Cy <= m_y + 300.0f && m_Cz >= m_z - 10.0f && m_Cz <= m_z + 10.0f) return true; }     if(T0y > 0) { m_Cx = x - (float)sin(Roty*piover180) * T0y; m_Cy = y - (float)sin(Rotx*piover180) * T0y; m_Cz = z - (float)cos(Roty*piover180) * T0y;     //RAY INTERSECTS RETURN TRUE if(m_Cx >= m_x - 300.0f && m_Cx <= m_x + 300.0f && m_Cy >= m_y - 300.0f && m_Cy <= m_y + 300.0f && m_Cz >= m_z - 10.0f && m_Cz <= m_z + 10.0f) return true; }     if(T1y > 0) { m_Cx = x - (float)sin(Roty*piover180) * T1y; m_Cy = y - (float)sin(Rotx*piover180) * T1y; m_Cz = z - (float)cos(Roty*piover180) * T1y;     //RAY INTERSECTS RETURN TRUE if(m_Cx >= m_x - 300.0f && m_Cx <= m_x + 300.0f && m_Cy >= m_y - 300.0f && m_Cy <= m_y + 300.0f && m_Cz >= m_z - 10.0f && m_Cz <= m_z + 10.0f) return true; }   if(T0z > 0) { m_Cx = x - (float)sin(Roty*piover180) * T0z; m_Cy = y - (float)sin(Rotx*piover180) * T0z; m_Cz = z - (float)cos(Roty*piover180) * T0z;     //RAY INTERSECTS RETURN TRUE if(m_Cx >= m_x - 300.0f && m_Cx <= m_x + 300.0f && m_Cy >= m_y - 300.0f && m_Cy <= m_y + 300.0f && m_Cz >= m_z - 10.0f && m_Cz <= m_z + 10.0f) return true; }   if(T1z > 0) { m_Cx = x - (float)sin(Roty*piover180) * T1z; m_Cy = y - (float)sin(Rotx*piover180) * T1z; m_Cz = z - (float)cos(Roty*piover180) * T1z;     //RAY INTERSECTS RETURN TRUE if(m_Cx >= m_x - 300.0f && m_Cx <= m_x + 300.0f && m_Cy >= m_y - 300.0f && m_Cy <= m_y + 300.0f && m_Cz >= m_z - 10.0f && m_Cz <= m_z + 10.0f) return true; }   }   if(m_Roty == 90.0f) {   //COMPUTE Ts GLfloat T0x = (m_x - 10.0f - x)/( -(float)sin(Roty*piover180) ); GLfloat T1x = (m_x + 10.0f - x)/( -(float)sin(Roty*piover180) );   GLfloat T0y = (m_y - 300.0f - y)/( -(float)sin(Rotx*piover180) ); GLfloat T1y = (m_y + 300.0f - y)/( -(float)sin(Rotx*piover180) );   GLfloat T0z = (m_z - 300.0f - z)/( -(float)cos(Roty*piover180) ); GLfloat T1z = (m_z + 300.0f - z)/( -(float)cos(Roty*piover180) );     //COMPUTE COLLISION COORDINATES   if(T0x > 0) { m_Cx = x - (float)sin(Roty*piover180) * T0x; m_Cy = y - (float)sin(Rotx*piover180) * T0x; m_Cz = z - (float)cos(Roty*piover180) * T0x;     //RAY INTERSECTS RETURN TRUE if(m_Cx >= m_x - 10.0f && m_Cx <= m_x + 10.0f && m_Cy >= m_y - 300.0f && m_Cy <= m_y + 300.0f && m_Cz >= m_z - 300.0f && m_Cz <= m_z + 300.0f) return true; }   if(T1x > 0) { m_Cx = x - (float)sin(Roty*piover180) * T1x; m_Cy = y - (float)sin(Rotx*piover180) * T1x; m_Cz = z - (float)cos(Roty*piover180) * T1x;     //RAY INTERSECTS RETURN TRUE if(m_Cx >= m_x - 10.0f && m_Cx <= m_x + 10.0f && m_Cy >= m_y - 300.0f && m_Cy <= m_y + 300.0f && m_Cz >= m_z - 300.0f && m_Cz <= m_z + 300.0f) return true; }   if(T0y > 0) { m_Cx = x - (float)sin(Roty*piover180) * T0y; m_Cy = y - (float)sin(Rotx*piover180) * T0y; m_Cz = z - (float)cos(Roty*piover180) * T0y;     //RAY INTERSECTS RETURN TRUE if(m_Cx >= m_x - 10.0f && m_Cx <= m_x + 10.0f && m_Cy >= m_y - 300.0f && m_Cy <= m_y + 300.0f && m_Cz >= m_z - 300.0f && m_Cz <= m_z + 300.0f) return true; }   if(T1y > 0) { m_Cx = x - (float)sin(Roty*piover180) * T1y; m_Cy = y - (float)sin(Rotx*piover180) * T1y; m_Cz = z - (float)cos(Roty*piover180) * T1y;     //RAY INTERSECTS RETURN TRUE if(m_Cx >= m_x - 10.0f && m_Cx <= m_x + 10.0f && m_Cy >= m_y - 300.0f && m_Cy <= m_y + 300.0f && m_Cz >= m_z - 300.0f && m_Cz <= m_z + 300.0f) return true; }   if(T0z > 0) { m_Cx = x - (float)sin(Roty*piover180) * T0z; m_Cy = y - (float)sin(Rotx*piover180) * T0z; m_Cz = z - (float)cos(Roty*piover180) * T0z;     //RAY INTERSECTS RETURN TRUE if(m_Cx >= m_x - 10.0f && m_Cx <= m_x + 10.0f && m_Cy >= m_y - 300.0f && m_Cy <= m_y + 300.0f && m_Cz >= m_z - 300.0f && m_Cz <= m_z + 300.0f) return true; }     if(T1z > 0) { m_Cx = x - (float)sin(Roty*piover180) * T1z; m_Cy = y - (float)sin(Rotx*piover180) * T1z; m_Cz = z - (float)cos(Roty*piover180) * T1z;     //RAY INTERSECTS RETURN TRUE if(m_Cx >= m_x - 10.0f && m_Cx <= m_x + 10.0f && m_Cy >= m_y - 300.0f && m_Cy <= m_y + 300.0f && m_Cz >= m_z - 300.0f && m_Cz <= m_z + 300.0f) return true; }   }   return false;   }
  2. Sup Everyone,   I'm having a problem where my Ray vs Box algorithm doesn't seem to work.   Sometimes it return a collision, but 98% of the time it doesn't.     The algorithm seems good though.   Can anyone tell me if you see anything misplaced or missing?     This is a code snippet from my Wall3x3 Object.   m_x, m_y, m_z is the center of my wall.   x,y,z are the coordinates of the Origin of the Ray. Roty and Rotx are the angles of the Ray's direction.   m_Cx, m_Cy and m_Cz are the coordinates of the collision point.   Finally, my wall is 600 wide by 20 thick by 600 high. Thus the m_x - 300 and m_x + 300 and ect and my Box boundaries.     bool CWall3x3::FastProjectileCollisions( GLfloat x, GLfloat y, GLfloat z, GLfloat Rotx, GLfloat Roty ) {     //COMPUTE Ts GLfloat T0x = (m_x - 300.0f - x)/( -(float)sin(Roty*piover180) ); GLfloat T1x = (m_x + 300.0f - x)/( -(float)sin(Roty*piover180) );   GLfloat T0y = (m_y - 300.0f - y)/( -(float)sin(Rotx*piover180) ); GLfloat T1y = (m_y + 300.0f - y)/( -(float)sin(Rotx*piover180) );   GLfloat T0z = (m_z + 10.0f - z)/( -(float)cos(Roty*piover180) ); GLfloat T1z = (m_z - 10.0f - z)/( -(float)cos(Roty*piover180) );   //COMPUTE TMIN AND TMAX GLfloat Tmin; GLfloat Tmax;   //Tmin if(T0x > T0y) Tmin = T0x;   if(T0y > T0x) Tmin = T0y;   //Tmax if(T1x > T1y) Tmax = T1x;   if(T1y > T1x) Tmax = T1y;     //FIRST MISS BOX CHECK if(T0x > T1y || T0y > T1x) return false;     //EXTEND TO 3D //SECOND MISS BOX CHECK if(Tmin > T1z || T0z > Tmax) return false;     //ALSO if(T0z > Tmin) Tmin = T0z;   if(T1z < Tmax) Tmax = T1z;   //COMPUTE COLLISION COORDINATES m_Cx = x - (float)sin(Roty*piover180) * Tmin; m_Cy = y - (float)sin(Rotx*piover180) * Tmin; m_Cz = z - (float)cos(Roty*piover180) * Tmin;   //RAY INTERSECTS RETURN TRUE return true;   }
  3. IT WORKS!!!!   WOUHOU ! you guys are the best in the universe.     Thank you!
  4. Yessir, CCRicer , you are totally right, it at least improves performance.   And to answer your question, yes the ray will collide with object in front and behind, not only behind if the collision behind happens.   Aressera , Thank you very much for your great answer I did not know that. I will do that.   Ravyne, you're awesome.   All your answers together are helping me a great deal, thank you very much!    Peace my Matrix Brothers. :)
  5. Thanks, it's a good Idea.     I thought about it and it would work, but it seems to be limited.   I mean, is this a common problem with ray casting or am I missing something here? Is the culling of spheres behind the character that is firing the ACTUAL thing that is missing?   I'm trying first to not have to do that.
  6. Hi Everyone,   I'm having this weird issue with my code for projectile collisions in my 3D game.   My gun functions with casting a Ray and checking for collisions against Spheres around my objects , located in the appropriate Collision Tile, of my Uniform Grid Tile System.   Now everything works fin, but sometimes for a reason I can't figure out, my Ray Collides with spheres behind the character firing the gun. And so it screwes up everything, and since I have a sorting process right after collision detections that determines which collision happened first to determine which object takes the fire (because my projectile does not travel through objects) it makes it not work as it should.   Here is some code that shows you what going on.   DragonSC is a car object and here is the collision code that determines if the DragonSC's Collision Sphere, collides with the Ray being Casted. x,y,z are the starting coordinates of my ray, starting at the Tip of the Fired Gun, xa, ya, za are the end coordinates of the ray (10000.0f further down the Line). Roty is the Angle the Firing character is facing and Rotx is the Angle at which the gun is firing, meaning at 90.0f the gun would be firing straight up in the air, parrallel to the Y axis.   Is there anything not right in my algorythm, I checked it 100 times using Sources on Stack Overflow and my Mathematics for 3D Game Programming & Computer Graphics Book by Eric Lengyel.     bool CDragonSC::FastProjectileCollisions(GLfloat x, GLfloat y, GLfloat z, GLfloat Rotx, GLfloat Roty) {     //COMPUTE END POINT OF THE LINE 10000.0F UNITS FURTHER FROM THE START GLfloat xa = x - (float)sin(Roty*piover180) * 10000.0f; GLfloat ya = y - (float)sin(Rotx*piover180) * 10000.0f; GLfloat za = z - (float)cos(Roty*piover180) * 10000.0f;   //COMPUTE COEFFICIENTS GLfloat a = (xa-x)*(xa-x)+(ya-y)*(ya-y)+(za-z)*(za-z); GLfloat b = 2*((xa-x)*(x-m_x)+(ya-y)*(y-m_y)+(za-z)*(z-m_z)); GLfloat c = (x-m_x)*(x-m_x)+(y-m_y)*(y-m_y)+(z-m_z)*(z-m_z)-( 640000 );   //COMPUTE DELTA GLfloat Delta=(b*b)-4*a*c;   //INITIALIZE SOME VARIABLES GLfloat d, d2, xc, yc, zc, xc2, yc2, zc2;   //NO COLLISION if(Delta < 0) return false;   //ONE COLLISION if(Delta == 0) { d = b/(2*a);   //COLLISION COORDINATES xc = x + d*(xa-x); yc = y + d*(ya-y); zc = z + d*(za-z);   //SET OBJECTS COLLISION COORDINATES m_Cx = xc; m_Cy = yc; m_Cz = zc;   return true; }   //TWO COLLISION POINTS if(Delta > 0) {   d=(-b-sqrt(Delta))/(2*a);   d2=(-b+sqrt(Delta))/(2*a);   //COLLISION COORDINATES xc = x + d*(xa-x); yc = y + d*(ya-y); zc = z + d*(za-z);   xc2 = x + d2*(xa-x); yc2 = y + d2*(ya-y); zc2 = z + d2*(za-z);   //SET OBJECTS COLLISION COORDINATES m_Cx = xc; m_Cy = yc; m_Cz = zc;   return true; }   return false; }      Thanks
  7. Hi Everyone,     I'm working on setting up a Sunlight for my 3D Game.   Up to now the best way I found was to enable a GL_Light and place it in the sky at a certain distance, and have it be placed outside of my main glRotatef and glTranslatef so that like a skyboxe it remains constant.   It's fun but i'm sure there are better ways of doing it.     Anybody would like to share their ideas on creating a cool SunLight?     Thanks!
  8.   I find the best way to learn for me is to dive in and start practicing actively right away. I find that having a practical hands on approach while being driven with high motivation is the best way. Just learning about a language without directly applying it to something I really want to do, never worked for me.    You practice and practice and as you're moving forward, question arise, and you find the answers as you go and keep on learning. Game programming is very complex. It's going to take a lot of work, a lot of trial and errors.
  9. Hi,   If you have no C++ Game Programming Knowledge, you could start with this tutorial , it will show you how to set up a little 2D SDL code base and from there you can start to learn. Just go through all the tutorials and write the code while following the video, don't worry if you don't understand, as you do it and do it more, things will start to fall in place.   https://www.youtube.com/watch?v=b1BLuYorzX0&list=PLHM_A02NtaaVey-4Ezh7p6bbOsv-DKA-0   This is what I started with and it did wonders for me.   You could also do the Nehe tutorials too, but since its 3D there is a bit more to it, I suggest you start with SDL in 2D, SDL sets up a lot of stuff for you, like creating a Windows window easily.   Don't be turned off by the obstacles, you'll overcome every single one of them. It just takes dedication.     Peace!
  10. I started two years ago, straight in c++ with the "Let's make an RPG" SDL tutorials from Code Rad on You tube. I didn't know anything, not even what a boolean was. All I knew about programming was QBasic back in 1993 which I did for one year back then, and thats it. No C++ nothing. Just the love of games :).   So I only did that and built a few games and always aimed at learning more.   Then my friend Pierric Gimmig who works at Warner Bros in Montreal looked at my stuff and became kind of my mentor, he showed my how to code classes and use Vectors.   Then after a year of programming non stop, game to game, he told me "Ok now you should Learn OpenGL, fuck SDL, go do all the nehe tutorials" because at that point I had some pretty cool final fantasy style game code running, and I had some issue with SDL being too costly using SDL_RenderCopy all the time to bring my grafix on screen.   So came here to NEHE, started doing all the tutorials on OpenGL, and here I am about 8 months later and loving it, and having a blast programming my 3D games.   Game programming is my favorite thing in the world.
  11. Basically should replace all the coded vectors :   m_x -= (float)sin((m_Roty-90.0f)*piover180) * m_WalkSpeed; m_z -= (float)cos((m_Roty-90.0f)*piover180) * m_WalkSpeed;   With a Vector Object...   Anybody got some tips...?     Thanks.
  12. Here's is my favorite:   https://www.youtube.com/watch?v=b1BLuYorzX0   It's Konrad Jablonski. This is what I started with in Juin 2013, and now I'm programming OpenGL 3D Games. And Konrad is the best he'll answer all questions.     Peace
  13. Hi everyone,   Ok so i've been thinking about trying to integrate vector math in a more advanced fashion.   I would like to know, can anyone guide me to a cool and good tutorial on how 3D vector math can really be applied as a Class to my game.   This is how i've been using it in my 3D Game, it's directly coded where my movement and collisions happen, but I know that I should be making a class of vectors, and then applying it to where I'm supposed, I know it will greatly improve my stuff.   //MOVE FORWARD if(m_MovingForward) { if(m_InCar == 0) { m_IsMoving = 1;   m_x -= (float)sin(m_Roty*piover180) * m_WalkSpeed; m_z -= (float)cos(m_Roty*piover180) * m_WalkSpeed; }   if(m_InCar == 1) { m_IsMoving = 1;   m_Car->m_x -= (float)sin(m_Roty*piover180) * m_Car->m_CarSpeed; m_Car->m_z -= (float)cos(m_Roty*piover180) * m_Car->m_CarSpeed;   m_x = m_Car->m_x; m_z = m_Car->m_z;   }   }   //MOVE BACKWARD if(m_MovingBackward) { if(m_InCar == 0) { m_IsMoving = 1;   m_x += (float)sin(m_Roty*piover180) * m_WalkSpeed; m_z += (float)cos(m_Roty*piover180) * m_WalkSpeed; }   if(m_InCar == 1) { m_IsMoving = 1;   m_Car->m_x += (float)sin(m_Roty*piover180) * m_Car->m_CarSpeed; m_Car->m_z += (float)cos(m_Roty*piover180) * m_Car->m_CarSpeed;   m_x = m_Car->m_x; m_z = m_Car->m_z;   }   }   //STRAFE LEFT if(m_StrafeLeft) { if(m_InCar == 0) { m_IsMoving = 1;   m_x -= (float)sin((m_Roty+90.0f)*piover180) * m_WalkSpeed; m_z -= (float)cos((m_Roty+90.0f)*piover180) * m_WalkSpeed; }   if(m_InCar == 1) { m_IsMoving = 1;   m_Car->m_x -= (float)sin((m_Roty+90.0f)*piover180) * m_Car->m_CarSpeed; m_Car->m_z -= (float)cos((m_Roty+90.0f)*piover180) * m_Car->m_CarSpeed;   m_x = m_Car->m_x; m_z = m_Car->m_z;   }   }   //STRAFE RIGHT if(m_StrafeRight) { if(m_InCar == 0) { m_IsMoving = 1;   m_x -= (float)sin((m_Roty-90.0f)*piover180) * m_WalkSpeed; m_z -= (float)cos((m_Roty-90.0f)*piover180) * m_WalkSpeed; }   if(m_InCar == 1) { m_IsMoving = 1;   m_Car->m_x -= (float)sin((m_Roty-90.0f)*piover180) * m_Car->m_CarSpeed; m_Car->m_z -= (float)cos((m_Roty-90.0f)*piover180) * m_Car->m_CarSpeed;   m_x = m_Car->m_x; m_z = m_Car->m_z;   }   }    Thanks guys