GMLscripts.com

Discuss and collaborate on GML scripts
Invert

You are not logged in.

#1 2011-12-20 00:35:29

xot
Administrator
Registered: 2007-08-18
Posts: 1,239

Disturbing Game Maker Surface Creation Tests

I recently got GM8.1 working again. I've never really used it much because of some of its bugs. I was goofing off and loaded up my Wireworld demo and was alarmed to find it did not work for more than a few frames. It seems that recent versions of Game Maker are not very reliable when it comes to surface creation. Below are some statistics I've assembled from the various versions of GM I have installed. The percentages are the success rates for different sized surface creation requests.

Version            FPS         1-512px    1024px    2048px    4096px    8192px
GM 6.1             300+ fps     100%      100%      100%      100%      100%
GM 7.0             300+ fps     100%      100%      100%      100%      100%
GM 8.0             300+ fps     100%      100%      100%      100%      100%
GM 8.1.139         300+ fps     100%      95.0%     28.6%     3.6%      0.0%
GM-HTML5 1.0.179   130 fps ?    100%      91.4%     27.4%     3.5%      0.0%

The frame rate of the GM-HTML5 test is really odd. The test starts at 256 pixels and the maximum frame rate is around 130 fps for most sizes. However, when the size is reduced to 1 or 2 pixels, the frame rate achieves the full 300 fps of the room speed. If the size is increased from there, it will maintain a steady 300 fps for all sizes up to 1024 pixels or more, at which point it begins to slow down just as the versions others do. If the GM-HTML5 IDE is active, tests from any version run at 30 fps (or slightly less).

These statistics are from a machine with 2GHz CPU cores and a GeForce 6 series GPU running WinXP. On an eMachine running Win7 the frame rates are significantly lower, but the test results are pretty much the same.

Below is a link to tests for the various versions of GM listed above. The archive includes project source files and executables. I would love to hear results from any who care to try the tests. An explanation would be even better. My best guess is that recent versions of GM are freeing surfaces in batches, rather than immediately, which is causing occasional shortages of available texture memory.

Download bug_surface_create.zip from Host-A

The tests request a new surface after freeing any existing surface. The automatic trials mode runs tests in groups of 100 for each power-of-2 size up to 8192px. It appears that the order or number of times surfaces of large size are requested for creation has an effect upon their chances for success. The number of trials can be easily adjusted in the source code.

I have not yet submitted any bug reports concerning this issue.

EDIT:
It's not a bug, it's a feature.

Last edited by xot (2011-12-21 15:49:57)


Abusing forum power since 1986.

Offline

#2 2011-12-20 07:06:15

mike.dailly
Member
Registered: 2011-10-04
Posts: 10

Re: Disturbing Game Maker Surface Creation Tests

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.

Offline

#3 2011-12-20 07:49:19

paul23
Member
Registered: 2007-10-17
Posts: 110

Re: Disturbing Game Maker Surface Creation Tests

mike.dailly wrote:

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.

Problem is there are quite a few cases which destroy surfaces (ie screensaver / other programs). And tehre's no way to "catch" this event. So I've in the past changed quite often simply added (in the step event):

Expandsurface_free(s);
s = surface_create(x,y)

Other solution would be to call "surface_exists()" first I guess (and only recreate on existance)? Though when I tested it with gm6 surface exists was slower than recreating surfaces on the fly. Well I really hope there would be a "solution" sometime for surfaces being freed by external sources.

Offline

#4 2011-12-20 11:38:10

mike.dailly
Member
Registered: 2011-10-04
Posts: 10

Re: Disturbing Game Maker Surface Creation Tests

surface_exists() is definitely the way you should be checking. That way you keep creation down to when you actually need it. You should ALWAYS assume that allocation and freeing is slow.

Offline

#5 2011-12-21 15:49:24

xot
Administrator
Registered: 2007-08-18
Posts: 1,239

Re: Disturbing Game Maker Surface Creation Tests

Thanks for the detailed reply, Mike. I of course agree with you about sane memory management and only wrote the demo the way I did out of convience and clarity. I'm sure if I allocated all of the necessary surfaces at the start it would work fine. I'll probably give that a go and experience a performance boost in the process.

The software to hardware transition certainly explains the differences in the rates of success, although it doesn't entirely explain the actual behavior. I think memory fragmentation is in a way the issue. My best guess now is the graphics driver allocates memory serially until it runs out, even if a same-sized chuck has just been freed. Once it hits a dead end, it reshuffles the allocated memory (which takes time and slows things down momentarily) and refuses any new requests until it is done. Then the process repeats starts again from the lowest available point in memory.

So, if we've established that it is not a bug, I guess I need to rename the test file 'feature_surface_create.zip'. tongue


Abusing forum power since 1986.

Offline

Board footer

Powered by FluxBB