How much sprite_add can be handled?

Discussion in 'Programming' started by Joh, Sep 11, 2019.

  1. Joh

    Joh Member

    Jul 23, 2016
    Hi, Just started working with external/run-time generated assets and apparently GM is not a fan, since it throws them all on different texture pages.

    I've tried being councious around it, load only a small portion of sprites. based on what is needed. I unload (sprite_delete and sprite_flush) when not needed.
    (I'm kind of doing somthing like lazy load for infinite scrolling websites)

    Anyways, mistakes in code made it so everything got loaded ~30 sprites at the same time. and to my surprise, there was little impact. FPS is still great, Memory usage went up a lot, but its still <100mb.

    So now I'm wondering, how much added sprites can there be at a time before performance hit? I'll experiment with it myself, but perhaps its something others have faced before. maybe I'm missing something too, because I am very surprised an alledged ~30 page swaps (if i understood correctly) barely has an impact on performace.

    Also, one of the issue I have with load/unload (on a very active basis) is it keeps creating new sprites and to my surprise, the indices dont get overwritten, thus after a while I'm in the 1K sprite indexes even if I obviously don't have that many.

    So yeah, overall, just want to know how much added sprite is viable and if I'm missing anything about sprite_add, textures, deleting sprites and potential memory leaks.

    Thank you!
  2. TheouAegis

    TheouAegis Member

    Jul 3, 2016
    Just because you loaded 30 sprites, were you actually using all 30 at the same time?

    30 texture swaps means very little if your program is hardly doing anything at all. The more code your game has to process in addition to those texture swaps, the more impactful those swaps will be.

    You should probably be using sprite_replace() after the initial sprite_add() calls.
  3. YellowAfterlife

    YellowAfterlife ᴏɴʟɪɴᴇ ᴍᴜʟᴛɪᴘʟᴀʏᴇʀ Forum Staff Moderator

    Apr 21, 2016
  4. Joh

    Joh Member

    Jul 23, 2016
    Yes, you are right while it loaded ~30 sprites, they were not all used at the same time, maybe 15 were.
    I did further experiment, see how far I could go:
    memory according to task manager (& debugger)
    100Mb at 38 sprites (89mb debugger)
    200mb at 89 sprites (191mb debug) still 500 fps
    400mb at 188 sprites (390mb debug) ~444 fps
    524mb at 248 sprites (510mb debug )~424 fps
    Its true that I don't do much else, its just a level selection menu.
    By loading only 1 sprite per frame, it stays very smooth with no performance drop.
    38 sprites (thumbnails) is already a lot, the idea is to have user generated levels, with user generated image (external).
    So what I have works fine already, but its more of a "make sure it scales well" as I don't know the ceiling.

    Im actually using sprite_create_surface() and that does seem to lead to the problem that I can't reasonably stop creating new sprites.

    Essentially what I'm trying to do is:
    add external sprite (full size)
    format to thumbnail with surface (sprite_create_from_surface)
    delete the full size sprite
    use that thumbnail
    delete the thumbnail sprite when not used

    • As shown above, I simply could load everything and keep the thumbnails.(never delete) it just takes a bunch of memory but remains managable levels I think. (as long as there arent too many)

    • The load & unload method is pretty good too. the memory remains much lower (since only a small subset is ever loaded) however thumbnails fade in & out of existance. (its smooth, i dont mind) problem is the sprite indexes keep rising, since I can't replace with the surface version.(just had an idea though, will try it out)
      + I'm not sure of any bad consequences of consistently adding new sprites.

    I have seen this extension and it seems a bit too powerful for what I'm trying to do, not sure I want all the overhead and extra functions I just wouldn't need.
    Will keep it in mind, does it go beyond base GM abilities? seems like it create fake textures pages and uses draw_part (all well packaged for user) but wouldn't that still involve all the issues I'm facing? (sprite index increase, lots of texture pages being made)


Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice