GMLscripts.com

Discuss and collaborate on GML scripts
Invert

You are not logged in.

#21 2011-09-23 18:11:26

xot
Administrator
Registered: 2007-08-18
Posts: 1,201

Re: GameMaker:HTML5 - Things that work differently

In a bug report Mike explains a bit about working with INI files in HTML5:

Mike Dailly wrote:

Actually, we do support INI files, but you must include them in your projects "included files", we will then load them from the localstorage, and if not found there, the server. Saving will always go to "localstorage".


The key is to make sure you have added them to the projects "included files" so they are copied to the web output folder.


Abusing forum power since 1986.

Offline

#22 2011-09-23 19:04:05

paul23
Member
Registered: 2007-10-17
Posts: 110

Re: GameMaker:HTML5 - Things that work differently

saw that, though "include files" is quite a rippled approach.. Very limited at the moment (no way to include a folder, or update include files automatically).

Also did you check the xml file? the include file interface seems to be missing about *everything* which old versions of gamemaker had. Though the xml still stores this information.

Offline

#23 2011-09-24 14:15:51

Alert
Member
Registered: 2011-09-24
Posts: 2
Website

Re: GameMaker:HTML5 - Things that work differently

Was there a confirmation on when image_angle would be added? Would help for some of my projects hmmm

Also, I always obfuscate my projects, so unfortunately I can't pass by reference at all. I think they should either add the possibility to pass by reference, or at least include a function for explode_string.

Thanks for keeping me up to date with the program though. nice topic

Offline

#24 2011-09-24 16:01:01

xot
Administrator
Registered: 2007-08-18
Posts: 1,201

Re: GameMaker:HTML5 - Things that work differently

Welcome to the forums, Alert!

There is no word on when we can expect image_angle beyond "the very near future". It and other advanced graphical features will rely on WebGL. If and when WebGL integration becomes available in GM:HTML5, understand that its adoption among browsers is spotty at best.

Several browsers already support WebGL, including Chrome and Firefox, but other popular ones do not. Microsoft's position is that WebGL is a significant security risk (which it is) and they will not be supporting it (although there are plugins to enable it). Apple has stated that it will not be supporting WebGL in iOS 5 except for products they themselves certify to be safe and release through their iAds service.

I think the WebGL specification, introduced earlier this year, will probably need to be emended to address security concerns before widespread adoption happens. Some think that completely securing WebGL may be impractical or impossible. Regardless, users may happily switch to enabled browsers if the reasons are compelling enough (for instance, a must-play Facebook game or amazing browser gimmick). Unfortunately, iOS users don't really have that choice.

My advice is not to rely on any feature that is not already available in GM:HTML5.


Abusing forum power since 1986.

Offline

#25 2011-09-24 19:24:43

xot
Administrator
Registered: 2007-08-18
Posts: 1,201

Re: GameMaker:HTML5 - Things that work differently

Silly YoYos have removed script importing and exporting from the Scripts menu. That's sort of problematic for a site like this. GM:HTML5 seems to have meddled with resource importing and exporting as well. Now you can only import or export an entire project as a *.gmz file ... although an oversight prevents *.gmz files from appearing in the file selector when attempting to import them. As paul23 pointed out in a bug report, the files can be imported if the correct path is supplied to the file selector. I'm a bit alarmed that *.gmres files are apparently not supported. GMLscripts.com is running out of import options.

YoYo also aren't following established *.gml file standards. Normally a *.gml file begins with a line like "#define {script name}" identifying the name of the script. The script itself then appears on the following lines. Multiple scripts can be included in one file as long as each has the #define line immediately before it. GM:HTML5 uses files of the same name in its project folders, one script per file, with file names matching the script name. They do not include the #define line. Not a drastic change but an incompatible nonetheless.

EDIT:

OK, my alarm is slightly assuaged. It is possible to import and export *.gml script files from the resource tree. Unfortunately, the files are incompatible (as noted above). Importing many scripts would needlessly suck. Hopefully I can talk some sense into them.

Last edited by xot (2011-09-24 19:43:19)


Abusing forum power since 1986.

Offline

#26 2011-09-24 20:54:24

xot
Administrator
Registered: 2007-08-18
Posts: 1,201

Re: GameMaker:HTML5 - Things that work differently

Here is something that was posted a few weeks ago in a private alpha forum. I don't think Mike would mind me quoting it here.

Mike Dailly wrote:

Differences....

So, while we knew this...It's far from obvious so I'll spell it out here.

1st, this is a new runner. That means it's different. Not everything you do in GameMaker will work the same. Instance sorting was the main candidate for this. However there are other differences.

  • Because of obfuscation, you can no longer "create" string variables and then look them up using functions like variable_global_set(), as they will now no longer match to the actual variable name!

  • Function like variable_global_set() are VERY slow... and I mean Really, REALLY slow! So you should avoid them anyway if possible! If you DO use them, they you must do ALL variable access via the variable_global_set/variable_global_get so that obfuscation doesn't affect things.

  • There is very little "clamping" for things like background alpha/colours etc. So if you set them to 1.09, it'll stay at 1.09. On GM8.x you could set 1.09 then compare to 1, and this would be correct. This no longer happens.

  • If you get anything "odd" happening, then 1st check the debug output to see if we've pumped out a message, and second, do your own debugging and print out values to check yourself.

  • There is NO colourising in HTML5. This means when you try and draw in anything other than WHITE, I will automatically create and cache a new image which i've "pre" tinted. This means you can't just fade through "many" colours, as I will be dynamically generating LOTS of images using only javascript to tint every pixel! I will be adding a new command soon to allow you to specify the NUMBER of these images you want to cache, so that memory doesn't go through the roof. It currently defaults to 4.


Abusing forum power since 1986.

Offline

#27 2011-09-24 21:05:26

xot
Administrator
Registered: 2007-08-18
Posts: 1,201

Re: GameMaker:HTML5 - Things that work differently

I really hope Mike and the others don't mind me quoting these next bits posted in a private alpha forum. It's pretty interesting stuff. I can't say for sure if all this information is still accurate. I'm sure we'll be learning more about this type of use in the near future but I thought I'd whet your appetites.

Web Events

Mike Dailly wrote:

I've started to add in new WEB events. This lets you set loading going in the background, and you can then get an event to let you know it's finished loading. This means you can now actually do seamless streaming using HTML5 - which is very cool.

Currently there are "Image Loaded" and "Sound Loaded" events. Although I'm considering splitting that into "Sprite Loaded" and "Background loaded". I'm not sure you need that though.

Inside the event you now use a new global variable (which is only valid in this event) to access the details of the loaded file - like this...

name =  ds_map_find_value(global.async_image_load, "filename" );
spid =  ds_map_find_value(global.async_image_load, "id" );
stat =  ds_map_find_value(global.async_image_load, "status" );

You can then use this to "enable" files that you have been waiting on.

We're thinking of making sprite_exists() and background_exists() return false if the image hasn't finished loading.

My simple little test current enables stuff like this...

if( stat<0 ){
    show_message("Error loading "+name);
}else{
    if( spid == mysprite1 )sprite_loaded[0] = true;
    if( spid == mysprite2 )sprite_loaded[1] = true;
    if( spid == mysprite3 )sprite_loaded[2] = true;
}

I am also going to add the ID from the instance where the file was requested - mainly because I have it at my disposal...

These events kick off from using normal loading functions like this.

mysprite1 = sprite_add("2_sprite.png", 2, false,false, 0,0);
mysprite2 = sprite_add("72x72_icon.png", 1, false,false, 0,0);
mysprite3 = sprite_add("background2.png", 1, false,false, 0,0);

I will also be adding "File Loaded" events for when you want to load text files (currently no binary), and don't want to "block".

I realise this is a little different from normal GML style of code, but we think it's the most flexible.


Any general comments on this?

< TESTER 1 > wrote:

This all made sense once I imagined the third code block inline before the second tongue

I worry that this method relies on so much manual set up-- GMers tend to rely on straight forward systematization.  A function or action that does it for them.

Could this not be built in by including something like a "streamed" or "external" resource group or flag (in the actual resource properties) that upon compile creates an external archive from all the resources flagged as such.

Then there could be discrete functions to load or stream specific content from the archived package.  These functions still throw the events.  But...

The events themselves could target specific resources, sort of in the way the Collision event targets specific objects.

Let me say, though, that your initial solution looks elegant, and I would actually kinda prefer this handled in some sort of cool collections system.  But, I'm just thinking about how GMers seem used to working with things.  Also, the visual dialog system of GM lends itself well to this kind of resource management rather than being forced to track things like this in code (which, of course, will always be an option.)  GM is great when it comes to flexibility like this.

Mike Dailly wrote:

Possibly in the future we'll allow for "lazy" assets. But for now this lets you deal with stuff yourself. If your doing a web site for example, this lets you pull in external assets which simply aren't included in the "game"

Remember this is only for stuff outside the normal game. Anything you add to sprites, backgrounds, sounds etc, are all loaded at startup (the loading bar bit).

