I'm working on a camera function. Right now it's controlled by some temporary code that lets me move it around with a controller, but I'll pop that out and drop some more complex code in that'll probably be based on the player's velocity.
I read a thread on here that said a good way to check collision is to move the sprite, and then if it's colliding, to move it out. I do my camera a similar way, where I move it first, and then if it goes over the level boundaries I snap it back to the maximum it can go.
I use two variables for each direction- one fine scroll that I also upload to the proper scroll register, and a coarse scroll that I keep for myself.
Is anything outta wack here? Anything that I'm doing that I shouldn't be?
Sounds fine to me so far. I like to think of the camera as just another game object, since it exists in the game world and has coordinates that specify its position within the level. This means that making it collide and eject when it hits the level's boundaries makes absolute sense. Also, as a game object, it can collide with other game objects, which is a way of telling if the objects are on screen or not.
In my game, the camera runs before all other objects (even the player) and it decides how much to move based on the player's position (and possibly speed, but I'm not sure how to use that yet). Two displacement values are generated, one vertical and one horizontal (which are clipped to the maximum amount supported by the scrolling engine - moving the camera faster than the rendering engine can draw the level would be BAD!).
It may seem weird that the camera is updated before the player, but that's a way to guarantee that a valid player position is used to guide it. If the player ran first, it could get inside an object or something and wouldn't be ejected until that object was processed, so the camera would end up following an invalid player position. And the camera MUST be updated before everything else, since its position is necessary for calculating the sprite coordinates of all the other objects.
Another thing I did recently was disconnecting the camera's coordinates from the scroll. Yes, most of the time the scroll is based on the camera coordinates, but now I have a special mode where the scroll can be manipulated by objects, which allows for big background bosses like those in Mega Man, while the camera continues to do its thing (meaning that sprites are still displayed in the correct coordinates relative to the camera).
I hope I didn't talk too much, and that my experiences with my own cameras give you some ideas on how to implement yours.
Awesome! Thanks a bunch!
It certainly does help to hear how others handle their cameras, as I don't think this subject comes up too much on here...
Woah, there's a camera in the nes; just like the camera in Direct X like a pen (does it have zooming)? Or is it simpler like a dot? Is that how you can scroll (moving the camera around the nametable)?
Sorry, just need to ask that... tomorrow I'll have more time for this forum.
The NES itself doesn't have a camera, but implementing one in software is the best way to handle scrolling in games with playfields larger than one screen. You can't zoom (not smoothly at least), and the coordinates of its top left corner are used to set the scroll registers of the NES.
But more important than providing the scroll position, the camera is also used to calculate the relative positions of the sprites (just subtract the camera's coordinates from each sprite's coordinates), so that you know where to draw them on the screen.
Thank you!