Changes are though that any widescreen game in it would be 1280x720, thus you'd have to downscale them if you do eg. 800x600 or 640x480 video. It'd be a better idea to upscale the 4:3 games to 960x720 with black bars to go with the 1280x720 clips.

I also vote for the "exes submitted to an editor" model. It'll ensure much more consistent recording and video quality.

I also volunteer myself as an editor, since I have lots of experience in the fields of video capturing, video editing, video processing and video compression.

I also suggest that when people submit their exes/caps they can say what they'd like to be recorded in it if it's not obvious what the thing is demonstrating.

newt's solution is probably the best idea. I thought I'd made an Angle Lerp expression, but I wrote it for something else. Might be useful to add to the next build?

You could add a "Rotate towards angle" function for sprites while you're at it. Right now you have to use a workaround like "Rotate towards position: Sprite.X+Cos(TargetAngle)*10, Sprite.y+Sin(TargetAngle)*10", which isn't really all that intuitive.

I sincerely hope your game won't be as terribly boring as that one Nanoha STG out there. I have bad memories from playing it.

I guess I'm sorta using a form of FSM for my character animation... I have a single variable called animstate, and then I just run events like "If animation != animstate -> Change animation to animstate" and then I have events like "When animation raiseweapon finished -> set animstate to weaponraised".

It does make handling animations in the events quite easy.

That's a good idea. Reported it to Google & Mozilla.

Figures, anything with "official" in the name that very clearly isn't official is bound to be spyware. I remember seeing that topic earlier but didn't realize this was the same. Good to know anyway, but I think something should be done to make that thing disappear from the web if possible... Though I don't think Conduit whatever will stop with their shady business with just an e-mail, but hey, it'd say it's worth a try.

officialscirra.ourtoolbar.com (edit: be careful if you visit - this is malware)

Ran into this while surfing on the net. Looks like some sort of scam toolbar or something...

*Line breaks. Might already exist?

"Line one" & NewLine & "Line Two"

In other words, it's already built-in as a system expression in Construct.

[quote:3pg0y3m5]Counters can be made with anything by adding and subtracting private variables. It is totally not necessary to have a separate counter object.

There's one benefit TGF/MMF-style counter object would have compared to the other alternatives though, you could draw the numbers for it yourself, meaning you could have custom graphic -counters made with ease.

With Construct, to get custom graphic counters, you'd need to use the SpriteFont object, which has its own problems... I guess the best solution would be just to get a more working SpriteFont object, it'd solve this issue and offer more usability in general.

[quote:6pkyd7k9]

+ On collision between aSprite and bSprite
   -> Set global('aFoo') to aSprite.Value('life')
   -> Set global('bFoo') to bSprite.Value('life')[/code:6pkyd7k9]

In Zetar's case the code would be like this:

[code:6pkyd7k9]+ On collision between Sprite and Sprite
   -> Set global('aFoo') to Sprite.Value('life')
   -> Set global('bFoo') to Sprite.Value('life')[/code:6pkyd7k9]

The hell are you supposed to specify which one is which in this scenario? I said to use a family because if your object Sprite is the only member of family Blue, you can do it like this:

[code:6pkyd7k9]+ On collision between Blue and Sprite
   -> Set global('aFoo') to Blue.Value('life')
   -> Set global('bFoo') to Sprite.Value('life')[/code:6pkyd7k9]

And it's very easy to to do basically anything, like comparing their values with each other, or doing specific things on the other one, like this for example:

[code:6pkyd7k9]+ On collision between Blue and Sprite
+ Blue('life') < Sprite('life')
   -> Destroy Blue
Else
   -> Destroy Sprite[/code:6pkyd7k9]

Without the family trick, the code would look like this

[code:6pkyd7k9]+ On collision between Sprite and Sprite
+ Sprite('life') < Sprite('life')
   -> Destroy Sprite
Else
   -> Destroy Sprite[/code:6pkyd7k9]

...which I'm fairly sure would not work as intended.

Considering all the annoyances involved in colliding one instance of a sprite with another I'd suggest you include your sprite in a family and test for Family on collision with Sprite. This way you can refer easily to whichever colliding instance you want, eg. Family('Life') and Sprite('Life') will each refer to the different colliding instances.