oosyrag's Forum Posts

  • dropbox.com/s/3lp90ilj38s9nio/pixeltransfer_example.c3p

    I'm not sure what's going on with that first row of pixels. Might be worth a bug report.

  • It is possible, but a bit roundabout.

    Paste the image into a drawing canvas object. Save the snapshot. Then you'll have access to pixel data at x/y. Loop through coordinates at your desired resolution, and set an overlapping collision tilemap's tiles accordingly by comparing the pixel data at each location if black/white. It only needs to be done once at start of layout, so it should probably be fine to use a high resolution, or go pixel by pixel even.

  • Yeah I understood that was what you were going for, but it will probably be a bit jarring if you do that no matter how you implement it, and I haven't really seen any other game use a design like that. If you just always have the camera rotate and pan based on mouse position it will be much less dizzying I think.

  • Try simply setting the camera to halfway between the player and mouse position every tick.

    You can have the 'camera' object always on the mouse, and have both the camera and player object scroll to enabled.

  • The manual is a pretty great place to start.

    Note that you don't need to know any JavaScript at all to use construct.

  • Can you provide the link for the data you're trying to get?

  • Use a single variable to calculate and represent change over time. Adjust this variable by adding and subtracting from it when appropriate. Display the variable.

  • construct.net/en/tutorials/using-3d-construct-2746

    See the section on using 2d layers.

  • I recommend xirsys.com

  • Start with the official beginner's tutorials to see if the event system makes sense to you, even though they are not for visual novel type games.

    I believe there are other game engines that are focused on make visual novels that would be more suitable for you if your intent is to make a visual novel.

  • I'm not quite sure I understand your question, but it seems like the timer behavior and it's expressions should have everything you need.

    construct.net/en/make-games/manuals/construct-3/behavior-reference/timer

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Use tags in the solid behavior, and the sprite object's 'set solid collision filter' action.

    construct.net/en/make-games/manuals/construct-3/behavior-reference/solid

    construct.net/en/make-games/manuals/construct-3/plugin-reference/sprite

  • I would avoid layers simply because it is inflexible, as it requires manual creation of the layers and can't be done at runtime, as well as not scaling well for larger puzzles.

    I'm not sure if 36 layers would have any performance issues, but I suspect it might, since (I think) force own texture will draw each layer individually, and drawing your entire screen 36 times over every tick sounds like it might run into fill rate issues. The more layers you have the problem will only get worse, so again it is inflexible and unscalable.

    As will all performance issues, try it out yourself and test if it is acceptable on your target platform.

  • Familiarize yourself with blend modes and force own texture on layer. This will be used to 'cut' your pieces out of the image.

    The straightforward way would be to have a layer for each puzzle piece, which consists of the cutout with blend mode over the image. We want to avoid using so many layers, so instead use a single layer to temporarily define each piece, and paste it to an instance of a canvas object.

    If I were to attempt it I would probably approach it over time, pasting one canvas instance/puzzle piece per tick and moving it out of the way, while cycling through animation frames of the various cutouts in place and moving the main image accordingly.

  • Well... slightly less tedious, as I consider changing the size of an object is easier than modifying collision polygons. You could for example, put all the visible sprites in a family, then use a single set size action on start of layout (self.x/y*1.01 or similar)