ArgumentError in createVertexBuffer about starling-framework HOT 14 OPEN

I get an "ArgumentError" which might indicate arguments are not as expected in some cases? I'm trying this in hope to get better reports.

diff --git a/starling-2.6/starling/src/starling/rendering/VertexData.as b/starling-2.6/starling/src/starling/rendering/VertexData.as
index 5e19f8b..70015b9 100644
--- a/starling-2.6/starling/src/starling/rendering/VertexData.as
+++ b/starling-2.6/starling/src/starling/rendering/VertexData.as
@@ -901,8 +901,14 @@ package starling.rendering
             if (context == null) throw new MissingContextError();
             if (_numVertices == 0) return null;

-            var buffer:VertexBuffer3D = context.createVertexBuffer(
-                _numVertices, _vertexSize / 4, bufferUsage);
+            var buffer:VertexBuffer3D = null;
+            try {
+                buffer = context.createVertexBuffer(_numVertices, _vertexSize / 4, bufferUsage);
+            }
+            catch (e) {
+                throw new Error("createVertextBuffer(" + _numVertices + ", "
+                    + (_vertexSize / 4) + ", " + bufferUsage + ") failed: " + error.message);
+            }

             if (upload) uploadToVertexBuffer(buffer);
             return buffer;

from starling-framework.

Sure, that would work fine.

If it's a little structured, like error.message = ...some text... (GL::<method>.<errorCode>) it would allow to do some regex magic.

What I'm looking at, if I can detect that it's a problem of GPU memory:

1. Show a proper error message to the users: "Your device ran out of memory, the game might be unstable. You can try restarting your device, but maybe it is just too old, sorry!"
2. If I can add figure out the total gpu memory of those users, prevent downloads from Google Play for those "low-ram" devices (I think it's possible). It will save some bad reviews.

from starling-framework.

Hm, the famous "Buffer creation failed. Internal error." ... Unfortunately, we were never able to pinpoint what's causing this. It would be helpful if Harman could maybe extend the error description – "internal error" doesn't give us a lot to work with. 😕

from starling-framework.

That's definitely a good idea! You're right, perhaps the arguments are somehow not in an allowed range or something. Please let me know when you receive those logs — thanks a lot in advance!

from starling-framework.

Got some data.

That's the error message now:

createVertextBuffer(288, 5, staticDraw) failed: Error #3672

It means:

• _numvertices is 288
• _vertexSize / 4 is 5
• bufferUsage is staticDraw

In another instance: createVertextBuffer(4, 5, staticDraw) failed: Error #3672

Both cases have _vertezSize/4 = 5, maybe that's expected... but it looks like the calls are valid.

from starling-framework.

Thanks for the update, Jean-Christophe!

Hm, yeah, those look like rather conventional values. The vertex size is stored in bytes in Starling, but expected as 32-bit integer by Context3D, so that's why it's divided by 4.

The standard vertex format in Starling is position:float2, texCoords:float2, color:bytes4, which is 20 bytes or 5 four-byte integers. Exactly what we're seeing here.

@ajwfrost, is there any way to get more information about this "internal error"? Or would it be possible to add some more detail to this error message internally in Stage3D?

from starling-framework.

Hi - so, "buffer creation failed" isn't in the initial parameter checking code. It means that the platform-specific creation of the vertex buffer hasn't worked properly..

What's the platform / driver mode? and is this reproducible for a particular app, or do you know if you hit this condition that you would get the same thing again if you just caught the error and re-tried?

I would guess we're getting an error from the graphics subsystem that we can't handle other than to just say "it failed".. if you can confirm e.g. what Direct3D version is used, etc, we can look at adding further debug info. Or perhaps we should just add something everywhere that this sort of thing could happen, to output a message to Scout?

thanks

from starling-framework.

It happens on Android.

Error happens to multiple users, don't know enough about the device, except this:

• Android / Linux 3.10.0-4756355
• Android / Linux 3.10.17-1133823
• Android / Linux 3.4.5

In the app's xml file, relevant sections:

    <renderMode>direct</renderMode>
    <android>
        <colorDepth>16bit</colorDepth>
        <containsVideo>true</containsVideo>

Please let me know how I can help more. I can instrument my app. I can share the stack trace from crashs we have on Android, as shown on Google Play Console. Quite a large number of crashs in libCore.so, but I assume it's not related because I believe I wouldn't get a report from AS3 if it was.

from starling-framework.

@j3k0 if it's Android then it may just be an OpenGL issue with one of the calls being made to allocate a buffer that's not working properly.. not entirely sure what we could do to recover in these scenarios - is it a very graphically complex app that may be running out of GPU memory?

For finding out the root cause, judging by your above code and saying you're getting the error message information: we may be able to adjust that error code (or throw a different error with a more meaningful error), but are you also able to see logcat output i.e. we could also output more information to the log about the failure, prior to it hitting the 'throw' bit?

from starling-framework.

@ajwfrost this isn't an error I could reproduce on our devices. It's happening to a few users: but for those there seems to be thousands of those errors. It may very well be that they ran out of GPU memory.

A way to access glGetError() from AIR would allow to add useful information to my error reports (or Starling's)

from starling-framework.

Will see what we can do re that .. but initially, if you are able to see the output from the below snippet

           try {
                buffer = context.createVertexBuffer(_numVertices, _vertexSize / 4, bufferUsage);
            }
            catch (e) {
               throw new Error("createVertextBuffer(" + _numVertices + ", "
                   + (_vertexSize / 4) + ", " + bufferUsage + ") failed: " + error.message);
            }

then, would it help if we changed error.message so that it contained the root cause (or at least, the gl function and return code)?

from starling-framework.

Thanks a lot for having a look at this, Andrew!

Yes, I agree — having more information inside the error message would be ideal. From a support point of view, knowing that a device has run out of memory immediately allows ruling out all kinds of other logic errors. So adding more text, or, as you proposed, the internal GL return code, would be a huge help!

from starling-framework.

I have this error consistently launching AIR desktop Starling projects in the windows virtual machine on the MB Pro.
Same project running directly on Mac works fine. In my case is related to graphic card and vram.

from starling-framework.

For me such issues (ArgumentError: Error 3672) fixed with latest AIR 50.2.3.7 if you using video playback on Android with Starling/Stage3D.

from starling-framework.