Creating a static object

22 posts

Flag Post

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.

 
Flag Post

That object must always stay on screen, there should be a function do do that, hmm.

 
Flag Post

well, add a layer that won’t move at all, and put your “static” objects there.

 
Flag Post

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.

 
Flag Post

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.

 
Flag Post

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.”

 
Flag Post

Draco is right. This problem exists entirely due to shortcomings with the method you are using. The problem doesn’t even exist otherwise. :)

 
Flag Post

By the way, what should I read about these cameras? Perhaps I’ll need to use one for a part of my SWF.

 
Flag Post

Make the healthbar seperate from the vcam.

 
Flag Post

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.

 
Flag Post

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

 
Flag Post
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).

 
Flag Post

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.

 
Flag Post

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.

 
Flag Post

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.

 
Flag Post
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.

 
Flag Post
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.

 
Flag Post
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.

 
Flag Post
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.×.

 
Flag Post

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.

 
Flag Post

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.

 
Flag Post

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).