dkdoom's Forum Posts

  • i'm glad you found a solution that works for you, but be aware that this does not really do what you asked for in your first post ( with 200 / 100, you'll get a 33 / 66 percent split ) </nitpick> :)

  • while you're at it, do you think that 'Duplicate Frames' could also be done by Ctrl-Dragging an animation frame, similar to the duplication of layout objects? that would make this operation even more comfortable than right-and-left-clicking :)

  • you are talking about dividing the new weight depending on the difference between the original weights, so with 200 to 100, the difference would be 100 / 0. in this case, you state you want a division of 25 / 75 percent. for 0 / 0, it should be 50 / 50. that sounds like the unbiased percentage of 50 is halfed for every 100 weight-units an object weights more than its counterpart. i think that is an exponential function ...

    myWeight = 200;
otherWeight = 100;
newWeight = x;
myBias = abs( myWeight - otherWeight ); // the weight bias
myBias *=( Sign( myWeight - otherWeight )> 0 ); // if its negative, make it zero
if( myBias != 0 )
    myPercent = .5 ^( myBias / 100 );
else
    myPercent = 1 - otherPercent;
myWeight += newWeight * myPercent;[/code:i1z7khp6]
something like that, i guess; it could be merged into one line, but that would just be confusing. unless you really wanted the division to respect the [i]relative[/i] weights of the objects, which would be simpler.

  • very nice! i like how it the worm is 'designed by math' but avoids to look sterile; the turning motion/swaying makes it really come to life! :)

  • instead of using a mask, i believe it is more efficient (and simpler) to just add an extra condition to your LoS-event:

    + Sprite has LoS to Target
+ Compare: Distance( Sprite.X, Sprite.Y, Target.X, Target.Y ) Less Than 300
    -> ...[/code:akr5ng2v]you could also have the field of view limited by angle, so the actor behaves more 'realistic' (e.g. can't look in the opposite direction he's walking):
[code:akr5ng2v]+ Sprite has LoS to Target
+ Compare: AngleDiff( Sprite.Angle, Angle( Sprite.X, Sprite.Y, Target.X, Target.Y )) Less Than 45
    -> ...[/code:akr5ng2v](the last one was actually what i thought you had meant when typing 'field of view')
it's rather easy to do in events when you know how, but i agree that the scenario might be rather common.

  • thanks for your feedback!

    i know that the ability to tilt the camera can ruin the illusion; but apart from that, i would really like to know how it is done properly (since my math is wrong in that regard).

    thats not how we roll around here.

    of course i know that the friendly people of this forum are not going to 'steal' this (aside from the fact that it's nothing special, too). mind you, the cc license is actually an explicit statement that the work can (and should) be shared. if i had not published it under a license, copyright law would have implied that 'all rights are reserved', which would (imho) not be in line with the creative spirit around here.

  • while trying to rip off space harrier, i finally found the guts to bite through the trigonometry required to build a simple faux-3d 'sprite scaling' engine:

    <img src="http://www.dikmann.com/scaler.jpg">

    all behaves well except for tilting the camera. i know it is a hassle to look at other peoples code, but maybe some of you math genius' spot my error straight away ... i would greatly appreciate it! (the code is rather clean to read, too ... :))

    scaler engine v01.cap

    and if anybody wants to use it, there's a friendly license on it that lets you do that, too. yay for sharing! <img src="http://i.creativecommons.org/l/by-nc-sa/3.0/de/80x15.png">

  • hi (and thank you, devs, for 98.7!)

    in the following example, i am trying to create a number of objects equal to the number of lines found in a ListBox, and set their attributes to the values found in the respective ListBox' entries. however, it appears that the second action always treats all sprites, instead of just the one that was created last. i read that creating an object automatically puts it (alone) into the SOL, so i wanted to ask if this is a bug:

    + For each line
    - Create Object: Sprite
    - Sprite: Set angle to ListBox.LineText( ListBox.CurrentIndex )[/code:1iy6gf5n][url=http://www.dikmann.com/sol_foreachline.cap]demonstration .cap[/url]

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • The effect is processed on the object's bounding box

    hm, so it's a bug that a sprite can shift his texture outside of its bounds?

  • i'm working on it :)

    (the fractal shader is out of reach for me, though, since it needs ps version 3.0...)

  • hi again,

    when putting the following pixelshader on a sprite:

    float4 color = tex2D( foreground, Tex.xy + 0.1 );
return color;[/code:17zosu4h]the texture is not only displaced as expected, but even drawn outside of the sprite's bounds. it also produces strange artifacts when moving the sprite close to the layout's borders. this happens with and without any combination of #BORDERMODE and #CROSS-SAMPLING, with varying funniness.

the following pixel shader, on the other hand:
[code:17zosu4h]float4 color = float4( 0, 0, 0, 1 );
if( Tex.x <= 0.1 ){ color = 1; }
if( Tex.x >= 0.9 ){ color = 1; }
return color;[/code:17zosu4h]produces white stripes on the sprite only when its bounds are moved near the borders of the layout.

could you enlighten me with what's going on, aka what geometry & texture the shader is really working on? (it is confusing that the first is not a sprite-sized quad since it can [i]sometimes[/i] render beyond its bounds, and the second is not the sprites' texture since a texture coordinate of (0,0) refers to the top left corner of the layout...)

thank you very much again!

  • thanks! i completely missed out on the wiki page

  • while some aspects of the shader implementation in construct (like the way parameters are specified, fore- and background-textures and the technique are named) are obvious from looking at the examples, i'm having trouble porting other shaders. mostly because of the omitted vertexshader, which breaks some of them in unexpected ways (related to world, view & projection spaces) that probably originate in wrong texture coordinates.

    in which way are texture coordinates handled in construct? which spaces are handed to the pixelshader? and are there any hooks in the implementation concerning sampler states / address modes?

    thanks for your time...

  • not out of the box. but thanks to directx, construct also uses .fx files written in HLSL, so the changes are marginal. most of them are due to the different ways the both programs interface with the shader.

    very short semi-informed manual: when looking at the Additive.fx in construct's effect folder, you can see that the most important (and in this case only) thing is to define a technique called ConstructEffect, which construct calls. when looking into any 'foreign' .fx, you will also find these definition (mostly at the bottom). these techniques tell which functions should be used for vertex- and pixelshading. if you just boldly go and rename them to ConstructEffect, construct can uses the shader. make sure to have VertexShader refer to null, though (else it didn't work for my first try).

    i'm just trying this out, so take it with a grain of salt, but i guess by looking at the other .fx in the construct folder, it should become obvious in which way one has to define variables for them to appear in construct.

  • admittedly, when thinking about it, i don't know of any easy ways to e.g. remove specific tags out of a private variable... since i'm a newbie, you should probably look into more advanced techniques than my 'first ideas' ;)