Looking down and up
Start off with some arbitrary alterable value that you can use for this. I chose an alterable value in the player sprite
* When the player is standing on the ground,
* Not pushing left,
* Not Pushing Right,
* Is pushing Down,
* Alt Value D is < 60 (60 will be the max amount of pixels the player can push the camera down.)
- Add two to Alt Value D
* Alt Value D is > 0
- Sub one from Alt Value D
Now the camera would look something like this:
* Always
- Set Y position to Y("Player") + Alt Value D
Its a little rough, but with some more events you could smooth it out a bit. And that was for looking down only. Looking up just involves doing the same thing except with negative values in Alt Value D.
Edited by the Author.
n/a
DaVince This fool just HAD to have a custom rating
Registered 04/09/2004
Points 7998
21st July, 2007 at 16:01:17 -
"Not 2 cameras sorry, but 2 representations. One for X and one for Y positions."
X and Y scrolling speeds will act independently. That's why.
Ooh, forgot to say, you can do things like rotation on the main "camera look to" object. I've done that for the swimming bit in Tormishire since it runs in 360 degrees. When on the ground it snaps back to left/right positions. Might put in looking up+down actually...
For boss fights I rigged up a little camera setup thats kinda nifty.
Always
.. set x position of Target to (x("boss") + x("player"))/2
.. set y position of Target to (y("boss") + y("player"))/2
x position of Target > x("player") + 95
.. set x position of Target to x("player") + 95
x position of Target < x("player") - 95
.. set x position of Target to x("player") - 95
Now just set your camera smoothing events and whatever to focus on "Target" instead of the player, and its done. What this does is always set the camera position to inbetween the player and the boss. Then, if the player gets too far away from the boss the camera gets pulled along with the player so that the player can't leave the screen. It works pretty well, and its easier to keep an eye on your enemy.
Oh yeah, and you probably want to adjust "95" to fit your window size if you plan on using this. This was done in a 320 x 240 game.
I'm sure 95 can be a ratio of "Screen width:number" as well. That way the code doesn't need to be changed everytime.
Like instead of 95 use: screen width/2.5.
Anyways, very cool!
thinking is like pong, it's easy, but you miss sometimes.
The method I use is similar to the code posted by Ben smileyface (not the example file - I haven't opened it.) If you're unfamiliar with that formula then do try to get your head around it because it's very useful.
Liquixcat - Why are you encouraging the use of fast loops to move camera objects? (I haven't opened your example file, I'm just referring to the code posted here and your comments to James.) Is there any difference between x("camera") + 5 and loop 5 times(x("camera")+1)? It's not essential to break out the fast loops every time you need to move an active object. I think you had the right intentions; people need to realise how useful fast loops can be, but they have their place.
Edit: Here's what I use. It's one event and doesn't need any extra active objects.
Always -
X( "player" )-((X( "player" )-(X Left Frame+((X Right Frame-X Left Frame)/2)))/1.1)
Y( "player" )-((Y( "player" )-(Y Top Frame+((Y Bottom Frame-Y Top Frame)/2)))/1.1)
Advertisement
Post Reply
Edited by the Author.
. Jimmi uses actives, I used co-ordinates 
... And Jimmi knows what he's doing lol...
/