tulamide's Forum Posts

    I wouldn't recommend changing the SDK this way. It still is a quick'n'dirty patch, and was only tested with the creation of a relative simple plugin. I'm still in doubt if all string tasks will work.

    But if it is fine for Scirra, I could prepare an alternative download. Then everyone can freely decide wether to get the official SDK, or the at-your-own-risk patched version.

  • Sprites have a hotspot that you set in the picture editor (select it with the little red icon below the ellipse tool). For more information, have a look at the wiki: http://sourceforge.net/apps/mediawiki/c ... ure_Editor

    The panel object does not support setting the hotspot in the picture editor. However, it has a property "Hotspot" that you can set to a few positions like top-left or bottom.

    Most other objects don't support hotspots.

  • But that's exactly what lucid's example does

    Or do you mean, you have a list of e.g. 20 different objects, and you want to loop through them? Then just create an array "names" that you fill with the names of your objects, and a global variable "selector"

    then do:

    + On key Shift pressed

    -> Add 1 to global 'selector'

    ++ Is global 'selector' greater than 20

    -->set global 'selector' to 1

    + On left click

    -> create object names(global('selector')) at mousex, mousey

    (this is the action "Create object by name")

  • lucid did beat me to it, but I made such a nice example (although a little more complex), well commented and such, so I will post the link anyway

    using_s_to_save.cap

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I can't tell what you are experiencing here. But I can say for sure, there's an error in the source code.

    main.cpp, lines 616-619, eDisplayAngleTurnRandomiser is set to return pp.growRandom instead of pp.daTurnRandom

    but this is only returning the wrong value, the correct values are set using the actions.

    Anyway, the above is a very easy to solve issue, put it on the tracker and hopefully here are also reading people who are working on updates to Construct 0.x

  • I remember a year or so ago, the main developer of the unreal engine 3 was asked how long it will take until a realtime engine could do all the sweet things those non-realtime raytracers of Maya, C4D, etc can do.

    He smiled and said that they do it already.

    Seeing something like this makes me believe he wasn't just promoting his product ...

    Wow, ROJOhound, you should turn your last post here into a separate thread, and it should be stickied.

    I did exactly what you proposed, and the only thing additionally left to do was to open "ConstructSDK.rc" and comment out

    #include "afxres.h"[/code:1leexwxx][h2](I replaced it with "windows.h" instead of commenting out, but I think this is nonsense)[/h2]

and
[code:1leexwxx]#include "afxres.rc"[/code:1leexwxx]

afxres is part of mfc, but I'm working with the "Template Win32 VC8-9 Static", so I simply hope, that they aren't needed.

I've gone through the GradientCalc Tutorial and successfully created the plugin and it works without problems. That encourages me to think, afxres isn't needed...

Summary:
To be able to create plugins for Construct 0.x, you need
1) Visual C++ 2008 Express
2) Construct's plugin SDK
3) WtlStdString
4) changes to the template as described by ROJO and me

...no 600MB downloads needed anymore

  • ...can I just have an event which is "every millesecond" then have tons of events under that event as sub-events?

    No, you can't!

    I can't stress this statement enough. 'every x millisecond' is not a reliable way of programming time based! Its timeslice is dependent on the framerate and that is exactly what you try to avoid when using a delta time.

    If your game runs at 60 fps, the shortest timeslice you get for 'every' is 1/60s, ~17ms. You could try to set the condition to 17ms, but if for whatever reason the game runs on another computer with 30 fps the shortest timeslice is 1/30 or ~34 ms. In result, the game will be half as fast as on the first computer, because the 'every'-event is still triggered on every tick...

    Btw, the example above also shows, that you can't even set the actual values but an approximation (e.g. 17 instead of 16.666666666666...)

    This is actually an interesting problem because the Every event can only trigger at most once per tick (like Always). So if you're running at 10fps, the Every event will only trigger at most every 100ms. This is kind of awkward because it can make things framerate dependent again, even in well-designed, framerate-independent games.

    h2]Source

    'Every x milliseconds' also triggers in the next possible tick, not at the exact time. For example, with 60 fps, the 20th tick is reached at 333.33333333...ms, the 19th at 316.6666666...ms. If you'd now have it run 'every 320 milliseconds' it will occur in the 20th tick, not in between tick 19 and 20. This isn't that bad when just, let's say, switching a light on and off, but it is crucial when constantly moving a sprite or fading a color, etc. It will get slowly out of time.

    Here is a cap. Run it and watch for a while (half a minute or more). The two sprites are both set to repeatedly move 400 pixels per second. The one above uses timedelta, the one below uses 'every...' I think, seeing this is better than a thousand words.

    TimeDeltaVSeveryXms.cap

  • I'm not quite sure what you mean.

    The time scale is just one project-wide setting, you can't apply it to a few things but not to others. When you set the time scale to 0.5, everything moves half as fast.

  • Be careful though, without the limiter all sounds being played at once will add to the maximum loudness. It is easily possible to exceed the 0db, which for digital sound means everything will be unbearable distorted. So, when working without the limiter, you have to make sure, you will never cross the 0db by lowering the volumes of the sounds!

  • Oh, that's cool. I missed that one, indeed.

  • By default, xaudio2 has a limiter active which makes sense but affects the sound being played. Try the following:

    1) While only playing this one sound, switch off the limiter and see if it still crackles.

    2) Open your wav-file with some sound editor and select the first milliseconds (ca 25-50 ms should suffice). Then use a fade-in on that part. Save it and try again with and without the limiter. Does it still crackle?

  • That's what I meant by "mathematically correct". You see, there are two problems here:

    1) sprite.angle returns a value between 0-360, and it expects a positive value in th range 0-360

    2) when crossing 0, the highest and lowest value change, and therefore it's lerping "backwards"

    My Post solves only issue 1)

  • This is so cool!

    Graphically appealing:

    http://earslap.com/projectslab/otomata/ ... 651n1a7a7n

    http://earslap.com/projectslab/otomata/ ... 251n1x7x7n

    Musically appealing (rather simple):

    http://earslap.com/projectslab/otomata/?q=7533

    http://earslap.com/projectslab/otomata/?q=1y79424g

    Graphically and musically appealing:

    http://earslap.com/projectslab/otomata/ ... 424q3y5i4u

    ...and my masterpiece! A very (very!) long sequence, still varying after 5 minutes or so! It's like some musician improvising. Sit back, close your eyes and relax

    http://earslap.com/projectslab/otomata/ ... 1535491v0l

  • Lerpin angles is a bit complicated, might do an example of that.

    lerp(sprite.angle, new angle,x*timedelta)= boo hoo when new angle is greater than 360, or is less than 0.

    That's no problem with math prior to lerp. Set a variable (we call it 'm' here) to:

    m = (abs(new angle) % 360) * Sign(new angle) + 360[/code:3phpb3i2]

then use lerp with:
[code:3phpb3i2]lerp(sprite.angle, m % 360,x*timedelta)[/code:3phpb3i2]

Whatever value 'new angle' has, it will be (mathematically correct) shifted to the range 0-360