oosyrag's Recent Forum Activity

  • There are two approaches to loading screens based on the way images in memory are handled between layouts.

    construct.net/en/make-games/manuals/construct-3/tips-and-guides/memory-usage

    Specifically:

    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.

    You can have your "loading screen" be either an intermediate loading layout that will create the objects required on the following layout, or a loading layer that covers the contents of the layout while they are being created.

    In both cases, you don't want to place the objects in the layout editor, so that the layout is not required to load everything into memory before starting. If you are using the layout editor to arrange your objects/level, then the first method would be more suitable (Place the objects in the following layout, not the loader layout. They will remain in memory when changing layouts). If not, the second might be more straightforward.

    Note that this normally should complete very quickly (thus defeating the purpose of having an animated/interactive loading screen in the first place) unless you're really pushing the limits of memory on the user's device, which is a situation you generally want to actively avoid.

  • Boids/flocking/steering style mechanics are probably the "best" way to do it. I don't know if the plugin implements it well or not though. It may have utilize calculations you may or may not need.

    Game performance drops in vampire survivors too, towards the end of a round. Also note that there aren't actually that many enemies on screen at any given time in vampire survivors. How many are you reaching before you have performance issues?

  • The very basics would be to first decide what data format you're using to store the state of your tiles. Either an array or tilemap would work well.

    When placing a building, check all relevant tiles/cells relative to the cursor/placement position to see if they are valid. If not, then do nothing or display an error. If all valid, then place the building and update the tile/cell data it now occupies.

    If using arrays, recording the uid of the building object is one way to keep track of what is currently occupying any cell. If using tilemap, the tile number itself could naturally identify the building.

  • What is your question?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You would normally use a tilemap, and check the if the tiles next to each water tile meets the conditions for a change, and change it if it does.

  • Are you using a beta build? Have you tried opening in the last version it worked with?

  • It would be nice if the link to the c3 manual from c2 manual pages would directly link to their respective pages instead of the c3 manual home page.

    Many Google searches still land in the c2 manual. For example, a search for "construct array" or "scirra array" results in the c2 manual pages for array, with the c3 one nowhere in sight. Clicking through has the link to the c3 manual in the c2 manual, but this lands on the c3 manual homepage and not the c3 array manual page.

    This is particularly egregious on mobile, as the navigation is hidden and nested. It takes a click to open the navigation, and then a click on plugin subcategory which doesn't expand the list, but takes you to the plugin page. Then you need to click the navigation link once again to see the expanded list, and find the plugin you were looking for to reach the target with one final click.

    Tldr: It's bad enough that c3 manual pages still don't show up from Google searches, it's worse that it takes 5 additional clicks through 3 different pages and hidden menus to get to the correct destination on mobile.

  • This is what arrays are for.

  • Note that the "base", or shadow, of the ball has both an x and y position, on the horizontal plane. The ball itself has an additional "height", or z position, otherwise it will be the same as the shadow. You can keep track of the height with a separate instance variable, and add this to the y coordinate of the shadow to get the position of the ball.

    Fundamental projectile logic follows that horizontal and vertical velocities are independent of each other. The shadow will keep track of the horizontal velocity (which has both x and y components), and it is always constant, so the bullet behavior is suitable for it. The vertical velocity of the ball is set at impact, and is affected by gravity at a constant rate, so you'll subtract a set amount from the vertical velocity over time.

    physicsclassroom.com/class/vectors/Lesson-2/Horizontal-and-Vertical-Components-of-Velocity

  • I suspect it may have to do with the size of your sprites. They aren't the most absurdly large textures I've seen someone try to use, but yours might be pushing the limits of some devices.

    It could either be a vram limit you're hitting, or a straight up maximum supported texture resolution that has been surpassed.

    Just a guess though, not completely sure.

oosyrag's avatar

oosyrag

Member since 20 Feb, 2013

Twitter
oosyrag has 38 followers

Trophy Case

  • 11-Year Club
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • Enduring Visitor Visited Construct.net 90 days in a row
  • Unrelenting Visitor Visited Construct.net 180 days in a row
  • Continuous Visitor Visited Construct.net 365 days in a row
  • RTFM Read the fabulous manual
  • Email Verified

Progress

21/44
How to earn trophies