This IS fairly advanced stuff in terms of GameMaker usage, and it does allow you to do some pretty sexy things. So while we might try and do something clever with it later, for now it'll stay for coders only. Lastly... streamed resources require a way for you to "preempt" the need. Otherwise if you fetch them on demand, it's already too late....

I will be changing it to "background loaded" and "sprite loaded", rather than just "image loaded". This is because the ID you get back may clash with the "other" kind of resource, and although you have a filename... that's a pain. If you have 2 resources, you can still call a single script if you want to deal with them both together.

< TESTER 2 > wrote:

I'm confused.

We have the Image Loaded and Sound Loaded events. Apparently, inside that event, we can access the details of the loaded file: which loaded file? My confusion is that you're talking about GM knowing about the existence of a resource, but I don't see where we are creating such a resource.

From what I understand, the process is this:

Create Event:

sprite_add("mysprite",blah,blah)

Image Loaded event:

name =  ds_map_find_value(global.async_image_load, "filename" );
spid =  ds_map_find_value(global.async_image_load, "id" );
stat =  ds_map_find_value(global.async_image_load, "status" );

Check if that resource exists:

if(stat<=0)
{
 if(spid=sprUglyGhost){return true}
}

So basically, when image loaded triggers it populates the async_image_load data structure with the data of the latest loaded resource? From which we can have our fun and check for the existence of stuff?


If this is so, nice. I love it! Can't think of a more elegant solution... really gives control to the programmer instead of just initiating a runner loop or something.


But if I got it wrong, a few pointers would be nice.  :chikin

Mike Dailly wrote:

Nope... that's pretty much it.    In "normal" GameMaker, when you do a sprite_add(), it's instance. The application blocks or stalls until the sprite is loaded. For stuff from disk, that's not a massive issue, but for loading from the NET, it's huge. If it's a large image, it could take 30 seconds or more to come in, and that's horrible.  So now on GameMaker HTML5 when you load a resource, it loads in the background, and then fires an event when it's loaded - or when it gets an error.

So while you can use the sprite_add() command anywhere (as you did before), it now doesn't complete on exit. If you do it right, then the new event also stops you from having to check throughout your code to see if a sprite/sound is ready yet, because the event could swap these resources for you.

GameMaker could do with these events as well so as to allow proper async file loading. It would allow bigger games as you could stream resources in without stalling, however for now... this is HTML5 only.

The other nice thing about using a ds_map, is that we can add more to it if we need to without changing things too much. You'd just request another variable.


Abusing forum power since 1986.

Offline

#28 2011-09-24 21:22:43

xot
Administrator
Registered: 2007-08-18
Posts: 1,201

Re: GameMaker:HTML5 - Things that work differently

GMC user aiacono asks about implementing callbacks from Javascript.

aiacono wrote:

Is there any way to call a game maker function from a javascript extension, such as a callback? A good example:
function gm_Ajax(verb, url, callback) {
$.ajax({type: verb, url: url, complete: callback});
}

From what I know, GML allows strings and doubles. Maybe the callback could be a string and there could be a js function called __gm_call?

Mike Dailly wrote:

MMmm... might not be impossible. If you reference a script, then the reference would be obfuscated as well, so it would still point to the correct thing. You would need an "instance" for variables etc. to work though... But it's definitely worth thinking about...

What you should probably do just now, is do your own callback, then have GML "query" it, that way you could return the data or an error if it's not ready yet. It keeps everything inside your own JavaScript code....?

TGMG wrote:

It is possible but a bit of a hack, just call your function like this:
gm_Ajax(verb, url, _Script_scriptname);

Change scriptname with the name of your script.

For example this code will run the script called testscript:

callback=_Script_testscript
script_execute_callback(callback);

Where script_execute_callback is simply:

script_execute_callback=function(callback) {callback();}

Last edited by xot (2011-09-29 12:44:29)


Abusing forum power since 1986.

Offline

#29 2011-09-24 22:29:12

xot
Administrator
Registered: 2007-08-18
Posts: 1,201

Re: GameMaker:HTML5 - Things that work differently

GMC user BlaXun asks about "ripping" GM:HTML5 games and preventing it.

BlaXun wrote:

Hiya everybody.

If somebody hosts a game...well, and I know the folder strucure (seems to be always the same)
then I could simply download all the necassary files and play the game as a window application again, right?

Is this intended to work like this? Somehow I think ripping games from a site that wants to get visits to stay alive will hurt a lot.
Is there some way to improve security on this?

Thx in advance

JacksonYarr wrote:

