AMD_Paulius_J
110 posts
|
Hello, i made a camera for a platform game with scrollRect function:
[
var view:Rectangle = new Rectangle(0,0, 720, 400); // A rectangle for camera
function ScreenUpdate(e:Event):void{
view.x = 250 + bird.x-(view.width/2); // Camera always follow player
sky.x = view.x -50; // Sky follow camera
info.x = view.x; // info follow camera
health.x = view.x + 30; // health too..
version.x = view.x + 590; // and version too
scrollRect = view;
}
addEventListener(Event.ENTER_FRAME, ScreenUpdate); // Update camera
]
And here is a problem, my parallax background has to follow camera, because player is actually moving, so health bar and other add ons has to follow camera too. This is very not practical and causes performance decrease.
My question is:
Is there a way to make a static object that is always on screen? for example i would like my health bar to always stay in the same position without having to follow camera, even if camera is moving away. i hope i written everything clear enough.
|
|
|
AMD_Paulius_J
110 posts
|
That object must always stay on screen, there should be a function do do that, hmm.
|
|
|
vesperbot
1883 posts
|
well, add a layer that won’t move at all, and put your “static” objects there.
|
|
|
AMD_Paulius_J
110 posts
|
That’s not gonna work, because player is actually moving and this rectangle is following him, it acts exactly as camera, so if i put a simple static background i would seem like player has run out of frame, i need background to stay on screen without actually having to make it follow camera.
|
|
|
draganviper
1043 posts
|
I don’t get what you’re asking. You could set the coordinates of static things relative to the camera but that’s the same as moving them. You really can’t get around that unless you make the camera stay still and move the whole world around the player, which isn’t usually practical.
|
|
|
Draco18s
6875 posts
|
And this is why I tell people not to use VCAMs.
If you don’t use a VCAM, then all you have to do is move the world. You add all the game objects and background to a single parent container and move that.
Sure, it makes less sense conceptually, but it makes things like HUDs a lot easier, because you don’t have to go “shit, it’s not following the camera.”
|
|
|
Drakim
1183 posts
|
Draco is right. This problem exists entirely due to shortcomings with the method you are using. The problem doesn’t even exist otherwise. :)
|
|
|
vesperbot
1883 posts
|
By the way, what should I read about these cameras? Perhaps I’ll need to use one for a part of my SWF.
|
|
|
qwerberberber
521 posts
|
Make the healthbar seperate from the vcam.
|
|
|
alecz127
817 posts
|
big ups to Draco. Theres a lot more efficiency. VCAMs are VSCAMs man, you’re going to end up messing with a lot more things in the code that way.
|
|
|
CuriousGaming
566 posts
|
I always link to this when someone asks a question about the camera, because Todd nailed it good:
http://www.youtube.com/watch?v=PLcsxKRPVbw&feature=youtu.be
|
|
|
AMD_Paulius_J
110 posts
|
Make the healthbar seperate from the vcam.
Thanks that would work for a healthbar, and for status bar. But it would not for a background.
By the way, what should I read about these cameras? Perhaps I’ll need to use one for a part of my SWF.
You don’t need to read anything, there is nothing much about that, you can just use the code in my first post, that’s the fastest way to create a vcam that i found on the net.
And now why i decided to use a vcam.
If i move a background and add enemies from a class (with separate physics and bumping program) they seem to react only to the position that background was when they were added ( if i move background a little) they will start bumping to air or go through obstacles).
|
|
|
vesperbot
1883 posts
|
hmm, it’s just a scrollRect property? So, this thing is local to a Sprite you call it from. Make your health bars, version etc in another Sprite that’s not a child of the one you’re setting scrollRect to, and pwn.
|
|
|
Senekis93
4090 posts
|
Which can be fixed by considering the background offset in your collisions, instead of using a vcam that is hundreds of times more expensive that any extra math you would need to throw in order to make collisions work with the offset. Not to mention all the extra issues that arise from the use of a vcam as the core of a collision method.
|
|
|
AMD_Paulius_J
110 posts
|
It’s just a rectangle, and hmm maybe we can call it a sprite. Screen just always shows what is inside that rectangle, well but creating separate background is really complicated, i think i will just switch back to a moving background.
Which can be fixed by considering the background offset in your collisions, instead of using a vcam
Could you guide me a little? because i don’t quite get it, maybe there is this “background offset” explained somewhere??
By the way, how do you quote a reply in kongregate forum? i’m very new here.
|
|
|
vesperbot
1883 posts
|
Originally posted by AMD_Paulius_J:
It’s just a rectangle, and hmm maybe we can call it a sprite. Screen just always shows what is inside that rectangle, well but creating separate background is really complicated, i think i will just switch back to a moving background.
First, where is that code located in your project? Main timeline? If so, learn DisplayList and create more than one container, one will contain the game, and another will contain your “static” objects.
|
|
|
draganviper
1043 posts
|
Originally posted by AMD_Paulius_J:
It’s just a rectangle, and hmm maybe we can call it a sprite. Screen just always shows what is inside that rectangle, well but creating separate background is really complicated, i think i will just switch back to a moving background.
Which can be fixed by considering the background offset in your collisions, instead of using a vcam
Could you guide me a little? because i don’t quite get it, maybe there is this “background offset” explained somewhere??
By the way, how do you quote a reply in kongregate forum? i’m very new here.
Look left at the posters name, then down an inch.
|
|
|
Senekis93
4090 posts
|
Originally posted by AMD_Paulius_J:
It’s just a rectangle, and hmm maybe we can call it a sprite. Screen just always shows what is inside that rectangle, well but creating separate background is really complicated, i think i will just switch back to a moving background.
Which can be fixed by considering the background offset in your collisions, instead of using a vcam
Could you guide me a little? because i don’t quite get it, maybe there is this “background offset” explained somewhere??
When you add an object as a child of another, its “real” position equals parent.position + object position. Of course, if there are more layers you have to take each of them into the calculation.
ie, you have A and B. B is a child of A.
If you want to know the actual horizontal position of B, you’d do A.x+B.x.
|
|
|
vesperbot
1883 posts
|
Originally posted by Senekis93:
When you add an object as a child of another, its “real” position equals parent.position + object position. Of course, if there are more layers you have to take each of them into the calculation.
ie, you have A and B. B is a child of A.
If you want to know the actual horizontal position of B, you’d do A.x+B.x.
If A has scrollRect set, the actual X position of B will be A.x-A.scrollRect.x+B.×.
|
|
|
AMD_Paulius_J
110 posts
|
First, where is that code located in your project? Main timeline? If so, learn DisplayList and create more than one container, one will contain the game, and another will contain your “static” objects.
Yes, it is in the main timeline. Thank you, DisplayList is a very important funcion that i was missing, now i think i can understand a bit more. It should be possible to create a vcam which follows a player and shows a scrolling background (with index 3 – so it would be on top), then another static vcam for status & health bar at index 2, then coulds index 1 and blue sky at index 0. Then move main camera at player.x speed, clouds camera at player.x * 0.2 speed, and here we have a parallax background.
Look left at the posters name, then down an inch.
Thank you.
When you add an object as a child of another, its “real” position equals parent.position + object position. Of course, if there are more layers you have to take each of them into the calculation.
ie, you have A and B. B is a child of A.
If you want to know the actual horizontal position of B, you’d do A.x+B.×.
Here is a part of code on how i add enemies:
funcion inside HedgeHog.as file to set coordinates
public function addHedgeHog(xLocation:int, yLocation:int) { // public .as function, set coordinates
// constructor code
x = xLocation;
y = yLocation;
}
And here a funcion to add hedgehog on main timeline:
addHedgeHog(800, 300);
function addHedgeHog(xLocation:int, yLocation:int):void
{
var hedgehog:HedgeHog = new HedgeHog(xLocation, yLocation);
back.addChild(hedgehog); // add to the background
hedgeList.push(hedgehog); // insert it into array
}
this hedgehog has a long script inside it’s .as file, if he would hit a stone he would turn arround and start moving to opposite direction. But when i move a background he starts bumping into free space or go through stones. So his real possition is back.x + hedgehog.x? So where would i place this, maybe in HedgeHog.as file?
Actually i think i will have to find out this myself, i will just search for info and will come back here to read this post until i fully understand this.
|
|
|
Senekis93
4090 posts
|
In this case, it’s an issue with the structure; the hedgehod shouldn’t take care of evaluating the map and boucing, you should do that in your game class or however it’s called.
|
|
|
qwerberberber
521 posts
|
this is the problem with Vcam. I don’t understand why you don’t just throw everything in a container and move the container around? It’s so much more efficient. The Vcam is built for transforming scenes in otherwise difficult ways (skewing/stretching).
|