fedca's Forum Posts

  • With WebGPU coming soon and some discussions about limitations by webGL 1 compatability (for example https://www.construct.net/en/blogs/skymen-13/flexbox-weird-characters-1590) I started thinking that maybe the time is ripe for construct to start phasing out webGl 1 and start to implement features unique to webGL 2.

    Some data:

    • webGL 1 96.27% adoption
    • webGL 2 89.58% adoption
    • difference 6.69%

    (source: caniuse.com)

    So my question is how much do we gain by allowing webGL 2 features and how much do we lose by phasing out support for webGL 1.

    I personally don't have an answer to that questions, as I don't have enough insight into the limitations opposed by webGL 1 support and how constructs renderer works.

    Secondly with webGPU renderer coming for Construct as well at some point, how much would that implementation be held back by also needing to support webGL 1?

  • The new "just press space to play and stop the timeline" is awesome, but it creates some questions about overall play/pause and stop workflow.

    First I want to define the terms I'm using just to avoid confusion:

    -play: play from the play-head (red line)

    -pause (icon: two paralled vertical bars): pause the play-back of the timeline and place the play-head to that position

    -stop (icon: rectangle): stop the playback and place the red line to the point where the playback started.

    Currently pressing space plays and stops the timeline.

    But instead I would prefer this solution:

    Dynamic play button: when the timeline plays, the play button becomes a pause button (and vice versa).

    Pressing Space plays and pauses instead of stopping.

    The stop button still exists but uses another shortcut.

  • the platform is still used by Scirra, just last week we got slide along solids for 8-directon which was a highly voted feature on the platform. Shortly before that we got a first implementation of templates which is the highest voted request on the platform and still in further development. (smaller request like enable/disable editor toggles for effects have been added as well)

    So The platform is definitly still actively used.

    But I agree, it's weird that we haven't got a 22h1 or 22h2 platform yet.

    Currently the platform is a bit bloated with multiple similar suggenstion, things that are out of date or features that already exist.

  • There also is this Website by the Construct Community where you could submit your game.

    https://www.madewithconstruct.com/

  • There has been a few suggestions talking about mesh distortion in the timeline, this is a common feature in other animation software and would be very powerful.

    But sadly there is one big concern, that needs to be adressed, before adding it to the timeline would even make sense to me.

    Construct currently draws tris instead of quads

    this leads to the texture looking off in a lot of cases, this is very undesirable as the usage of mesh deformation in the timeline would mostly be for visuals. (even the advertised examples by construct for using mesh don't work well for that reason, unless you want your textures to look terrible.)

    This problem would be fixed if the drawQuads method would be used instead

    Example to visualize the problem, if it's still not clear I can add more examples.

    You might argue, just add more points, but this would be bad for performance as well as would make it insanely difficult to edit and place the points.

    If tris need to stay we would need a way to add edges to the mesh in user defined placed (look at spine) so we have control over where the edges are and with it where the mesh should bend. Currently we can only place them in a perfect grid.

    http://de.esotericsoftware.com/spine-meshes

    But for transforming a grid quads are the better solution.

  • No, you would need to create all the systems, like a different view per eye yourself (Construct only renders one camera view out of the box)

    Though it is possible it is definitely not effective or seamless.

  • You do not have permission to view this post

  • In my first post I suggested integrating the ease editor more closely into the Timeline ui, this would make adding and adjusting eases as well as visualizing ease presets much easier.

    Also from the CC discord I know that people tend to not even know custom eases exist, as it is fairly hidden in the Project bar. (not being aware of custom eases would still be a problem with the suggestion, if the user is only using tweens. So for tweens there might be another solution needed)

    Suggestion one: it is added to the Timeline as well as Keyframe properties. The ease editor would also preview the selected ease preset, but if you try to change a preset it would prompt you to (or automatically) create a custom ease.

    visualization:

    Suggestion two: same as above, but docked to the right of the timeline.

    visualization: this is an example from Rive, with their very clean timeline. (this would me my favorite implementation)

    Third option, Even though I am personally not a fan of it, I wanted to add it for completion as someone on Discord suggested it. This solution adds the eases into the Timeline itself, this might be great for eases flowing into each other, but leads to a very messy timeline that required alot of vertical space.

    this example is from blender I think:

  • Another timeline QOL improvement, currently the scrub-bar is draggable, this leads to the user not being able to select keyframes that are under it. Because the scrub-bar jumps to the keyframe you click it is always above the keyframe you were trying to select unless it's the first click after clicking somewhere else in the timeline. This is very frustrating.

    I would suggest to remove the dragging of the scrub-bar so keyframes can be selected when the scrub-bar is over them.

    The scrub bar would still be draggable on top where the seconds markers are and I would suggest adding a little handle on top as well for better readability, the handle would also solve the problem I described in my first post about the scrub-bar being hidden behind the end and start bar.

    This change would also be in line with timeline conventions.(it would additionaly be worthy to consider if the scrub-bar should even jump to the selected keyframe at all)

    Edit: same problem with the end bar, keyframes cannot be selected if they are at the position of the end bar, adding a handle to the top of the bar and only make that part draggable would be my solution.

    This has been fixed, differently then my suggestion, but now keyframe can be selected even when under bars, as well as the playhead/scrub-bar doesn't jump to the selected keyframe any more.

    Thank you!

  • I think we all assume there will be mesh deformation with bones using Timelines as the minimum for what would be considered full featured.

    Of course that's for both products.

    I think aside from QOL improvements these would be the most sensible additions. As both Construct products would benefit from this greatly imho.

  • Construct can technically handle an unlimited amount of controllers.

    But there might be a limitation by the Operating System.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 1. Duzen oder siezen

    There is a mix of the informal "du" and formal "sie" in the translations.

    There should be a decision made for either or, possibly even by Scirra as this changes tone and perception of the software.

    (Windows and Google uses "sie" while Twitter uses "du" for example)

    "Du" allows a more direct translation and sounds more approachable. Even alot of the Professors at my Uni are using the "du" now and I think overall usage of "sie" is going down.

    But some, especially older people might find it disrespectful.

    2.Consistency in the translation of gravity

    Sometimes "Gravitation", "Gravitationskonstante" or "Schwerkraft" is used.

    I would advocate for "Gravitation".

    3. Consitency in the translation of rotation

    Sometimes "Drehung" or "Rotation" is used.

    I would advocate for "Rotation".

    4. Translation of Eases as "Lockerungen"

    I don't think this is a good translation and I would prefer to use the english terms: Eases, Ease-In and Ease-Out, as they are used by German animatiors as well afaik.

    5. Translation of Drag-and-Drop as "Ziehen und losslassen"

    I don't think this is a good translation and I would prefer to use the english terms: Drag-and-Drop, as they are commonly used in German as well.

    6.Translation of Next, particualrly in cases of a buttons.

    Sometimes "Nächste" or "Nächstes" is used, should be unified imo.

  • Also statements like these are not a good look imho. Sorry for being so harsh but this reads to me as either delusion or ignorance to other animation software. (or maybe just empty marketing talk)

    Edit: The welcome dialog message has been changed, thank you!

  • Here I am listing the missing features that I expect from a paid animation focused software (not exhaustive, just what came to mind):

    1. Easier animating, preview and scrubbing of the camera movement (including 3d camera). This is important, especially if you would want to export to video. Currently you would need to go into preview mode to see this, which is a terrible workflow assuming you have complex camera movement and need objects to move in and out of the frame.
    2. Scrubbing in edit mode should show the current animation state by default. (like if ctrl is held). This is the case in any animation software that I have used iirc Edit: this has been adjusted.
    3. Export to image sequence and export with transparency in cases the animation is supposed to be used or composited in another software. Edit: Image sequence Export has been added
    4. Animate mesh deformation in the Timeline. (also next point)
    5. Animating large amount of mesh points would need some sort of mesh selection tool/mesh weights. (also next point)
    6. Bones that objects can be attached to and meshes that can be weight painted. (also next point)
    7. Inverse kinematics and forward kinematics for bones.
    8. frame by frame animation and timeline merged, or better cross integration for hybrid workflows (also next point)
    9. Onionskinning in the timeline for hybrid sprite and tween animations. Or at least a simple way of setting frames and animations in the timeline.
    10. The scrub bar should not be hidden behind the start and end line. (animation software often add a handle at the top of the bar) has been added
    11. Recording mode (or changes to edit mode) any change should automatically create a keyframe at the current scrub position.
    12. Dragging in the timeline should do a rectangle selection of keyframes. has been added
    13. Animating layer properties and effects in the timeline (if not possible already, I'm not sure).
    14. Alot of the useful timeline keyboard shortcuts require ctrl to be pressed, which makes them harder to execute. For a animation focused software where you would use them x times per minute that is bad ux. I understand why it is that way, as the edtior also uses the shortcuts without the ctrl.
    15. Button and shortcut for play from beginning. has been sort of added
    16. Better integration from a ux/ui pov of the ease editor into timelines.
    17. Particles etc. should automatically preview when playing a timeline animation with them.
    18. The current image editor seems to be lacking for an animation software now.
    19. Vector drawing tools and animation in timelines.

    If you want to look at some competition check out https://rive.app/ which is basically a free, aside from live collaboration, animation software targeting a similar niche.

  • nice, glad it's what you were looking for.

    :D I saw a lot of dublicate code and thought it's time for a function ;)