Author Topic: Upcoming SGDK2 Implements Rules in HTML5  (Read 322992 times)

durnurd

  • Lead Lemming
  • Expert
  • Fanatic
  • *****
  • Posts: 1234
  • Games completed so far: 0
    • MSN Messenger - durnurd@hotmail.com
    • View Profile
    • Find My Ed
Re: Upcoming SGDK2 Implements Rules in HTML5
« Reply #45 on: 2012-01-17, 07:57:27 AM »
I am referring to the Export to html5 form.  There's a field to specify the file name, and you pop up a Save File dialog to edit the field.   Then you click the Save button in that dialog, which changes the filename field.  Then you hit OK to actually save the file.  Why not just get rid of the file name field and pop up the save file dialog after you press OK.

When running the game as HTML you could export using the last used seettings, or show the dialog the first time.

I'd like to have the different sprites and maps in different files so that I don't have to deal with one big file to deal with just the code for one sprite.  It seems like better encapsulation, too.

As for the bug I found, it just happened that I was working on something that used it.
Edward Dassmesser

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: Upcoming SGDK2 Implements Rules in HTML5
« Reply #46 on: 2012-01-17, 08:26:57 AM »
I am referring to the Export to html5 form.  There's a field to specify the file name, and you pop up a Save File dialog to edit the field.   Then you click the Save button in that dialog, which changes the filename field.  Then you hit OK to actually save the file.  Why not just get rid of the file name field and pop up the save file dialog after you press OK.

Popping up the dialog after clicking OK would be an unnecessary step in most cases.  As it stands, if you want to save to the default path you only have to click OK once and the file is saved without necessarily showing another dialog.  But perhaps it would be good to change the text of the "Save" button to "OK" or to merge the functionality of the save dialog into the export form instead of having it separate.

I'd like to have the different sprites and maps in different files so that I don't have to deal with one big file to deal with just the code for one sprite.  It seems like better encapsulation, too.

Within the IDE the JS code for the sprites is separate from the JS code for the maps.  Are you not using the editor in the IDE to edit the JS code?
In my limited experience, Javascript shirks encapsulation anyway.  It's possible, but ridiculous-looking... not a normal/formal language construct for JavaScript.
Don't a lot of JavaScript generators do even worse, obfuscating and compressing the code so it's almost entirely illegible in its final form?

Not that that's a good excuse.  It might help in knowing where an error originated -- seeing the file in which it occurred would be a clue if it was separate from other files.  And if there is a good reason to edit the JavaScript outside the IDE (I'd like to understand what cases like this exist), it's probably nice to have separate files.  Do you think each map and each sprite definition should be in a separate file, or should maps be in one file and sprite definitions in another?  My guess is the more separation the better.  Of course it should be an option not hardwired anyway, but I'm wondering if there's any value for an extra option to have all maps in one file and all sprite definitions in another versus splitting them all out into individual files ad the finest level.

durnurd

  • Lead Lemming
  • Expert
  • Fanatic
  • *****
  • Posts: 1234
  • Games completed so far: 0
    • MSN Messenger - durnurd@hotmail.com
    • View Profile
    • Find My Ed
Re: Upcoming SGDK2 Implements Rules in HTML5
« Reply #47 on: 2012-01-17, 08:38:27 AM »
I would put each sprite in its own file.  I'm not looking at code that's editable in the IDE, I'm looking at generated code based on the rules.  Just so I can see rexactly what the code that's generated looks like.

Perhaps there should be Export and Export As menu items, the same as Save and Save As.  That way, you can get rid of even more extra steps when exporting.

