0

I just got camera zoom with OpenGL up and running in my little Pyglet game, but now I'm facing a problem: When I zoom in or out, the game objects' hitboxes won't obviously scale, so the game doesn't respond to mouse events correctly. Altering thousands of objects' properties might just be a bit slow, so I was wondering if I could modify the mouse's position instead. I just have no idea how. Zooming is done by glOrtho(), with multiplying the parameters.

Zooming code (self.dx and self.dy are the total movement of the camera so far, and self.zoom is a multiplier from 0.1 to 2):

pyglet.gl.glMatrixMode(pyglet.gl.GL_PROJECTION)
pyglet.gl.glLoadIdentity()
pyglet.gl.glOrtho(-screen.width / (2 * self.zoom), screen.width / (2 * self.zoom), -screen.height / (2 * self.zoom), screen.height / (2 * self.zoom), -1, 1)
pyglet.gl.glTranslatef(self.dx - screen.width / 2, self.dy - screen.height / 2, 0)
pyglet.gl.glMatrixMode(pyglet.gl.GL_MODELVIEW)

Edit

What about reversing the zooming calculations for the mouse coordinates?

Edit 2

The way I'm handling mouse collisions with game objects is at least notorious. I'm actually using pygame.Rect objects to represent object's position, and then colliding it with mouse's position. It has worked great so far, since I haven't done any zooming until now. Maybe there's a way that suits better the OpenGL/3D world?

Syklis
  • 109
  • 2
  • 10
  • I suppose you're making a 2D game? It's a common problem with these. Most "proper" (not necessarily but they are called that way) 2D games are in fact 3D games with a restricted camera (no rotation). To zoom in you just have to make the view angle smaller. –  Oct 06 '12 at 16:11
  • Yes, I'm making a 2D game, and it doesn't need any rotation. But I think I'm already doing that? – Syklis Oct 06 '12 at 16:28
  • If you're already doing that -> aka you have 2 triangles on which you draw your texture that are paired together into one object and to zoom in/out you change the view angle... You wouldn't have this problem. Of course, if your hitboxes are defined in screenspace you would but they *should* be tied to the object, no? –  Oct 06 '12 at 16:39
  • I believe hitboxes and the way I'm using them is the problem here. Basically they didn't change at all when I jumped from SDL to OpenGL. I really have no idea how I could do it otherwise, though. – Syklis Oct 06 '12 at 16:44

1 Answers1

1

If you are using pygame.Rect you're specifying a point on the screen, not a point in the 3d world.

What you should have is:
A base class "enemy".
Any "enemy" must have two opengl triangles, a texture and a "hitbox" object.
A hitbox object specifies two opposite corners in 2D space. It is assumed that the 3d coordinate is the same as the two triangles. You can choose the triangles to determine the hitbox, in that case no need for an actual object, just forget it and override the access functions.
When you shoot, determine a 3d vector of the direction of the shot. Divide the screen in two, left/right and determine where it was shot. Then same with down/up. Then browse through your targets. Check for visibility 1st, if visible, check for side of screen, if right side, check if projectile would hit. Then get a collection of all those it would hit and only hit the 1st one.

Illustrated above is one of the many versions of how this may be done. It's one I quickly came up with. I hope that looking at it you will realize what is wrong (probably the fact that the hitboxes have nothing to do at all with your actual enemies) and be capable of fixing it based on the example.

  • 1
    Got your point, but not exactly the demonstration. Will definitely look into this. Note-to-self: Learn to do stuff in the current environment from the beginning and don't try to smuggle it in from the previous one, it'll only end up broken in the end. – Syklis Oct 06 '12 at 17:10
  • 1
    ^ very good point. I tried learning ruby once. I used it as python. I had a bad time. Then I decided to look more carefully. **OMG ALL THIS SUGAR <3 <3 <3 <3** –  Oct 06 '12 at 17:14