TiAm & DrewMelton I mentioned earlier that both my machines use above-average SSD's + good CPUs and I still had projects with 10+ second preview times. I'm sure SSD's help a little but it looks like we need more optimizations on C2's part.

Ashley The initial preview on NW.js appears to take ~1 second longer than Chrome. Subsequent previews (reloading the existing preview) take the same time.

Generating the preview is fairly quick; 2.5 seconds and the game window is there.

Loading the preview (with percentage or progress bar in the game window) is what takes the longest, at about 4.5 seconds.

So all in all it takes about 7 seconds for a fresh preview.

Approx. download = 17.7mb | Memory use = 7.2mb

C3 will probably be out by the time this becomes a real problem (for my team, at least) but if it's not too much trouble I think any preview optimizations will be appreciated!

Well sprite frames/images are the main culprit so maybe something can be done to better optimize them for previewing..?

*crosses fingers for live-editing in C3*

My game takes about 45 seconds to preview to node-webkit.

That's insane.

Ashley Please tell me there's something we can do about this...

Hm. Disabling audio pre-loading and even deleting all audio files doesn't make any difference here. Previewing with NW.js btw.

My CPU is a 2.5GHz Intel Core i7 4710HQ. The game I referred to with the 10+ second preview times was on my desktop with a 3.5ghz i5 2500k . Both have preeeeeetty fast SSD's so...eh.

It's kinda been discussed before but is there anything I can do to decrease the time it takes to preview my game? The larger it gets, the longer it takes to preview. An older project of mine used Tiled and sprite objects acting as tiles, and my preview times took over 10 seconds despite everything being on a very fast SSD. I'm just worried the same thing is gonna happen with our current game farther down the road even though we're using the tilemap object now. Testing small tweaks and such is already annoying with ~4 second preview times.

At least it's not as bad a GM or Stencyl - those can take upwards of 30 seconds to preview! However, MMF2.5's preview is practically instant even on giant levels with lots and lots of objects.

gdog105 I think there's some confusion here... Publishers who are seeking out HTML5 content will prefer games that run on browsers and mobile devices. Publishers who, er, just prefer games, don't care if it's HTML5 or not. Does it run on the target platform? Cool. Any others are just a bonus. There are numerous HTML5 games for desktops, mobile devices, and browsers, all with or without publishers.

MovingAngleStart is fine. Thanks for taking the time to add this! I kind of found a different solution but it involves a dummy var and some other stuff and still isn't perfect.

I'm working on a snake that uses both the moveto and the sine behaviors. I want to tell the snake's head which angle to face based on the "moving angle" of the moveto behavior, which will be limited to 0,90,180,270.

Problem is, the moveto's "moving angle" expression is just the angle between the object's current and previous position, and the sine behavior screws it up. Instead of, say, 180, I get values between 160 and 170. I tried to make the snake face an angle if the moving angle was between these values, but that didn't work for some reason. I'm assuming this is because the variation of the sine is so great that my conditions overlap...or something.

So I'm wondering if there's some math I can use to remove the sine offset from the moveto's "moving angle" entirely. I think I need to calculate the difference of the angle w/ sine and the desired angle, then subtract it, but I dunno how to get the desired angle in the first place. Agh.

EDIT: Kinda solved this by rounding a separate move angle var to the nearest max deviation of the sine, then comparing that variable instead. So if the moveto's moving angle is within, say, 15 of 180, my var will be 180 and the snake will face it properly. Would still be nice to have the proper expression if anyone's got some free time though

C2 loves making difficult things easy and easy things difficult. What you're asking doesn't sound terribly difficult though. Just use generic input functions, UIDs, families, and maybe custom containers because C2's aren't very good.

rexrainbow Tried that and a handful of other things. The sine keeps screwing it up. Can't you just change the moving angle to the angle between previous target and next target instead? Or a new type of moving angle that does something like that to be completely independent of other behaviors?

edit: Trying to do this myself with events but it's easier said than done...

I don't really see what's so terrible about it :T For example in my game I use functions to damage enemies

+Projectile collides with enemy

-Call "Projectile_Destroy" (Projectile.UID)

-Call "Enemy_Hurt" (Enemy.UID)

+On "Projectile_Destroy"

+Pick Projectile by UID Function.Param(0)

+If Projectile.Name = "Blah"

-Do a thing with it

+On "Enemy_Hurt"

+Pick Enemy by UID Function.Param(0)

-Hurt Enemy

So now I can do many things that hurt the enemies just by calling that function, or I can hurt all enemies at once by excluding a UID. I have a higher level of control this way, and no duplicated code whatsoever.

Also sometimes you'll want to store the UID of a different instance than the one that called the function. I do this for a complex moving platform system.

*Shrug* We'll see what Ashley thinks I guess.