Behavior mount to display position?

#1 A couple ideas off the top of my head:

Mount all scene object GUI items to another scene object that is the size of the camera. This large scene object is then attached to the camera.

or

Create a second scene window and level where all GUI scene objects are placed. This second scene window sits on top of the first one. All scrolling/player movement happens in the first scene window and the second one remains static.

#2 Mike:

Yah, I am looking at the first option. The camera follows the player. The scene object follows the camera. Need to find info on attaching to the camera.

Anyone seen such info for TGB?

#3 Although you can mount the camera to an object, I do not believe you can mount another object to the camera. Since it is not a real object -- it is internal to the sceneWindow -- you can't actually call mount on it at all, you just have the sceneWindow methods to work with.

So you might implement a behavior that utilizes "onProcess" to continually do something like this...

%pos = sceneWindow2D.getCurrentCameraPosition();
%this.owner.setPosition( %pos );

I have a strong suspicion this will result in your object "mounted" to the camera moving rather jerkily, but its worth a try.

If you don't want your mounted object to be in the exact center of the camera ( which you probably don't ) you might have a 2d vector "offset" from that position specified as a field in your behavior.

eg.

%pos = sceneWindow2D.getCurrentCameraPosition();
%pos = t2dVectorAdd( %pos, %this.offset );
%this.owner.setPosition( %pos );

#4 Yes, James is right - it is the camera that actually gets attached to a scene object and not the other way around.

For an example, check out the camera behavior I wrote for the mini platformer tutorial. You could perhaps enlarge the size of the scene object that has the camera behavior and then attach all your GUI elements to that scene object.

tdn.garagegames.com/wiki/TGB/Tutorials/Platformer/Camera

#5 Another, slightly complex but much more flexible system would be to have two scenegraphs, one for your game, and one for your GUI.

The GUI scenegraph would contain non-moving objects (your gui buttons, or whatever you want to display), and a sceneWindow that was full size, with a transparent background. The complex part comes from the issue regarding which scenegraph should be first responder to system events (mouse, keyboard), and how to make sure they get passed over to the other scenegraph when required, but a reasonable system can be developed in script with a little work.

It can be much easier in some cases if you have a source code license, and are willing to dig down into the deeper levels of scenegraph event handling.

#6 Here is a note from Melv. Will be researching the forum for code snipits to help. As I am not strong on coding, any help will be appreciated.

And yes Melv, an "easy" HUD is one aspect. But others come to mind; a night filter, a damage flash, etc...

Yes this probably would have been better in the General Discussion group. : \

Quote:
You can only mount the camera to an object, not the other way around. With that said, I'm saying TGB won't automatically do it for you but like anything, it's possible to do it easily in script.

It seems then that you want to have TGB objects act as HUD elements that move with the camera?

To do that....

In the scene-update callback you can reposition any objects (maybe you have a set of them) to be relative to the camera. In this scene callback you'd simply retrieve the camera position and reposition the set of objects. A better way would be to have a single t2dSceneObject and mount all "filter" objects rigidly to that. This way you only need to reposition the t2dSceneObject to, say, the cameras position each frame.

So in summary...

Create t2dSceneObject (it's invisible because these objects don't render anything).
In the scene update callback reposition the t2dSceneObject to the camera position "getCurrentCameraPosition()".
Mount all your "filter" objects rigidly to the t2dSceneObject. Objects are then relative to the center of the screen no matter where it's looking.

----

Hope this helps,

Melv.

#7 Note that this is pretty much what James outlined above.

Melv.

#8 Yes, studying James and Mikes stuff too.

#9 Mike - In your PlatformerCameraBehavior you appear to have the scene object that has the camera behavior attached, fixed to the player. I had ( and still ) tried that. I can not however get the scene object to follow the player. Where do you accomplish that in the behavior code? Seams the simplest solution, but I have not gotten it to work.

Question 2) I note in your comments you say the behavior should work with the PSK with changes to the movement assignments. Do you know if it will conflict with Phil's camera tracking?

#10 Movement is done in the onUpdate function. X direction movement is carried out, for example, with this command:

%this.owner.setPositionX(%this.target.getPositionX() + %this.xOffset);

%this.owner is the scene object the behavior is attached to and %this.target is the target you specify in the behavior rollout in the edit tab. So every 32ms it grabs the player position and sets the scene object to that position as well. As I documented in TDN, the target (i.e. player) is currently set for animated sprites only but that is easy to change.

Answer 2) This behavior would conflict with the camera tracking in the PSK. Although as far as I remember, all the PSK does is simply attach the camera to the player object. What I did was comment out the camera mount calls in the playerMethods script file and change the code in the behavior slightly so if you use the facePlayer option it would correctly work.