Scrolling Game Development Kit Forum
SGDK Version 2 => News and Announcements => Topic started by: bluemonkmn on 2012-01-02, 05:52:17 PM
-
The sample project that I used to demonstrate HTML5 support (with the slime splotches and the platform) was a simple project that I had made before implementing support for HTML 5. With the initial HTML5-supporting release of SGDK2 (2.2.0), I had to manually modify the generated HTML5 code to make the player react to inputs and make the map scroll. Basically all the rules were ignored and I had to edit the JavaScript directly to make them work.
However, with the work I did this weekend for version 2.2.1, I have managed to make that project work entirely on its own. Just generate the HTML5 code and all the rules are now generated and working in a browser. I think this is very exciting. The best part is that the project itself did not have to change at all. All the necessary conversions were taken care of during the HTML5 code generation process. So with the code currently checked into source control (not yet released), fully functional simple projects can be entirely developed and generated to HTML5 code. A basic set of functions have been implemented as JavaScript, and there are more to come. And I am exposing the JavaScript code in the code editor too, very much like the C# code, so you can still add custom functions so long as you provide both a C# implementation and a JavaScript implementation (if your project is used to generate HTML5 -- if not, all you need is C#).
So I still have a little work to do, implementing more of the rule functions in JavaScript and documenting what things work and (hopefully only a few minor things that) don't work, but a release should be on its way soon. Very much looking forward to fully functional HTML5 support in SGDK2!
-
Awesome! :)
-
How exactly will sound be handled, loading a file with HTML5 Audio?
And on top of that, since it seems like the HTML5 Output will eventually reflect an actual game, which would you honestly reccomend people to output to- Browser games or Standalone Binaries?
-
Wow! Great stuff! ;D
-
How exactly will sound be handled, loading a file with HTML5 Audio?
Sound will probably not be part of the standard supported features with 2.2.1. It was kind of an add-on even with the C# projects being the FMOD-based "custom object" that it is. However, I was thinking sound would eventually use HTML5 Audio. It's unfortunate that HTML5 Audio does not support MOD files, though. That's one of the reasons I chose FMOD. Anyway, even without "standard" sound support in 2.2.1, I think it will be possible to write functions into a project that support sound. And if I have the patience and good-fortune to find a good solution before releasing, I may include some support for sound delivered with 2.2.1. If you have any better suggestions over HTML5 audio, I'm open.
And on top of that, since it seems like the HTML5 Output will eventually reflect an actual game, which would you honestly reccomend people to output to- Browser games or Standalone Binaries?
There isn't one right answer there. If you want all the flexibility and power of .NET (and FMOD) and don't mind restricting the portability of your project to computers with .NET Framework installed, then a standalone binary is best. If you are willing to give up some of the flexibility and power of .NET in exchange for the portability of JavaScript and HTML5, then a browser game is the answer. In case it's not clear, though, when you create a game within the restrictions of SGDK'2 HTML5 support, you can build to *both* browser *and* stand-alone binary without making any changes to the project (it's just a build option). So if you can live within those restrictions, you can give end users the choice of which format they'd like to have the game in. It's easy to build both.
-
Well I honestly don't know any other way of playing audio without having to download a plugin- but I've also never compared performance between all known methods.
Hey, if it's not too much, is there any way for us to make our own rules for the HTML5 in the IDE, say an Editor that allows you to create a rule and paste the Javascript code that follows?
I tried deciphering the page source to the HTML5 output but it seems fairly difficult in terms of adding more complex rules.
-
Hey, if it's not too much, is there any way for us to make our own rules for the HTML5 in the IDE, say an Editor that allows you to create a rule and paste the Javascript code that follows?
And I am exposing the JavaScript code in the code editor too, very much like the C# code, so you can still add custom functions so long as you provide both a C# implementation and a JavaScript implementation (if your project is used to generate HTML5 -- if not, all you need is C#).
You mean like that?
-
Curse my selective comprehension :P
Heck, I wonder what I could possibly do with Ajax and a bunch of PHP files :D
Wow, I'm extremely excited for this! I really wanted to finish my game before I go to college, maybe this may finally be the thing that keeps me motivated throughout the process!
Oh, one final question, if you've reached that rule: how will SaveGame Files work, in the same file format as the Desktop edition?
Can't contain... excitement :D
-
Actually SaveGame was one of the first rules I had to implement because the simple test project I was using relied on SaveGame to reset the game when you die. And just yesterday I implemented the ability to distinguish between temporary and permanent slots, but I haven't tested it yet. I think it'll work, though.
The format is very different. Saved games will not be portable between desktop and web games. The web version uses JSON.stringify to store much of the information about the state of the game because .NET binary serialization is not available, and the data maintained by the JavaScript engine is very different than that maintained by the .NET engine anyway. Another difference (at the moment at least) is that saving and loading games does not (yet) construct new instances of layers or maps, only sprites. Rather than de-serializing saved game data to a new instance of a layer or a map, it simply resets the existing layer or map to the state stored in the saved game. This may change somewhat because I just encountered a possible problem when switching maps. There's no way to automatically reset a map to its initial state to simulate the .NET behavior of unloading and re-loading a map if you choose to unload a map when switching to another. So I might be forced to at least make a map and its layers reset-able if not 100% serializable. Sure I could simulate this by internally saving the initial state of a map and its layers for use with the reset feature of SwitchToMap, but that seems like cheating. Then you'd have 2 copies of the initial state of the map in memory -- one in the code and one in the serialized copy.
And the saved games will not be saved in normal files, of course. Temporary saves will still be in memory only, but permanent saves will be in HTML5 "Local Storage" using localStorage.setItem. It's a beautiful thing, and as I was working more on the saved games yesterday I was very pleased with how well it fit right into what HTML5 provided. I'm glad I didn't do this earlier when it could have been much messier.
I know the feeling of "can't contain... excitement" :). What they hey, I might as well post what I've got so far: http://sgdk2.enigmadream.com/ben/BenJ.html (http://sgdk2.enigmadream.com/ben/BenJ.html)
-
Ohoho, I see Sprite Collisions and Use of inputs rather than "Any other Key"
This is incredibly impressive, It appears from the looks of things I may be able to make a Perfect Replica of my Game (With all the functionality)
The game runs smoothly, no framerate issues whatsoever! It actually runs as noticeably nice as a desktop game would.
I bet there's plenty of ActionScript Developers that would blow their lids upon seeing this!
So SGDK2 will officially also be a browser game development engine? Prepare to see the forums grow exponentially!
Hey, I wonder who controls the Wikipedia page- they might need to do some updating. :P
-
Very nice! Inputs, collision, reloading after death, etc. It's definitely improving. Good job! :)
-
Ohhh... I forgot about sprite collisions. Right now it's only the function for landing on a platform that is checking if the rectangles overlap. That will be an interesting challenge. I wonder if it'll be worthwhile or even practical to try to implement pixel-perfect collision detection again. I'm tempted to only implement rectangular collision detection for the web. I suspect players are rarely discerning enough to tell (or care about) the difference. And generating and maintaining those collision masks can get expensive. Probably won't be in 2.2.1 at least... maybe something for later, though.
As for the wikipedia page, I updated it in November. And I don't usually update it until after I release. It even mentions HTML. And "who controls it" is perhaps a rhetorical question? Anybody can edit Wikipedia pages of course, but probably nobody else will, so it usually falls to me.
-
You may want to consider some simple collisions, like circles, or rectangles that are not the same size as the sprite. Not sure where that would go in the IDE though.
-
http://www.nihilogic.dk/labs/pocket_full_of_html5/
*Leaves this here*
-
You may want to consider some simple collisions, like circles, or rectangles that are not the same size as the sprite. Not sure where that would go in the IDE though.
It could simply be a separate collision detection function: "isSpriteWithinRadius"
-
Wow, there are just a lot of functions to implement. I finally got enough implemented for the sample game to work: http://sgdk2.enigmadream.com/ben/JavaSample.html (http://sgdk2.enigmadream.com/ben/JavaSample.html). I need a break! I'll be back another day to update the documentation and release the SGDK2 code that created this.
2 notable limitations: No multi-view games (2 player mode does not show a split view) and no sound. Also, I realize the sample game doesn't do any sprite collisions except for the platform, so the sprite collision functions are still not implemented. But really I just wanted to get enough implemented for the sample game to work for this release.
-
I'm guessing the JavaSample means JavaScript :) Multi-view is nice, but the current features I see are impressive enough! Honestly, this seemed to be alot of work, and an impressive sample output.
Sound can always either be implemented later, and although collisions are also important, this is still an impressive release.
If anything, these sample game posts should be considered teasers- they get people excited enough and want to hang on even longer for the release. :D
Impressive sir!
-
I just discovered that the sample runs *much* more smoothly (consuming much less CPU) if we don't have those transformed tiles in the background:
Compare the new faster http://sgdk2.enigmadream.com/ben/JavaSample.html (http://sgdk2.enigmadream.com/ben/JavaSample.html) to the original http://sgdk2.enigmadream.com/ben/JavaSampleo.html (http://sgdk2.enigmadream.com/ben/JavaSampleo.html).
-
I didn't monitor my cpu, but to the human eye there is no difference. It runs very smoothly for me (Firefox). :)
-
For me, in Chrome on my high powered desktop, the slow version runs smoothly, but not as fast as the compiled sample program as an EXE (which sets LimitFrameRate at 80 fps). LimitFrameRate is used in the HTML5 code to determine the parameter for setInterval, the function that tells JavaScript to call a function periodically every X milliseconds. So if the CPU hadn't hit its limit, the game should run at the same speed in a browser as it does in a compiled EXE. When I run the other simplified version, it runs fast even in a browser.
I tried on my laptop where I have FireFox installed too. There, both the old and new versions run slower than the compiled EXE, and the slower one is noticably slower. On my desktop in IE, the performance is similar between the 2 versions. I think it still runs slower than the compiled EXE (although very smooth), and the old version runs slightly slower than the simplified version. I have not verified this -- just visual reaction.
-
The new samples won't accept my keyboard inputs. :no:
-
It's all well and good, until you try it on a Mac with multiple desktops enabled, where [CTRL]+[Left/Right] switches desktops. Kinda makes it hard to see where you're going :)
-
The new samples won't accept my keyboard inputs. :no:
You can't even use the menu to start a 1-player game? Were you able to interact via the keyboard before? I haven't seen that behavior anywhere on any of the browsers I've tried. What OS and browser are you using?
-
It's all well and good, until you try it on a Mac with multiple desktops enabled, where [CTRL]+[Left/Right] switches desktops. Kinda makes it hard to see where you're going :)
What default key layouts do you suggest? Try a few out. Search for "key.Up" and you will see the block of code that sets the default key layouts. Search for "PageUp" and you will find the list of all available Keys.
-
The new samples won't accept my keyboard inputs. :no:
You can't even use the menu to start a 1-player game? Were you able to interact via the keyboard before? I haven't seen that behavior anywhere on any of the browsers I've tried. What OS and browser are you using?
It was not able to start at all. I was able to interact with the first demo you had announcing HTML5 support.
I'm using Firefox and Windows 7.
I'll see if I can update Firefox and try it on Internet Explorer.
-
It works fine on my Internet Explorer. And I do not need an update on the firefox browser. (I think).
-
Do you know how to debug Javascript in FireFox? Can you determine if the "keyboardState.handleKeyDown" function is being called? Anybody else that can reproduce this problem? I know I've tried Firefox on Vista, and I think Vincent tried Firefox too and it worked for us.
-
I would suggest any layout that doesn't use ctrl or alt. those are really the only two that would cause problems. Or maybe there's a way to capture those and not pass them on to the OS.
-
Bah... leaving the thinking up to me. Okay I'll have to think of something manually myself then ;). Maybe I'll just swap Ctrl and Space so Space is the more frequently used button, or the one most likely to be used in conjunction with the others.
-
I have summarized the current state of all the rule functions available in SDGK2 and published it on the web (https://docs.google.com/spreadsheet/pub?key=0AuyO-2scTVuRdFBpTUZoM0NNRzhXVXdud1E5a3A4cFE&single=true&gid=0&output=html). Next step is to implement or remove the unsupported functions from a copy of the sample project and make that a new HTML project template.
-
The TestCollisionMask and the modulate alpha/colors made me feel kind of down, but at least there's more than enough for a game!
So 'soon' means that there will be support, but 'no' means it will never be included?
-
No doesn't mean never. It just means I don't know if/when it will be included. I might put all the "Soon" items in for this release and look at many of the "No" items for next release. Or put all the Soon functions in the next release and some "No" items in the release after.
Why are the color modulation functions so interesting to you? You can still make frameset frames that are based on color/alpha modulations of graphic sheet tiles (the code can pre-render those); you just can't modulate colors in real time (HTML5 unfortunately doesn't seem to support it).
And do you feel like TestCollisionMask is so important and TestCollisionRect won't suffice? If so I can consider that sooner (after the other "Soon" functions) to see if it's feasible in JavaScript.
-
Ack no no... My earlier compliment.. came off extremely blunt, I apologize, I'm in no way saying those functions are the "bread and butter" of a game, but superfluous..
It's hard to explain my desire for either of those functions, because my game uses both heavily (Players choose the color of skin and clothing, hair, eyes etc at runtime- and collisions to detect if all movable joints are within a players 'bounding box', and attached to each other to form a body, although the bounding box actually does the collisions.)
I can make every body part, hair, clothing accessories,eyes, etc in every color, and I can always switch to single sprite animation rather than bone based animation, although a collision rectangle wouldn't do much to the end result.
-
Do you know how to debug Javascript in FireFox? Can you determine if the "keyboardState.handleKeyDown" function is being called? Anybody else that can reproduce this problem? I know I've tried Firefox on Vista, and I think Vincent tried Firefox too and it worked for us.
I'm not sure exactly how to do that, so I looked around my tools and found "Web Developer". So, I assumed it could be the debugger. When running the page again, I got this:
[10:25:07.496] GET http://sgdk2.enigmadream.com/ben/JavaSample.html [HTTP/1.1 304 Not Modified 65ms]
[10:25:07.624] Unknown property 'user-select'. Declaration dropped. @ http://sgdk2.enigmadream.com/ben/JavaSample.html:8
-
I'm not sure exactly how to do that, so I looked around my tools and found "Web Developer". So, I assumed it could be the debugger. When running the page again, I got this:
My wife (who has done more recent work with FireFox and is taking web classes) says FireBug is a plug-in for FireFox useful in debugging JavaScript. Give that a try.
-
Ack no no... My earlier compliment.. came off extremely blunt, I apologize, I'm in no way saying those functions are the "bread and butter" of a game, but superfluous..
No worries. I'm trying to keep in mind that I don't necessarily have a full awareness of the most valuable features of SGDK2 since my use of the engine is somewhat limited. So as a result I try to take the comments I do get seriously; try to gain whatever awareness I can about what features are important especially when in the process of choosing among which features are going into an upcoming release.
And if your project is using the features, it's a good source of information. Knowing how your project would be affected by the lack of these features could be important to other people planning similar projects. So with that in mind, I can think about what alternatives this kind of project would have. For customizing colors, you might have the options of:
1. Limiting the range of colors available to the player when customizing the color, and rely on different colored frames instead of color modulated sprites.
2. Manually applying the color modulation function that the HTML5 framework uses to modulate frame colors. Apply it directly to the graphic sheet instead of while drawing if you don't need to be constantly changing them. Perhaps functions like "ModulateCellRed", "ModulateCellAlpha" could be provided to permanently modulate color in a graphic sheet (until the page is re-loaded).
As for collision masks, if I find that more games are wanting to detect collisions at the pixel level, I should have a try at implementing the collision mask functions. If you have individual bones at different angles that want to detect collisions because they are not aligned with the rectangle they are in, perhaps we could make a different rectangular collision function that can detect collisions between *rotated* rectangles. Or maybe if the components are small, pixel detection *is* the best way to go.
-
I'm not sure exactly how to do that, so I looked around my tools and found "Web Developer". So, I assumed it could be the debugger. When running the page again, I got this:
My wife (who has done more recent work with FireFox and is taking web classes) says FireBug is a plug-in for FireFox useful in debugging JavaScript. Give that a try.
Alright. I'll get back to you on that as soon as I can.
-
1. Limiting the range of colors available to the player when customizing the color, and rely on different colored frames instead of color modulated sprites.
2. Manually applying the color modulation function that the HTML5 framework uses to modulate frame colors. Apply it directly to the graphic sheet instead of while drawing if you don't need to be constantly changing them. Perhaps functions like "ModulateCellRed", "ModulateCellAlpha" could be provided to permanently modulate color in a graphic sheet (until the page is re-loaded).
Heh, I could never go wrong with color palettes. It makes more sense than the loads of questions I'll get when my game is released, like "Hey, why can players choose to have green or purple skin and hair?"
I'm sure I could also rotate rectanges, that would actually be perfect!
But a browser version is far from now, I'm still in the process of trying to get a functional Master Server online, (It's actually much more fun and more importantly easier than I thought it would be!) and If I did infact get a browser version running, it would be a "Try a Browser Demo that lacks User Accounts before downloading" since I don't want to have to drive my hosting into the ground from multiple users driving up the CPU usage.
-
Alright. I'll get back to you on that as soon as I can.
Never mind -- I found out the same problem exists here too, and probably for everyone using FireFox. I am going to post a question on stackoverflow.com and see if someone there can help me since it seems to affect all FireFox users.
-
The Firefox keyboard event problems have been resolved in the 2.2.1 release. (Had to use scripted event handler setup instead of event attributes.) The sample HTML5 project has been tested successfully on IE, Chrome and Firefox.
-
The Firefox keyboard event problems have been resolved in the 2.2.1 release. (Had to use scripted event handler setup instead of event attributes.) The sample HTML5 project has been tested successfully on IE, Chrome and Firefox.
Awesome, thank you. :)
-
Oh, this may not be important, but I didn't realize this entire time I was using Opera.
Well, it works fine in Opera - for all the Opera users. :)
-
A couple of suggestions for friendliness:
Remember settings in the Export to HTML5 code.
Either add another button to the toolbar or another option in the play dropdown button to run the game in HTML.
Add an option when exporting as HTML to export sprites and maps as their own js files, just like the C# version (for better debugging of individual sprites)
Pressing the Save button seems like it should actually save. Probably you don't need the output filename as a field on the form, just show the dialog when you hit OK.
-
Found a bug in "blocked" in the "Up" case. It calls this.floor where it should call Math.floor.
-
Add an option when exporting as HTML to export sprites and maps as their own js files, just like the C# version (for better debugging of individual sprites)
How does having the sprites in a separate js file help debugging?
Pressing the Save button seems like it should actually save. Probably you don't need the output filename as a field on the form, just show the dialog when you hit OK.
Are you implying something doesn't save when you press the save button? The project saves when I click the save button. I think I'm misunderstanding something.
The reason I have an output field on the form is in case you want to export the HTML before saving the project (there will be no default output name in that case). It doesn't seem to interfere or even be an extra step in the process, and it gived you more control in case you expect (with good reason) that the term "export" means you get to choose where the output is going.
Good suggestions about remembering the export settings and having a button to run the HTML. I'll try to remember to investigate those. But I assume I have to write a file in order to run the HTML. So do you suggest that operation displays the export HTML dialog first?
Found a bug in "blocked" in the "Up" case. It calls this.floor where it should call Math.floor.
Thanks. How did you notice that? Are you testing all my "Untested" functions or just working on a project that randomly encountered this?
-
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.
-
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.
-
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.
-
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.
-
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.
-
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?
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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;"/>
-
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?
-
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!
-
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.
-
I can't really easily profile what's happening on the device, but Chrome has a pretty good profiler, and it says that a large chunk of the time is spent during drawing. A surprisingly large amount of time is also spent in the getTile method that takes in x,y and returns tiles[y % something * something else + x % something more else]. Is the modulus operator really inefficient or something? Note that this was for a sample I was working on which had a layer with a single tile and a virtual size to cover the screen, so I don't know if that made it worse.
-
Hm... just discovered the ondevicemotion event for HTML5. I wonder if I could use that to provide inputs on mobile devices. Looks like support for it is not very consistent yet. But I got a new phone yesterday (LG Optimus T) partly so I could start testing mobile game compatibility/support, and that device can detect motion. I don't know yet whether its browser supports motion events, but hopefully someday if not today. I can't tell what browser the device runs. I suppose there are other browsers I could download. Wow there's Dolphin Browser, Opera mini, Opera mobile, Skyfire, Dolphin Browser Mini, Boat Browser, UC Browser, Boat Browser Mini, Angel, Galapagos, Ninesky (ooh, explicitly supports HTML5 and flash), NetFront Life Browser, good grief, 15000+ results! Why the hoop'n'daddy are there so many browsers!?
-
Well, I made a game that runs nicely on my phone (and presumably an iPot touch) at: http://sgdk2.enigmadream.com/ben/Spudzu.html (http://sgdk2.enigmadream.com/ben/Spudzu.html). Click the map to drop lights that attract the little yellow creature. I designed it to run at 15 FPS, and it seems to have no problem doing so. Let me know if it runs about the same for you. The background clearing is a little glitchy, especially on large displays that show more map than exists, but it works pretty well on small displays. There are a few pixels of background that still don't paint right, but I was too lazy to do it correctly for just a few pixels. Maybe nobody will notice :).
P.S. I made some changes to SGDK2 in the process and committed them to SVN:
- Implement GeneralRules.Clicked to check if mouse was just clicked down or touch interface was touched.
- Implement MapMouseToSprite in HTML5 projects.
- Correct ClearInputs function implementation in HTML5.
- Implement SetInputsTowardSprite and setInputsTowardCategory functions for HTML5.
- Enhance MapMouseToSprite to allow specification of hotspot.
- Improve tracking of old mouse position in .NET code.
-
Did you have any issues at first with frame rate, or was my problem just a fluke, do you think? Because it runs just fine on my iPot Touch. Knee thing I would change though is the scrolling insets. The character gets somewhat close to the edge of the screen.
-
Did you have any issues at first with frame rate, or was my problem just a fluke, do you think? Because it runs just fine on my iPot Touch. Knee thing I would change though is the scrolling insets. The character gets somewhat close to the edge of the screen.
Hearing of your issues with low frame rate, I designed this game to work at a low frame rate. So I have not attempted anything with a high frame rate yet to see if I would have any issues. Did you have (m)any real-time transforms being drawn in your test project that ran at a slow frame rate. The reason I took out the background from the sample project was because it significantly slowed the running to have a full screen of tiles all being drawn with real-time transforms.
Also, about your "Knee" comment:
1. I think you had some other word besides "Knee" in mind there
2. I am reminded of your other comment about being an adventurer until you were shot in the knee with an arrow. I heard that comment on Skyrim yesterday so now I know what you're talking about. I had heard it before, I'm sure, but my memory is very good at purging useless information ... so good it sometimes purges useful information too. BTW, when did you play Skyrim?
3. The scroll margins are narrow because when you're playing on a small device if you have wider scroll margins, you get a flickering effect from the player trying to stay within completing scroll margins. But you *can* drag the map. On my device, when I use Dolphin, which allows my to turn off all the framing of the browser window, I can get a decent size view where I could increase the scroll margins. But I don't know how large I dare to make them before I risk some browser of some phone causing the scrolling to go nuts.
-
1) Damn You Autocorrect. Should be "One".
2) Never played Skyrim. Just heard of many, many other people mentioning that comment coming up a lot in Skyrim.
3) Would it be possible to have scroll margins be display-size dependent? So that if you're playing on a small screen, it works as intended, but if playing on a really big screen, it still scrolls without needing to go all the way over to the edge? Scrolling around is possible, yes, but somewhat difficult due to the tapping to scroll also placing the light on the spot you tapped. So you have to be careful to tap where the character already is.
That said, I ran it on an iPad. Pretty cool.
-
Not sure if here is the best place to continue reporting issues I've found, or if I should create a new topic.
That said, I've found an issue with saving the game. If the very first thing done is saving the current state of the game, before specifying what should be saved (where it should supposedly save everything), it fails to save, because GeneralRules.saveUnit.maps is undefined.
Another issue is with rules whose function name is only one character long (such as = or +). The CamelCase function assumes the names to be at least 2 characters long. When it reaches the method to apply camel case to such a function name, it throws an index out of bounds exception.
A third issue, which is another with the Blocked method. It has "Math.ceiling" in the "left" case, where it should be "Math.ceil"
-
Sorry, I just had to post a reply comment loling at the arrow to the knee thing. lol. :laugh:
-
Not sure if here is the best place to continue reporting issues I've found, or if I should create a new topic.
That said, I've found an issue with saving the game. If the very first thing done is saving the current state of the game, before specifying what should be saved (where it should supposedly save everything), it fails to save, because GeneralRules.saveUnit.maps is undefined.
Another issue is with rules whose function name is only one character long (such as = or +). The CamelCase function assumes the names to be at least 2 characters long. When it reaches the method to apply camel case to such a function name, it throws an index out of bounds exception.
A third issue, which is another with the Blocked method. It has "Math.ceiling" in the "left" case, where it should be "Math.ceil"
Very strange that you are observing that behavior with the CamelCase function. I have an "=" function in my Spudzu project (to jump), and it returns "=" when I call CamelCase on it. "=" is the first character, and a 0-length string is the remainder starting from position 1. In the immediate pane, I can enter
? "=".Substring(1)
and it returns
""
Only when I enter
"=".Substring(2)
does it throw an exception. Something else must be going on. Do you have a 0-length function name?
-
I suppose that's possible, but I thought I had noticed it occurring on a "+" function. I would assume there would be other issues with a zero-length function name though.
Edit: After removing the code I added to make it work in the case I had problems with, it's working fine again. It may very well have been an empty string function name, but I would've expected that to show an error rather than just not work (there were no errors listed in the top, and compiling with F7 worked correctly).
-
I've corrected everything except the CamelCase problem since it's not clear what the problem was. Revision 200 committed. Seems like a milestone. It's our bicentical version update - woohoo! ;)
-
Durnurd, do you have a project that I might be able to use as an mobile device template project and demo (perhaps with some overlay for directional inputs), or should I be working on one of those myself?
-
I had made something that sort of worked, using a custom Player and four plans to change the inputs when touching inside them. But it was kind of messy, and didn't take too long to make. so you may just as well start from scratch.
-
Okay, I think I'm ready to release SGDK 2.2.2 with a template designed for mobile devices/iPads:
sgdk2.enigmadream.com/ben/Mobile.html (http://sgdk2.enigmadream.com/ben/Mobile.html)