I am making a maze game, and I know how to do everything except make it so that you can't just cheat your way through the walls. I am using freeglut with OpenGL in C++ and I would like to know the most effective way of using collision detection ( hopefully without needing to use anything other than freeglut).
OpenGL is just for drawing; it makes things appear onscreen at the coordinates you specify, but it doesn't play a role in deciding what the coordinates of your objects should be. For motion and collision, you may want to use a physics library, such as ODE or Bullet. (There are also bigger, more commercially-oriented physics systems like Havok and PhysX, but those are probably overkill for a simple project.)
Related
I'm currently in the process of developing a very basic 3D OpenGL game in C++ as part of a small college project. We don't get a lot of insight from the teachers however, and only very limited documentation, as well as a small timeframe, so I'm kind of a little lost here at the moment.
My game is a tank battle on an orthogonal plane that pretty much looks exactly like the image I sketched below. Each tank (A and B) can be controlled by a different player, and each one can shoot projectiles, which are supposed to influence the other tank's score upon collision.
My question is, what would be the simplest way of effectively implementing collisions for the tanks? (Tank vs tank, tank vs map boundaries and tank vs any kind of parallelepipedic object like the one in the center of the picture - and the same thing but applied to the projectiles shot from the tank turrets).
Ideally, without the need of using an external physics engine, but also accepted if the implementation can be done easily. At the moment, I'm solely using the GLUT library.
Download and integrate Box2D (http://box2d.org) into your project.
Unless your project is to implement a physics engine, then don't bother doing it yourself. Your time will be much better spent learning how to integratate libraries and how proper physics engines work.
You can then easily use a box collider for your tanks, circle for projectiles and 4 lines for your perimeter. You can create callbacks to notify you when a projectile has collided with another tank.
You will have to use forces and torques to move and rotate your tanks, rather than just updating their positions. But you would probably have to do that anyway if you were going to implement the physics yourself.
The user will input two co ordinates. We have to change them to opposite co ordinates and we should output a rectangle on the screen. Can we do it in C++ ??
Sure we can, it's just not quite as simple. You will need an external library to achieve this result - personally I recommend looking into these two tutorials:
I suggest you learn this if you want 2D graphics
Or this if you want to go all the way
With both SDL and OpenGL, once you learn to understand them of course, your issue will be easy to resolve by writing very simple code - writing a rectangle or a similar object is usually the first thing being taught. The difference is that SDL encompasses fairly complex framework that allows you an efficient use of 2D graphics, while OpenGL (which SDL is based upon) is much more difficult to deal with - the reward, on the other hand, is far more freedom in what you can do.
I'm interested in trying to create realistic fluids (water), for a 2D game. This game is similar to Terraria. I have heard about how you can slap a bunch of colliding particles on the scene and render over it and voila, realistic acting water.
Terraria uses tile based water, which I am not a fan of.. I want something more advanced.
I thought about using bullet 3D physics (box2d has limits I would hit). For non colliding particle effects, I am thinking about using something like SPARK, since I think that'd give me the best of both worlds.
The issue I am thinking about, is that each block is 16x16, so on a 1600x900 scene, there are about 5 thousand tiles.
So I need to tell the physics engine that these tiles are collidable. Of course, there are void tiles that are considered to be non collidable.
Does anyone have ideas on this? Language is C++, I doubt that's relevant though.
EDIT: i think i'm going to have to cave in and use grid based water. I suppose, in retrospect particle based just makes everything more difficult but for what gain?
Your question is about tiled fluids, but you seem to actually be asking about a particle based approach.
If that's the case, what you're looking for is "Smoothed Particle Hydrodynamics", or SPH, which is a very popular technique for 2D and 3D fluid simulations in realtime situations.
Yes, it's basically just a particle system, with each particle responding to the forces in your environment (gravity, collisions etc.) in a reasonable (mathematically stable) way, combined with a constraint that they must stay a certain distance apart in order that the fluid is incompressible.
You can render the particles as points, if you have enough of them, or you can use them as a source for deriving a surface (for example using marching-cubes, though in 2D I wouldn't worry about that).
http://en.wikipedia.org/wiki/Smoothed-particle_hydrodynamics
It has the advantage of being relatively easy to code, and indeed to accelerate on a GPU.
Indeed I think they're probably a better approach than trying some kind of tile-based approach, and you get some more interesting results, such as spray kicking up, waves kicking against the edges of objects, etc. It's not too hard to get something pleasing working, I'd give it a go.
I've spent quite some time searching a simple / fast c++ library (Win / Linux) that can answer the two questions 'does this ray crosses any of the triangles?' or 'where is the first intersection, if there are any?'.
It's for my little game I'm writing and will be used to see if a NPC can see a player and also to check if a player can fall all the way to the ground (or not).
The triangles will not move (well, if you can flag a triangle group 'on' / 'off' that would be nice).
I actually found some libraries but only non-continued (or it seems) like OZCollide for example.
Of course there are all those new shiny Physics engines out there but I don't need 99% of what they offer.
A bonus would be if the library can load .3ds an .b3d files and even better if it can be used in a multi threaded environment (creating several instances of the search data).
Thanks all!
Bullet Physics (http://bulletphysics.org/) is a physics library, but it's built in several layers.
Because of this it can be used as just a collision library which is quite efficient at casting rays through a scene.
(You wouldn't be using or be bothered by any of its physics features)
It's available on Windows and Linux, but also on several more platforms and even on game consoles.
The library is proven and used professionally by various game developers.
It does not directly support .3ds files, but it does has a pipeline for getting geometry from various 3D modelling applications converted to the right format Bullet understands.
It might feel overkill to use it because it's a physics library. But that is actually the reason you should be using it.
A physics library is highly reliant on a good collision library, which actually forces the collision library to be of high quality and offer excellent performance.
Well, there seems to be no 'simple & small' library / code out there so I guess the answer might be 'roll your own'.
That is what I did anyway:
a tool that uses Irrlicht to load up my (static) geometry and then save off all (triangle/vertex) data to a file, just 9 floats for each triangle.
Then a collision library that loads up the data into an octree and the c2005 triangle / ray intersection test and it works OK.
I am writing a very simple 3d particle software rendering system, but I am only really interested in coding the particle system and the rasterizer, so what I am looking for, is the easiest way to go from 3d particle coordinates, through camera, to screen coordinates, but with features like variable FOV, and targeted (look at) camera.
Any additional features such as distance from point to point, bounding volumes etc. would be a bonus, but ease of use is more important to me than features.
The only license requirement is that it's free (as in beer).
You probably want a scenegraph library. Many C++ scene graph libraries exist. OpenScenegraph is popular, Coin3D (free for non-commercial use) is an implementation of the OpenInventor spec, any of them would probably fit your need as it doesn't sound like you need any cutting-edge support. There is also Panda3D, which I've heard is good if you're into Python.
You could do all of this in a straight low-level toolkit like OpenGL but without prior experience it takes a lot longer to get a handle on using OpenGL than any of the scenegraph libraries.
When choosing a scenegraph library it will probably just come down to personal preference as to which API you prefer.
Viewing is done with elementary transformations, the same way that model transformations are done. If you want some convenience functions like gluLookAt() in GLU, then I don't know, but it would be really easy to make your own.
If you do want to make your own Look At function etc. then I can recommend eigen which is a really easy to use linear algebra library for C++.
If you're trying to just focus on the rendering portion of a particle system, I'd go with an established 3D rendering library.
Given your description, you could consider trying to just add your particle rasterization to one or both of the software renderers in Irrlicht. One other advantage of this would be that you could compare your results to the DX/OGL particle effect renderers that already exist. All of the plumbing/camera management/etc would be done for you.
You may also want to have a look at the Armadillo C++ library