Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - durnurd

Pages: 1 2 [3] 4 5 ... 83
31
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;"/>

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

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

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

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

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

37
Found a bug in "blocked" in the "Up" case.  It calls this.floor where it should call Math.floor.

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

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

40
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 :)

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

42
Projects / Re: Dynamic map loading
« on: 2011-12-19, 08:32:59 AM »
Almost no recollection of it whatsoever.  I do remember something about it, but I couldn't tell you anything about implementation.  I may very well have the implementation laying around somewhere on my Desktop, which I haven't turned on lately.  But if I remember, I can look and see what's there.  Since we're in .NET 2.0 now, it sounds like the major hurdle has been... hurdled?

I don't know how we would address the other hurdles though.  Like I said, I haven't looked lately.

43
News and Announcements / Re: Upcoming SGDK2 Outputs HTML5
« on: 2011-11-15, 08:52:06 AM »
If you're just looking for a map that looks good for scrolling, wouldn't the sample project work well?  Or are you thinking something more expansive?

As for difficulty of finding, etc... I'm used to it by now but most apps don't let you just extract all the files and be good to go.  You usually have to go through some sort of installation process.  You may want to include a readme or mention something about how it's self-contained and you don't need to install anything, which is a plus for most people.

44
News and Announcements / Re: Upcoming SGDK2 Outputs HTML5
« on: 2011-11-14, 08:40:54 PM »
Looks pretty nice.  I tried it with TVSGDK2, and it worked pretty well.  There were some oddities when viewing with a full window and changing the browser's size, but that's probably "not supported" anyway.

One thing I would suggest is changing the export flow. If I want to change from fixed size to full screen, and toggle generation of buttons before exporting, that requires navigation through the menus three times.

My suggestion would be to instead make it another form, and also allow the user to select the location of the file/files to go, rather than just place them in the project directory.  I was fully expecting a dialog asking me where to save it, but nope.

45
Off-Topic / Re: Concentrating on an old game
« on: 2011-08-16, 10:44:16 PM »
Three words: Duke Nukem Forever.
Three words: Universally bad reviews
Not to say that a long-lived project can't work, but in the case of Duke Nukem Forever, the metascore hovers around 50 out of 100.  It's probably due to changing hands, story arcs, platforms, game engines, and release dates so many times, and even being canceled once.

The 12-year development cycle was probably the worst of the problems, because if they had stuck to the original game engine, it would look like Duke Nukem 3D.  Which wasn't bad for its time, but now?  Well, that's probably the reason they kept changing game engines.  In the case of game developers using SGDK2, I think that anybody working on a game for 12 years straight might find that their measly SGDK2 engine doesn't stand a chance against SGDK9 ;)

Pages: 1 2 [3] 4 5 ... 83