Sam Dimanche's Forum Posts

  • Thanks for your answer dop2000 !

    I don't think your solution works key in hand since setting music volume immediately interrupts the built-in fade mechanic. What would be possible would be to maybe restart the fade for the remaining time, but that's a bit complicated and frankly at this point it doesn't seem much easier than my previous audio manager which was lerping two sounds in the opposite direction...

    I think I'll give up on this idea since my previous code worked ok. It's just too bad this new feature is not flexible at all.

  • Hello everyone,

    I'm trying to implement the new "Fade Volume" action to crossfade musics, but I have a problem with it : once the crossfade has started, I cannot adjust the Music Volume effectively.

    I have a "Music Volume" slider as well as a "FX Volume" one, so I cannot simply adjust Master Volume because it would impact FXs too.

    I want to ensure players can change the volume even if a crossfade is in action.

    How would you solve this ? I can't use the "Set Volume" action because it immediately stops the fading.

    Thanks in advance for your suggestions !

    I'm trying to make my Sound Management System leaner than before, and I thought the Fade Volume would be great for that but this problem is making me pull my hair.

  • Found a workaround. If you're only fetching a text file like me with this XML, you can directly use the NWjs.readfile(NWjs.UserFolder) expression to get it, the NWjs object has no problem handling its incomplete URL.

    And as a sweet bonus it's instant whereas Ajax requests are asynchronous.

  • Hi everyone,

    I have a problem with my backup save I create in NWjs.UserFolder in case Appfolder requires a permission.

    The problem is that while NWjs.AppFolder and NWjs.ProjectFilesFolder provide perfectly fine URLs, NWjs.UserFolder does not. It actually omits the drive letter.

    Thus the path is incomplete and if I try to request a file from this URL with for example AJAX it triggers an error.

    Here is an example C3P I made :

    mediafire.com/file/sjze230aefptdsh/UserFolderProblem.c3p/file

    Basically I have the same exact problem as Colludium in this other topic :

    https://www.construct.net/en/forum/construct-2/closed-bugs-22/nwjs-object-userfolder-path-115407

    Or Suntank there :

    construct.net/en/forum/construct-2/how-do-i-18/nwjs-return-user-folders-115809

    An user in the last topic said we could always add "C:\" in front of UserFolder, but is it true that it would work on all computers ? I would like a formal confirmation before taking that claim for granted.

    Thanks in advance for your time :)

  • You're right, I have to try and make measurements myself whenever possible, it's not something that comes to my mind instinctively.

    However these were simple questions and I didn't want to reinvent the wheel ;)

    Ok ended up doing two tests and here are the results. I hope it will come useful to someone. Personnally that's the kind of good practices I'd like to see listed somewhere ^^

    1/

    - The "Set Color" appearance action is not CPU intensive (apart from the very first draw call when the action is used). It is thus entirely safe to use on a lot of spritefonts at the same time and is a convenient way to change color.

    - The "SetColor" effect is still very CPU intensive. It WILL bump the Draw Calls in a continuous manner if there are a lot of sprites using it.

    If you need to use it, consider disabling it as soon as you don't need it anymore.

    mediafire.com/file/qz9t8ps9czt172y/TestSetColor.c3p/file

    2/

    - Yes, several picking actions appear logically to be more CPU intensive (on the Event side) than a single "grouped" picking action. I'll try to use this method of picking as a good practice from now on.

    mediafire.com/file/2uqco0qx99nphkz/TestPicking.c3p/file

    See you

  • hi Seymore,

    Your code is almost right, but you're missing a "For Each Head" loop after the "Every 0.05 seconds" that will tell exactly what ID is each body.

    Right now you're picking all the bodies which are overlapping A head (but you don't know which one exactly), and you tell them to take the same ID as this head but it's very confusing and only one of the three bodies actually have the good ID in the end.

    If you add a For Each loop somewhere, every head will spawn a Body and the body knows it must take this same head's UID.

    Here is the working file :)

    See you

    mediafire.com/file/y1o22brdx48ax7h/SlitherCorrected.c3p/file

  • Hello everyone,

    Coming from C2, I refrained to use the SetColor effect on my (numerous) spritefonts since I noticed it was quite taxing on the CPU. In general I used as little effects as possible to run on older configurations.

    Now I see in C3 you can Set the Color directly as an Appearance action. I read it is more like 'Tint' than 'SetColor' but for spritefonts it's perfect.

    Is it costly in terms of performance to use this feature ?

    In my case I can have hundreds of spritefonts visible at the same time, either black or greyed. The text is always a figure from 0 to 9 and I used to have the two colors in my spritefont sheet with 0-9 being the black numbers and A-J being the grey numbers as a workaround to save on CPU. Setting the color the new way would definitely be a more flexible way to do it.

    My second question is unrelated and is regarding Picking.

    Would you say this :

    is much more efficient than this ?

    I used to do it the second way but I recently realized that grouping all the different checks in one single Picking could maybe be more efficient since every Sprites would need to only be checked and picked once. Do you think that's true ?

    Thanks for your opinion :)

    Have a nice day

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Dang I'm reading the Shipped tab and there are several cool new features I had missed x)

  • Ok, thank you! I've just got to keep this in mind then :)

  • I did, but the memory won't decrease back so much, plus that means giving up on the performance improvements Ashley said were linked to bigger spritesheets :x

    But if this lack of flexibility is voluntary I'll be moving on and I won't bother you with more questions.

    What about the absence of automatic purge at layout restart though ? I can't help but think it contradicts the manual.

  • Thank you again Ashley for your quick answers :)

    1) Spritesheeting

    Ok so this spritesheeting is normal behavior... I don't question its general usefulness, but it feels kinda counterproductive in certain instances, especially when it groups objects that are never meant to appear together. Sometimes the algorithm doesn't have a choice to do so I understand, but still.

    For example in my project I used to have a sprite with 100 frames of 800x800 (reprensenting a whopping 300mb by itself), but since there would always only be one that'd be used per layout I splitted it in a hundred sprites 800x800 instead.

    With the spritesheeting this optimization is diminished since the game needs to load at least a spritesheet each time, which represents 4 sprites (3 being useless).

    It's probably not feasible, but since we can consult the Spritesheets it would be great to be allowed to isolate one or more sprites, effectively saying : "these must not be grouped with other sprites". That would save a lot of image memory and enable anyone to build their own Performance/Memory Scale sort of.

    Maybe it's not that big a deal on desktop, although it probably depends on the project, but I suppose for mobile it wouldn't be negligible?

    2) No purge at new layout

    I read and re-read the layout-by-layout memory management page, and the simple test I produced directly contradicts it. Supposedly :

    When the layout ends, all images that are loaded but not used on the next layout are released from memory.

    If an object is not placed in the layout view, but events create it at runtime, its images are not pre-loaded.

    In the example I linked, after you've created sprites through events that bump the memory usage from 2mb to 34mb, restarting the layout should purge the memory back to 2mb since they are not on the next layout. And it's not the case, it stays at 34mb and memory must be purged manually :x

  • Investigating a little more I think I bumped into the problem, and to me it seems reaaaaaally severe.

    Here is a test case for both C2 and C3 :

    https://www.mediafire.com/file/b3ij98kz87g6luq/ConstructMemoryProblemCase.7z/file

    In each of the projects, I have 8 sprites of the size 800px*800px.

    In C2

    If you create these sprites on an empty layer one by one, the memory progressively increases. From base 6.6mb to 9mb to 11.5mb etc... That's around 2.5mb per sprite added.

    If you restart the layout, the memory is purged and you go back down to 6.6mn.

    In C3

    • C3 groups the sprites into spritesheets of 2048*2048, and these can hold 4 sprites of 800px*800px at a time. Clicking Tools >> View Spritesheets you can see Sprites 1 to 4 are together and 5 to 8 are together.
    • if you create sprite1 on an empty layer the memory increases by a massive amount, from 2mb to 18mb right away!
    • try to create sprite2 and... the memory doesn't budge.
    • try to create sprite5 (which is on the second spritesheet) and the memory jumps again to 34mb.

    ==> conclusion : C3 loads the ENTIRE spritesheet containing a needed sprite, even if the other sprites inside are not needed. That's a massive waste of memory if you ask me!

    Even trying to unload unused memory manually won't change this memory load.

    It is a very big problem and I really don't think it's intentional.

    • Another problem : If you restart the layout... the memory stays the same even though the sprites are not here anymore ! You have to manually purge the memory using the system action "Unload Unused Images from Memory".

    ==> memory is not automatically purged on start of layout!

    This to me seems like another very big problem that didn't exist in C2.

    I hope I'm doing something wrong because these would be fundamental problems for the image memory management system, wouldn't they? I reproduced the case easily with a basic project, so that convinced me the problems I first encountered weren't related to the fact I was trying to convert a pretty big project from C2 to C3.

    Thanks in advance for your opinions on the matter. If I need to write a bug ticket, I can, just tell me.

  • Looks pretty dope !

  • Thank you Ashley. If you don't think it is alarming then I won't dig too much into it. I'll test my game again on older configurations and see if the performance/memory tradeoff is problematic or not :)

  • Oh, right, that's swiping. I did offer you a classic desktop scroll bar that you need to click.

    I kept clicking on your own scrollbar thinking that it was completely broken x)

    Glad you're satisfied by ReallyBasic's solution then.