GM:S 1.4 which is better drawing optimized ?

Discussion in 'Programming' started by kerim, Jul 11, 2019 at 12:30 PM.

  1. kerim

    kerim Member

    Joined:
    Aug 10, 2018
    Posts:
    28
    Hey,
    Lets say i do draw 5000 sprites in a room with all 32x32 and room is 3200x1600.

    should i direct draw them ahead or should i use a surface which is in gui length and width (1408,800)
    and draw the sprites on there?
     
    Last edited: Jul 11, 2019 at 2:19 PM
  2. Simon Gust

    Simon Gust Member

    Joined:
    Nov 15, 2016
    Posts:
    3,117
    Only tiles have that automatic not-drawing-outside-view Thing.

    With sprites, if you draw 5000 of them I think your gpu will explode.
    You should definetly look into tiles.
     
  3. kerim

    kerim Member

    Joined:
    Aug 10, 2018
    Posts:
    28
    actually i have tested many times game runs on 40-50 fps with 5k sprites and 5k shadows(just black draw of sprite)
    ok i'll look at tiles
     
  4. rIKmAN

    rIKmAN Member

    Joined:
    Sep 6, 2016
    Posts:
    4,260
    With the amount of newbies around taking things at literal face value, you should be careful of this becoming gospel lol.
     
    wipeout2185 and Simon Gust like this.
  5. GMWolf

    GMWolf aka fel666

    Joined:
    Jun 21, 2016
    Posts:
    3,315
    drawing them to another surface will not help whatsoever. You are still drawing the sprites!
    Room size means nothing for performance. Its just a number. the back buffer will only be the size of your window. it is not tied to room size.

    Why/how are you drawing your 5k sprites? could we have a look at the code? we might be able to point out some ineficiencies. (5k sprites at 50fps is pretty bad. IDK what is acheivable with GM by my own 3D engine was able to churn out hundreds of thousands models at over 60 fps on a old mid range GPU. I would expect GM to be able to render more sprites than that).
     
  6. flyingsaucerinvasion

    flyingsaucerinvasion Member

    Joined:
    Jun 20, 2016
    Posts:
    2,033
    For anything that is static (doesn't move, or moves in a deterministic way), look into using vertex buffers. Nothing will beat that.

    If you just try to draw huge numbers of random sprites using gml, gml is just too slow for that. Actually, instance sprites outside of the (2d) view will never even be written to a vertex buffer or sent to the gpu. The gpu would easily be able to handle 5000 sprites under most circumstances. However, whatever gml is doing to process the sprites before even writing them to a vertex buffer, is not efficient. So drawing lots of sprites this way will not be good for performance.
     
  7. Simon Gust

    Simon Gust Member

    Joined:
    Nov 15, 2016
    Posts:
    3,117
    To put it into perspective, my gpu could just barely handle a filled screen worth of 16x16 sprites with the draw_sprite command last time I checked. Thats like 8000 calls. Still though, you might not want to give out processing power for rendering like that. Its also electrical power that you're using. Notebook users do not approve.
     
    marasovec likes this.
  8. GMWolf

    GMWolf aka fel666

    Joined:
    Jun 21, 2016
    Posts:
    3,315
    Hmmm, thats pretty rubbish. I was sure GM could handle more than that...
     

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