Away3D html5 target runtime errors with Lime

Lime
#1

Not sure how to approach this - I have Haxe projects that no longer work in html5, but did previously.

For example, my OpenFL Away3D Terrain Demo at GitHub runs in Flash, but not html5. However, the html5 target was previously operational, which a previous html5 build is available for demo.

This project now builds, but throws a runtime error from Lime:

Uncaught TypeError: Cannot read property 'getParameter' of undefined
    at openfl_display3D_Context3D [as __class__] (Away3dTerrainExample.js:73732)
    at openfl_display_Stage3D.__createContext (Away3dTerrainExample.js:73411)
    at openfl_display_Stage3D.__renderDOM (Away3dTerrainExample.js:73458)
    at openfl__$internal_renderer_dom_DOMRenderer.clear (Away3dTerrainExample.js:62771)
    at openfl_display_Stage.render (Away3dTerrainExample.js:72336)
    at f (Away3dTerrainExample.js:84029)
    at Array.tmp (Away3dTerrainExample.js:71754)
    at lime_app__$Event_$Void_$Void.dispatch (Away3dTerrainExample.js:37119)
    at lime__$backend_html5_HTML5Application.handleApplicationEvent (Away3dTerrainExample.js:31288)
    at f (Away3dTerrainExample.js:84029)

This is the Lime operation that throws the error:

this.maxBackBufferHeight = this.maxBackBufferWidth = lime_graphics_opengl_GL.context.__context.getParameter(3386);

Likewise, my OpenFL Away3D Actuate Demo builds, runs perfectly fine as Flash, but brutally freezes my Chrome browser at runtime.

I guess my questions are:

  • Is there an update to Away3D / OpenFL graphics Iā€™m missing?
  • Without diving deep into Lime, any recommendation for debugging?

Haxelib versions:
actuate: [1.8.7]
away3d: 5.0.0 [5.0.1]
box2d: [1.2.3]
format: [3.3.0]
hxcpp: 3.4.49 [3.4.64]
layout: [1.2.1]
lime-samples: 3.4.0 [4.0.0]
lime: 3.7.4 [4.0.1]
openfl-samples: 4.7.0 [4.9.0]
openfl: 4.8.1 [4.9.1]

#2

Try building without the ā€˜domā€™ haxedef flag in your project.xml. Away3d primarily targets webgl now for html5 so DOM might not be as well tested - clearly it isnā€™t :wink:

#3

@Greg209, thanks - removing the ā€˜domā€™ haxedef flag gives me one frame, but then locks Chrome or Safari browser to the point I have to force quit.

Anything else look suspect in my project.xml?

<?xml version="1.0" encoding="utf-8"?>
<project>

    <meta title="Away3dActuateDemo" package="com.sample.project" version="1.0.0" company="Company Name"/>
    <app main="Main" path="Export" file="Away3dActuateDemo"/>

    <source path="Source"/>

    <haxelib name="format" if="html5"/>
    <haxelib name="away3d"/>
    <haxelib name="openfl"/>
    <haxelib name="actuate"/>

    <haxedef name="source-map-content" if="html5"/>

    <haxeflag name="-swf-version" value="11.3"/>

    <assets path="Assets" rename="assets"/>
    <icon path="Assets/openfl.svg"/>

    <window width="1024" height="700" if="desktop"/>
    <window width="0" height="0" if="html5"/>
    <window orientation="landscape" vsync="true" if="cpp"/>
    <window fps="60" hardware="true" allow-shaders="true" require-shaders="true" depth-buffer="true"
            stencil-buffer="true" background="#000000"/>

</project>

Though Flash target works for both projects, both fail in html5. Actuage fails in C++, but the terrain demo is functional in C++.

#4

I just cloned https://github.com/jasonsturges/openfl-away3d-terrain-demo and gave your sample a try, it worked on HTML5 for me (though there was a long delay before it began rendering)

After running a profiler, I was able to spot a performance regression in the updated OpenGL bindings. On Chrome, checking if (data == 0) was VERY expensive ā€“ almost 80% of the processing time (!) was spent on this check.

A quick bit of untyped JavaScript code on this made a big, big difference

Give it a try and try your sample again.

We have invested in Stage3D support in OpenFL, as well as improved Away3D and Away3D sample consistency with the original sample. For example, we have the original Stage3D ā€œTerrainDemoā€ running now :wink:

2 Likes
#5

Josh, really appreciate that - I guess Iā€™ve had tunnel vision on my Actuate demo, which after 5-minutes is still frozen to the point that I cannot bring up the inspector.

MacBook Pro, 2.4 GHz Intel Core i7, 8 GB RAM, NVIDIA GeForce GT 650 M 1024 MB video.

C++ target also appears frozen for that target, after the first frame.

Thanks for taking a look.

#6

It appears to be something with my RandomTimer class. Though functional in Flash, it chokes on html5 and C++ targets. If I replace the RandomTimer with a openfl.utils.Timer, it works fine.

If I can isolate the issue, Iā€™ll report back.

Thanks @Greg209 for the ā€˜domā€™ haxedef flag in the project.xml, and @singmajesty for the lime optimization.

#7

Wow @singmajesty thatā€™s really quite scaryā€¦ whatā€™s it trying to do?

Really nasty if things like that can choke the browser.

#8

Iā€™m handling WebGL overrides, which means some dynamic data types. When I checked for 0, it appears to removed optimizations in the browser, since it thought the value was an object, and suddenly Iā€™m comparing to a number.

Itā€™s bizarre, but just checking for false resolves the issue, and makes a significant difference

Since Lime 4 doesnā€™t pass through directly to the WebGL rendering context, weā€™ll need to keep our eyes open to any possible issues like this in our bindings while weā€™re testing HTML5 :slight_smile: