Yes, I've done it also a while ago, with physics and a special blob shader:

http://www.scirra.com/forum/viewtopic.php?f=8&t=7037&p=55148#p55148

It isn't very complicated.

I used the plugin in a small side project and had severe crashes. I could avoid the crashes by using one object per layout while all of them needed to be ticked global. Using one global object crashed as well as having several local objects.

PixelRebirth was a few minutes faster than me. Anyway, here is another .cap doing basically the same, but without a hash table

random array.cap

Don't get me wrong: All I said about angles only apply to code you copied from the original engine. Wherever you use you're own methods you are working with the clockwise model and therefore shouldn't inverse the angle. It was just an example of why you would need to change the code when copying from the original.

Btw, if you didn't take everything from the original, but rather found your own solutions, then you might also find your own slp value by just experimenting - it would be hard to tell, what values you have to use, if it is mixed that much with your own methods.

The ratio business is, well, rather tricky. You see, the original acceleration wasn't even close to 100. It was 0.046875. Which means the ratio would have to be literally 9600. XD Yeah, the values for variables in the guide are freaking TINY. The slope factor is bigger than the acceleration!

Well, 0.125 * 0.5 * 9600 = 600. Adding 600px per step doesn't make sense, agreed. But all those tiny values let me assume, the developers normalized them. Do you know, how many steps per second where used and what display size was used? I ask, because that 0.046875 makes sense somehow. For example, if the steps per second were 30 and the display width was 640, then 30/640 = 0.046875, or, if the steps were 15 and the width was 320, then 15/320 = 0.046875 I don't think this is coincidental.

But I have no clue how they would use such a ratio...

Also, with angles, I guess all I have to do is just add 180 onto every angle calculation or something?

Yes, either that or the logic should be adapted. I read something about converting the ground speed to x- and y-speed:

Xsp = Gsp*cos(angle);

Ysp = Gsp*-sin(angle);

If you would take it that way without adding (or substracting) 180 from angle, then the directions are inverted. Think of the 30? example. sin(30) = 0.5, but Gsp * -0.5 would get negative, so Sonic's Y position would lower (= he would walk upwards) while he should walk downwards. You may either do

Ysp = Gsp * sin(angle) or Ysp = Gsp * -sin(angle + 180)

but stick to one method throughout the game code, and make sure the angle you pass to the object's angle is a value in the range [0, 360]

EDIT: Just to stress that. The original is based on counter clockwise. That means you may only correct on the Y-axis, not on the X-axis!

By the way, do you how to set angle based on on X/Y Velocity?

Basically, if the velocity is expressed both negative and positive, then the angle of the velocity at that moment of time you sample it is

angle(0, 0, xVel, yVel)

But you would need to take into account the current angle of the object, the velocity is applied to. When time based it could be something like that:

object.angle = object.angle + angle(0, 0, xVel, yVel) * TimeDelta

(If I'm not totally off beam)

EDIT: Ah, sorry, no, the last one is not correct. It would spin the object even if the angle is already reached.

You guys know I'm working on a Sonic engine for Construct, SO...

Okay, for starters, here's the current version of the engine.

Okay, so I've been trying to implement slope acceleration and deceleration, with pretty much no success whatsoever.

The Sonic Physics Guide (to be specific, this section) uses a "Slope Factor (slp)" that is used with "slp*sin(angle)" and added to Sonic's speed at the beginning of every step. The results of my attempts at implementing this method have been... Varied. The regular value for "slp", 0.125, does nothing at all. This is mainly because Construct's "Custom Movement Behaviour" works with much larger values (for example, Sonic's 'normal' acceleration is 450). Moving the decimal point around to the right once so it's 1.25 doesn't do anything either. Move the decimal point to the right again, however, and suddenly when Sonic is angled to the left he goes incredibly fast and when angled to the right he stops in his tracks, no matter which direction he's facing. Naturally, this is because clockwise from 0 degrees is positive and counter-clockwise is negative.

(Note that the default angle for when Sonic is NOT on a slope is 90 degrees. I merely reduce that by 90 when performing calculations.)

More complicated methods I've tried have not worked either. I might be doing the Physics Guide method wrong somehow, but why that would be so hasn't quite hit me yet.

If anyone could help me out, it would be very much appreciated. If any general programming guys might have an idea why I might be doing the Physics Guide method wrong, that would be awesome too.

Well, I can't help that much, but I can point in the right direction. Let me start by explaining that the behavior of being too fast to the left and stopping to the right is not correct. Look at this image:

No matter what angle value you use, you will always get the correct result. A is a 30? slope downhill to the left. B is a 30? slope downhill to the right. If you calculate the sin of the four green values (30, 150, -210, -330) it will always result in 0.5; and if you would have 30? uphill to the left or right (330, 210, -150, -30) it would always result in -0.5

If we use the slope calculation, slp * sin(angle) == 0.125 * 0.5, we get a value of 0.0625 and that value is added per step.

Now, what is a step in the original engine? Is it running at, let's say, stable 60 fps, and every step equals one frame? If so, the above value would result in adding 3.75 per second to the speed. That really isn't much, and if the speed is at something like 150 px per second, you will barely notice it.

But you said, that you raised some of the values of the original values. Be careful when doing so. Make sure, you raise them all by the same ratio. Then take that ratio and multiply it with the slope factor. For example, if the original 'normal' acceleration was 100, you used a ratio of 4.5 and your calculation would be

slp * sin(angle) * 4.5

With the example values above it would result in adding 16.875 per second instead of 3.75, which should be more noticable.

Also, if all of your movement is time based instead of frame based, while the original engine was frame based, you can't work with constant values. Instead you would then calculate the original values per second before using them. You would need to find out the frame or step rate. Example: slp = 0.125, steps per second = 60 >>> results in 7.5 * TimeDelta * sin(angle) * raisefactor

But back to my first point: If sonic is too fast to the left and stops to the right, then you're getting the wrong angles prior to the calculations. And make sure to convert all substracting and adding of angle values correctly. The original engine reversed all angles (45? are 315? in the original engine, 90? are 270?, 315? are 45?, etc. Or, in other words, they ablate the unit circle counter clockwise)

I hope, this helps a bit, I'm sorry that I explain it so complicated.

2007? Nothing happened on this feature? Shame, scrolling backgrounds need to be made easy please.

2011. There's a Construct Wiki. Shame, one should really test out objects or read the wiki before complaining <img src="{SMILIES_PATH}/icon_wink.gif" alt=";)" title="Wink" />

http://sourceforge.net/apps/mediawiki/construct/index.php?title=Tiled_Background_Object

As you all might know, the music volume is controlled with a value in the range [0, 100]

Unfortunately, this sets the volume on a linear scale, whereas human ears hear the loudness on a logarithmic scale.

To set the volume of the music more naturally (meaning 50% feels like half as loud, etc), do this:

-> XAudio2: Set music volume to max(log10(myVolume) * 50, 0)

where myVolume is your desired percentage in the range [0, 100]

I'm terribly sorry. I forgot some sprite's effect. Should work now. I updated the link in my post above

Doing something like this with events as a finger exercise - I bow deep to your wit.

Can't get it to work since you changed the name of color overlay. Could you update the example?

Here you are

But see this as an approach only. There would be much work to have it the way you need it. Maybe chroma key is yet the way to go?