Improve full screen performance.

0 favourites
  • 7 posts
From the Asset Store
City ride is a game to improve your memory.You have to focus and remember the information related to passengers of previ
  • There is not much to configure when it comes to this option.

    A few days ago I launched a game with twice the size, more active sprites, more events to check, and it worked perfect in full screen.

    But right now I have this project that just performs poorly.

    and it has only very few events and the graphics are not really a great improvement to the previous ones.

    for now I have it configured in the last option to choose which is not really a full screen, as it fills everything in black.

    I don't want it to end like this

    not like this construct bros... :(

    What I can be doing wrong?

    or

    how to improve game performance on full screens?

    • Try changing the option Fullscreen quality, Downscaling quality in project settings, also try putting framerate mode to unlimited.
    • There is also performance tips, try checking if you're doing something performance intensive: https://www.construct.net/en/construct-2/manuals/construct-2/overview/performance-tips
    • It might be a bad loop you have, try running the project with debug layout instead of the normal way and every time, before you run it, disable some code or remove some sprites to see how much they affect your performance (comparing cpu usage) and you'll pin point the problems out soon enough.

    You can go through that, but it's a bit hard finding your issue without seeing your project file, so if you could upload it here it would help to find the problem

  • OMG :D

    Thank you very much for the link to that guide

    I was looking for one before placing the discussion but could not find something because I was looking for Construct 3.

    I had only two sprites but they had large transparent spaces and I had no idea that this could affect performance.

    point number 5 "Avoid large areas of overlap between objects" is something that I was unaware of, and it is a problem of this project that the previous one did not have.

    After solving these things the performance improved a LOT.

    I also repaired a bad loop that the game had, and everything is perfect, only missing maybe some tweaks but the problem is more than solved.

    I will not forget to keep these things in mind for a future project.

    Thank you HolidayExplanation.

  • Welcome, glad you have it working again =]

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Please note the earlier link is to old Construct 2 documentation - for up-to-date advice see the Performance Tips guide in the Construct 3 documentation instead.

  • Please note the earlier link is to old Construct 2 documentation - for up-to-date advice see the Performance Tips guide in the Construct 3 documentation instead.

    Ashley, could you please define what do you mean by: > "Drawing more images, and larger images, requires writing more pixels to memory."

    Does this implies also to tiled background? or small stretched sprites? or it is specific to a large images by pixels (and not by their size itself?)

    Still here > "Therefore the worst-case scenario for fill rate is a stack of large overlapping images."

    When you says as "large overlapping images" do you mean large by their pixel size in the image editor? like, if you have an image that is 24x24px and you stretch it to 1024x1024px, is that considered a large image?

    Lastly, I have a questions about tilemaps.

    I have been doing several experiments using tilemap. Do you think a tilemap that is 1024x960px covering a 40000x5000px is more performant then having hundreds of small but stretched tiled backgrounds? I found that using multiple tiled background are faster than a huge tilemap, both in editor and ingame.

    Thank you!

  • Answer your own performance questions with measurements

    In terms of fill rate, both the source size and destination size count: the larger the source image, the more memory it takes up and the more memory bandwidth it needs to read from the image; and the larger the size it's drawn at, the more memory bandwidth it needs to write pixels to the screen.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)