Layout Progress Indicator

Hi all, thanks for viewing.

I have looked at several topics regarding distance and such but could not find any solution for what I want to do.

I am working on a vertical scrolling shooter, and have been trying to make an indicator that shows how far along you are in the layout.

Here is what I thought might work:

I have a background bar, a progress bar, an arrow, and a scroller sprite (with scroll to behaviour).

I would like the arrow to always stay within the boundaries of background bar, starting at the very bottom and finishing at the top.

To achieve this I figured I could set the height of the progress bar relative to the scrollers position, the LayoutHeight, and the background bars height, and then set the arrow to the bottom of the progress bar.

Events:

|System Every tick|

barProgress - Set height to (Scroller.Y / LayoutHeight) * barBack.Height

arrow - Set Y to barProgress.Y + barProgess.Height

This is pretty close but never accurate and the results differ slightly depending on the layout height.

Here is a capx that demonstrates what I am trying to achieve. (Requires R155)

Thanks for any suggestions.

Something like this would probably work:

barprogress - set height : (layoutheight-scroller.y)*barback.height/layoutheight+barprogress.y

Something like this would probably work:

barprogress - set height : (layoutheight-scroller.y)*barback.height/layoutheight+barprogress.y

LittleStain, thanks for the suggestion, but does not work, the progress bar ends up being way below the ViewPort and the length increases instead of decreasing.

I tried a few variants of the equation but to no avail. Math is not one of my strong points....

Just to clarify a little more on what I want to do.

The game I am working on has many levels with varying heights.

The background bar is like a gauge representing the length of the layout, but of course much shorter in height (say 256px) and is on a HUD layer (parallax 0,0).

Hope that clarifies things a bit from my first post.

Please note, I spent quite some time on the capx to explain what I want to do. so it would be much easier to understand if you can look at that.

Again thanks for any help\suggestions. :)

First guess is that you need to allow for the 384 you are stopping the scroller at in your calculation of the arrow height ?

If you remove this stop when equal to or less than 384 and allow it to go to 0 then it works ?

So is the offset the arrow is stopping at related to the layout height/384 ?

right I think I've got this...

The distance to are multiplying by the barBack.height should be

((LayoutHeight - 32)-scroller.y)) / LayoutHeight-384 )

so this is the start position (or LayoutHeight-32 : the 32 is because you are starting the scroller at half its height from the bottom of the layout). Take from this the scroller.y (so now we have the height above its starting point). Divide this height by the layoutHeight- 384 (which is the total distance the scroller will move)

This does not allow for the height of the arrow - so the arrows origin point will travel from the boxBack bottom to top.

I will go and have a coffee and then probably find this is all wrong ! :)

First guess is that you need to allow for the 384 you are stopping the scroller at in your calculation of the arrow height ?

If you remove this stop when equal to or less than 384 and allow it to go to 0 then it works ?

So is the offset the arrow is stopping at related to the layout height/384 ?

RamPackWobble, thank you for the help. Your tips sent me in the right direction. I don't know why, but I didn't even try that!

In the actual game I am working on I had the scroller starting and finishing in the centre of the viewport, but I can work around that.

The fix:

Starting scrollers Y coordinate at the bottom of the layout and stopping it at 0 the arrow now starts and stops in the same postion regardless of the LayoutHeight.

Changed: arrow - Set Y to (barProgress.Y + barProgress.Height) + Self.Height

This causes the arrow to always start and stop in the same position regardless of the layout height.

However when starting at the bottom the arrows top edge was below the barBack.

To get around that I placed barBack of screen, and added another bar (barBackHUD) for the visual gauge, and made it a bit longer (the height of the arrow).

Works a treat!

Edit: modified capx

So many thanks for your help

One coffee later and a bit of a code tidy...

https://dl.dropboxusercontent.com/u/143636437/examples%20for%20web/scroller%20gauge.capx

michael,

This should help I hope. Rather than place the arrow to a position on the gauge in such a complicated way, try the following:

1. Put the arrow's origin to its center.

2. Modify the every tick function on line 2:

    arrow -> Set Y to barBack.Y + arrow.Height/2 + (barBack.Height - arrow.Height) * (Scroller.Y - 384) / (LayoutHeight - Scroller.Height/2 - 384)

This way you don't need to stretch a barProgress sprite (or even have one) and the above formula considers the playable height of the layout (-384 because your demo stopped with the Scroller in the middle of the screen: 768/2) and it also considers the height of the Scroller at start because its height slightly reduces the available playing area.

Edit: It took me so long to type this out I see another option has been posted. Food for thought anyway I hope - regards, Ed.

One coffee later and a bit of a code tidy...

https://dl.dropboxusercontent.com/u/143636437/examples%20for%20web/scroller%20gauge.capx

Awesome! You are legend! (coffee is amazing isn't it?)

Your solution is great, especially removing the need for the progress bar - less sprites is always good!

I make use of instance variables a lot in the game, but I would never come up with what you put together there.

I have made a note to add you to the credits when the game is completed.

—

Thanks for your input, I will give this a try tomorrow as well.

It's after midnight here and it has been a very long day. I don't even think coffee will keep me awake now! So off to bed...

Thanks to all for taking the time to work this out.

I see you've been helped already, but just to show you how close you actually were yourself:

progress indicator improved

I only changed two lines to take the 384 and the arrowheight into account.

LittleStain - thanks for that, good to know I was on the right track.

Colludium - thanks again, gave your suggestion a try and it also works pretty well.

RamPackWobble - again just to say your solution is perfect.

Since your solution makes good use of both Instance and Global variables I reckon this would make a great tutorial, or addition to new capx examples section. Maybe others can benefit from this.

Many thanks again for all the help - you people are awesome!

Just a little update here for the benefit of anyone who wants to impliment something like this in their game.

RamPackWobble solution as already stated is perfect - well almost perfect!

In the game I want to implement this gauge in, it is important that the scroller starts in the middle of the viewport (which was not portrayed in the example capx), and this throws the calculations out a bit.

But if you stop the scroller at the top of the layout it gives a reliable stoping point for the arrow on the gauge.

I spent some hours trying to work the math out..... thank goodness for the cricket!

But I have spent way to much time on this, time to get on with the game itself. Will come back to it later.

Mentioning the cricket ? <img src="smileys/smiley19.gif" border="0" align="middle"> Are you sure you want my help ? <img src="smileys/smiley17.gif" border="0" align="middle">   

I forgot to allow for it not starting at (almost) ground level.

Change

(((LayoutHeight-gvScrollersStartingHeight)-Scroller.Y)/(LayoutHeight-gvMaxHeight))

to

(((LayoutHeight-gvScrollersStartingHeight)-Scroller.Y)/(LayoutHeight-gvMaxHeight-gvScrollersStartingHeight))

this will use the (hopefully) correct (distance travelled)/(distance to travel) rather than what is was doing now I've typed that it doesn't look right...I will look again later when I've got more time

and don't forget to set gvScrollerStartingHeight to the correct position .

Perfection ?

(In this version the gvScrollersStartingHeight is only set after a reset...also not a good idea to have it running the calculation every tick (maybe find a way to do this only during flight?))