WackyToaster's Recent Forum Activity

  • Only have physics run on the host! Sync the objects position, angle etc but have physics disabled for the peer. If you simulate the physics on both machines, even miniscule differences in CPU timing and rounding errors will have the objects often diverge.

  • You do not have permission to view this post

  • Should have bolded and quoted "RELATIVELY".

    Haha yeah. Thank you so much! I'll try it out asap.

    There is no explicit FPS for the whole animation, instead each frame has a time in milleseconds. To fill in a value I calculate a tentative FPS from the duration of the first frame and then use that value to calculate durations for the rest of the frames which are relative to that first measure.

    That is fine. That is one of the settings that I often end up changing anyway. Often I end up importing an animation and it ends up faster or slower than I have set it up in aseprite simply because in the context of the entire game it feels different. What is interesting is really the individual frame-timing!

    The way Aseprite uses settings such as Loop is per tag, so you can have multiple different ones in ranges of the whole timeline. C3 just has one value for the whole animation. So instead of using the values from Aseprite, the export script just shows a dialog with the settings that can't be extracted in a way that makes sense.

    The way I use tags is to have multiple animations in one file. In my ideal world I would export each tag from aseprite into a different animation. Here's an example from the net of how I roughly set up my files. So each tags loop settings would be per animation, and each tag would export a different animation for the same sprite.

    i.ytimg.com/vi/KzgugqLahik/maxresdefault.jpg

    The export script can use the tag information, but not completely because Aseprite is more advanced that C3 in that regard. In C3 you only have a tag for each frame, that's it. In Aseprite you can define a range. To do something useful with the data, the frames where a tag range starts, get the value, while frames covered by the range, are left empty. The information could be used differently.

    See above, I'd use the frame tag as an individual animation. Tags in the context of aseprite are used differently than in Construct. That would mean though there is no real place to actually put tags as they are used in Construct, but that's a fair tradeoff. I'll see if I can manage to adapt the script.

  • On start of layout set your global variable to yourobjectname.count

  • I think I figured it out. The CanvasToLayer expression was the key.

    wackytoaster.at/parachute/resize.c3p

  • Here is another solution - click any point on the sprite:

    https://www.dropbox.com/scl/fi/drhkya67euorlv2iq1pqr/rotate_easypeasy.c3p?rlkey=eb74yo7bqm398j8oqt1kdcy2o&dl=0

    Heh, smart solution. Not sure how well it would work with the player in motion though.

  • I think the easiest solution would be to have a separate double-jumping animation with a different origin point.

  • As for adding some margin outside of the canvas, I don't think Construct likes that. But construct games can run in an iframe, so you could add a custom index.html that has the game running in an iframe and add the margin to the iframe. I think that should work, but I'd not want to bother with it.

    Instead adding it in the game should be very much possible and not too hard. First there's the anchor behavior construct.net/en/make-games/manuals/construct-3/behavior-reference/anchor which I found has some quirks to it, but overall is useable.

    Setting the spacer manually there's a couple of things to think about:

    - You can detect device orientation in the browser plugin "is portrait/landscape" construct.net/en/make-games/manuals/construct-3/plugin-reference/browser

    - The plugin also has the request fullscreen action, which offers different scaling modes that you may have to take into consideration. That is likely why your bar changes size when resizing. You might want to refer to this construct.net/en/tutorials/supporting-multiple-screen-17

    - There are system expressions to get the desired full width/height/etc. of the viewport. ViewportBottom(layer), ViewportLeft(layer). ViewportRight(layer), ViewportTop(layer), ViewportMidX(layer), ViewportMidY(layer), ViewportWidth(layer), ViewportHeight(layer)

    - You have to pass a layer into these, so I recommend creating a layer on top specifically just for your bar. And most likely you'd want to set it up for UI-type stuff so with parallax 0,0 and scalerate 0 construct.net/en/make-games/manuals/construct-3/project-primitives/layers

  • Thanks! I should try out typescript at some point. But would that mean in typescript I can't have a base class with subclasses like I used to? Or is there a different way to achieve what I'm trying to do?

  • I just noticed that subclassing changed at some point, probably here construct.net/en/make-games/releases/beta/r362

    Ensure InstanceType namespace exists at runtime

    Now subclassing appears to reference the specific object the class is supposed to extend, as in this case the Player instance.

    class PlayerInstance extends globalThis.InstanceType.Player
    

    However it used to be like this (if the player is a sprite)

    class PlayerInstance extends ISpriteInstance
    

    This code seems to still work, is it fine to keep using it like that? I like being able to extend a generic sprite instead of the specific sprite of the player object. Or am I just misunderstanding something here?

    The reason is I do tend to further subclass my subclasses, so both the player and enemies might derive from a base class with shared functionality, e.g.

    	class Entity extends ISpriteInstance...
    	class Player extends Entity...
    	class Enemy extends Entity...
    
  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Newest project. I actually went events only since it's a very simple game. No need for js :)

  • Here's an in-depth post about it + a section about solutions

    construct.net/en/blogs/ashleys-blog-2/surprising-difficulty-1528

    Generally you'd want to avoid cutting sprites off directly at the edges, that's why the image editor in Construct adds a 1px transparent border around sprites by default. If that doesn't help, you can use the higher downscaling quality.

WackyToaster's avatar

WackyToaster

Member since 18 Feb, 2014

Twitter
WackyToaster has 26 followers

Connect with WackyToaster

Blogs