R0J0hound's Forum Posts

    In this context it’s fine using -infinity for volume. It converts to 0 anyways internally when the decibels are converted back to the 0-1 range for webaudio

    I mean with the formula

    Decibels = 33*log10(percent/100)

    We get approximately

    0db for 100%

    -5db for 75%

    -10db for 50%

    -20db for 25%

    -infinity db for 0%

    So decibels and percent are pretty interchangeable in that regard. Fading with one unit vs the other would give different results for sure. For a slider I’d use percent. With the numbers I’m not seeing how the top half would barely do anything.

    Construct and Audacity are the only pieces of software I’ve used that has decibels. I’ve certainly never played a game where volume was anything but a percent. Audio apis such as webaudio and fmod set volume in the 0-1 range, so basically a percentage.

  • Those debug console error messages are seldom helpful. Could it be an issue with a third party plugin? Maybe. Some were never tested with the minifier so that could be the issue. My only suggestion is to try exporting with the minifier turned off.

  • If you exported to the arcade and uploaded the exported file it should work.

  • Fixed.

    * drag based on where the mouse clicks now like you had it before.

    * also fixed the janking craziness. Turns out near a tilt of 90 things could go haywire. Fix was to limit tilt to range 1 to 89.

    dropbox.com/scl/fi/ljuplixdxjtghe23ijzdo/2d3dcam_Test.c3p

  • Here's one possible solution. Can't make an example with the free version. 

    + layer 1: force own texture
|-+ light: force own texture, effect darken, transparent no, color black, 
|-------- light gradients with destination-out blend
|-+ level: level stuff
+ layer 0: background

    Basically you'd have a light layer that's black with the light gradients with the destination-out or additive blend. The layer has force own texture so we can apply it to another layer.

    Below that you have a normal layer with all of your layer.

    To show a normal background layer under all that you'd place the light and level layers as sub-layers to a new layer with force own texture. Finally add a bottom layer with the background.

  • For 1.

    Sounds like a bug. When a texture is created from an image the code specifies whether the texture repeats or is clamped. So looks like construct recognizes that it’s the same texture and reuses it but doesn’t change the repeat mode of the texture.

    For 2.

    Tiledbg has a texture per instance. By default it loads the default one when creating, but when you load a texture it replaces it on that instance alone.

    Sprites have their textures in an animation structure that’s shared between instances. So if you replace a texture it affects all instances.

    I thought they added a way to add frames at runtime too for sprites. But overall the textures are loaded in specific ways per type.

  • logic would probably be along the lines of : 

    every 0.5 seconds
-- enemy has los to player
-- -- enemy: find path to player
-- -- enemy: set mode to "seek"
-- [X] enemy has los to player
-- -- enemy: stop following path
-- -- enemy: set mode to choose("walk", "stand", "turn")

enemy: mode = "walk"
-- enemy: move forward

enemy: mode = "turn"
-- enemy: rotate choose(-90,90) degrees clockwise
-- enemy: set mode to "walk"

enemy: on path found
-- enemy: follow path

    Or something like that.

  • Oh strange since it’s smooth on my end. I’ll have to test again. Maybe add a trace of the mouse path to debug.

    Either you’re moving the mouse in a path I didn’t test or the easing is flawed on other refresh rates? You can try to set t to 100*dt or something instead of what it has now and see if that affects things.

    It’s probably easy to switch it back to moving relative to where it clicked on the ground. Could also rotate based on where we clicked on the ground too, but then we’d need a separate control for tilt.

    Edit:

    Did you change any of the values? When I had t=exp(-100*dt) the ease was super gradual.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

    If you find older topics about it the dev explained his reasoning a few times.

    As I recall he was into audio processing in university so he prefers decibels. And he says volume isn’t linear so 50% doesn’t sound half as loud so decibels are better.

    But probably best to look up what he said exactly.

    But I prefer setting volume from 0-100 instead of -infinity to 0 so the conversion formula is helpful for me.

    Yeah. But they seem pretty adamant at using db for volume. Fun fact, the underlying sound apis set volume with a percentage.

    Anyways you can just convert the percentage to decibels with a simple formula.

    construct.net/en/forum/construct-3/how-do-i-8/user-change-volume-percentage-162705

  • Everything in construct, including tilemap use collision polygons not per pixel collisions. You should be able to set the polygon per tile. I think there’s a button for that on the tilemap toolbar.

  • Here's a modification that includes the rotation fix. I apologize, the events ended up looking a bit different since I tried simplifying a lot while I was trying to pinpoint what was causing the bug.

    * All mouse input is on the ui layer now.

    * As a side effect the drag move formula is a bit uglier since it has to rotate the mouse position delta by the rotation. Before you used mouse position from the 3d layer but that was giving NaN's when tilt was 0. Reverting back to use mouse position from the 3d layer has it's merits though since the point on the ground where you started dragging would match where you dragged to.

    * It now only moves the target object directly and the cam object eases toward the target. Also it eases position, zoom, tilt and angle. That was the main change that enabled the fix.

    * The lerping is now framerate independent. It was a small change basically using exp(-100*dt) instead of 0.2*60*dt.

    * The 3d camera position is calculated in one go with spherical coordinates which incorporates zoom, angle and tilt. It should end up the same as what you had.

    dropbox.com/scl/fi/ljuplixdxjtghe23ijzdo/2d3dcam_Test.c3p

  • It wants me to create an account to download.

    I was just saying these two should be the same. 

    sprite: timer: is timer running "foo"
    system: pick by comparison: sprite, timer.duration("foo") <> 0

    The "<>" means "not equal to".

    Anyways, the rest of my other post was the reasoning why it would be the same. You can ignore that.

  • You'd get a similar jerk in motion when using anglelerp and the target angle differs more than 180 degrees. Best i can tell you're easing the positions and getting angles from that so it's indirectly the same thing.

    One possible solution could be to use a variable for the current angle and add the change of the mouse position to that and lerp another angle to that. Here's a minimal example showing the difference between normal angle lerping and that. Could be something to try at least.

    dropbox.com/scl/fi/q8cf0o8htz5h8dubo25e1/rotationEasing.capx