fedca's Forum Posts

  • const ALPHAEX_SHIFT = 1024;
const ALPHAEX_MAX = 1023;
const RGBEX_SHIFT = 16384;
const RGBEX_MAX = 8191;
const RGBEX_MIN = -8192;

C3.GetRValue = function GetRValue(rgb) {
 if (rgb >= 0)
 return (rgb & 255) / 255;
 else {
 let v = Math.floor(-rgb / (RGBEX_SHIFT * RGBEX_SHIFT * ALPHAEX_SHIFT));
 if (v > RGBEX_MAX)
 v -= RGBEX_SHIFT;
 return v / 1024
 }
}
;
C3.GetGValue = function GetGValue(rgb) {
 if (rgb >= 0)
 return ((rgb & 65280) >> 8) / 255;
 else {
 let v = Math.floor(-rgb % (RGBEX_SHIFT * RGBEX_SHIFT * ALPHAEX_SHIFT) / (RGBEX_SHIFT * ALPHAEX_SHIFT));
 if (v > RGBEX_MAX)
 v -= RGBEX_SHIFT;
 return v / 1024
 }
}
;
C3.GetBValue = function GetBValue(rgb) {
 if (rgb >= 0)
 return ((rgb & 16711680) >> 16) / 255;
 else {
 let v = Math.floor(-rgb % (RGBEX_SHIFT * ALPHAEX_SHIFT) / ALPHAEX_SHIFT);
 if (v > RGBEX_MAX)
 v -= RGBEX_SHIFT;
 return v / 1024
 }
}
;
C3.GetAValue = function GetAValue(rgb) {
 if (isNegativeZero(rgb))
 return 0;
 else if (rgb >= 0)
 return 1;
 else {
 const v = Math.floor(-rgb % ALPHAEX_SHIFT);
 return v / ALPHAEX_MAX
 }
}

  • yea you are right, it seems to give incorrect results. Let me check c3 source to see how they generate it

  • Converting a colorValue back to RGB 255:

    R = int((-colorValue / 2^38) % 1025 * 255 / 1023)

    G = int((-colorValue / 2^24) % 1025 * 255 / 1023)

    B = int((-colorValue / 2^10) % 1025 * 255 / 1023)

    A = int((-colorValue) % 1025 * 255 / 1023)

  • There is this property available for the parent of a hierarchy, with the mode set to wrap or all it will now select the whole hierarchy every time you select any of its members. If you want to select them individually again, for example to turn off wrap mode you can hold alt and then click the instance

  • I read this very interesting blog posts on the topic yesterday, it goes into different 2d collision optimizations as well as benchmarking. https://0fps.net/category/programming/collision-detection/

    The main verdict is:

    - cells are super fast if the cell size is tuned properly and the distribution of instances is uniform

    - the tree structures try to fix that by putting more cells where more instances are so it can handle random distribution and clusters more efficiently

    Looking at the benchmarks this person does it seems like rBush (https://github.com/mourner/rbush) is performing very well in a wide variety of cases, so I added it to Wacky Toasters benchmark https://drive.google.com/file/d/1aM894Ckvqb-BVBREuXN34CqDtpzmuZQ3/view?usp=sharing (just hacked in)

    Test 1:

    3x faster than quadTree and 100x faster than collision cells. But that is probably only due the collision cell size being tuned badly, as in theory this bench should be very favorable to collision cells.

    Test 2:

    I don't really understand how events are so fast in that benchmark.

    Another side note: to me it seems like wasm is a good fit for a collision system like this as it seems easy to separate from the main js logic and could lead to some nice perf improvements.

  • one is for Edit Time, the other for Run Time.

    But I agree that it's super annoying to have to juggle a ton of different files for addons.

  • Press enter after selecting multiple objects to wrap select them

  • does this work for you?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • never mind my last message it doesn't work properly in all cases, I think my test was flawed.

  • Ashley so if you are checking for 10 different timers in the event sheet, enemy on timer X, enemy on timer y etc. You have the overhead 10 times. With true triggers the behaviour processing might be slightly higher but you wouldn't have the overhead againfor each on timer check.

  • They don't have to be in the layout, you usually create a object repository layout where you set them up

  • Construct has hierarchies (scene graph) and a system called templates. These two combined can do what you are looking for

  • Ashley I hope this really is an oversight... But this has been brought up before so I doubt it...

    you can only add containers to the base object types, so when picking its family variant there is no way to know which container each instance has. This might be fixable if families had their own container so an object type can have both a family and a object type container

  • yea I noticed that rewriting stuff in js also leads to worse performance if it's just a simple event. I was able to get better performance if I was doing some heavy stuff on the instances, as this evens out the initial overhead.

    The reason for it seems to be that getting the instances is slow, no matter if using the iterator or getting the array of instances, maybe due to runtime glue or because they are lazy created? (getting instances by UID was fast again)

  • 100% agree, Overboys addon is great! (most of your recent posts make me feel like I'm not alone xD)

    This plus nested families would allow writing so so much cleaner, more scalable and more performant events as you can get rid of a lot of picking spaghetti and for each.