camera scroll walls
Moderator: Moderators
Forum rules
- For making cartridges of your Super NES games, see Reproduction.
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
camera scroll walls
Has anybody ever looked into how games are able to restrict camera movement in certain parts of levels, such as having only horizontal scrolling in one part of the level, vertical scrolling in another section, diagonals in the next section, and free scrolling in the next section?
- never-obsolete
- Posts: 411
- Joined: Wed Sep 07, 2005 9:55 am
- Location: Phoenix, AZ
- Contact:
Re: camera scroll walls
Have invisible objects in your level that alter the behavior of the camera. You could also have special tiles in your tilemap if you want to go that route.
- jeffythedragonslayer
- Posts: 344
- Joined: Thu Dec 09, 2021 12:29 pm
Re: camera scroll walls
Which games have you seen this camera behavior in?
-
- Posts: 611
- Joined: Mon Jan 23, 2006 7:47 am
- Location: Germany
- Contact:
Re: camera scroll walls
(NES) Metroid 1 had sections that scrolled either vertically or horizontally...jeffythedragonslayer wrote: ↑Wed Jun 22, 2022 2:43 am Which games have you seen this camera behavior in?
Links relevant to camera movement:
https://www.gamedeveloper.com/design/sc ... -scrollers
https://www.gdcvault.com/play/1022243/S ... Theory-and
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
Re: camera scroll walls
Cameras should normally have variables defining minimum and maximum values allowed on each axis, so that you can confine it to the boundaries of the level at the very least, but you can easily have invisible objects configured to change these boundaries at specific places.
When the camera is outside of the allowed range in any given axis, you may need to take different actions depending on where it was before moving - If it was in an allowed position before, just snap it to the nearest allowed position. If it was outside of the allowed range already, smoothly move the camera toward the nearest allowed position.
This way you can have the same camera logic throughout the entire game, and after it moves you validate its position to make sure that the restrictions in both axes are being respected.
Also, in some games where the type of scrolling changes radically in a single level, the program might actually be secretly swapping to a different level map entirely... If a level scrolls exclusively horizontally for 8 screens, and then starts to scroll up for 4 screens, it would be extremely wasteful to store this level as an 8x4 rectangle, since there would be a 7x3 area that the player would never see... In this case, it would make more sense to haver two maps, one 8x1 and one 1x4 (with one repeated screen where they connect), and seamlessly switch between them when the player collides with a trigger or something.
When the camera is outside of the allowed range in any given axis, you may need to take different actions depending on where it was before moving - If it was in an allowed position before, just snap it to the nearest allowed position. If it was outside of the allowed range already, smoothly move the camera toward the nearest allowed position.
This way you can have the same camera logic throughout the entire game, and after it moves you validate its position to make sure that the restrictions in both axes are being respected.
Also, in some games where the type of scrolling changes radically in a single level, the program might actually be secretly swapping to a different level map entirely... If a level scrolls exclusively horizontally for 8 screens, and then starts to scroll up for 4 screens, it would be extremely wasteful to store this level as an 8x4 rectangle, since there would be a 7x3 area that the player would never see... In this case, it would make more sense to haver two maps, one 8x1 and one 1x4 (with one repeated screen where they connect), and seamlessly switch between them when the player collides with a trigger or something.
- never-obsolete
- Posts: 411
- Joined: Wed Sep 07, 2005 9:55 am
- Location: Phoenix, AZ
- Contact:
Re: camera scroll walls
The Donkey Kong Country series fiddles with the camera throughout the course of some levels. I don't know the details of how, but there might be a level editor out there that could shed some light.
- jeffythedragonslayer
- Posts: 344
- Joined: Thu Dec 09, 2021 12:29 pm
Re: camera scroll walls
I tried to open this Donkey Kong Country level editor, but the "AGREE & CONTINUE" button doesn't do anything for me:
http://www.dkc-atlas.com/forum/viewtopi ... =57&t=1532
http://www.dkc-atlas.com/forum/viewtopi ... =57&t=1532
Re: camera scroll walls
If you're asking because you're looking for ideas on how to implement camera cues, then think of them like you're defining an arbitrary region in your level where, when the player enters this region, certain restrictions are applied to the camera's behavior. When the player exits the region, the camera's behavior returns to normal.
So maybe the level has a square region defined in the level data where, when the player is inside this region, the camera moves to a fixed position, maybe a position which more optimally shows you the obstacles compared to how the default camera works.
I can think of a fairly straightforward system you can implement in your level data. If your maps are divided into "screens", you could have each screen contain a camera cue which is active as long as the player is inside that screen. The simplest cues would be stuff like "left boundary" "top boundary" like if you wanted to prevent the camera from scrolling farther left or up.
You could hide a secret by marking a screen as "right boundary", then having another screen farther right with no camera cue, to create an effect where the camera doesn't follow the player to the right until the player crosses into the next screen over, in which case the camera unsticks itself and follows you right, revealing that there was indeed another screen over there.
So maybe the level has a square region defined in the level data where, when the player is inside this region, the camera moves to a fixed position, maybe a position which more optimally shows you the obstacles compared to how the default camera works.
I can think of a fairly straightforward system you can implement in your level data. If your maps are divided into "screens", you could have each screen contain a camera cue which is active as long as the player is inside that screen. The simplest cues would be stuff like "left boundary" "top boundary" like if you wanted to prevent the camera from scrolling farther left or up.
You could hide a secret by marking a screen as "right boundary", then having another screen farther right with no camera cue, to create an effect where the camera doesn't follow the player to the right until the player crosses into the next screen over, in which case the camera unsticks itself and follows you right, revealing that there was indeed another screen over there.
-
- Posts: 1565
- Joined: Tue Feb 07, 2017 2:03 am
Re: camera scroll walls
Map based triggers or predefined camera points in a table.
Re: camera scroll walls
This reminds me of an unused sprite from SMW that gives the level a layer 1 horizontal section before transitioning seamlessly into a layer 2 vertical section.tokumaru wrote: ↑Wed Jun 22, 2022 10:58 am Also, in some games where the type of scrolling changes radically in a single level, the program might actually be secretly swapping to a different level map entirely... If a level scrolls exclusively horizontally for 8 screens, and then starts to scroll up for 4 screens, it would be extremely wasteful to store this level as an 8x4 rectangle, since there would be a 7x3 area that the player would never see... In this case, it would make more sense to haver two maps, one 8x1 and one 1x4 (with one repeated screen where they connect), and seamlessly switch between them when the player collides with a trigger or something.
I have an ASD, so empathy is not natural for me. If I hurt you, I apologise.
Re: camera scroll walls
In Rem, I have the map stored screen by screen (256x256 px regions called "rooms" in the code) and metadata attached to them with a 4 bit bitmask for placing a camera wall at each side of the room (called "scroll barriers" here). It's in here: https://github.com/rmn0/rem/blob/develop/src/tform.s
They're "soft" barriers as in the camera is allowed to skip over them when it's smooth scrolling to a new place, only the destination the camera wants to go to is restricted to be inside the walls. This is intentional, to make scrolling around corners look more natural.
They're "soft" barriers as in the camera is allowed to skip over them when it's smooth scrolling to a new place, only the destination the camera wants to go to is restricted to be inside the walls. This is intentional, to make scrolling around corners look more natural.