A very simple camera lib

[Rockford]

Hi,

I know this is an old thread, but seeing as it is about this library I thought it okay : )

I am running into a problem that my inexperienced mind cant figure out.

Here is what I have:

A player that moves with the camera. Can move around freely without affecting what the camera looks at.

The camera moves at a steady rate of 15 * dt upwards.

I have enemies that move independently of the camera - that shoot at the player.

I cant figure out how to have the bullets from the independent enemies, target the player. Either the bullets (from a "tank") appear from the middle of the screen, or if I switch it up, the bullets target an area just above the player (but appear at the tank). The bullets are "heatseekers" so they follow the player around.

I know that I need to account for the fact that the tanks and its bullets are using the coordinates for the whole world, and that the player coordinates are within the fixed viewport of the camera. But I cant seem to figure it out. I have spent just over 4 hours trying to find a solution - but I believe that the solution is very simple - I just cant "see" it yet.

If I add the camera Y position to the player y position, I should get the world coordinates for the bullets to aim for, but that wont work for some reason. They just go haywire and go everywhere. I have tried multiple different ways but cant get it. Once the camera reaches the end of the world, everything works correctly, the bullets leave the correct position, and they go to the player. That is why this is so frustrating, because it feels like the solution is right in front of me but I cant figure it out!

Anyways, sorry for this big post, I actually was looking for a point in the right direction, rather than a fix - which is why I posted so much. I really am trying to figure out as much as I can by myself. I am using a piece of code for the heatseeking bullets that I got from here on the forum - because that level of math completely goes over my head and I would have no clue (i did give it a go though : ))

I have included my current .love, you can ignore all the enemies and bullets that are flying everywhere. They wont kill you. The tanks will appear and start shooting after about 5 seconds. I should also warn you that this is my first time programming (just started a couple of months ago) so my coding cleanliness might not be what you expect - however it is indented (if correctly, I dont know).

Again I apologize for the length of this.

Rockford

[micha]

Your code is fine. First of all, ignore the camera. Since all coordinates are in world coordinates, the camera itself should only change the way, things are displayed. It should not influence the way, things move on screen.

The reason, why you always hit the tip of the player is because this is the point of the coordinates (player.x and player.y) If you want the bullets to go to the center of the player, then make them go to the point (player.x,player.y+20) (the number 20 is just a guess. Try different values here.
Note that images are always drawn with their upper left corner at the coordinates. What you do is, draw the player ship at (player.x-15,player.y). That is why (player.x,player.y) is the point at the tip of the players ship.

[Rockford]

Hi micha,

Thanks for the reply.

If I put the tanks within the viewport (opposite to how they are now), they will spawn at their respective x, y values. But they dont, they spawn way above the field of view, and the camera slowly brings them into view.

So the camera does affect the objects that are based off of its x,y coordinates. right now the tanks dont move with the camera - which is what they should do.

In the previous .love I uploaded, you are correct, the bullets do reach the x and y position of the player. I forgot that I changed it before uploading.

I have uploaded the version that spawns the bullets at the correct place (the tanks) but stop at 200 or so pixels above the player. The reason it does this is because the tank bullet draw code is placed inside the camera function that scrolls over the items in it. The tank is also in there, so they are using the same coordinate system. When I take the bullet code out of there, it will do what the original love does - spawn at the incorrect place, but hit the player -- because the bullets are using the coordinate system that the player is using.

So there is definetly a difference in how they are interpreting their position. The objects that stay with the screen are based on the typical x,y system where top left is 0 , 0. And the things that dont scroll with the camera (background, objects on ground like tanks) are basing their position on the whole world size.

I have edited this post quite a bit as I am having a hard time explaining myself, as I am quite confused. However I believe it is now clear, and I hope you can understand it.

[kikito]

So there is definetly a difference in how they are interpreting their position. The objects that stay with the screen are based on the typical x,y system where top left is 0 , 0. And the things that dont scroll with the camera (background, objects on ground like tanks) are basing their position on the whole world size.

I can't really go through your code, but it seems that there is some misconception going on here.

Your game world should be consistent. Everything should move according to a global set of coordinates. I call these "world coordinates".

What the camera does is displaying a particular rectangular window of that world, and putting in on the screen. But the actors in that world - the bullets, the enemies, the explosions, the background and the player, should be oblivious to the fact that there's a camera. They should work as if everything was just a whole world. They also don't know about the "screen", neither. They only know their world, which could be 4500x4500 pixels.

Think about it this way: you could have multiple cameras filming different parts of the world (maybe with a split-screen for local multiplayer, or maybe a minimap). That would not work if some parts of the game were moving according to some individual camera (they would look weird in the other camera).

Also, I made an evolution of this library called gamera. It's a bit more powerful, in that it allows rotations and zooms.

[Rockford]

Thanks for the reply Kikito.

I was concerned I might be misunderstanding the whole idea. I will go back and just rethink everything.

But here is why I thought they were using different coordinate systems:

If i place my player on the screen, and print out his y position, it will stay at 500(if I dont move him) no matter how far the camera moves up. If I move him up to the top of the screen he will go down to 0 and then into the negatives as I pass the top border. This is all happening while the camera is moving up the screen at 15 pixels per second. So when printing the x and y position of the player it prints out as if the player is on a fixed width and height screen.

That and the bullets not finding the player.

However, as I dont have much programming skills, I have been using just what I know to make things work. So I am thinking that I must of coded something that is affecting the bullets and the player - that I cant remember doing.

I need to check everything out. I will do so and hopefully find out why I am messing up.

Thanks!

[Rockford]

Okay I figured it out.

I remember a while ago I had everything in the camera.draw function, except things like the player score, health, etc.

But because I wanted the camera to move at 15 pixels per second, I created an invisible square, and then had the camera use that for its "look at" y position. Everything was fine except that the player didnt move with the camera - which I want so the player doesnt have to hold the up arrow key down to stay in view. So I used the same math to make the player move (player.y = player.y - 15 * dt) ... but it made the player jitter up and down just a tiny bit.

So I decided to put the player into the camera.draw function so that it moved with the camera without jittering. But that meant I had to start putting other things in there, like enemies, bullets, etc, or else they wouldnt collide properly. It didnt matter with those enemies because they were flying and it didnt change anything. But when I got to the tanks that have to stay on the ground, well that is when the problems started.

So thanks! I guess I needed to write it all out, and then be told that I was misunderstanding something in order to go back far enough to realize what I had done.

I appreciate that you guys didnt tell me outright what the problem was, whether that was intentional or not. Getting these aha moments really make me feel like I am improving.

Now I just have to figure out why the player jitters about when I move it 15 pixels per second automatically. I am guessing it has something to do with the fact that the camera also moves at that rate, because it doesnt have the jitter effect if I turn the camera movement off.

Thanks again!

[kikito]

Ok! Good luck