jobel

not really enough info to debug your issue. What plugins do you use, what obscure functionality, at what point does the error occur, etc.

Elios

Certainly Q3D is going to be polished up before I start anything new, but i'm nearing the end stages of development with it now so it's mostly documentation left to do after the next big update. This is just a poll out of curiosity. In any case i'm more looking for potential weekend projects and the like, it's always good to have a lot on the back-burner so I never run dry on ideas.

As for the sprite + lighting, this might be something I integrate into Q3D.

—

I probably wouldn't do spine, It's proprietary software and it's pretty redundant with spriter already being around and tightly integrated into C2. I also don't own it or desire to purchase it. There just isn't enough incentive to justify the work for me.

Path plugin is something i'm really starting to consider now.

There are a lot of good suggestions so far.

some issues i have to unfortunately point out are that a lot of editor/export/etc. functionality isn't exposed to 3rd party developers in C2, so this might be something Ashley should take into consideration for C3. I'd love to be able to make a "path editor" that opens up but it's just not possible with what C2's sdk gives me access to. however I am trying to think up some clever hack to work around this and potentially use global states in the editor and multiple plugins to define this type of information. A path plugin wouldn't be too much work to implement, and it seems sorely needed.

Image manipulator is a good idea too.

sprite fonts seem to be in great demand aswell.

newt

not really sure whats meant by "grid" movement. Path i assume is a simple follow the line type behaviour? I'd probably do path as a plugin rather than behavior so it can show something in the editor (sdk limitation), and so that multiple objects can be linked to the same path, or you could pair paths through containers if you'd want per object paths.

the gravity stuff sounds like something you can already do with custom movement very easily.

UberLou

Im not sure but doesn't C2 do this already? at least sprite has a function for it internally, might not be used. It might be possible, though I haven't thought about it enough.

Hello, most of you have likely seen me on the forum occasionally and know me as the creator of Q3D. I've been using construct for some odd 8 years now and would consider myself one of the more experienced developers around here.

Lots of talk on these forums in recent time has centered on mobile, HTML5 performance, etc. but this doesn't really do anything for anyone using construct right now. As a skilled developer I'd like to know what kind of plugins / behaviors / features are in demand so I could attempt to fill those voids in the future when I'm mostly finished with my current projects. I'm not making any promises to do whatever anyone's asking for, however I'd simply like to get a gauge on what people want, and good ideas will be taken into consideration. There's not much I can't do programming wise, however it has to be worth the investment and effort, and it has to be feasible within the current C2 SDK.

I look forward to what you all have to say.

Irbis

It's not really possible. You need tons of engineers to get it done right and maintain it consistently for the unbelievable number of hardware/driver configurations. It'd never be better than NW. A better option would be to implement a proper native engine with SDL to handle the main issues of cross platform but it's a huge undertaking.

The main issue is that your game is likely NOT hitting a consistent 30 fps. If the lower frame-rate is due to the CPU/GPU being taxed and having to wait longer between frames, you wont get "smooth" 30 fps, because you're getting a fluctuating fps in the first place. It's possible to schedule longer times between renders for logic, however construct doesn't have an in engine option to do this, so your "30 fps" is not really the same as a console games 30 fps, it's a 25-35 fps from overtaxed hardware. If you were to build your own renderer that skips every other frame in a properly scheduled way it'd be 'smooth' (if you could really call 30 fps smooth in the first place, something i'd argue), I've done tests with Q3D doing exactly this, and even have an option to skip rendering of specified ratios of frames. If your game is lagging to 30 fps it's unplayable because of the instability of the logic and the effect that has on frame scheduling, not because of the renderer/browser or otherwise. It's the same way any game because horrendous to play with significant drops in framerate, especially when timedelta based games make everything unstable in fluctuating fps.

Regardless if vsync is slightly off, chrome still has the fastest javascript and WebGL performance as far as I've tested informally by running various projects. The issue of occasional tearing isn't nearly as big as the issues IE11 tends to have in all other areas IMO.

—

Sure ill ask my partner to take a look tonight

The issue is theres very little ashley can fix atm, and im afraid soon unity will have similar woes as their web export is going to have to be webgl due to the deprecation of plugins. This should involuntarily put a lot of pressure on vendors to fix crap.

megatronx

No, it doesn't. That would break the logic in a lot of way if for example you move an object between checks etc.

To be fair, construct 2 works really well in browsers. The major complaints i see are with people using construct 2 for mobile games, a place they will not excel because of hardware constraints that make even java-script itself perform poorly. If you want to make a game for mobile with javascript you absolutely have to scale back and be very frugal with the resources you use.

Mobile games aren't complicated, and that's because you really need to develop them from the ground up to get any kind of good performance. Making a complicated mobile game in C2 is easy, however it wont work because it's too complicated. The more difficult an engine is to work with, usually the better the performance you can squeeze out of it but the slower your development will be, ESPECIALLY if you are inexperienced.

You could very easily code a fast HTML5 game for mobile, however you wont have the wonderful abilities like picking which construct allows you to use, you'd have to build the game in an optimized manner. If your game is GPU bottlenecked, then that's going to be a problem no matter what. There's a lot of inexperienced developers using C2 (which is understandable) and they end up complaining that their game is working poorly because it works on desktop "just fine" but dies on a mobile platform. The only answer that can be given is that their game is trying to do too much, regardless of if it's doing "a lot less" than other games they've seen on the platform.

As an example, anyone familiar with demoscenes will understand that some people can squeeze a ton out of very little. Take for example classic c64 games and their graphics, and compare them to some of the more impressive demos for c64:

demos:

vs.

games:

A lot of low level optimizations that have to do with using smart memory structures and reusing data in an intelligent way mean you can get "way more" out of something. This is what mobile developers manage, even if they're using html5+javascript from the ground up, vs construct. Construct 2 will allow you to very easily trim down recursively through lists of objects with picking conditions / actions, however the fact this is used everywhere to make events "easy to use" means the performance suffers, ESPECIALLY on weaker platforms where performance is constrained. Things like "creating" and "destroying" in construct are very high level and generally expensive even with the recycling systems in place. They're general so that when something is gone it's gone and everything knows it's gone, however this is expensive compared to just pretending something is gone and controlling at a low level. In most cases a game with limited actors could much more efficiently be constructed by having a short array of references and never having to really pick anything.

To top things off, most people abuse the hell out of collision detection in construct since they have a poor understanding of the costs associated with it and the mechanisms behind it's operation. It's very easy to blindly apply collision detection throughout code for repeated conditions, but really most engines have a SINGLE collision detection run per frame because it's so expensive, when in construct you can end up with many many many collision detections per frame, which make things "tighter" at tremendous cost. Behaviors are also a big issue because of how general they are, the expense they incur quickly adds up.

If you want great performance, you need a powerful platform, or you need to fine tune your game from the ground up, there's no magic bullet and complaints are misdirected for the most part.

shinkan

Q3D is confusing because of the limited editor SDK of C2, so if people want powerful plugins with good editor integration, im afraid supporting C3 development is the only way they can do it... Regardless Q3D is constantly improving, and hopefully i'll have time to get some documentation out after the next update which finalizes a lot. I can guarantee using Q3D is way easier than trying to make a 3D WebGL game directly, and it works quite well at achieving that goal. In any case UE4 and Q3D have entirely different purposes, UE4 doesn't really work in browsers, regardless of what their poor HTML5 emscripten demos that barely work try to prove, they really aren't trying to make an engine for WebGL.