tulamide's Forum Posts

  • A few things about the original example and splines: They are much more than curves. In fact they are ideal partners for such effects. Because you control the bendiness of the segments of a spline. They can be straight lines as well as a whole circle, they keep connected to each other, etc. The randomness is created with 2 perlin noise generators that are re-seeded on every tick in the flash example.

    The problem is just, that splines are much easier done in a script language like AS3 or Python than in an event-based system.

    The rest of the flash example is realized with effects, that you can use in CC as well, namely 'additive', 'horizontal blur' and 'vertical blur' and 'behind glow'

  • I had a quick look at parallax mapping, and it is not so much about the pixel shader version (it could be done v2.0 compliant). But in Construct you only have access to the actual texture and its background, you can't access a second or third texture (which would be needed). Maybe with a fixed parallax angle (set by a parameter) it could be done to the background.

  • Yep, the flash example uses splines, and you could achieve something similar with CC. But why doing all that work (and it is a lot of work) if there already is a nice looking solution using the ribbon object and distortion? <img src="smileys/smiley2.gif" border="0" align="middle" />

  • Here: mediafire.com/file/18ez6q6i60ibwb7/randomunique.cap

    EDIT oh, shadowlord beat me to it <img src="smileys/smiley36.gif" border="0" align="middle" /> That brings up the question, why I saw his post not before posting mine <img src="smileys/smiley5.gif" border="0" align="middle" />

  • Metal_X described a lot more detailed, what I meant in my previous post by "when not working v-synced".

    And, yes, you have to decide wether to go pixel based or time based. A mixture will almost always fail. Using a fixed rate may assure you to work pixel based, but will have a jerking output (as it isn't in sync). v-sync and deltatime, on the other hand, will assure you of the same game speed at all rates and a smooth output.

    For problems like yours, when people want to work time based, they use a technique like "push out". Whenever a collision happens, the object will be moved out of the other object within one frame. In result, it looks like it collides pixel accurate. There also is "overlap at offset" which helps a lot, too, when working time based.

  • > This is what I see (but running smooth):

    Try to change the screen resolution to 1280x720 or to 1280x768,1280x1024,1366x768,1440x900,1600x1200,1920x1080. Maybe it will help.My screen resolution already is 1920x1080. There seems to be some calculation problem (maybe the calculation for the zoom is wrong?)

    However, you're on a very good way, atmosphere and sound are brilliant.

  • The game does run smooth on my pc, but the first time I started it it, after "Forever" there was just a brownish area with a big black line below and nothing else happened (besides the music playing). Today I started it again and the gamescreen appeared this time, but I don't think it is shown as you intended. This is what I see (but running smooth):

    Link to bigger image

    MSI GTX460 Hawk

    AMD Athlon II X2 250 3 Ghz

    2 GB RAM

  • Subscribe to Construct videos now

    Wow, Arima, it's the first time I see actual gameplay of Loot Pursuit, and it instantly reminds me on the good old times of early console RPGs, like Grandia and such. Very, very good work! (Did I see some variation of either FF's "active time battle" system, or the one from Grandia?)

  • Short answer: no.

    <img src="smileys/smiley1.gif" border="0" align="middle" />

  • I might overlook something, but from a quick look at the events, Construct does exactly what you order it to do.

    Sprite.Right Lower or equal Sprite2.Left

    If Sprite2.Left is 100, then this is true for 0 to 100, if you negate it, it becomes true as soon as Sprite.Right is 101, and that's 1 Pixel overlapping.

    It should work, when you change all conditions to just 'lower than'

    Sprite.Right Lower than Sprite2.Left

    Is true for 0-99, if Sprite2.Left is 100. Negated it is true as soon as Sprite.Right is 100 == no overlapping

    But in general pixel perfect condition testing can only be done reliable, when not using v-sync (have a look at TimeDelta on the wiki, if you are not sure if this is important to you)

  • What am I doing wrong?You are playing music. Really, I'm not joking. The XAudio2 implementation differentiates between music and sound. The master volume options belong to the sound part. Music has its own seperate volume options, that you would need to set to 0 (zero) to mute.

  • It's a shame, you don't get any comments. Not only is it a fine example of using the hashtable object, but also something, many people wanted to have an example for. (This and hashtable/array-based inventory)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Thank you all :)

    Yaottabyte: Thank you so much. It's a good feeling, that someone makes good use of the effects :)

  • No, there isn't any bug with the else-condition. While it is working correct, the logic behind the creation of the events is incorrect.

    Let's have a closer look at it:

    + Terrain: Terrain overlaps Shadows

    + Terrain: Value 'Nodarken' Equal to 0

    -> Terrain: Set filter to

    + System: Else

    -> Terrain: Set filter to

    On every tick CC is ordered to check if any Terrain overlaps any shadow. Of those, only the ones with the correct value of the pv are picked. This selection of objects get a grey filter.

    But using 'else' here means that only if NO terrain is overlapping any shadow, all terrains will get the white filter.

    As you can see in your layout, there are several instances of 'Whiterock2' that always overlap a shadow object, so the else-branch will never be executed, because the first conditions are always true.

    Currently all terrain objects are tested on every tick. Unless it isn't so, you can (besides Metal_X's solution) also do it just like this:

    + System: Always (every tick)

    -> Terrain: Set filter to white

    + Terrain: Terrain overlaps Shadows

    + Terrain: Value 'Nodarken' Equal to 0

    -> Terrain: Set filter to grey

  • In collaboration with oppenheimer (many thanks for the input, ideas and testing) I finally could make something useful out of the original idea of C-DEX.

    C-DEX is an effect that allows for gradient mapping. An offset parameter enables palette animation as well, which is the highlight of the effect. It is designed to be as easy to use as possible.

    Here is a demo in executable form:

    <img src="http://dl.dropbox.com/u/11182740/construct/C-DEX%20beta/cdexscreen.png" border="0">

    Use it to play around with the parameters and to see what it does. Just click on any of the options in the menu, then use the mouse wheel to change that parameter. In the lower part of the window you will find two buttons allowing you to load your own color palettes/gradients and background images. The latter should be in some power-of-two format (16x256, 32x32, 128x8, etc.) to be able to animate the background. The gradients can be in any format or size, just load any texture you get your hands on. Download link: C-DEX Demo A.rar

    Effect Download:

    C-DEX.fx

    EDIT: And here some explanations for usage. The effect recolors everything underneath the object it is applied to, using the first pixel line of the texture of that object from left to right. "offset" shifts the start value for mapping to the right and is used as a value from 0.0 (=left) to 1.0 (=right). You can enter a value higher than 1.0, it will then calculate the correct position (2.2 = 0.2, 3.0 = 0, 4.7 = 0.7, etc.) If you enter a negative number, then the range of colors to map to is reduced until you reach -1.0, at which point only the leftmost color remains. Could serve for a nice color fade in effect, or something)

    If you want to use it as a layer effect, the gradient should be on the top of that layer, and again the full length is sampled. (You could just place the gradient object on that layer, as an example). Everything underneath that layer is then recolored.

    Note: Due to the nature of the effect and the limitations of the hlsl-implemetation, rotation of the object is not possible (the colors are still sampled from the first pixel line of the bounding box)