R0J0hound's Recent Forum Activity

  • You can do a ray cast with a sprite.

    Set its origin to the left and set its size to 0,0. Then set its position to the player and the angle to the direction you want to go. Events would look like: 

    While
Ray: width<100
[X] ray: overlaps wall
— ray: set width to self.width+1

    The 100 would be the distance limit and the 1 would be the step size. Notice the overlap condition is the inverted version. So you’re checking if the ray doesn’t overlap a wall.

    You can tune the step size to be as accurate as you like, and to see the rays you can make the height>0.

    If the walls are sprites you can light them up with something as easy as

    Ray: overlaps wall -> wall: set opacity to 50

    So you’d probably want a step size lower than 1, and a much lower max range for your tiny layout.

    There are better algorithms that can be utilized too. But that’s a simple one that can work well enough.

  • Both sound equally possible, but it largely depends on skill and knowledge I suppose.

  • The link in the first post was a cap file for Construct 1. It wouldn't be useful for C2 or C3.

    Have you tried doing the logic for the falling sand yourself? It's pretty simple. Move down if the space below the grain is empty. Or if that isn't empty try moving down left or down right if those spaces are empty.

    You have options with how to do it. Sprites, tilemap, or drawing canvas are options.

    If you do it with events you'd want to only use system compare and else's under a loop to avoid as much picking overhead as possible.

  • — Fawk

    Here's an updated test that additionally tests using picking after the loops in the "first" and "middle" cases. Move the mouse up and down to see pics of the events to compare with the readings.

    dropbox.com/scl/fi/0qazj62jfevm0vuk2fvxp/event_timing_2.capx

    Jase00 The nesting of the events doesn't seem to affect the speed significantly.

    So far the fastest way to do things is to have the loop as the last thing after picking stuff, or you can use compares after the loop as long as they are in sub-events.

    KryptoPixel

    To change the internals it would require filing an issue, Ashley investigating it, and him possibly finding a fix to improve the performance.

    The value with this topic either way is seeing some more optimized ways to order things than others. Like from slowest way to fastest way is around 20x faster, which isn't bad.

  • We already know a system compare or evaluate is faster than picking events, but here is a performance test of variations of looping with two picking events. Half the instance's "a" variable is 0 and the other is 1. I also made them all invisible so we are just measuring how long the events take.

    It measures and averages the timings of each event with 10,000 instances. Made in C2 but tested in C3 r449.

    dropbox.com/scl/fi/xd5mz5kofj7c67ftbrhvo/event_timing.capx

    We are mostly measuring the performance of the loop and how many instances are being copied in the SOL. "First" and "Last" are taking advantage of some optimizations whereas middle does not. I tried variations of using sub events but that doesn't appear to be significant.

    The for each appears to roughly do this under the hood: 

    save SOL copy
for each sprite
-- if(following conditions or sub-events do picking)
-- -- load SOL copy
-- select nth sprite
-- do stuff

    The if may be if the loop is the last condition and sub-events don't do picking but I didn't dig too deep

    The "load SOL copy" is the heavier part.

    With the "first" tests it's not heavy since the copy is just all the instances so construct sets a flag so nothing needs to be copied.

    The "last" tests are able to skip the loading since the SOL isn't being modified past that point.

    And finally, "middle" is the slowest since it has to load a copy of half the instances every iteration.

    I can almost see a way to avoid loading the list of picked instances every iteration, but it's not my code. I'd say it still may be worth filing a report in regards to how slow the middle case is.

  • Even after looking a the runtime's source in C2 I'm having trouble coming up with consistent rules. C2 and C3 run similarly but C3 is faster.

    Anyways by default the picking system duplicates object lists a lot. Think at the top of every event block, with every iteration of a loop, and probably with some other special events. That is slow with a high amount of instances.

    But there are two major optimizations being used:

    1. When all the instances are picked then copying just sets a flag so nothing needs to be copied which is faster. That is why having the "for each" as the first condition is faster in 3 and 4.

    2. When exporting it keeps track if any of the following sub-events modify the SOL. And if they don't there's no reason to copy the SOL after that point. That's why 2 is fast. So effectively the loop would need to be the last condition in a block, and the sub events would need to do no picking to take advantage of that.

    The short version that's easier to remember is you'd want the loop to be the first or last condition in a code block. You can have non-picking events after the loop but it needs to be in a sub-event.

    The high cpu usage in 1 is from the worst case with no optimized code paths. And oddly enough number two performs just as bad if the "system compare" was directly below the loop instead of in a sub-event.

  • 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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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.