It’s nice if one person wants to help another person. However, what I am trying to say is that some help is pretty much useless (no offense) just because the person who are trying to help did not analyse all information. Steps 1-6 describes how to install AIR SDK on CS5.5. Why do I need this info if I mentioned that the app is running meaning that i have sdk correctly installed. Step 7 describes setting the values that were described here in this thread multiple times. So, again, why to suggestion some possibly correct values again?

My initial question actually was not regarding setting the value in app descriptor file as is. But actually about what does this property do and what is better to use.

I have found similar discussion. So, this is not something that happened only to me
Hm, tried to put the link here in the message to another thread on this forum, and it did not allow me to post it because spam filter assumed it is spam.

Anyway, the title of that post is Away3D 4 problem with Android, you can navigate to message #6

FlexIncubator,

Thank you for your careful analysis and trouble-shooting of the #3709 error.  Will you kindly open a bug for this?

Since Adobe has done such a poor job of documenting the purpose and the functional specifications concerning GPU hardware that is devoted to managing depths and applying stencils, I am pretty sure that any of us who rely on a molehill framework such as Away3d’s to isolate us from having to understand and implement video card drivers have been left scratching our heads wondering not only what appears to be broken with the roll out of the AIR3.2 release candidate, but how in the world the code must have been working for the past several months without there being any application descriptor tags associated with that hardware.

While you were wrestling with your build/test environment, I was wrestling with mine, but did not want to otherwise cloud the issues you were documenting.  My use case—with almost identical symptoms to your own—is very, very different.  I can reliably replicate the #3709 runtime error in a desktop application where, in fact, the window that hosts the View3D is a Spark Window instance that is only opened from the main Spark WindowedApplication, on demand, thus deferring the appearance of the error to a point in time after the main AIR application is already correctly established.

I think the point of making that distinction is that it validates your fix.  First, as you noted, we can make the #3709 error ‘go away’ by forcing both the <depthAndStencil> parameter to false and modifying the Stage3D code to always set _enableDepthAndStencil to false as well.  But. a close look at the appearance of the objects in the view will show that something is amiss in the rendering.  Clearly, whatever that GPU functionality is, we want it.  We want it for the new class of mobile devices and we want it for the legacy desktop class of video cards.

So, if everything is configured as ‘true’, with trial and error, we can coerce the #3669 size error.  The BETA ASDocs for AIR3.2/Player11.2 have not been updated to provide descriptions of either the 3669 or the 3709 runtime errors, but the description of errors that might be thrown by Context3D.configureBackBuffer() clearly indicates that the width-height values are subject to some ‘minimum’ value.  Your decision to use 320x480 met that requirement.  I have found that 1x1 does not meet the requirement, but 100x100 does.

Perhaps the Away3d development team has access to documentation stemming from their NDA participation in the molehill program which gives a definitive answer to the question of what constitutes a minimally acceptable value.  I can confirm that initializing _backBufferWidth and _backBufferHeight to 100 is at least a valid workaround that has allowed me to upgrade my application from 3.1 and Away_Beta to 3.2 and Away_Beta.  Moreover, since Stage3DProxy was not touched in going from Alpha to Beta, I can confirm that the same change for anyone using 3.1 will not break anything.

-swf-version=13, does not trigger the Stage3D API for AIR Mobile??

With Away3D it’s not possible to use the -swf-version=15 for now? This is a bug for Away3D?

When I edit the Stage3DProxy like you said, I still get a slow fps…

Erik - 01 March 2012 07:25 PM

-swf-version=13, does not trigger the Stage3D API for AIR Mobile??

With Away3D it’s not possible to use the -swf-version=15 for now? This is a bug for Away3D?

according to release note you should use -swf-version=15. Some people reporting that it also works with 13. I do not know any processes which is done under the hood based on this number. It works with 15 for me. Not sure why to use 13.

Erik - 01 March 2012 07:25 PM

