I have just finished the mouse input for my game. My "player" sprite will always look at the mouse position. I am now trying to set up a zoom and translate to center the "player" sprite. I want to have it so when the sprite moves, it will stay exactly center in the frame. I sort of have one working, but when I start moving around, the mouse part gets all screwed up. Also, I can't get it perfectly centered in the frame. Is there some kind of formula, or do I have to eye it out.

Edit: Solved!

My old atan2 function used the center of the sprite minus the mouse position to get the rotation. It worked fine when it was in the center, but when I moved around with the sprite, it got messed up.My new atan2 function uses the center of the screen (400 x 300 in my case) minus the mouse points to get the rotation. Works fine now.

then you have a camera, which is just a rectangle with the size of the screenyou move the player and adjust the camera to look at the player

now at rendering you render everything with that camera.

first, to not render stuff that wouldn't be on the screen, you say, well is the object inside the camerabasically camera.intersects(object)and for every object that is, you render it with its absolute location minus the camera's location

It's just a concept that came to me naturally and I have been using it every since, it's not a way I read somewhere - but it might be the same or very similar to "what you're supposed to do"

anyway, using this you can also have parallax scrolling with layers and different cameras easily, as well as scenes in which the camera would look/shift to something other than the player

I think I get it now, I was in a completely different mindset. I was focused on the canvas moving around, instead of the objects moving around dynamically to the "camera". Thanks for the tips, I'll see how it works.

Its easier to visualize if you have a real world example. Remember Warcraft 2? You have the large map and the minimap. On this minimap you see a rectangle which you can move around to see that part of the larger map.

The rectangle in the minimap still perpetuates the "camera" idea. Imagine the minimap rectangle is stuck in the center of the minimap, and the entire map scrolls to fit the visible part within that rectangle. That's how the camera works: your camera never moves, you simply move the whole world into view.

The rectangle in the minimap still perpetuates the "camera" idea. Imagine the minimap rectangle is stuck in the center of the minimap, and the entire map scrolls to fit the visible part within that rectangle. That's how the camera works: your camera never moves, you simply move the whole world into view.

Then you will see that it is not the spoon that bends, but yourself

Yes thats how the OP is currently doing it, right? Translate everything in the entire world. But the idea posed in the thread is to not move the entire world but to move the camera rectangle. The latter matches the minimap example.

Another way of thinking about it is you move the minimap rectangle internally, but to actually render things into view you translate (move) it and the world back in the reverse direction so it's back at the center where your fixed unmoving camera lives.

In that case, the camera, such as it is, is like any other object in the world, except you always render it first and you use the inverse of the normal translation and rotation to get your camera transform on the world.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org