R0J0hound's Recent Forum Activity

  • That's strange for sure. Actually those hidden characters are in that "$‎¥‎" you posted. Using js I'm getting a length of 4 with that and the unicode value of each value is (gotten with the js method .charCodeAt(n)):

    36, 8206, 165, 8206

    36 is $ and 165 is ¥.

    So what is that 8206 (or in hex 0x200E) value? After searching a bit it might be this:

    "Control Character left to right mark"

    en.wikipedia.org/wiki/Implicit_directional_marks

    It's used to switch ordering from "right to left" languages to "left to right".

    Still it's not clear to me why that's added. In your posts it's after the ¥ and $ in quotes in your last post and only after one ¥ in your fourth post. It's not after your other uses of that symbol.

    One way to quickly check for invisible characters is with the browser console. When you type in in a quoted string the invisible characters are shown as circles you can hover the mouse over to see what they are.

    Alarmingly there is a lot of invisible characters.

    invisible-characters.com

    Guess you could bring this up as a suggestion to have a way to show hidden characters in construct to aid with debugging.

  • I figure that setting opacity is just setting a number so it’s light to set it twice. Else does a bit more than just run if the previous event was false. I tend to only use it in simple cases like you did since how it behaves with more complex picking isn’t entirely intuitive to me. However, it may be mostly a personal preference to do things in as few events as possible.

    I was almost going to write out some pseudocode for all that the events are functionally doing under the hood but I’m not sure that would be useful. I’ve only perused the source for the picking system in the C2 days, but mostly regard it as a black box so I don’t know all that’s going on other than basic behavior.

  • You’re probably just encountering overhead from the picking system. Picking involves juggling lists of picked object with one known optimization if all the instances are picked.

    So in your case it’s slower to filter 1000 objects down to 500 before looping over it for collision checks, instead of just looping over the 1000 objects to do collision checks. So I’m guessing one case is able to be optimized to be faster over the other?

    In that particular set of events you could try some other things to improve it. One could be to do “sprite overlaps sprite2” instead of “sprite2 overlaps sprite” since you are only dealing with sprite.

    You can also eliminate the else, and the loop for that matter. Loops are known to have a fair amount of overhead. 

    Sprite: is visible
— sprite: set opacity to 33
— sprite: overlaps sprite2
— — sprite: set opacity to 100

  • The lines may just be an artifact of the text renderer on Linux or in wine or something.

    To see if that’s an actual character you could open it in c3 and run a len() on that to see if it’s counted as a character. Theres probably other ways to check.

    Typing text is a fundamental feature of edit controls and really it’s controlled by the operating system that the browser and then construct uses. If it is adding extra characters it’s something outside of construct most likely.

  • You have options though.

    One way is to get a list of words (you can find and download lists of words online). Load that into a dictionary, and just check to see if the typed word is found in the dictionary or not.

    Another option is to find a js library to do it for you. Although attaching js libraries have their share of annoyances to use.

    Found this one that requires minimal boiler plate code. It will also offer some possible suggested corrections too.

    github.com/cfinke/Typo.js

    dropbox.com/scl/fi/cgdne40or7tx39wy518ih/spellcheckjs_c3.c3p

  • I just have a normal English keyboard so I used the window accessory “character map”, searched for yen and copied the character from there. But I imagine I could have copied it from anywhere and it would be fine?

    You could use \u{a5} instead of ¥ if the text input accepts escaped sequences.

    If you can consistently reproduce it then it would make it simple to make a bug report. But sounds very odd if something as simple as typing and deleting characters causes issues.

  • It’s working for me.

    I added a sprite font, added the yen to the character set, then drew it in on the image. Then the set character width action worked fine.

    Example:

    dropbox.com/scl/fi/owlta99xjl1kd5f761sbr/spritefont_spacing_test.c3p

  • I ended up taking a dive looking a lerping like this in a framerate independent way.

    In a frame dependent way we'd use: 

    set a to lerp(a, b, f)

    Where f is a value from 0 to 1. The speed it moves will vary according to the framerate.

    The quick improvement is to just multiply it by dt. 60 is multiplied by it too to make it have the exact same motion as the non-dt version. 

    set a to lerp(a, b, 60*f*dt)

    With that it's largely framerate independent and approximately follows the same motion path no matter the fps, but the path can vary a bit and overshoot.

    For full framerate independent version I've found two versions online.

    One is from Ashley: 

    set a to lerp(a, b, 1-f^dt)

    and one from Freya Holmer: 

    set a to b+(a-b)*exp(-decay*dt)
