I agree with a desire for multiple collision masks. It's not entirely great to take a complex character, make 3-5 copies and then form various collision boxes like that. It works, but theres a lot of annoying crap involved (optimally I'd wanna be able to play collision masks over transparent version of the normal original sprite).

I C1 I'm working with 4 different characters, each each with anywhere from 6 to 10 attacks, and it gets pretty cumbersome. If I had something liek this as an option, I would not only just use it for what I'm doing now, but probably do even more complex things in games.

I'm pretty sure Gamma is right. You'll be hearing this request again.

Hahah, I don't want to hate on anyone who cares about web games. It is the future and the direction most people are working in! But my ideas and thought processes do not lend themselves to the whole 'web' thing. Having people play a 50-100 megabyte game online (Especially one you sorta wanna just sell on steam or something) can be logistically obnoxious and lead to poor user experiences with load times and the like.

So I don't want to say web games are bad. I'm just saying that I don't have a horse in this race.

To put some perspective on the Flash/HTML5 thing (mostly for Vicu, but some of you might might enough this), Flash and HTML5 are not equivalent platforms. HTML5 isn't a 'thing' or discrete entity like Flash is. HTML5 standards for browsers just bring together a combination of features (Canvas element, faster javascript) that allow for flash like features.

To say HTML5 can go down the same dark path flash did in the realm of performance and bloat is sorta a silly misunderstanding. It would be like someone saying "Oh well C++ has gotten so bloated over the years". Adobe makes a product and authoring tools for that product. They expand it and they add new features to their authoring tool that makes the fast majority of Flash content.

HTML5 is just a bunch of tools. No one is controlling javascript. You have unlimited potential there, you just need implementation. Flash's advantage currently is it has a well developed authoring tool. HTML5, just being a collection of standards and a real programming language is something that is, at this point, potential Construct has the benefit of being one of the first tools help make HTML5 content, especially for games. That's both big for Scirra and great for developers. Flash WILL die. Even adobe knows this, which is why Adobe Flash Professional has HTML5 export abilities (or at least some sort of converter, I don't remember). Even if their platform dies, they can still monetize their tool. It's hard to compete with an open standard that has many advantages and very few drawbacks, it's just a matter of time. When enough folks in the content creation market are skiled in HTML5 and it's deployment and when things become more cost effective, things will change. HTML5 will only improve as content creation tools are made to support it and as browsers improve performance.

Flash still has some advantages now. They come in discrete, independent files which can be used as standalone executables, for example. You know things will behave the same on any platform. But since html5 is a very open standard, as soon as someone comes up with a good way to package something made in html5 as a single, easily embedded, clean entity, it'll happen. People will want this to make it easier to upload games to places like kongregate easily and more securely. But if I were to guess, I'd say there are probably ways to do it right now. The question is more about which implementations will end up being the most popular and well supported.

So while Flash and HTML5 cover a lot of similar functionality they are very much NOT analogous platforms and there is little reason to expect them to share similar histories. HTML5 is a specification, flash is NOT. Flash has a single vendor, HTML5 either has no vendor or many vendors depending on how you look at it. It would be like saying HTML4 and PDF are similar "Things" with similar histories.

But anyways, I hate webgames! So whats the vague timeline for exe-export? If it's anywhere within the next year I'll be thrilled.

If you've made 5,000 off of your game, I think the extra 60 bucks won't really be a deal breaker.

Looks good. I'll probably pick a license up eveutally, though I do want to see more progress first. Progress seems pretty rapid though. I'm hoping my next game project will line up just in time for the EXE export. I know it's a ways off, but whats the vague time line on that?

It's probably a lot to do with other stuff and not file size. If I made a game with lots of music and big graphics, it could easily be large while not having much sophistication nor benefit much from these changes.

Complex projects with lots of code -- where the code is the bottleneck for FPS, not the display -- are what would be necessary to benefit. If you're using lots of effects and only a little code, no amount of code optimization would give you a better frame rate. Also whats sets this problem off is lots of objects. I'm working on an NES style game where tiles are 16x16 and everything is super small and barely uses any vram. But I have LOTS of tiles, thus making my relatively small game benefit from these changes.

Now I have no idea what you're working on, but these are just some of the reasons you might now have seen any benefit.

I suspected a lot of the massive lost of FPS I experienced to be a result of what Ashley said too. Working on my current project, FPS loss from project growth seemed to slow down quite a bit once I was in the 200fps range. Losing the first 1000 FPS was quite easy though! Of course the amount of reduction seemed unsettlingly fast early on and the new files give me an FPS that seems more appropriate.

Hopefully this means Construct Classic will get some big name releases in the next 6 months.

My old project that I bitched and bitched and bitch and bitched about? Went from 900fps to 2000. The other, developed project I'm working on is all the way up from 120 to 250. SO BASICALLY MORE THAN DOUBLE.

I love you guys.

Out of curiosity, what caused this issue? Due to the suffering I've gone through, I'm invested in the answer.

I already tried to set the client height and width with the same results With a zoom I get a chrisp image and with the window plugin I get a fuzzy image. The fuzziness I would assume is an intentional feature (Only so much you can do when stretching an image), but there is still no way to get a crisp pixels (point/nearest neighbor) without resorting to annoying zoom shenangians that messes other things up.

I have photographic evidence if you want, but it's pretty much what you'd expect. A a game window with bilinear upscaling and a window that resembles nearest neighbor upscaling.

I've noticed that the resized windows functions in the windows plugin kinda create crappy little sub-pixel crap that mucks up the display, as opposed to zooming in with point sampling which is nice and clean. Anything I or you guys could do about that? The windows plugin is so much less infuriating when it comes to dealing with multiple layers and it's a shame that it makes things ugly, especially when someone is working with retro resolutions.

I'm just going to be sad that, I can still gain hundreds of frames of FPS by deleting objects in completely separate layouts, even if I delete every script I had available first.

But glad to see you guys are still supporting this, casually. I gotta still be grumpy though if I have any hope of continuing with that project.

Sure thing! I'll PM you everything that I put in the bug tracker so you can get a better idea whats up. I definitely appreciate it, this has been the bane of my existence for awhile now and I'd much rather use Construct than GM.