• Hey Guest! Ever feel like entering a Game Jam, but the time limit is always too much pressure? We get it... You lead a hectic life and dedicating 3 whole days to make a game just doesn't work for you! So, why not enter the GMC SLOW JAM? Take your time! Kick back and make your game over 4 months! Interested? Then just click here!

OFFICIAL GMS2 HTML5 surface_create_ext()

rmanthorp

GameMaker Staff
Admin
GameMaker Dev.
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
 
C

Chris

Guest
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.
 

FrostyCat

Redemption Seeker
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.
 

DukeSoft

Member
@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
 

MrDave

Member
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.
 

FrostyCat

Redemption Seeker
@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)
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.
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.
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.
 

True Valhalla

Full-Time Developer
GMC Elder
I have always avoided surfaces when working with HTML5. Wouldn't be concerned to see this function go.
 

DukeSoft

Member
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.
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 :)
 

Tsa05

Member
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.
 
Top