General slowdown with larger project?

Yes, it should be fine. The best way to measure framerate is actually delta-time - it's linear and frames per second is nonlinear. Basically, the difference in a real game should be nothing, it's only when you measure empty levels that you can see the effect the tiny difference has.

Does this mean there is going to be a final 'full' release of CC ?

Also, there seems to be a significant size difference in 2 of the 3 latest runtimes - a 3rd of the previous size. Just wondering why.

~1250 to ~1660 here.

Good deal :)

Does this mean there is going to be a final 'full' release of CC ?

Also, there seems to be a significant size difference in 2 of the 3 latest runtimes - a 3rd of the previous size. Just wondering why.

I doubt it, but this is a biggy.

So, question is, is it time to put out another release? It has been a

while.

As to the file size, the last two had a different installer.

yea this seems reason enough for a whole new release

The problem was there was a function in the runtime - "GetObjectTypeByName" - that loops every single object type and finds the one with the given name, case insensitive. For behavior management, this was called once every tick. This meant if your project was huge (hundreds if not thousands of different object types), it was doing a fair amount of work per tick. I came up with a faster way that doesn't need to loop every single object type, so now it barely does anything every tick.

So by object types, you mean, for example, a .cap with only multiple uniquely named sprites?

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.

I have a very big game(36 mb), but when I run the game FPS not change... Maiby it working on small games, but in big not works((

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.