You could create a Javascript extension to solve this issue. The external Javascript would be:

function JS_getLocation()
{
return window.location;
}

Once you've added this extension into Game Maker, it's then a simple matter of using Game Maker code something along the lines of this:

location=JS_getLocation();

if (location != "http://www.MyWebsite.com/MyHTML5Game/")
{
room_goto(roomBlocked);
}

Hope this helps.

- JacksonYarr

JacksonYarr wrote:

Here's a quick example JS Location.zip

This example only displays the current address of the game, however it shouldn't be too hard to restrict it to a single address once you know where it will be hosted.

Mike Dailly wrote:

We do have some idea's for slowing this kind of thing down. The one listed above is one of them, but we have some others we'll do as well.

Users can always decompile the source and change it... but as long as it's not "easy", then only determined folk will do it.

...it's on our to-do list for sure. Bugs first... then new features.  rolleyes


Abusing forum power since 1986.

Offline

#30 2011-09-24 22:46:30

xot
Administrator
Registered: 2007-08-18
Posts: 1,201

Re: GameMaker:HTML5 - Things that work differently

Andrew McCluskey (NAL) revealed some information about GM:HTML5's DRM.

NAL wrote:

It doesn't limit the installs. With Softwrap, it was five activations then the key stopped working until you contacted them to get it reactivated. With the new DRM, there is no hard limit - as long as it's only active on three computers at a time (so if you uninstall it on a computer, it's formatted or whatever, you get one back), you're fine. The installs are tracked though and can be remotely blacklisted or questioned if they're being installed too frequently.


Abusing forum power since 1986.

Offline

#31 2011-09-24 22:52:38

xot
Administrator
Registered: 2007-08-18
Posts: 1,201

Re: GameMaker:HTML5 - Things that work differently

GMC moderator tangibleLime posted a very helpful tutorial about integrating GM:HTML5 with PHP and MySQL using AJAX. Buzzword overload!

http://gmc.yoyogames.com/index.php?showtopic=520198


Abusing forum power since 1986.

Offline

#32 2011-09-24 23:01:07

xot
Administrator
Registered: 2007-08-18
Posts: 1,201

Re: GameMaker:HTML5 - Things that work differently

Ninja Dodo asks about multitouch.

Ninja Dodo wrote:

Out of curiosity, will there eventually be a way to do multi-touch or tilt-based gameplay via HTML5?

Mike Dailly wrote:

Look up command like YoYo_AddVirtualKey(). This allows you to add virtual joysticks and does allow multitouch for virtual key presses.

For clarification, YoYo_AddVirtualKey() creates a rectangular region on the screen that produces a key press event when touched. Multitouch gestures (eg. iOS "pinch") would seemly be rather difficult to detect and probably could not be very precise if you managed it. Visions of just-in-time dynamic virtual keys are swimming in my brain.


Abusing forum power since 1986.

Offline

#33 2011-09-24 23:11:28

xot
Administrator
Registered: 2007-08-18
Posts: 1,201

Re: GameMaker:HTML5 - Things that work differently

Mayhem Games has posted a tutorial about Java integration. One of the suggested uses is exploiting sockets to enable high-speed multiplayer games.

http://gmc.yoyogames.com/index.php?showtopic=520085


Abusing forum power since 1986.

Offline

#34 2011-09-25 01:58:06

icuurd12b42
Member
Registered: 2008-12-11
Posts: 303

Re: GameMaker:HTML5 - Things that work differently

xot wrote:

Multitouch gestures (eg. iOS "pinch") would seemly be rather difficult to detect and probably could not be very precise if you managed it. Visions of just-in-time dynamic virtual keys are swimming in my brain.

Well could you possibly create multiple regions and over a view steps determine an action?

region is entire screen
{
detected something
{
define other regions excluding that area to detect other touches....
}
}

and so on. could you track multiple fingers?

Last edited by icuurd12b42 (2011-09-25 01:59:09)

Offline

#35 2011-09-25 04:19:30

paul23
Member
Registered: 2007-10-17
Posts: 110

Re: GameMaker:HTML5 - Things that work differently

I'm really hoping .gmres comes back - simply for compatibility options tongue.

GMResource files kept the folder structures, so exporting engines was only useful in that manner. Currently I still have no idea how to combine engiens.. - Well I might start creating a tool for this, but only if yoyogames doesn't add support themselves (I'll wait for the non beta version/word of yoyogames).


EDIT: (in reply to mike about variabel_local_set) so that was where that post in the trash forum originated from. Saw it a few weeks ago already. You guys at admin forums have to watch your trash more closely.

