Jump to content
  • Advertisement
Sign in to follow this  
Paladin2005

About glReadPixels , (is there any thing better too ?)

This topic is 4762 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello Gamedev Members , Ok Im (trying to) develop a game with collision detection etc. using glReadPixels(). The map is in 2d and is a bitmap textured object. The collision detection for the man works fine , as he is generally centerd in the middle of the screen . However when ever he creates projectiles (member class , instances of stored in a vector) how do i get those to detect when they collide with terrrain if they move and even go off the screen ???? Is there any thing better I could use which is simple for collision detection , ie the bullet explodes and is deleted when it is not on 0,0,0 black ??? . Perhaps withought using glReadPixels(), as it is also sloooooow . Also any ideas on how i can make them readthe pixels or something when there off the screen :P , would be helpful . Thanks , Mark

Share this post


Link to post
Share on other sites
Advertisement
The physics simulation and the rendering should be independant.

The player, terrain, and other objects in your game should have their own processing steps where you run your mechanics (physics or motion). This includes turning the player and AI input into forces and motion, collision detection and response, particle system updates, and anything else related to the management of the world.

You need a separate set of steps where your art assets are drawn to the screen at the positions computed by the mechanics engine. The only thing the graphics engine should know about are the location and orientation of objects, and the interpolation between mechanics steps (assuming they are running at different rates).


The mechanics engine should never need to make a call like glReadPixels.

Share this post


Link to post
Share on other sites
Quote:
Original post by frob
The physics simulation and the rendering should be independant.

The player, terrain, and other objects in your game should have their own processing steps where you run your mechanics (physics or motion). This includes turning the player and AI input into forces and motion, collision detection and response, particle system updates, and anything else related to the management of the world.

You need a separate set of steps where your art assets are drawn to the screen at the positions computed by the mechanics engine. The only thing the graphics engine should know about are the location and orientation of objects, and the interpolation between mechanics steps (assuming they are running at different rates).


The mechanics engine should never need to make a call like glReadPixels.


Exactly. Maybe I can clarify. The rendering should not have anythig to do with the collision/physics. You already know how slow glReadPixels is. Instead, you should make it to where you can detect collisions without drawing anything. As in, you have in memory vectors for location, velocity, direction, size, etc... about each object, then using this info, detect whether the objects collide. The drawing may use the same info, but shouldn't change it. As in the above post, keep drawing and physics separate. For this case, I recommend a simple sphere collision if the action is relatively fast. Just use the two positions of two objects, get the distance, then add up the two sizes of the objects. Then if the distance is less than the two sizes they have collided. Say you have the Earth and the moon. The distance is 2000 m(These numbers are way off, just for examples), the earth's size is 1500 m and the moon's is 100 m, when added together get 1600 m, which is less than the distance of 2000 m, so you know they didn't collide.
To optimize this, don't do the square root in the distance part, rather do the square of the two sizes added together, that way you don't do the expensive square root, but still get the same accuracy. This collision detection is probably the quickest way, but isn't too accurate. If the game is slower moving, you need a more accurate method. If it is fast, usually objects collide or they don't collide. Due to the speed, you don't have many of the "close calls" so the user collides or doesn't and won't notice the inaccurate detection.

Share this post


Link to post
Share on other sites
I cna see what your saying , but I am loading bitmaps as my maps (trying to be like worms ) . So ithe charchter / player collides with any terrain which is not black or a certain colour .

Share this post


Link to post
Share on other sites
then you should acces the bitmap data directly, not after it has been drawn. Just use the image you send to the renderer, not the rendered one.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

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

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!