best way to make a static HUD and other overlays?

I'm in the process of setting up a static HUD panel, along with some collision boxes to prevent a few things from going wrong when 2 players are moving on screen.

Now, thanks to deadeye's suggestions, I have an object that controls the scrolling.

It moves up the background map, and is set to "centre view on me" , while the player objects can move freely over the background.

now when it came to setting static objects on the screen i was doing :

always set Y to scrollcontrollersprite + 144

always set X to scrollcontroller X pos

that way the objects are always sat in the same place.

the problem lies in the fact that when the player moves on the X axis, the background controller moves in the opposite direction, 1 pixel per tick.

when this happens the HUD objects shift by 1 pixel left and right, making the HUD wobble every tme the player moves on the X axis..

Deadeye tells me I can use a second layer and set the scroll movement to zero, but the overlaid layer doesnt display anything on it when I run the app..

the collision objects seem to be there, but they cant be seen, and bsides it seems like they are locked to the scrolling backround after a bind of blind testing..

can anyone help?

Thanks

Deadeye tells me I can use a second layer and set the scroll movement to zero, but the overlaid layer doesnt display anything on it when I run the app..

the collision objects seem to be there, but they cant be seen, and bsides it seems like they are locked to the scrolling backround after a bind of blind testing..

Hmm, don't know what to tell you about that one. Sounds like a bug, maybe? Here's a .cap showing that this method does work, though:

http://www.mediafire.com/?aejdnznk0cx

Setting different scroll rates on layers is how you do parallax scrolling, so setting the HUD layer to 0% scroll rate for x and y should do the trick (as it does in the example .cap).

deadeye is right, the best method for a static HUD is a layer with 0% scroll X/Y rates. Remember to put your HUD stuff in the top-left area of the layout to get it to display, because that layer will remain always scrolled to 0,0.

Hey work, maybe you could post your .cap so we could see what's going on with it? Unless it's top-secret of course

hmm - it seems that i'll try and shift it all to the top left and see what happens, sounds like that could be it..

*edit*

yep, that works perfectly - the reason why it was disappearing ws that I hadn't the objects at the very top of my playfield..

BUT - I was also using the layer for some invisible boundaries - it seems that one layers' objects can't collide with other layers objects.. is this true?

i'm not too sure but i know that even though layers can be locked the objects can still be interacted with (i don't mean at runtime)

so can different layers collide with each other? if so, how..

thanks, as always..

Solid objects on different layers should collide by default, but for best results the two layers should have the same scrolling rate. If you have different scrolling coefficients on the different layers (like a hud layer set to 0,0 scrolling) then you'll get some funky results. It doesn't seem quite perfected yet. Parallax is best suited for display stuff only though, really. I can't think of a reason why you'd need things on different layers with a different scroll rates to collide.

If you want non-solid objects on different layers not to trigger overlaps, add an "obj1 is on layer obj2.layer" condition to the collision event.

I can't think of a reason why you'd need things on different layers with a different scroll rates to collide

I assumed this would be the best solution as aligning some collision boxes near the edge screen would be less hassle than checking for positional coordinates of moving player objects as the XY coords are always changing on a scrolling background.

as I mentioned I tried setting the collision bounds relative to the the object that centres the view, but the objects that were set relative to it were not 100% perfectly static

Okay, I'm a little confused so let's see if I've got this right... you want to keep something from going offscreen, but you still want scrolling? Correct me if I'm wrong.

The best way to do it would be to check an object's x,y coordinates with the visible edges of the window. It's a quick value compare, which is much more efficient code-wise than setting up collision boxes. Any time you are able to do something with just math, it's a good idea to just work it out. Checking the edge boundaries is quicker than calculating collisions, and having no collision boxes at the edges means less objects.

the screen edge bounds aren't right to the edge of the window, they're a fair bit smaller so that the moving sprite never goes off the screen.

they are also there to check where the second player is, so that if the window scrolls left, and the second player is on the far right of the screen, it will "push" the player on the far right to prevent him going offscreen.

Ah, I see.

Well, if you really want colliders at the edges of the screen then you would have to have them on a layer that matches the same x,y scroll rate as the layer your player sprites are on. This means that you will have to update your colliders x,y coordinates every cycle to match up with the scrolling screen. This can cause some buggy problems, though... if you manually set the x,y of a solid object like your screen barrier, then it's possible to move it into a position where it intersects with your player sprite. It would take a lot of tricky custom events to compensate for this.

If you're dead set on having barrier objects then you might do something like giving your barrier Bullet Movement. That way you can tell it to move towards where you need it on the screen rather than set it's x,y manually (it will still "push" solid objects rather than intersect with them). But even this method is getting rather complicated and convoluted for what you want to do.

The simplest, most efficient method would be to ditch the detectors altogether and use math. If you don't want your sprites to go half-way off the edge of the screen then make your edge collision condition look like this:

sprite.X Less than (ScrollXRight-numOfPixels)
[/code:2yo1b835]

This will check whether your sprite is inside the visible play area as compared to the right edge of the screen, where numOfPixels is the amount of space you want to leave at the edge.

If you want to check if it's in the play area as compared to the top edge, you'd do like so:

[code:2yo1b835]
sprite.Y Greater than (ScrollYTop+numOfPixels)
[/code:2yo1b835]

You can check your second player's location just as easily using x,y value comparisons, so there's really no need for the barrier objects.

Thanks redeye, it's alot to digest, but i'll experiment with it tonight - thanks so much as always

Heh, sorry. Being long-winded is a bad habit of mine