Although the reason I was suggesting this in the first place was because I was exporting over and over and had to change the settings every time.  If there were a run button, that would solve my individual problem (as long as pressing run wouldn't open a new browser window every time.  Is that possible to control?).  Not to imply that these other options should not also be available.

As for the code obfuscation, that's after all the debugging is complete and you can then minify it to make it download faster.
« Last Edit: 2012-01-17, 08:48:49 AM by durnurd »
Edward Dassmesser

durnurd

  • Lead Lemming
  • Expert
  • Fanatic
  • *****
  • Posts: 1234
  • Games completed so far: 0
    • MSN Messenger - durnurd@hotmail.com
    • View Profile
    • Find My Ed
Re: Upcoming SGDK2 Implements Rules in HTML5
« Reply #48 on: 2012-01-17, 10:30:23 PM »
Another note:  In Chrome, you can edit Javascript on the fly, if the code is in a .js file.  So if you want to edit how a sprite is working, you can just open the js file in the scripts tab, edit the code, and it will start running with the changes.  That's easier to do with each sprite in a separate file.
Edward Dassmesser

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: Upcoming SGDK2 Implements Rules in HTML5
« Reply #49 on: 2012-01-20, 10:06:47 PM »
Screenshot of the new Export HTML dialog.  The browse button is just a folder browser now.  It's a little early to do another release, so I'll hang onto this change for a while and maybe get something else in before another release goes out.

durnurd

  • Lead Lemming
  • Expert
  • Fanatic
  • *****
  • Posts: 1234
  • Games completed so far: 0
    • MSN Messenger - durnurd@hotmail.com
    • View Profile
    • Find My Ed
Re: Upcoming SGDK2 Implements Rules in HTML5
« Reply #50 on: 2012-01-20, 10:53:11 PM »
Yeah, it's probably not worth it for another full release.  But at least I can use it, maybe :)

If you're looking for other things to do with it, I've got a few bugs I've found:
  • A sprite with no rules doesn't get an "executeRules" method created, but it attempts to run it every frame anyway.
  • If there are compile errors in the project for the executable version, exporting to HTML5 takes a really long time to compile the temporary project (it looks like it's trying over and over again) and then misses places where it should put in "this." but doesn't.  Places like dy = -5; instead of this.dy = -5;  It's weird that it _sort of_ works, but not completely.  Not sure what the best course of action here would be.
  • Exporting sometimes misplaces end braces. I have to explicitly put in an extra end rule to make it work.
  • The "push" call at the bototm of addSpriteHere doesn't work if the sprite being added is the first sprite of the specified category to be added to the layer (because this sprite categories array doesn't contain the category).  Not sure if this may also be problematic elsewhere.

I also implemented the tileTouchingIndex method.  I imagine you just didn't get around to it (The conversion is trivial, considering it's the exact same code except in JavaScript).  Anyway, here it is.  It's had some... rigorous testing?
Code: [Select]
Sprite.prototype.tileTouchingIndex = function(tileValue, initialOnly, markAsProcessed) {
  if (this.touchedTiles == null)
     return -1;

  for (var i = 0; i < this.touchedTiles.length; i++) {
     var tt = this.touchedTiles[i];
     if ((tt.tileValue == tileValue) && (!tt.processed) && (!initialOnly || tt.initial)) {
        tt.processed = markAsProcessed;
        return i;
     }
  }

  return -1;
}

Ooh, ooh, one other thing I thought of, is having an HTML template that you can edit for the export process.  Or at least a CSS stylesheet you can edit to make the page show up just like you want without having to edit it after exporting.
Edward Dassmesser

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: Upcoming SGDK2 Implements Rules in HTML5
« Reply #51 on: 2012-01-21, 03:42:05 PM »
Yeah, it's probably not worth it for another full release.  But at least I can use it, maybe :)

I have committed all my changes to SVN if you want to download and compile for your own use.  (See what I also fixed in this update below.)


A sprite with no rules doesn't get an "executeRules" method created, but it attempts to run it every frame anyway.

Fixed

If there are compile errors in the project for the executable version, exporting to HTML5 takes a really long time to compile the temporary project (it looks like it's trying over and over again) and then misses places where it should put in "this." but doesn't.  Places like dy = -5; instead of this.dy = -5;  It's weird that it _sort of_ works, but not completely.  Not sure what the best course of action here would be.

Fixed -- If an error occurs building the temporary project, it aborts the export process and tells you to build with F7 for details.

Exporting sometimes misplaces end braces. I have to explicitly put in an extra end rule to make it work.

If you can give me an example of how to make this happen I can try to fix it.

The "push" call at the bototm of addSpriteHere doesn't work if the sprite being added is the first sprite of the specified category to be added to the layer (because this sprite categories array doesn't contain the category).  Not sure if this may also be problematic elsewhere.

