Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

140 Neutral

About Tesserex

  • Rank
  1. I need to ask for some opinions for a level editor I'm writing. My game project is the C# Megaman Engine (YouTube), and right now I'm writing the editor. There main form that shows the stage lays out all of the screens based on how they're joined, so that you can see how they connect and the overall layout of your stage. So the issue I'm having is that people can make levels that don't layout in a logical way. This is fine, but it causes problems when displaying it. For example, someone could make a trick room where when you leave one way, and come back the same way, you end up in a different room than where you started. Or one room could loop back on itself. In any case, it may easily be impossible to lay out all the rooms properly. What would be an intuitive interface for showing rooms in this case? I'm thinking that a room that doesn't fit should be moved away some distance until it does fit, and draw a path with arrows between the two joined rooms. But then how would you expect to manipulate these joins? By dragging the screens / join lines around? When you add a new room, would you expect it to be placed on this form, or would you have to drag it onto there and hook it to the other rooms yourself?
  2. Tesserex

    Mega Man Movement Vectors

    YES, the info IS available. I'm making a mega man engine as well, and I found this very helpful. It's on a website for tool-assisted speedruns. Here's the whole page, enjoy! http://tasvideos.org/RockmanData.html
  3. Tesserex

    Vehicle obstacle avoidance

    One thing I did learn in my robotics class last year (never thought I would use actually use this again) was pathfinding. You mentioned you tried robotics stuff - did you try the potential field method? I don't remember the exact equations, but basically, imagine your entire environment as one of those "infinite rubber sheets". Tilt it downward from the start to the finish, so if you were to place a ball at the start, it would roll down toward the goal. Now poke a well down at the goal so the object gets more drawn in and stuck there. At each obstacle, create a hump in the field to repel it. When you place the ball at the start, it will tend to roll down, around the obstacles, and fall into the goal. The bumps and well are some sort of quadratic. The tilt of the field is linear. Just sum up all the individual equations of the tilt, goal, and obstacles to get the total field, then find the gradient at your current location to decide where to go next. You can also add weights (coefficients) to each obstacle to encourage more or less avoidance. Not sure if this is quite what you were asking for, but I hope it helps at least a little.
  4. My main question is what's the best way, for collision between a line and plane, to confine the plane to the surface you're actually drawing? My main problem is that my restrictions don't seem to be working accurately. I have the following, in OpenGL: A quad, drawn in the XY plane, with some Z. Let's just use X and Y to mean half the width and height, since it's drawn with 0,0 at the center. A line with points to define as ray_s and ray_t, found as follows (yes the matrices are properly defined). I'm basically finding whether the mouse is over the object on the screen: POINT mouse; GetCursorPos(&p); ScreenToClient(hWnd, &p); GLfloat winX, winY; winX = (float)mouse.x; winY = (float)mouse.y; winY = (float)viewport[3] - winY; gluUnProject( winX, winY, 0, modelview, projection, viewport, &ray_s.x, &ray_s.y, &ray_s.z); gluUnProject( winX, winY, 1, modelview, projection, viewport, &ray_t.x, &ray_t.y, &ray_t.z); Then I find the collision between this ray and the quad with the following. I have defined * as the dot product. Also ignore my using both temp, the point, and ray, the vector, I didn't define my structs polymorphic enough, but it's the same. I'll fix that later. // this is a func - r1 = ray_s; r2 = ray_t; Point temp = r2-r1; Vector ray = Vector(temp.x, temp.y, temp.z); Vector n = Vector(0,0,1); // normal to XY plane Point p = Point(0,0,z); // point on XY plane float d = n*p; float numer = d - (n*r1); float denom = ray*n; if (denom!=0) { float t = numer/denom; Point i = r1 + (temp*t); // check that it's in the quad if (t>0 && i.y <= y && i.y >= -y && i.x >= -x && i.x <= x) return true; } If I have this function return the entire point of collision, it gives me a correct Z value. However the X and Y values are a bit inflated, if I put my mouse near the borders of the quad, it returns false, because even if I've defined my quad to go from Y = -2 to 2, the collision point returned, at the top of the quad, says something like Y = 2.143... something, or higher. And yes I'll be using this for quads not in the XY plane, I know in this case it could be simpler. Any ideas why this is happening?
  5. Not to say "I follow exactly what everyone tells me", but the article on a simple quaternion camera uses gluLookAt with quaternions. update: I have it basically fixed. Issue 1) I needed to update my camera up vector along with the chase vector. Issue 2) I can't just transform the basis by the chase quaternion and then the ship quaternion - that causes the gimbal lock. Instead, I needed to multiply the camera (chase) and ship quaternions togther, and then apply that to the basis vectors. [Edited by - Tesserex on May 5, 2007 8:12:53 PM]
  6. I think I'm onto it but I dont know what to do next. When I set the camera parameters, the forward vector is given by the ships rotation.transform(chasevect). However, the up vector is just the basis vector transformed.... Hmm, even if I transform the chase vector instead, the "up" part of the chase is never specified. I'm just asking for gimbal lock here. Right?
  7. I have, what I think, is a working quaternion camera control. When I fly my spaceship around it has no gimbal lock. To set the camera (in OpenGL) I use gluLookAt. My up and forward vectors are calculated by the following: up = rotation.Transform(Y_VECT); forward = rotation.Transform(Z_VECT); where rotation is a quaternion. The parameters are just basis vectors. My Transform function looks like this. Remember that it does work (it seems): Vector Transform(Vector v) { Vector nv; nv.x = v.x*(w*w + x*x - y*y - z*z) + v.y*(2*x*y - 2*w*z) + v.z*(2*x*z + 2*w*y); nv.y = v.x*(2*x*y + 2*w*z) + v.y*(w*w - x*x + y*y - z*z) + v.z*(2*y*z - 2*w*x); nv.z = v.x*(2*x*z - 2*w*y) + v.y*(2*y*z + 2*w*x) + v.z*(w*w - x*x - y*y + z*z); return nv; } Now, is this doing the same thing as that "q*p*q^-1" thing I've seen around? Or is it just coincidence that it works in this case? My actual problem. When I try to use this to modify the vector that controls the camera's view relative to the ship (my "chase" vector) it gets gimbal lock. The quaternion used to rotate is a small constant increment. I make the call: chasevect = cam_dx.Transform(chasevect); which I thought would rotate the chase vector by the quaternion cam_dx. It doesn't work. Why? Maybe I'll try the same way as the ship: Instead of incrementing the vector by a constant quaternion, update a new chase quaternion (my function to multiply 2 quaternions I know works) and use the chase quat to transform the original "basis" chase vector. I would think though that the methods should do the same thing. [Edited by - Tesserex on May 5, 2007 8:11:37 PM]
  8. Tesserex

    Quaternion vs Euler Angles

    Nope, two rotations, unless you correctly predict the effects, will not be equivalent to using quaternions. If the rotations are variable, and change often, use quaternions.
  9. Tesserex

    Should I use display lists?

    edit: this entire post was written stupidly and was wrong. Even after gluLookAt, the origin is still the origin, as it always was, right? The rule of thumb is: You move the camera around and draw things where you want, but once its drawn, its pasted on the screen as is and nothing further will change that. We use that feature as an advantage. So... I look at some location and draw my ship. Then, I want to draw an object at (X,Y). Since the display list is at (0,0), I move the camera away from the origin by (X,Y), then draw at (0,0), giving the illusion (because its stuck where its drawn) that its at (X,Y), correct? One thing I don't get: Why is it, that in my skybox code, the first translation is by a POSITIVE campos, and not negative? If the ship is at a location of +campos, shouldn't it be that I move by -campos to return to 0, draw the skybox, then move the camera back? That way it would always be that the skybox is drawn at the same place every frame. I tried that and its not the case. Also note I can't just draw the skybox as the first thing, because then it wouldn't even rotate with the ship, which it should. I also tried two gluLookAt's, the first with no translation and then drawing the skybox - that failed miserably. Another concern - about translation - once my camera is moved around, I have a very strong feeling that just doing a glRotate isn't going to cut it for rotating a distant object around. Maybe its just because I had such a hard time with the quaternion camera. I suppose... since the display list is at (0,0) the object will rotate just fine, and then I take my snapshot (draw it) from the new angle, then carry that drawn image back when I un-rotate and un-translate. Another plus is that since object orientations are in game-space, I don't have to worry about my ship or camera angle affecting how I should rotate for the ship, it's one less set of transformations to do. The game-space axes don't change, just the camera's location and orientation do. [Edited by - Tesserex on April 21, 2007 5:32:38 PM]
  10. I've just learned what display lists are but from what I've read I don't know if I can implement them. I'm writing an engine for a free-roam 3D space flying game. I've got a working quaternion camera and a system for putting objects anywhere and controlling their position and orientation with a reference to game-space (not camera-space). I feel that will make it much easier to keep track of other independent objects down the road, since the camera follows the player's ship. Now the thing is, with this system, if I create display lists to hold things like the swarms of enemy ships or laser blasts, how can I make sure they're drawn in the right place? Keep in mind that any algorithm for drawing a display list object shouldn't require more computing than just redrawing the object the old way. Here's same relevant code: // from the drawing function testplayer.GetView(camup, camfor, campos); // read camera location gluLookAt(campos.x, campos.y, campos.z, campos.x+camfor.x, campos.y+camfor.y, campos.z+camfor.z, camup.x, camup.y, camup.z); // draw skybox - demonstrates my current method for display list drawing, namely, translate-draw-translate back glTranslatef(campos.x,campos.y,campos.z); glCallList(skybox); glTranslatef(-campos.x,-campos.y,-campos.z); testplayer.Draw(); // these objects have game-space locations hard-written into the display lists - they can't be moved or rotated at all like this. glCallList(blocklist); glCallList(olist); Would any other code segments be useful?
  11. Tesserex

    Stuck on moving forward.

    HGE (Haaf's Game Engine) is pretty good. hge.relishgames.com
  12. Ok I have a different question, but it's still about the camera so I decided not to make a new thread. It's about which of two methods to use for third person chase cam. It seems to me there are two equally valid possibilities: A. 1) Translate a set Z distance from the origin 2) Draw the player object at the origin (after rotating properly) 3) gluLookAt the world based on player position B. 1) gluLookAt 2) Draw the player at the correct position it stores This second method I know requires calculating the camera forward vector to have a consistent length maintained in chase, and also finding the proper camera position in the direction behind the player. Does the first method require this as well, or are the gluLookAt parameters simpler? I had what seemed to be a working 3rd person camera but then I guessed (and still am not sure) that when I rotated pitch, the player object was technically moving in space while the camera spun.
  13. Where do you suggest I store data pertaining to vertices that have one color for one face and another for an adjacent face? Should I just make those objects as composites of faces then as a special case? Like a "cube" is one color or corner blended colors, but a "open box with a different colored top" is something else, made of four quads?
  14. Before I get too deep in my program and end up doing an overhaul, I think I'd rather get it right the first time. I'm writing some classes and methods to draw various opengl primitives like the 2d faces, and then the next level up, drawing whole cubes and pyramids and such. I don't know which is better for the 3d objects: storing the data on the points, or data on the faces. Here's my pro/con breakdown: Note: for "points" I have written a struct containing x,y,z,red,green,blue. "Faces" are a struct of three or four points. Storing points: PRO - Smaller total data storage, no redundant information - Transformations performed once per point to save processing time CON - Functions that draw objects will have to be more literal, taking four points for a pyramid and explicitly drawing each face. The alternative is constructing four triangles on the fly and then drawing those. This takes more processing time per frame. - Cannot store differing color information for each face without some other method I haven't thought of yet. Storing as faces: PRO - Since faces are already constructed, only the face-drawing function needs to be called each frame. They don't need to be rebuilt out of points. - Each face can store it's own color and texture information. CON - Faces that share points store redundant data on them, waste of memory. - Redundant points are transformed repeatedly by rotations, waste of processing. Is there some happy medium here? Or is one just better than the other and I haven't realized it yet? Does it matter / depend on the type of program I'm creating? What do you usually do?
  15. Thanks, the enable/disable got it.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!