[Solved] OpenGLView next to OpenFL Sprite


#1

Hi all,

TL;DR - I am having trouble adding a simple colored box sprite (graphics drawrect) to an openglview version of bunnymark. I can see either just the sprite, or the bunnies.

I have been messing about with other things for awhile in Haxe (pulling data from web apis, analyzing it etc) and must remark real quick, that the ease of use (httprequest, json parsing etc) is quite good. Anyways, I am wanting to make a game real ‘quick’ and find myself dabbling in the rendering side of things, and I am having trouble making something simple work. It is probably a foolish oversight on my part but after spending a couple days on it, I am reaching out.

This time around, I am going for cross platform - for both Windows desktop and HTML5 deployment.

I can get the Lime version of bunnymark visible on both. Switching to openfl (ie adding the library in project.xml) and converting glrenderer to sprite, with openglview (addchild) I have gotten to work for both targets.

The problem is when I try to create a new sprite, simple colored box, and add that to the stage, I can only see the colored box and no longer can see the openglview bunnies. This is occurring whether I add the sprite before or after adding the openglview to stage.

Also, I am using setviewport to only render the bunnies to the bottom left quarter of the screen, and then setting it back after render to whole screen. The sprite-colored-box is being added to the top of the screen. I am also making sure I clean up the gl code after, disabling the vertex attribs, use program null, and bindbuffer null

Unfortunately I cannot post code right now or build version numbers used (away from my home comp, but versions are updated from last week) but I will update later on today after a bit more fooling around. Does anyone have any ideas though?

Sidenote, maybe related - is the SimpleOpenGLView sample no longer working? I remember before being able to add a sprite to that without issue.

Thanks all, talk to you soon, hope the coding is going well! :slight_smile:


#2

What versions are you using? You may have to make sure that you reset your state before rendering as well (such as setting your shader), and make sure you render every frame.

The development version of OpenFL has a new API to replace OpenGLView, called RenderEvent. It’s dispatched from any object, and I’d be happy to work with more developers who interested in kicking tires and suggesting ways to improve it :slight_smile:


#3

I have resolved this (for both desktop and html targets) - I ended up rewriting a ton of it (the openglview webgl-related setup and implementation) and employing my webgl utility/boilerplate functions I have been building up since I started learning it (and converting some of those from dealing with a passed GLRenderContext to WebGLContext). Not sure what the ultimate fix was (as it is largely rewritten from scratch on my end) - but most likely it was related to one or more of the following, in order of descending likelihood:

(on the openglview side of things)

  • post render cleanup being needed (bindbuffer(gl.ARRAY_BUFFER, null), useprogram(null), etc to free things up for the OpenFL displayobject rendering system)
  • attribute variable activation, binding buffer, sending data to buffer, etc order of operations (for both init, and render loop)
  • There may have been a gl error or two that needed resolving as well (ie our favorite friends 1282 and 1281)
  • viewport resizing
  • something z or depth_test (depth buffer) related

Sorry I could not post a more clear solution (away from home desk, ie dayjob, and the code is very different anyways) but if anyone else comes across something similar, has checked the above things, and still needs help feel free to message me or bump this. If I have time I’ll strip it down back to bare (until it breaks) to see what it was, and post it here.


Re: the new paradigm - RenderEvent. Sounds interesting - I am guessing the usage is, an object lets the program know when it wants to be rendered? Likely on for every frame by default for things like bitmaps, sprites, etc if something in their ‘area’ has changed?

I am peeking at these during downtime right now, but which other files/methods should I check out?
openfl/lib/openfl/events/RenderEvent.hx
openfl/lib/openfl/display/DisplayObjectRenderer.hx
openfl/lib/openfl/display/OpenGLRenderer.hx

I would be down to test it out, but it has been so long since I have used display objects and things like that (just getting back into them, ie this initial issue/topic), that I am not sure that I would know what to look for as far as input, and I would be viewing through webgl lens, rather than most other OpenFL users (so if something is ‘hard’ or confusing, it probably would not bother me as much as it should, coming from pure webgl). A concern of mine would be how much support there would be for advanced webgl rendering techniques (some mentioned a couple paragraphs below).

As an aside, I still have to get up to speed with what has changed re Tilemaps /sheets etc (I am guessing some form of texture atlasing), and I’ve yet to check if for example the aforementioned and/or bitmaps/bitmapdatas have the ability for their own custom shaders or programs (but I am not sure how I would then be able to supply shader specific data such as uniforms, attribute vars, etc). Before diving into webgl, I was a hardcore bitmapdata blitter (which started back when I wrote AS3, as the performance was to die for), and as time went on I found myself wanting to do more custom things, effects, etc to the pixels. In hindsight, that rabbit hole was a helluva lot deeper than I ever imagined.

I am at the point where, rendering wise I can now do what I want to do, by using from scratch webgl. For example customized/intermediate lighting shaders, normal mapping / using multiple textures as inputs in a fragment shader for a given ‘sprite’, fbos, deferred shading, etc.

But for everything else (UI overlay, text, buttons, key/mouse input, sound, etc) I would rather use openfl than reinvent the wheel for em (as they work how I want them to, at least until I get crazy ideas about those - jk). Its been a wild ride, but far worth it.

Thanks for everything that you and the others do to make it all possible!


#4

Check out the Twitch stream from yesterday for both the OpenFL 8 announcement and a workshop going through some advanced topics, including and custom rendering’’


#5

The openfl part in the second video starts at 02:22:16