Log In  

I'm trying to figure out how to make my camera area shift based on when the player is a certain distance from a center zone. I don't want my player in the middle of the camera all the time. I want them to "push" the camera zone around as they get to the edges...but then push the camera back when they hit a certain distance in the camera zone.

That's confusing, maybe...how about this...

There's a 128x128 "free zone" where the player moves around freely. They go right and when they hit x128 it switches to camera mode and the player can keep moving right until the edge of the world. Once they get to the edge, they need to go back to the left, but on the way back the camera needs to move when they hit the half way point of the viewport they're in...as opposed to moving the camera when they hit the left edge of the camera viewport.

It's like a lot of the old NES games where you'd move forward once your character hit mid-point, but if they turned around the camera wouldn't move anymore. Kind of like Metroid was.

Sorry if that's still as clear as mud...but if you think you know what I'm trying to accomplish, any insight or thoughts are appreciated. I know camera() is the key but everything I try to calculate doesn't work out...

P#20968 2016-05-20 22:49 ( Edited 2016-05-24 18:52)

Forgot to mention I'm trying to do this over X and Y axis...if that matters.

P#20970 2016-05-20 23:16 ( Edited 2016-05-21 03:16)

Look at the Jelpi demo, specifically line 679.
Is that the behavior you want?

P#20973 2016-05-21 00:11 ( Edited 2016-05-21 04:11)

my guess is something like

if px-leftbufferplusfreezone>camx then
 if px-leftbuffer<camx then

edit: that was worded for a setup with a free/no-scrolling zone in the middle. If you wanted to scroll right only after hitting the edge of the screen, then the first if would check against px-screenwidth+alittlebitforplayersprite.

P#20974 2016-05-21 00:17 ( Edited 2016-05-21 04:34)

Cart #20976 | 2016-05-21 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

Like this?

function _init()


function _update()
 local speed=2.25
 local allowance=28

 if (btn(0)) then
  if (p.x-cam.x<(64-allowance)) then

 if (btn(1)) then
  if (p.x-cam.x>(64+allowance)) then

function _draw()
P#20977 2016-05-21 00:46 ( Edited 2016-05-21 04:46)

Thanks for the tips and snippets, guys.

@scgrn - Your example was pretty much what I needed, I just added Y camera movement using the same pattern. I made a new cart that includes both. I'll be using it as my go-to template.

I hadn't thought to make the camera(0,0). I just had the camera() call wrapped in a condition. Learning I can just leave the camera "on" all the time makes a big difference.

P#21024 2016-05-21 15:29 ( Edited 2016-05-21 19:29)

Glad to help! Looking forward to seeing your game!

P#21222 2016-05-24 02:08 ( Edited 2016-05-24 06:08)

Here's a good reference article on the topic! Scroll Back: The Theory and Practice of Cameras in Side-Scrollers

P#21223 2016-05-24 03:09 ( Edited 2016-05-24 07:09)

Thanks for the link, some great reading there with examples. If nothing else, it's a glossary for camera types.

P#21245 2016-05-24 09:23 ( Edited 2016-05-24 13:23)

The article that impbox link is a realy good reference. I tryed to make something good in my game p.craft, but it's prety difficult. I wanted to have the player moving in a center zone without moving the camera, but you couldnt see around where you go. It's specialy bad when there is enemies just beyond the camera space. So I tryed a camera that start to recenter the character when he walk and is outside the center safe zone.

P#21254 2016-05-24 14:09 ( Edited 2016-05-24 18:09)

Totally...in a shooter game I started, I wanted to allow the player to fly around a big ship but having it centered all the time meant you couldn't see bullets coming. Having that reference list at least tells me what type of thing I should try...which in that case was the Defender camera model. Not to mention I can now articulate what I'm trying to achieve when asking for help.

Of all the little demos I've made now with Pico-8, the biggest adjustment has been the square aspect. Not a complaint at all, just a limitation that is a challenge to deal with, but a challenge I'm loving. Really helps pair down your game to make you think what's important.

...and it really makes me appreciate the games of my childhood. I've been going back and playing them a lot to see how they dealt with the same issues or designed around them.

P#21255 2016-05-24 14:52 ( Edited 2016-05-24 18:52)

[Please log in to post a comment]

Follow Lexaloffle:          
Generated 2024-02-25 17:48:51 | 0.017s | Q:27