I am working on a gesture tracking feature for a virtual reality game I am working on. I need to keep track of the players hand coordinates to check them against a existing gesture. I only want to track on the X and Y. My Problem is taking the 3D coordinates and making them 2D. Any suggestions are welcome. Thanks for your time.
Related
I am making a 2D game and I have created two circles, one named player and one named enemy. The circles are drawn by calling a drawPlayerCircle and drawEnemyCircle function, both which are called in my display() function. At the moment my project isn't Object Orientated which you can already probably tell. My collision works for both circles as I have calculated penetration vectors and normalised vectors etc... However my question is, expanding this game further by having 10-20 enemies in the game, how can I work out the collision to every single enemy quickly rather than calculating manually the penetration and normalised vectors between my player and every enemy in the game which is obviously very inefficient. I'm guessing splitting my player and enemy entities into their own class but I'm still struggling to visualise how the collision will work.
Any help will be greatly appreciated! :)
Collision between two circles is very quick to test. Just check if the distance between the circle centre points is less than the sum of the two radii.
I would just start by comparing the player against every other enemy. Doing 20 comparisons is not going to tax any computer from the last 10 years. I'm a big believer in just writing the code that you need right now and not complicating things, especially when you are just starting out.
However if you end up having millions of circles and you've profiled your code and found that testing all circles is slow, there are quite a few options. The simplest might be to have a grid over the play area.
Each grid cell covers a fixed amount of space over the play area and stores a list of circles. Whenever a circle moves calculate which grid cell it should be in. Remove it from the grid cell that it is currently in, and add it to the grid cell that it should be in. Then you can compare only the circles that overlap the player's grid cell.
Space partitioning. Specifically, if you're in 2D, you can use a quadtree to speed up collision detection.
I'm self learning C++ and playing around 2D tile mapping.
I have been reading through this scrolling post here, which is based on this tiling tutorial.
Using the above tutorial and some help from the Pearson, Computer Graphics with OpenGL book I have written a small program that draws a 40x40 tiled world and a Sprite (also a tile).
In terms of drawing/render order, the map(or world) itself is that back layer and the Sprite is the forward most (or top) layer. I'm assuming that's a good way of doing it as its easier for 2 tiles to interact than a tile and a custom sprite or rectangle. Is that correct?
I have implemented a Keyhandling() function that lets you move the map inside the viewport using the keyboards arrow keys. I have a variable called offsetx, offsety that when a key is pressed increases or decreases. Depending on whether I assign the variable to the map or sprite, I can more one or the other in any direction on the screen.
Neither seems to work very well, so I assigned the variables to both (map and sprite) but with positive values for the sprite, and negative for the map. So upon a key press, this allows my Sprite to move in one direction whilst the map moves in the opposite direction.
My problem is, the sprite soon moves enough to leave the window and not enough to bring the more of the map into the scene. (The window only shows about 1/8th of the tiles at any one time).
I've been thinking all day, and I think an efficient/effective way to solve this issue would be to fix the sprite to the centre of the screen and when a key is pressed the map moves around... I'm unsure how to implement this though.
Would that be a good way? Or is it expected to move the viewport or camera too?
You don't want to move everything relative to the Sprite whenever your character moves. Consider a more complicated world where you also have other things on the map, eg other sprites. It's simplest to keep the map fixed, and move each sprite relative to the map, (if it's a movable sprite). It just doesn't make much sense to move everything in the world whenever your character moves around in the world.
If you want to render your world with your character always at the center, that's perfectly fine. The best thing to do is move the camera. This also allows you to zoom your camera in/out, rotate the camera, etc. with very little hassle in keeping track of all the objects in the world.
Be careful with your usage of the word "viewport". It means a very specific thing in OpenGL. (ie, look at the function glViewport). If your book uses it differently, that's fine. I'm just pointing this out because it's not 100% clear to me what you mean by it.
Question on how this could be done, if possible.
I have sprites in each of the following directions (up, down, left, right, upright, upleft, downright, and downleft). I am making a similar game to the old school zelda, running around a tile map (using tiled editor). This is working well, until now, I want to be able to shoot arrows/spells at any location on the map. I can do so, but the graphics look horrible because my guy will only turn each 45 degrees.
I have corrected this so I can only shoot in the direction my guy is facing, but now I can't hit them if they are not at a 45 degree angle from me. To fix this, I need to have a sprite at every 1 degree, or somehow combine the images say at 0 degrees (up) and 45 degrees (upright) to be able to get say 10 degrees via interpolation. Is this possible? Any ideas on how to do this?
I am looking into working with key animations since I wouldn't have to have so many sprites and use much less video memory (and smoother animations), but I still run into this same problem. Would like to know if this is conceptually possible and if so, a little psuedo code or snipit would be much appreciated.
One other question, if this is possible, do I need to be rendering this via openGL in 3D? Didn't really know if 3d would help in a 2d (orthogonal tile) game, but it might help spells falling look like they are falling downward more than moving across tiles from above to below?
I am kinda new to all this but I am trying to make myself a simple 2D game in c++.
I have decided to do a kind of a maze type game and what I am doing for this is drawing out the maze as a texture and then having another texture as my character move around inside this maze.
However I am hugely struggling with the collision detection so that my character doesn't just walk through the walls. I have been told that I can use glReadPixels to find the colour of the background but whenever I try this it just ignores the colour and still continues on through the walls.
Can anybody please help me with this and tell me how I can do it as I cannot find anything anywhere which can help.
Thanks in advance.
Depending on the maze type, if you only have vertical and horizontal walls of unit length, you could reprezent the maze and current position in a 2D array/matrix and decide whether the new position is OK to move into based on the content of the new position in the maze matrix.
You will have to do some translation to/from matrix coordinates and screen coordinates
Advantages:
you don't need to read from the screen
maze can be larger than what fits on the screen -- draw the relevant portion only
Disadvantages:
you can only have "bolck" type terrain (e.g. vertical/horizontal walls)
if you want to add movign enemies, the collision detection can be too coarse (you cannot avoid the monster "just by a hair/pixel")
I'm developing a game that basically has its entire terrain made out of AABB boxes. I know the verticies, minimum, and maximum of each box. I also set up my camera like this:
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
glRotatef(Camera.rotx,1,0,0);
glRotatef(Camera.roty,0,1,0);
glRotatef(Camera.rotz,0,0,1);
glTranslatef(-Camera.x,-Camera.y,-Camera.z);
What I'm trying to do is basically find the cube the mouse is on. I thought about giving the mouse position a forward directional vector and simply iterating through until the 'mouse bullet' hits something. However this envolves interating through all objects several times. Is there a way I could do it by only iterating through all the objects once?
Thanks
This is usually referred to as 'picking' This here looks like a good gl based link
If that is tldr, then a basic algorithm you could use
sort objects by z (or keep them sorted by z, or depth buffer tricks etc)
iterate and do a bounds test, stopping when you hit the first one.
This is called Ray Tracing (oops, my mistake, it's actually Ray Casting). Every Physics engine has this functionality. You can look at one of the simplest - ODE, or it's derivative - Bullet. They are open-source so you can take out what you don't need. They both have a handy math library that handles all oftenly needed matrix and vertex operations.
They all have demos on how to do exactly this task.
I suggest you consider looking at this issue from a bigger perspective.
The boxes are just points at a lower resolution. The trick is to reduce the resolution of the mouse to figure out which box it is on.
You may have to perform a 2d to 3d conversion (or vice versa). In most games, the mouse lives in a 2d coordinate world. The stuff "under" the mouse is a 2d projection of a 3d universe.
You want to use a 3D picking algorithm. The idea is that you draw a ray from the user's position in the virtual world in the direction of the click. This blog post explains very clearly how to implement such an algorithm. Essentially your screen coordinates need to be transformed from the screen space to the virtual world space. There's a website that has a very good description about the various transformations involved and I can't post the link due to my rank. Search for book of hook's mouse picking algorithm [I do not own the site and I haven't authored the document].
Once you get a ray in the desired direction, you need to perform tests for intersection with the geometries in the real world. Since you have AABB boxes entirely, you can use simple vector equations to check which geometry intersects the ray. I would say that approximating your boxes as a sphere would make life very easy since there is a very simple sphere-ray intersection test. So, your ray would be described by what you obtain from the first step (the ray drawn in the first step) and then you would need to use an intersection test. If you're ok with using spheres, the center of the sphere would be the point you draw your box and the diameter would be the width of your box.
Good Luck!