Fixed

I also implemented the tileTouchingIndex method.  I imagine you just didn't get around to it (The conversion is trivial, considering it's the exact same code except in JavaScript).  Anyway, here it is.  It's had some... rigorous testing?

Included and restored in the HTML5 template project.

Ooh, ooh, one other thing I thought of, is having an HTML template that you can edit for the export process.  Or at least a CSS stylesheet you can edit to make the page show up just like you want without having to edit it after exporting.

Maybe later.

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: Upcoming SGDK2 Implements Rules in HTML5
« Reply #52 on: 2012-01-22, 01:12:44 PM »
I committed some new changes to SVN and I think I need your help, durnurd.

1. I think I corrected the problem relating to wrongly placed braces.  The problem I found was related to inactive rules.  If you had an inactive rule that affected the indentation level of the code, the indentation would be lost too, but now I've corrected that.  Inactive rules retain their effect on bracketing level, but don't do anything else.

2. I started trying to [re-]implement mouse/touch support for HTML.  I got it working with a mouse, but I don't have the tools to test the behavior of the touch event handling.  Maybe you could check/fix that for me.  I briefly tried MapMouseToSprite on Amy's iPod touch, but it only moved the sprite when I lifted my finger.  There was no following as I moved my finger around.  I ran across something this morning that suggested maybe I need to disable the browsers default trapping of these events for scrolling purposes.  But I thought we had the map dragging working without that, so I'm confused.  There's a new DragMap function that I haven't tried on a touch interface at all yet.  I removed the default behavior of allowing you to drag the map around and created that function instead so you can control if/when that happens.

durnurd

  • Lead Lemming
  • Expert
  • Fanatic
  • *****
  • Posts: 1234
  • Games completed so far: 0
    • MSN Messenger - durnurd@hotmail.com
    • View Profile
    • Find My Ed
Re: Upcoming SGDK2 Implements Rules in HTML5
« Reply #53 on: 2012-01-22, 03:13:44 PM »
Yes, you do need to disable default handling, I remember having to do that for some other thing I had worked on.  But like you said, you already had it working, so that is kind of odd.

I just got the code from SVN.  A couple of issues:

The IDE crashes when trying to generate the project.  It looks like there are two issues with this part.  If there are too many end if rules in a sprite, GenerateRules throws a Stack Empty exception, which is issue 1.  A dialog pops up saying "Stack Empty".  GenerateAllRules is catching the exception, except at the point it is caught err doesn't have any text in it when it returns.  So when it tests for errors by checking if (errs.Length > 0) it sees that there are no errors, and continues attempting to generate code, which fails miserably later, throwing up the critical failure dialog, crashing the IDE.

I found that one because I had inserted extra end rules to counteract the problem with the previous version.

Another problem is with the property inspection when exporting to HTML5.  It goes through the CompileTempAssembly method, which compiles the rules, even though it doesn't need to, because it's just inspecting properties. Switching GenerateLevel to ExcludeRules in that method seems to work correctly for generating the temporary assembly.  Not sure what else that affects.

I found that one because I have some rules that have JS code in them instead of C# code, which doesn't compile correctly.

Finally, there's an issue about the order the javascript is in, if exported as separate files.  Basically, it looks like custom source files are included in the main js file, before sprite js files.  And I have some custom methods attached to specific sprites, ala spriteDefinitions.MySprite.prototype.myMethod = function() {....  Except MySprite hasn't been defined yet.  Would including the custom source files separately, at the end work?

Oh, one last thing.  Where do the .js files come from?  They weren't in the blank project or default project.  Can I do something like reset source code to get them into my project?  I had to copy the changes directly from the IDE's source.
« Last Edit: 2012-01-22, 03:53:33 PM by durnurd »
Edward Dassmesser

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: Upcoming SGDK2 Implements Rules in HTML5
« Reply #54 on: 2012-01-22, 09:40:07 PM »
OK, I will look into disabling the default handling, but I might have you do the testing after I do.

