As far as plugins go, I think something like shaders would be totally fair to reserve for the paid version. They're not necessary for game development, they're more like icing on the cake.

I completely disagree with this - shaders are really what put Construct above the other 2D creators in terms of what could be done with it. Basically everything I've worked on so far in Construct has involved shaders to a very game-defining degree, that is to say the game would be completely impossible to develop without shaders unless humongously drastic changes were to the gameplay and visual output. They should definitely be available in the cheapest version, whatever that ends up being.

Also, I gotta say that I like the Reaper licensing scheme mentioned earlier - the base price is high, but it's available for considerably cheaper for indies/student/whatever, then if they make a lot of money with it, they'll need to buy a full license. No features restricted between these two licenses.

I am excited about the potential of Construct 2, though I probably won't try to do anything serious with it until it gets Windows/OSX/Linux exporting and pixel shader support to go with it (because pixel shaders are amazing and absolutely vital to the development of the projects I'm working on). In other words, as long as the capability of having multiple exporters doesn't hinder the possibilities of individual exporters and everything doesn't always have to adhere to the lowest common denominator, I'm game.

[Post removed for backseat modding]

Makes me wonder though if it optimizes it at all, since it has to be tested on all the trees, and calculating square roots isn't exactly all that fast. And surely collision detection starts with bounding box testing, so that if bounding boxes do not overlap, no per-pixel calculation is done. And I'd think bounding box overlaps would be a lot faster to calculate for all trees compared to their distance to player.

But if you really want to do some sort of distance checking, I think something like this (using Is number between) would be more optimized:

Is tree.X between player.X-ScreenWidth/2*Zoomlevel and player.X+ScreenWidth/2*Zoomlevel

Is tree.Y between player.Y-ScreenHeight/2*Zoomlevel and player.Y+ScreenHeight/2*Zoomlevel

-> Check for overlap

Yes, you can do this pretty easily with Python.

Basically you have a formula like 5+5 in your INI string. Then you just set the value of anything to Python(YourFormulaString).

With this you could also have formulas like DMG*3 and then run Python(replace(YourFormulaString,"DMG",object('damage')))

Or if you have multiple variables you'd want to use, you should probably have a list that you loop through that knows where to check for the values or stores the necessary values.

I'm just chiming in to say that this plugin is absolutely fantastic and makes life a lot easier for everyone.

Also, I believe (not really sure though) that the algorithms are not pixel-shader friendly.

And here I was going to suggest giving that a stab. Oh well. Maybe it could work, though?

You know, you guys could always just use functions. Name the function object F, make an on function abscosp and set the return value to:

lerp(.Param(1),.Param(2),abs(sin(lerp(0,180,.Param(3)))))

Then you can use it with F.abscosp(a,b,t) anywhere you want.

I'd say 0-based. I'm not even testing Construct before either all mathematics and computer software are made 1-based, or Construct is adjusted to how reality actually work.

4 mod 4 is 0, not 1. Sin, cos and tan centers around zero. A variable defaults to zero (don't tell me variables are also 1 by default in Construct). The value that is returned in place of "aaw, that's unset" is also zero, unless a NULL value is supported. The range of an unsigned byte is 0-255, not 1-256. The top-left position of a screen and object is 0,0, not 1,1. You move an object 0 pixels to not move it anywhere. In every situation when negative numbers are used, it's a pain to have 1 in the middle. I'm just going to be too annoyed over dealing with this that I'd rather stick to what I use now where things are randomly 0 and 1 based (because at least some features are 0-based).

Basically all those things you mentioned are zero-based in Construct. I think the only things where the 1-base shows are loops and arrays, where the loopindex of the first one is 1, not 0 (though if you run a for loop from 0 to 255, the first loopindex will be 0).

So yeah, if you don't regularly use arrays, pretty much the only time you need to remember the 1-base is with not-for loops. A minor annoyance, really. But an annoyance none the less.

I hope the fact that this poll doesn't have "full unicode support" means that it's already planned and listed as an absolute must feature.

I'd say Mac/Linux is the most important thing. Web browser is a bad idea in my opinion, since that'd basically mean Flash or nothing, and that's stupid. You can't play certain Flash games everywhere anyway, so supporting all kinds of PCs would be the best choice - that way'll the game will be playable on all the major PC platforms. I think mobile platforms should be left out of Construct completely, since due to the fact that we're talking about embedded systems getting everything out of the platform tech-wise is a lot more important than with desktops/laptops, thus it'd be a better idea to use stuff specifically meant for those platforms.

Making Construct capable of exporting to Flash/Java would most likely just make the program less capable overall, even worse in terms of performance than what it offers now. I hope you people voting for web browsers realize this.

A simple way to deal with the original problem:

Always: Add 1000*TimeDelta to 'millisecondcounter'