OFFICIAL GMS2 HTML5 surface_create_ext()

Discussion in 'Announcements' started by rmanthorp, Nov 15, 2018.

  1. rmanthorp

    rmanthorp YoYo Games Staff Admin YYG Staff

    Joined:
    Apr 15, 2016
    Posts:
    267
    Hey,

    Just to let you know we've been evaluating surface_create_ext() a function used for HTML5 that's ended up causing some issues and is itself buggy. We are looking to deprecate this function in an upcoming version of GMS2, so I'm posting to let the community know.

    If this is something you rely on please let us know and we can discuss options with you. Thanks.

    It's something we've clearly been thinking about for a while :D
     
  2. Chris

    Chris Member

    Joined:
    Jun 20, 2016
    Posts:
    52
    I've never used it myself, and I would consider myself a power HTML5 user. I think the use-cases are slim enough that it can be removed safely. If someone really needed this functionality for some reason, a JS extension could probably be made to sort it out somehow.
     
  3. FrostyCat

    FrostyCat Member

    Joined:
    Jun 26, 2016
    Posts:
    4,058
    I did advise using it once for Facebook, which contains endpoints accepting base64-encoded PNG data: https://forum.yoyogames.com/index.php?threads/converting-a-surface-into-base64-on-html5.50089/

    I have iterated time and time again that YoYo still has a lot of ground to cover in term of extensibility, and HTML5 is by far the export that lags behind the most. Sure, you can push out and return strings and reals through extensions, but things like canvases, data structures and buffers stay stuck on either side of the GML-JS divide (i.e. JS extensions can't touch GML-created canvases, nor can they add external canvases into the ID pool for use with GML). If YoYo takes this opportunity to improve GML-JS interoperability and add two-way canvas access as part of that, only then would I be happy to let surface_create_ext() go.
     
  4. DukeSoft

    DukeSoft Member

    Joined:
    Jun 20, 2016
    Posts:
    768
    @FrostyCat you actually can use buffer_get_address(); to access a real-time buffer thats used within GM in HTML5 :) (I know its not the same as making one from JS and pushing it in GM, but it provides a way of access without returning doubles or strings)

    As far as this function goes, I guess supporting it is very hard and time consuming - I've never used it and can't really think of real use-case scenarios where you'd want this. IMHO, if you really want to use something like this, you could do so yourself by making something that works like this, without using the function.
    So in my humble opinion; remove :D
     
  5. MrDave

    MrDave Member

    Joined:
    Jun 20, 2016
    Posts:
    74
    I do a massive amount of HTML5 stuff and didn’t know this was possible. Now I know about it I kinda want to use it.

    If it were up to me I would move the functionality to a different name and document how it is buggy. This frees up that function name to be used in the future.
     
  6. FrostyCat

    FrostyCat Member

    Joined:
    Jun 26, 2016
    Posts:
    4,058
    But that behaviour in HTML5 isn't documented in the Manual. It talks about returning a pointer, which doesn't have any real context in JS. And like I said, this is still a one-way street. To be complete, there should also be a way to push buffers from JS extensions back into the runner with a new internal ID.
    Except it isn't trivial for JS extensions to access GML-native things like sprite-drawing functions to paint onto a canvas. And like I said, there are API integrations that require exporting canvas and image data, the Facebook example being one of them.

    surface_create_ext() is a hacky function that only partially serves out-bound drawing traffic. If YoYo can implement a way for JS extensions to access canvases by internal ID and push in canvases to get a new internal ID (i.e. 2-way access), only then is surface_create_ext() ready to retire.
     
    DukeSoft likes this.
  7. True Valhalla

    True Valhalla Full-Time Developer GMC Elder

    Joined:
    Jun 20, 2016
    Posts:
    310
    I have always avoided surfaces when working with HTML5. Wouldn't be concerned to see this function go.
     
  8. DukeSoft

    DukeSoft Member

    Joined:
    Jun 20, 2016
    Posts:
    768
    Correct, the HTML5 exporting stuff is barely documented (fun fact is that you can execute execute game code outside of the game loop - which in turn is causing timing bugs for me but not a big issue ;p )

    I was planning on doing some more documentation on the HTML5 export and external functions since I had to figure most out by myself (with the help of other on the forums here). The buffer actually returns an actual ArrayBuffer object, by the way: https://forum.yoyogames.com/index.p...llbacks-array-buffers-in-gm-extensions.54839/

    As you stated that an API for creating / loading / managing resources would be best - heck yes. That would be awesome and it would allow GM to expand so much further - but I also see how this is pretty hard to implement correctly everywhere. If any, I'd opt for a stronger, better, GML - but I guess you would too :)
     
  9. Tsa05

    Tsa05 Member

    Joined:
    Jun 21, 2016
    Posts:
    545
    It's a brilliant concept; haven't used it since playing with the demo.
    I would much prefer a set of html_ functions to fetch and replace canvas, text, and image objects out of a page. This gave us a peek into using GameMaker to interact with html elements but only in an incredibly specific way that I wouldn't miss.
     
  10. DukeSoft

    DukeSoft Member

    Joined:
    Jun 20, 2016
    Posts:
    768
    You could easily do that by wrapping jQuery for example, or writing your own little library :)
     

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