I will look into and hopefully fix the compile/export process problems.  I thought I already was putting the custom code at the end, so I'll check that again and see if I can get it to come in at the end.  Now that I think about it, maybe it was only at the end when generating a single file.  I'll try to get it at the end of the separate file output too.

The .js files are not initially part of the project, but get added to the project when you export HTML.  Then you can edit them, and if they are still in the project next time you export, it will pick them up from the project, otherwise it will re-add them from internal template code.  That doesn't fully answer the question about where they are from: most are resources embedded into SGDK2IDE similar to the .cs template code.  The code is not embedded in the *.SGDK2 template file; that way the template files stay relatively small by deferring to the IDE for the standard template code that does not need to be specialized.  If you use the "Reset Source Code" command to reset to the HTML5 Sample Template, it will delete all the JS files that it considers "standard" from the project (so they will be re-loaded from the IDE internal template next time you export), but it will keep the few customized files that *are* embedded in the template that are specific to HTML5 (eliminating unsupported functions) or the sample project logic (implementing the springy tile).  So in short, yes, you should be able to use the "reset source code" with the updated HTML5 template project to re-sync the source code.

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: Upcoming SGDK2 Implements Rules in HTML5
« Reply #55 on: 2012-01-25, 07:04:17 PM »
Can you recommend how to disable the default touch event handling?  I assume I want to do something with a meta viewport tag, but I'm not sure exactly what.  I can't find the document I found before with that info.

durnurd

  • Lead Lemming
  • Expert
  • Fanatic
  • *****
  • Posts: 1234
  • Games completed so far: 0
    • MSN Messenger - durnurd@hotmail.com
    • View Profile
    • Find My Ed
Re: Upcoming SGDK2 Implements Rules in HTML5
« Reply #56 on: 2012-01-26, 08:08:35 AM »
In the touch event handler, use e.preventDefault().

The only stuff in the meta tag deals with display size.  What I had in my sample was this:
<meta name="viewport" content="width=device-width, initial-scale:1.0, user-scalable=0;"/>
Edward Dassmesser

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: Upcoming SGDK2 Implements Rules in HTML5
« Reply #57 on: 2012-01-26, 08:35:28 PM »
I have committed an SVN code update with the following changes:
  • Allow HTML code to be customized by editing the Template.html file.
  • Allow custom HTML files to be added to the project Source Code.
  • Improve error handling when extra "End" rules are added to sprites or plans.
  • Exclude rules from the temporary compile that is performed before exporting HTML.
  • Ensure that custom JavaScript files get included after other code even when written to separate files.
  • Prevent default handling of touch events.

Want to test the functionality of touch events on SGDK2 mouse functions on an iPod?

durnurd

  • Lead Lemming
  • Expert
  • Fanatic
  • *****
  • Posts: 1234
  • Games completed so far: 0
    • MSN Messenger - durnurd@hotmail.com
    • View Profile
    • Find My Ed
Re: Upcoming SGDK2 Implements Rules in HTML5
« Reply #58 on: 2012-01-26, 10:51:34 PM »
A couple of notes:
My provided meta tag was a bit off.  The correct tag should be:

<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=no"/>

Second, the touch events should be called ontouch* instead of touch*.  The reason things were happening on touch up only was because they were being handled by the mouse events rather than touch events.

The next thing to work on then is framerate.  I'm getting about 3 fps on my iPod.  But I have a touch screen control working!
Edward Dassmesser

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: Upcoming SGDK2 Implements Rules in HTML5
« Reply #59 on: 2012-01-27, 06:47:15 AM »
I suspect we'll have to make a different kind of sample game for iPod because it can't handle the HTML5 sample game kind of game at 30+ fps.  Or we'll have to make it much smaller.  And the background should have the alpha translucency eliminated -- I never bothered to do that after removing the equalizer background layer.  Any other suggestions for improving framerate?  Is the slowness in the drawing, or is the JavaScript engine on iPod slow enough that the JavaScript itself is managing to slow things down too?  I assume its all in the canvas operations and there's not much that can be done about it except to draw something simpler or smaller.

I corrected the metatag and touch events and committed the changes to SVN.