When I edit the Stage3DProxy like you said, I still get a slow fps…

Low values of fps is absolutely different questions. Obviously, it is based on a lot of parameters like, for example number of objects on the stage, amount of polygons, the power of your device etc etc. You should not expect the same values like on desktop.

Thanks!!! Works perfectly now… I had just too many objects for my phone GPU :/

I had similar issue, and nothing helped. Finally I noticed that I add to stage my Away3D class only after it is initiated. So reading the stage.stageWidth was undefined, and hence this error. Oh!

Following Flexincubator’s advice above, I got my app to stop having the stencil depth issue, but now I’m getting the following problem in RenderableMergeSort.as on line 74:

var aid : uint = head.renderOrderId;

The error is:

[Fault] exception, information=TypeError: Error #1009: Cannot access a property or method of a null object reference.

Which is really strange because I’m running it in the Flashdevelop debugger and none of the values are null.

I hear the sound from my game, but I only see a black screen.  I’m using one of the last builds of the alpha version of Away (haven’t tried this with Beta).  Could that be my problem?

I’ve exactly the same problem with Beta.

The debugger stuck on core.sort.RenderableMegerSort # 74
var aid : uint = head.renderOrderId;
but head is not null.

lechatpotte - 08 March 2012 10:38 AM

I’ve exactly the same problem with Beta.

The debugger stuck on core.sort.RenderableMegerSort # 74
var aid : uint = head.renderOrderId;
but head is not null.

There is a seperate thread with this error:
http://bit.ly/FP6mKj

( I use bit.ly url because the forum software is broken and won’t allow you to link to another topic :s)

FlexIncubator - 29 February 2012 06:53 PM

I have found another, maybe more correct solution.
Assuming that we have to use depthAndStencil=true, there is a need of setting some default values in Stage3DProxy. _enableDepthAndStencil should be set to true. What is important is to set some default _backBufferWidth and _backBufferHeight, for example 320 and 480. These values will be updated later in the code to use the size of your app.
Then we should set depthAndStencil to true in app descriptor xml.

Thanks you very much for your post!
I couldnt compile swf-version=15 without setting default values of backBuffer and enableDepthAndStencil.
(Use: sdk 4.6.0.23043 and air 3.2.0.2060 RC1)

marronnier - 22 March 2012 10:42 PM

FlexIncubator - 29 February 2012 06:53 PM

I have found another, maybe more correct solution.
Assuming that we have to use depthAndStencil=true, there is a need of setting some default values in Stage3DProxy. _enableDepthAndStencil should be set to true. What is important is to set some default _backBufferWidth and _backBufferHeight, for example 320 and 480. These values will be updated later in the code to use the size of your app.
Then we should set depthAndStencil to true in app descriptor xml.

Thanks you very much for your post!
I couldnt compile swf-version=15 without setting default values of backBuffer and enableDepthAndStencil.
(Use: sdk 4.6.0.23043 and air 3.2.0.2060 RC1)

Same solution worked for me, edited Stage3DProxy.as to hold following default values : EDIT : better use hyzhak’s solution in post #29

my application descriptor xml contains both tags

compiler settings contain

flex 4.6 sdk was updated with air 3.2 sdk and playerglobal.swc 11.2
http://www.flashdeveloper.co/post/20583114199/air32-in-flash-cs-55

thanks a lot!!!

Haha this used to happen to me on mobile devices, the fix was to wait a bit until initializing the view, I think its a good practice to put a small timing code that waits one millisecond before starting to initialize your app while using AIR 3.2 on mobile devices, it’ll save you some trouble.

i find that issue can be fixed without modifying Away3D Stage3DProxy code. Just by running view.render() after View() has created and added to stage. It’s look like a magic, but it’s works.

Nifty little bastard ... the force is strong within you ...

works ... even more elegant ... nice one!

note for others: you still need the depthAndStencil tag in the application descriptor and the swf-version in the compiler flags