Road to 1.0 - what's to be done

If no one's said it yet, I thinking getting Construct to work with general PC controllers, not just the 360 control type, is a must. If you want this to go bigger and more public with a solid release, people are going to be expecting being able to use their generic PC controllers.

If I'm not mistaken, there's two control types, right? XBox 360 has its own type, so it's good that got out of the way, and then there's a universal type for all the rest? 360, and PC? I can't remember what the non-360 control type is called though...

But seriously, if anything, getting Construct to work with general PC controllers should be a top priority for 1.0.

If no one's said it yet, I thinking getting Construct to work with general PC controllers, not just the 360 control type, is a must. If you want this to go bigger and more public with a solid release, people are going to be expecting being able to use their generic PC controllers.

If I'm not mistaken, there's two control types, right? XBox 360 has its own type, so it's good that got out of the way, and then there's a universal type for all the rest? 360, and PC? I can't remember what the non-360 control type is called though...

But seriously, if anything, getting Construct to work with general PC controllers should be a top priority for 1.0.

Would this work?

Slooow it down now. Top priority? Really? Then why has no one else asked for it?

A lot of people have asked for it. It just gets shot down everytime so I think they quit after a while XD

But anyway. Yes, I imagine the new input plugin is more than enough for universal gamepad support and configuration. Haven't tried it myself yet, but judging by the examples it's very promising.

I can also vouch for wanting support for many control inputs. There are so many computers that vary how many keys can be pressed at once on a keyboard so that just pressing left arrow and two buttons won't work. So only having the alternative of Xbox controller is kind of disappointing.

Can you please fix add/remove attribute? It's an extremely useful feature that hasn't worked for a long time.

The player spends the whole time using input devices (and staring at glass), so it'll be great when all that gets sorted.

I don't understand why anybody would shoot down supporting gamepads in a game engine. To be honest, I don't know why any game released wouldn't support gamepads. I agree wholeheartedly that making sure gamepad support is flawless and thorough should be a top priority.

That said, perhaps more gamepad-related conditions? Obviously the engine has analog support for the joysticks on the 360 controller, so maybe the ability to track it? To give an example of where this would be useful, suppose you want to have two speeds for a character. Joystick 50% - 100% = high speed, 0% - 50% low speed. Etc. Most controllers have analog support so being able to track this data is potentially useful, because at the same time most players don't need an infinite variety of speeds.

I don't understand why anybody would shoot down supporting gamepads in a game engine. To be honest, I don't know why any game released wouldn't support gamepads. I agree wholeheartedly that making sure gamepad support is flawless and thorough should be a top priority.

This.

And this:

http://www.scirra.com/forum/viewtopic.php?f=29&t=7511

So yeah, it's solved now. Yes it should be built-in, but hey, it works now so it's good.

( and I had asked, several times on several threads )

I think not the only the program should be improved but also the support for it.. for example a centralized repository of some kind where the submition of tutorials, resources, uploads, plugins would be managed. I think it would be easier for everyone especially newcomers.

I'm just going to be a pain in the ass again and beg for my bug on the tracker to be looked into so I can get some closure. I'm pondering just moving to GM for the next IWBTG game (though I'd be checking back here for C2 for future games).

I swear, if a solution is found, Construct will have a big release title under it's belt. I'd be back to work instantly. Even if the bug isn't fixable, I'd just like some closure on the issue of some sort so at least my hopes aren't kept up.

What bug is that?

It involves a cap where objects in one layout cause framerate drops across the whole cap. Basically the more I add to the file (not just the layout) the slower the game gets. And not just a few lost FPS. David looked into this and acknowledge the bug but couldn't figure it out. It's a private entry on the tracker right now since it involves project game files. Sadly since Ashley and David tend to be busy, I haven't heard about the issue for like 6 months or so and I'm reaaaaaaaaally itching to work.

So I'm just trying to remind them once and awhile in hopes they can either deal with it or tell me I'm shit outta luck (or even tell me just what not to do to avoid the problem). I can deal with a lot of quirks and bugs, but in this situation it's absolutely crippling.

I'm sure David would've found it but it sounds like creating new instances of global objects, but that's a bit too simple, right?

I really don't think so, as I don't use global objects for anything. Even if I did, that doesn't line up I don't think. If that were the case, I believe FPS would drop as I move from layout to layout? In my case, if I test a layout, my FPS will be the same. If i go to another layout, delete some seemingly random junk and return to test again, my FPS will be higher. This is true for compiled files too (So it's not the editor keeping things in memory).

Am I misunderstanding what you're implying?