or
set a to lerp(a, b, 1-exp(-decay*dt))

    Where decay is a value from 1 to 25.

    But the rate of change is different between the two. Surprisingly if we tweak either of them to use a f value of 0 to 1 and shift it to match the f and f*60*dt version we get the same equation: 

    set a to lerp(a, b, 1-(1-f)^(60*dt))

    Which will give the exact motion no matter the framerate.

  • 1) One way could be to create an invisible sprite at every grid location that isn't occupied and pick the closest one. Likely you could do that with collision detection and a double loop to loop over all the squares. It would give you an opportunity to understand some extra nuances to picking since you'd need wait or something to let all the newly created objects be pickable before picking the closest. Or just keep an invisible sprite at all the grid positions and not have to worry about it.

    Or if you prefer traditional programming logic you'd just loop over the center positions of all the empty squares, and calculate the distance. While doing it you'd keep track of the position with the closest distance, and update that if another is closer.

    2)

    It's mostly a matter of adding a condition i imagine. This is the power of events. If you want to do something conditionally you can add another condition.

  • You can look in the manual, namely the system expression section. But in general you can use any sort of math or combination of expressions as parameters. Construct supports expressions with text and numbers but you can convert between the two.

    There's even a tutorial about the uses of dt.

    construct.net/en/tutorials/delta-time-framerate-2

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • For the grid you can set the position to int(x/64)*64+32, int(y/64)*64+32 to center it in the grid. Notice the +32 which is half the grid size. I used int instead of round because it works better for this case, but you can try both to see what i mean.

    For the rest of your question I'd recommend utilizing families and\or representing things as instances of fewer types. Both would require less events.

    Consider a simple example with similarities with your setup. Each object has it's own object type: Bullet1, bullet2, enemy1 and enemy2. And both enemies have health variables. Events would look like: 

    keyboard: on z key pressed
-- create bullet1

keyboard: on x key pressed
-- create bullet2

bullet1: collides with enemy1
-- enemy1: subtract 1 from health
-- bullet1: destroy

bullet1: collides with enemy2
-- enemy2: subtract 1 from health
-- bullet1: destroy

bullet2: collides with enemy1
-- enemy1: subtract 2 from health
-- bullet2: destroy

bullet2: collides with enemy2
-- enemy2: subtract 2 from health
-- bullet2: destroy

    A quick fix would be to instead use families. Remove the health instance variables from enemy1 and enemy2, and then add enemy1 and enemy2 to a family. Call the family enemyFamily and give it a health instance variable. Similarly add bullet1 and bullet2 to a family and call it bulletFamily. Then add a variable called damage to that family. Your events then could reduce down to: 

    keyboard: on z key pressed
-- create bullet1
-- bullet1: set damage to 1

keyboard: on x key pressed
-- create bullet2
-- bullet2: set damage to 2

bulletFamily: collides with enemyFamily
-- enemyFamily: subtract bulletFamily.damage from health
-- bulletFamily: destroy

    You can do something similar by just having different enemies be different animations on the same object type. But it just depends what you want to do.

  • Manually in what way? In construct we deal with positions in layout coordinates, and construct converts those to canvas coordinates using scrollx/scrolly, layout scale, layout rotation, canvas size, and layer scale, parallax, etc… to draw.

    Well, maybe you are asking how viewportMidX(“ui”) is calculated… that could also be calculated with:

    ViewportLeft(“ui”)+viewportWidth(“ui”)/2

    Or

    (ViewportRight(“ui”)-ViewportLeft(“ui”))/2

    Or presumably if the ui layer has a parallax of 0,0 then you could just use:

    viewportWidth(“ui”)/2

    If the ui had a parallax of 100,100, and the layout had unbounded scrolling checked, then you could also just use:

    Scrollx

    With bounded scrolling the scrollx gets clamped but you can also clamp it manually if you’re so inclined:

    Clamp(scrollx, viewportWidth/2, layoutWidth-viewportWidth/2)

    But it would behave oddly if the view was smaller than the layout.

    If you set the canvas width the the window.innerWidth and had no layer or layout scaling then you could use:

    PlatformInfo.InnerWidth/2

    Of course all of those could be used with int() to round away the 0.5s from odd sizes. Also to manually handle the transformations that layers let you have then the formulas would get more involved and you may as well just use the expressions construct offers.

    Anyways, based on your previous posts you could get an unscaled pixel perfect viewport covering the window by setting the fullscreen scaling in your project properties to “none”, the set the canvas size in events to the innerWidth/height of the window. As long as the canvas is the only thing on the window there shouldn’t be any page scrolling. Then you’d just center with viewportMidX like you did above. There really isn’t a whole lot of benefit to calculating it more manually unless you encounter something that the engine doesn’t recalculate until drawing.