Last edited by paul23 (2011-09-25 05:11:51)

Offline

#36 2011-09-25 08:30:26

xot
Administrator
Registered: 2007-08-18
Posts: 1,201

Re: GameMaker:HTML5 - Things that work differently

It didn't take long for a GM:HTML5 Facebook game to appear in the wild.

http://apps.facebook.com/superawesomepong/

Some implementation info from the creator is here.

http://gmc.yoyogames.com/index.php?showtopic=520243



I'm hoping we'll learn more from YoYo about multitouch and collaboration this week. Also hoping GM:HTML5 will be a state fit for actual work by next week. Too many bugs at the moment to do anything non-trivial (and even trivial stuff doesn't work very often). To be honest, I'm somewhat amazed that any games work at all.

Last edited by xot (2011-09-25 11:36:49)


Abusing forum power since 1986.

Offline

#37 2011-09-25 09:57:52

paul23
Member
Registered: 2007-10-17
Posts: 110

Re: GameMaker:HTML5 - Things that work differently

Well I'm really wondering if those HTML5 game sites have any api to act as "middle man" for highscores/multiplayer games.

From what I understand it is basically only possible to communicate with "same origin" from javascript: so, if you play through a game portal, you can communicate only with that portal website - not directly with your own server.

Once the dust settles a bit I'm going to start a discussion about this, as I can see 3 possible methods to circumvent this:

  • Use browser.postMessage / browser.receiveMessage - Well this only works in the "next generation browsers" (ff 4+, ie 8+, chrome opera 11+), but then again these browsers are the only ones with enough support for games anyways. Problem is, I'm in the dark of how to use this - hardly any help can be found on the internet

  • Use the portal site as middle man. - You connect to a simple php page which forwards the request/answers. Problem is that this requires the game site to be set up exactly for this, and isn't fast enough for websockets.

  • Use java. - Well java can be used for everything, and sockets/server communication is as old as anything there. Problem is that this requires java code on the portal site, + limits your game to only users who installed JAVA.

Well there is a 4th option: keep highscores on the portal site. But that is quite a limiting option, as then you can't ever create multiplayer games and the like. I'm wondering how this will progress, and hope for a discussion to spawn once GM:HTML5 is stable enough.


Another (annoying) bug:
When converting literal strings, "\" signs are changed to "\\" signs.. This leads to many problems for extensions tongue, also for draw_text it is fun:
draw_text(0,0,"\") - shows "\\"

Last edited by paul23 (2011-09-25 11:28:18)

Offline

#38 2011-09-25 11:11:05

xot
Administrator
Registered: 2007-08-18
Posts: 1,201

Re: GameMaker:HTML5 - Things that work differently

I keep hearing that multiplayer networking is one of the big features that is coming next to all versions of GM. I think they've finally been shamed into admitting the mplay hasn't been a viable feature for years, which I'm happy to take credit for. I've certainly prodded them hard enough.

It seems like something like the combination of browser-enabled WebSockets (headerless bidirectional client-server communication), Node.js (asynchronous server-side Javascript) and Socket.io (Node.js module) is going to be the way to go. I've read people claiming as little as 10ms latency using them which should be good enough for almost any game.

Here's a little tutorial/demonstration: http://wesbos.com/html5-canvas-websockets-nodejs/

As for portal integration ... who knows. If HTML5 has as much momentum as it seems to, the problems may resolve themselves. The matter may be entirely moot. From what I've read, cross-domain support is provided by WebSockets with the proper authorization, so your client should be able to "call home" as easily as connect to its native server ... but I really don't know anything about any of this stuff.


Abusing forum power since 1986.

Offline

#39 2011-09-25 19:48:40

Alert
Member
Registered: 2011-09-24
Posts: 2
Website

Re: GameMaker:HTML5 - Things that work differently

Are developers of GM talking about this?

I just started with 39DLL and programming with that but if there was a better method included with game maker I would be very grateful. Even if some people port forward they can still have problems hosting. But I wonder if that is a router issue or the dll. Either way it would be an easier learning curve if it was part of game maker.

Offline

#40 2011-09-26 01:04:45

BlaXun
Member
Registered: 2011-09-26
Posts: 18

Re: GameMaker:HTML5 - Things that work differently

Thank you for the nice info-collection xot,

Didnt work with GM for a few years now... with GM4HTML5 I think we have some interesting months ahead.

Please continue with your info-collection. Very helpful to me and propably a lot of people out there.


blax_sig.png

Offline

Board footer

Powered by FluxBB