Feature todo-list

- Improve the Controls system; allow two movements to use separate controls, have a Set control action, allow gamepads and such.

It would be nice for you to include the full keyboard. I can't test my games in dvorak, where wasd is actually ,aoe... there is no comma or period in the controls or key pressed check. Or at least, that I saw. If I'm wrong, it would be nice to know the way, outside of switching to qwerty every time I wish to test a Construct game.

Gamepad use would be one way around it, but still.

"Set control" sounds awesome.

Here's an interesting feature request...

Granted, it's probably not one of the most important ones, but can be a really nice addition...

A camera plugin where you can have a box display another portion of the layout. Would be useful in say making a TV screen in the middle of a game level that displays an area later on...

Or in fact, split screen gameplay...

i suggested split screen multiplayer before but maybe a plug in that will expand on the display functions would be better, the ability to have picture in picture with specified dimensions rather than a screen simply divided into halves

Got a few requests:

More sampling methods for rotations/scaling

A powerful Overlay like plugin to help create dynamic shadows like

2

A toroidal(sp?) sprite object that warps the moving picture inside either vertically or horizontally. (Cloud filter in photoshop, subtractive shader in construct and you got some nice fog)

Mersenne twister plugin.

7z compression plugin for files and text.

AES encryption plugin.

Hash plugin (SHA-1 and MD5)

Python(I know its getting added into the IDE) or LUA plugin to help make games more mod friendly

Also which physics engine is Construct using?

A camera plugin where you can have a box display another portion of the layout. Would be useful in say making a TV screen in the middle of a game level that displays an area later on...

Or in fact, split screen gameplay...

I think a camera object to control the player's view would be useful. One could apply affects directly to the camera object dynamically, rather than from a restricted perspective. Unless this is all in there already...

[quote:q14m4ti0]More sampling methods for rotations/scaling

As far as 2D goes, the only sampling methods most graphics chips have built in is point or linear. These effects like 2xSal would require pixel shaders so should be implemented there.

[quote:q14m4ti0]dynamic shadows

Very cool. On the todo list.

[quote:q14m4ti0]warps the moving picture inside either vertically or horizontally

Is this the same thing as scrolling a tiled background's image?

[quote:q14m4ti0]Mersenne twister plugin.

The 'Random' expression already uses Mersenne Twister.

[quote:q14m4ti0]Also which physics engine is Construct using?

Newton Game Dynamics, http://www.newtondynamics.com/

Also a camera object is a good idea, but you can already scroll and zoom the view in and out either per layer or for a whole layout, and it should be able to rotate soon too. Is that what you wanted?

[quote:g1kptl76]Also which physics engine is Construct using?

Newton Game Dynamics, http://www.newtondynamics.com/

Construct is using a 3D physics engine? If I may ask, what was the reason behind choosing this particular engine?

Also, would it be possible with this engine to make a per-pixel collision mask? I'm thinking for curved surfaces and such.

Well, in theory we could extend it to do 3D physics, but that's a bit optimistic. It was the best physics engine I found - I tried some 2D ones but they seemed unstable or lacking in features. I guess someone could always make an alternative physics movement if they found a decent 2D engine, it'd probably be faster too.

[quote:2ewknj0p]warps the moving picture inside either vertically or horizontally

Is this the same thing as scrolling a tiled background's image?

Something like this, but the picture insides scrolls inside the objects box rather on the whole layout. (Also right clicking on New Action, Bullet Movement in the event sheet editor brings up a blank)

[quote:2ewknj0p]Mersenne twister plugin.

The 'Random' expression already uses Mersenne Twister.

Ops, forgot to request the ability to seed using several values (Useful to keep "random" values the same between uses)

>

> [quote:2aseojbf]Also which physics engine is Construct using?

>

Newton Game Dynamics, http://www.newtondynamics.com/

Construct is using a 3D physics engine? If I may ask, what was the reason behind choosing this particular engine?

Also, would it be possible with this engine to make a per-pixel collision mask? I'm thinking for curved surfaces and such.

I believe that Newton Game Dynamics aims for accuracy over speed. Perhaps something like Chipmunk or Box2D, which are built for 2D and speed?

I really wish I knew C++ so I could help out with Construct <img src="{SMILIES_PATH}/icon_sad.gif" alt=":(" title="Sad"> . The amount of features your adding must make you crazy busy.

Dynamic shadows!! I've asked for that before i think.. doesn't matter, ITS ON THE TO DO LIST! YAAAY!!! *jumping around screaming*

I believe that Newton Game Dynamics aims for accuracy over speed. Perhaps something like Chipmunk or Box2D, which are built for 2D and speed?

I really wish I knew C++ so I could help out with Construct <img src="{SMILIES_PATH}/icon_sad.gif" alt=":(" title="Sad"> . The amount of features your adding must make you crazy busy.

From what I've seen of Chipmunk (MMF uses it), I'd rather stick with what we have now. The only thing Chipmunk has over Construct's physics engine is a couple dirrent joint types and the ability to do per-pixel collisions. Otherwise it seems to run like crap (at least in MMF... if it ran as smooth as the videos on the Chipmunk page show that would be a different story).

Check out this thread at TIGSource where Noyb and I post prototypes of his game concept, except he makes his idea in MMF2 and I tried it out in Construct. IMO Construct kicks MMF2's ass in the physics department. Everything else I've seen with MMF's Chipmunk physics is slow as hell, too.

> I believe that Newton Game Dynamics aims for accuracy over speed. Perhaps something like Chipmunk or Box2D, which are built for 2D and speed?

>

> I really wish I knew C++ so I could help out with Construct <img src="{SMILIES_PATH}/icon_sad.gif" alt=":(" title="Sad"> . The amount of features your adding must make you crazy busy.

>

From what I've seen of Chipmunk (MMF uses it), I'd rather stick with what we have now. The only thing Chipmunk has over Construct's physics engine is a couple dirrent joint types and the ability to do per-pixel collisions. Otherwise it seems to run like crap (at least in MMF... if it ran as smooth as the videos on the Chipmunk page show that would be a different story).

Check out this thread at TIGSource where Noyb and I post prototypes of his game concept, except he makes his idea in MMF2 and I tried it out in Construct. IMO Construct kicks MMF2's ass in the physics department. Everything else I've seen with MMF's Chipmunk physics is slow as hell, too.

I don't think MMF has ever been associated with speed <img src="{SMILIES_PATH}/icon_wink.gif" alt=":wink:" title="Wink">. Chipmunk seems pretty fast.

I agree Chipmunk would probably be faster since it only deals in 2D: I think Newton still processes the Z axis but the results have no effect. Newton is good and usually stable (providing you don't slam objects in to walls with millions of newtons of force, which isn't physically realistic and surprise surprise messes up!). If a certain implementation of chipmunk sucks then that's not really chipmunk's fault, the demo videos looked pretty good.

I won't however look at any alternative physics engines till after 1.0, because the current one works, and rewriting stuff pre-1.0 won't do the release schedule much good.

I don't think MMF has ever been associated with speed <img src="{SMILIES_PATH}/icon_wink.gif" alt=":wink:" title="Wink">. Chipmunk seems pretty fast.

If a certain implementation of chipmunk sucks then that's not really chipmunk's fault, the demo videos looked pretty good.

Okay, you've convinced me. I see now where the fault truly lies <img src="{SMILIES_PATH}/icon_wink.gif" alt=":wink:" title="Wink">