tulamide's Forum Posts

  • I'd very much like to see it. I also didn't know you were using custom collision shapes. Is ellipse slower? I'm thinking for an actual game I'd probably set the simulation steps to 1. I'm not sure how much that effects how "real" the water looks, but in one of quazi's examples it seemed just as good as 10. I'm also wondering if the physics plugin does any other calculations that really aren't necessary liquid, or at least, don't make a big difference.

    Using custom collision was a neccessity because of the nature of the shader. What you see of one "water drop" is just about 5% of its actual size. If I'd used ellipse, the drops would collide although they are visually still far away from each other. I'd bet the standard collision shapes are faster.

    From my experience the lowest simuation steps are better for liquids. Maybe it is a kind of "tree lookup depth", but whatever it is, the liquids feels more natural with less steps.

    Here is the link to the same project as the exe you were already testing, but as a .cap plus the needed effect: fluid.rar

  • The only reasons for crashes is if the file has not been extracted yet or there are no Resource instances. In both cases the resource plugin doesn't crash, it is another plugin trying to load a file that crashes.

    The expression Resource ("foo") will return the path of the file if it's been extracted, otherwise if the file isn't extracted it will return an empty string :"".

    The action of loading a file with the path "" is what causes the crash. For example this will crash:

    -> EditBox: Load file ""[/code:2maq9f0a]

All that should be needed is 1 global resource object.  When a object is global it will exist on the layout it was created on then all other layouts run after that.  If there are no instances of Resource the expression [b]Resource ("foo")[/b] will return 0, which also causes a crash if it's used as a file path to load.  It's a default behavior of construct to return 0 when a expression is used and there are no instance of that object.

    I see and it is exactly what I thought, too. And I wasn't clear enough of what I was using it for. I used it to load a font from a folder on disk. And it really only works the way I describe it. Here is the project (just some private text removed), in case you are curious:

    http://www.mediafire.com/file/j82u8distd6x68c/Xmas%20Yv.rar

    btw, what happens if you are trying to load and use a font that is already installed on the computer? Is it safe to load it anyway?

  • Tulamide, your example looks pretty cool. I can't seem to find what the fps is after the simulation actually starts but it shows fps at 60 first when it measures and the max particles is 380.

    It runs at v-synced rate the whole time. As soon as the frame rate (that was measured at the beginning) drops, the spawning of sprites is stopped until the frame rate is up again (normally just a few ticks) The physics use 10 simulation steps and there are some calculatons that are done in an "for each" loop on every spawned sprite on every tick (for testing purposes). I'd say, with less calculations and lower simulation steps you could reach 600-1000 sprites. But the physics object seems to have problems with too many sprites that use custom collisions. I ran into serious issues with a collision shape using more than 5 points when having more than ~500 sprites on screen.

    I could send you the cap and the blob shader (that isn't very gpu heavy, it works on a layer not on every sprite) if you are interested.

  • 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

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

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