Great stuff, happy for you....

And like danialgoodwin says, families are a real benefit....

Happy game creation.... <img src="smileys/smiley17.gif" border="0" align="middle" />

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

RamPackWobble, I can't thank you enough! The math looks so simple when you see it.... <img src="smileys/smiley20.gif" border="0" align="middle">

Perfection? That will certainly do!

Every Tick? Yeah I was wondering about that, will look into it..

When I first decided to implement this kind of gauge it seemed simple enough, but in practice it was certainly putting my head into a spin!

I really think your example would make great tutorial, an explanation of arriving at the calculation, along with the order of things in the event sheet, would be great for learning from.

Many thanks.

Oh, did I mention the cricket.... my bad! <img src="smileys/smiley36.gif" border="0" align="middle">

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.

Hi —

you need to break up your backgrounds, use TiledBackgrounds and smaller sprites.

Ashley wrote a great blog about game design here

Hope that helps...

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!

—

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.

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.

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

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

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

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.

Hi, just wondering if this issue has been sorted. I get the same error, either importing thru the dialog, or by dropping the .tmx file on the layout.

The .tmx file was created using Tiled....

Edit: using R155. Win 8.1.