SimpleOpenGLView crashes via Neko

#1

When running the latest versions of OpenFL / lime (2.1.5 / 2.0.0-alpha.8 respectively), the SimpleOpenGLView sample crashes when building using Neko, but not when building using CPP.

I’ve tracked the issue down to these two lines, as commenting only them out allows the program to run successfully on Neko:

GL.uniformMatrix4fv (projectionMatrixUniform, false, new Float32Array (projectionMatrix.rawData));
GL.uniformMatrix4fv (modelViewMatrixUniform, false, new Float32Array (modelViewMatrix.rawData));

Having the same issue with my own game.

#2

I think something was changed within the NME / Lime “legacy” codebase, which may cause the crash on Neko. I wish I knew off-hand what was causing this. Last I tested, this was working properly when running with the new Lime “next” codebase, and used to work before.

Would you mind opening an issue for this on GitHub, and I’ll try and take another look at it? Thank you! :blush:

#3

Okay, you can safely ignore this post.

I didn’t think the -Dnext flag was necessary anymore, but now I see in the 2.1 blog post that it still is. My bad.

I thought I had tried it with the flag before, but may have used a lowercase d.

Also didn’t think the flag was necessary since I was getting other crashes in my own game that were pointing to the _v2 folder without using the flag.

Edit: And now I realize that the _v2 folder is the older version of OpenFL. I thought the _v2 meant that it contained the latest 2.0+ changes in it, but it does not apparently. Bit misleading.

#4

Yeah, struggled to decide what to call it, it is “v2” for OpenFL 2, as opposed to when we may move to the next entirely, maybe when we go to version 3

#5

Ah, okay… So if I understand correctly, OpenFL Next is being developed in the root openfl folder and when fully ready will be OpenFL 3.0 (or similar), and the current OpenFL 2.0+ version is being maintained in the openfl/_v2 folder.

Guess I just got too excited when I read the first line of the OpenFL 2.1 blog post (“The next version of OpenFL is now final.”) and thought that “next” meant Next and may have went straight to upgrading without reading the second paragraph, haha…

#6

Pretty much. Flash and HTML5 already use the “next” code, but for native, we still have enough things to finish that we aren’t pulling the gun just yet. Some projects will work fine for “next” on native already, but for others, we still need to add areas to the new renderer, platform support, etc, so this was all a solution so that we could all be on the same “page” together, even as the new codebase takes more time to develop, rather than perpetually having a divide between the new code and the older code people are still using :slight_smile:

#7

I found the issue – it’s because on Neko it uses the “VectorData” type, which is neither a ByteArray nor an Array. I’ve just made fixes in the “openfl” repository, so Neko (using -Dnext or not) should work in the next release :slight_smile: