GMLscripts.com

The first thing I would say, is no matter what the platform, you REALLY don't want to create surfaces "all" the time. You create them once and keep them around. Since moving to hardware rendering this is even more important as surfaces are created "on card" using VRAM, and this is a limited resource. So if you make several large surfaces all the time, you will very quickly fragment memory and never be able to allocate one again.

In "real" cases (i.e. in a game), you will create a surface on object creation, and then keep it around which is what you really want to do.

As a general rule, you should really try and pre-allocate stuff before playing a level, as allocation is always slow.

It's also no surprise hat you can get render targets over a certain size, as this will be limited by your graphics card, and the hardware rendering API. For example, I easily get 2048x2048 at 60fps (WebGL), but jumping to 4096x4096, it drops like a stone - I'm surprised it even did it.

GM8 and lower were all Software rendering, which means it could have ANY size you wanted, and with the amount or RAM usually available to the CPU, you're not very likely to hit issues. However, hardware rendering should outpace the CPU - particularly once we move to the C++ render which batches things properly, although even on the Delphi runner I'd expect better performance  when your doing more than just playing with a couple of surfaces.

So, no... not a bug. Hardware limits. And if you need an 8kx8k surface, I'd question why - it's a bad idea that BURNS memory 512Mb bytes per surface to be precise (surfaces also include depth buffers as well remember). Not a good idea - ever.

No it's not.... it's like putting an accessor on every class variable, and disabling inlining.  The slow down would be ridiculous! You lose SO much performance by doing calls all the time, rather than taking the extra time and care to write your code.

We can't check stuff that goes direct to variables, particually as in GML a variable can be "anything". It's typeless, so who are we to say that variable "X" is a number and not a string? Sure the built in ones are, but it may already be a NAN by the time you come to set the built in one and your still going to have to debug it yourself.

But at least you now have a full source level debugger built into most browsers so you CAN find out.

Really... if your coding in script, there's only so much we can do to protect you without crippling it for everyone else.

We have started to put in some "debug" specific code that swaps in extra checks at runtime, but there are well over 1,000 functions so these will take time to expand out.

If I had my way, I'd be forcing you to use "X" for numbers and "X$" for strings. Basic had it right in my mind.... but we can't do that, mores the pitty.

Okay... this is a rendering issue with the browsers... but I don't think it's going to go away. I need to rewrite the full-screen part completely. 

We try to fix show stoppers first, then try and pick off the simple ones next. outside that it's whatever bit of code we're currently in as that's where our "thinking" is at. If you are truly "stumped" and can't progress, then adding a comment to the bug bumps it up the list and it'll get reviewed again (as we tend to go by the one line description for picking whats next).

Worst case, ping us on twitter (@mdf200 ,  @russellkay) if you need help "now". We can't promise immediate action, but we do try to help when it's possible.