Davioware's Forum Posts

  • 64mb RAM, and a 400mhz CPU, honestly? My pc from 15 years ago had more RAM than that, and it had a 333mhz processor, and a 6 GB hard drive.

    I'd say the bare minimum is 500 mhz processor, 128mb ram, and some kind of graphics hardware with DX9. Even with that you're pushing it. The event engine bogs down HARD on slower cpus with anything remotely complex. Anything with shaders will also kill framerates on older gpus.

    Anything made with Construct needs some kind of graphics card to run at acceptable frame rates. I just don't think a 15 year old pc would cut it.

    2. How can you import video into the runtime? You can't without a special plugin or python. You can let the user load music, but what do layouts have to do with that? You can just simulate different "layouts" with proper design, all on a single layout.

  • It doesn't work well for anything remotely complex, you'll have to make your own.

  • You learn by practicing, and examining examples.

    Sprite2.X - (Sprite2.Width/2)

    It means exactly what it says: The X position of the sprite, minus half of its width. It's completely logical, just think about it.

  • Gblur100 is a powerful 100 sample variable Gaussian blur. It is split into 2 separate shaders to be more efficient. Apply them both for a uniform blur, or just use one if you only want to blur in 1 dimension.

    Gblur100 uses -100- Gaussian weighted samples, which means unlike the stock blur shaders (which use 13 samples), this one can blur to extreme amounts, resulting in complete loss of focus, without noticeable quality loss. It is also variable, which mean you can tell it by how much to blur each pixel at runtime.

    Moderately new graphics cards won't have any problem handling this shader, but it might be taxing on integrated cards or very old gpu's.

    Also included is an oversampling parameter, which makes the blurred image glow or weaken, without using another shader. Useful for transitions, Luminosity level corrections when combining with other shaders, etc.

    NOTE: the GIF compression makes the blurring look dithered due to the low color amount, at runtime the effect is completely smooth.

    <img src="https://dl.dropbox.com/u/1010927/Forumpics/Gblur100.gif" border="0">

    -Download-

  • If you don't know mySQL and php or an equivalent you can probably forget about an account based system.

  • Ok, one thing I found was that double clicks don't count as a click. Maybe there's a setting I'm missing, but I created a button, then I wanted a sprite to rotate every time it was pressed down, regardless of if the click was a double click or not. The only action for the button which worked as expected was "on up". I realize there's a seperate action for double clicks, but the button should respond equally for the action "on down" as "on up"

    Edit: I experimented further and this only happens if the mouse is pressed at the exact same position as before on the second click. For example, if you change position every time you click, it doesn't care about whether it's a double click or not.

    Also, the double click action works strangely, not as expected.

  • Looks like it could be a godsend for editors made in Construct. Bought a copy, trying it out now!

  • Basically, It remembers the previous 2 frames, then uses them to affect the data.

    Honestly, you're better off trying to recreate the effect yourself by looking at that site, you'll understand the basics and be able to adapt them to your own implementation. Don't feel bad if you don't understand it right away, it's tricky.

    However, if you don't know what loopindex is, or aren't experienced in "real programming" (ie, algorithm design, with traditional programming methods) then this might be a bit too complicated to understand for now, but don't let that stop you from trying.

  • Wow, amazing. One of the few effects that construct was missing.

  • There isn't a purpose to doing that though, since you want the MaxSpeed variable of the behavior to change according to constantly true events. Where you would modify the real max speed you should just change originalMaxSpeed. If you want to use the actual variable (there isn't really a purpose to this), you should use another eventing paradigm. What that means (basically) is setting up the character with states, so that upon entering "crouched", his max speed changes once (not every frame like it does now), and then it gets set back to the original only once he exits that state. In my experience, this method is much more prone to bugs depending on the complexity of your system. It's much safer coding practice to reset the maxspeed every frame, then change it when things are true. Imagine a waterfall, where game frames are the water. Now, when it flows straight the max speed is its base value. However, when the player is crouched, a funnel diverts the flow of the water to half of it's original value. when the crouching events are true it would set a state "crouched" for the player to 1. Then, whenever crouched=1 it would "create the funnel" (setting the speed to half of it's original). however the frame when crouched goes back to 0 would mean the waterfall returns to it's full force.(the original speed returns.). The reason you would want a state called crouched is so that you can checked whether the player is crouched further down the line for other events. Let's say he can only go invisible while he is crouched, then all you would have to check is if crouched=1, instead of checking whether he is on the ground, and holding down button. Just giving you some insight to a more complex scenario where you would want a solid foundation for more complex logic.

  • The reason you lose the ability to move is because your dividing the max speed by 2 every frame the condition is true. Max speed is a variable, so when you divide it by 2, next time you access it it will be then halved value, not the original. The reason image-height/2 works is because it's a constant. Had you used .height instead your player would shrink infinitely.

    To fix this you have a few options:

    1. create a variable called originalMaxSpeed and set it to the max speed you want as a base. Then set max speed to originalMaxSpeed/2.

    2. Set the max speed to the base amount every frame, then affect it as the event sheet progresses. Since it will get reset on every frame, then it won't accumulate like it's doing now.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Events don't skip.

    Using timedelta is actually the cause of most failed collisions. Using frame based logic will slow down the game when it lags, as opposed to moving the objects further when the frame rate is low. What you have to do to stop collisions from failing is run a loop which steps the objects 1 pixel at a time and checks for collisions incrementally during the loop. For example, if an object is going to move 100 pixels on the x axis this frame, you must run a loop from 1 to 100, and move the object one pixel at a time, and check for collisions after every 1 pixel movement. The loop can also be less accurate (a fixed number of steps moving the object a percentage of it`s required distance each iteration, as opposed to 1 pixel per step), which saves cpu time. This stepping method is how many behaviors work.

  • Hash table in C1 (It's called Dictonary in C2, I guess since it does away with the underlying hash)

  • I was wrong, read my edit above.

  • Ok, I tested a bunch of stuff by making a program which graphs the rate of change of timedelta (or the timedeltadelta, if you wish), and I think the problem has to do with the margin of error of timedelta. For example: At unlimited fps, the graph shows less, and smaller changes in timedeltadelta over the same period of time. I guess this has to do with the fact that the higher fps allows for more calculations of the delta, so a small error is corrected faster, and has less effect on the net error accumulation. At v-synced fps, the timedeltadelta shows more periodic drops, resulting in a smaller overall timedelta accumulation (hence the slower object speed).

    TL:DR, I believe this has to do with a higher fps being more accurate in the average timedelta calculation. When you set an objects speed by accumulation like you're doing, you're accumulating a lot of error, which is why the speed varies wildly across framerates. V-sync seems to accumulate A much higher error %, in the same amount of time, biased towards lower value than expected error (more of the errors are drops).

    I'm not even sure if the floating point calculation errors are to blame for some of this error though, it's hard to tell.

    Edit: I'm wrong. While what I said is true, there isn't enough error to account for that amount of speed difference. The reason it's moving faster is because you're not multiplying the set position action by timedelta too. You have to multiply BOTH the acceleration increase and the set position action by timedelta, otherwise you're increasing the acceleration rate at a timedelta'd factor, but you're the moving the object based on the framerate. It's REALLY counter intuitive at first glance.