Feeling stuck -- problems with new and old versions of OpenFL. Advice?

Help
#1

Once again I’m finding myself feeling quite lost in trying to understand the state of OpenFL and Lime development, and could use some help or pointers.

For the record, I’m developing a 2D puzzle game. It’s almost entirely vector graphics, so I’m relying heavily on the old Flash API for drawing paths and text.

With the latest versions of OpenFL and Lime, my game is basically unplayable:

  • My layout depends on knowing the screen DPI, which is currently unavailable
  • Filters don’t seem to be working
  • Text rendering quality is poor in places (possibly because of filters)
  • Text layout with embedded HTML doesn’t work
  • My event handling no longer works (using code that worked fine in previous releases)
  • Transparency looks very different
  • My app crashes on startup in iOS (in lime::font::getAscender?)

I can sort of muddle through with -Dlegacy, but there still seem to be problems with DPI, and this mode doesn’t work in neko mode on my retina display (the graphics are squeezed into the bottom-left quadrant of the screen, but events still come from the whole screen). To summarize, I’m currently feeling a bit… forsaken by Haxe/Lime/OpenFL, projects that I’d really like to support.

I’m not a full-time software developer, so I’m hoping for a relatively painless way to get unstuck. Should I persist with the newest OpenFL, expecting things to stabilize very soon? Should I wait for a fix to legacy mode? Or should I downgrade to earlier versions of OpenFL and Lime? Generally speaking, how can I keep track of what features should be working and what’s currently being repaired?

Thanks for any help or advice.

Mouse events now being received by entire bounding box of paths?
#2
  • Instead of DPI, why not scale based on screen dimensions?
  • A few people have been reporting filter issues. Joshua is working on this for the non-legacy branch.
  • Text rendering was totally broken on the new branch until a month or two ago. Not sure if it’s caught up to the legacy version yet.
  • Text rendering is hard in general. I wouldn’t hold my breath for html rendering, but depending on your needs, you may be able to work around it using setTextFormat().
  • Can you show us some sample code?
  • How so?
  • Check and see if it’s related to the font you’re using. If you add that font to the AddingText sample, does it still crash?

The newest version is stabilizing very slowly. Each bug report helps, but it will take a while more. I think legacy mode is your best bet at the moment.

#3

Thanks for the feedback, player_03. I fear that the nature of my post will force us to run six separate conversations in each message, but I’ll persist for now…

  • I like your library (thanks!!), but I don’t see how it helps me achieve all my goals. If I want, say, a circular button of diameter 1cm on all devices (or really, any other real-world physical measurement), don’t I need to know the stage resolution and the pixel density?

  • Regarding text formatting, I’m currently using multiple text sizes, stylings and colours within a single text field, so I don’t think I can hack it using just setTextFormat(). What’s the best practice here? Do people bake their text into images? Here’s a comparison of -Dlegacy (above) with the current OpenFL (below). (Note that you can also see a difference in transparency.)

  • Regarding handling of mouse events, please see my other post from yesterday. As far as I can tell, mouse events used to be received when the mouse interacted with drawn paths in a sprite. Now it looks like sprites are using the entire bounding box of all those paths as the hot region? I find it hard to believe, but the sample code in that other post seems to demonstrate the difference. I’d love to figure out what’s going on here.

  • Regarding transparency, it seems to me that transparent paths are more grey and washed out in the newest OpenFL, as in the example above. But I couldn’t isolate that difference in a quick test, so it’s possible there’s something else in my code that causes the difference between OpenFL versions. I’ll have to investigate further.

I guess the moral of the story is that because of the cluster of features I’m using, I had better stick with -Dlegacy for the time being. In that case, can I ask for a fix for my retina display? There’s a short discussion of the issue here.

#4

Hi @isohedral, thanks for laying this out :smile:

Screen DPI

-Dlegacy does have Capabilities.screenDPI implemented, the intention is for Lime to have a full suite of APIs to get information about A) connected displays, B) supported resolutions, C) screen density and other details helpful for multi-window applications.

This hasn’t happened in Lime 2 quite yet, so the new API in OpenFL does not have a place to hook back into for getting screen density, yet. As the above unfolds this is definitely planned.

Filters

In -Dlegacy, a few filters are supported, using a software renderer pass. The goal is for the new OpenFL to allow custom shader support. With this, I would like to see filters implemented as hardware shader effects, so that glow, blur (and other effects) can use hardware acceleration. In the meantime, only a few (like ColorMatrixFilter) are available in the HTML5 target

Text

The TextField in -Dlegacy is broken – key pieces of functionality (such as being able to support complex language layout) are not supported at all. Also, it’s a totally different implementation than what we have for HTML5 or other non-C++ targets (Lime 2 and OpenFL even compile to Node.js or Java, or we could C#, there’s a lot of options) so I’m keen on an implementation we can share on all our OpenFL targets, so we can get TextField nailed, and get it right once instead of re-implementing!

We got Cairo rendering hooked for better shape rendering, and switched the TextField to use Cairo recently for better memory and better performance, but I noticed some tweaks that it needs for better rendering accuracy on text. I’m hoping this will happen soon – there is a drawTiles implementation that looks more correct, but because the text rendering is still evolving, some things (such as htmlText support) require a bit more development.

Shape Flag

I mentioned in the other post, that the hit testing appears to be the difference between a “shape flag” or not. We’ll have to look into whether there’s a fast method to use Cairo to detect this on shapes.

UPDATE: It seems it does, it looks there is inFill (x, y) to detect if a point is inside a fill, perhaps we can adapt this somehow and make the hit test a little more nuanced

Transparency

We use pre-multiplied alpha, supporting hardware blending modes (like ADD or MULTIPLY modes) and fixing “dirty” blending problems inherent in -Dlegacy, there was a bug with some Cairo surfaces where it was premultiplied twice, which would explain a darker appearance. This is in the dev repository and will go out when we’re ready for another release

Font

Related to the text work, the Font support in the newer code, is, well, newer, so perhaps there’s an edge case there we haven’t handled, but using “AddingText” and changing fonts is a great start as @player_03 mentioned

Does anyone else have the same problem you have on -Dlegacy iOS?

#5

Thank you right back, @singmajesty, for taking the time for such a comprehensive reply. It warms the heart.

As a preamble, it’s pretty clear from the answers I’ve already received that I need to stick with legacy for now. Happily, that will put all my woes on the back burner except for one, the rendering problems associated with my retina display. Fortunately that’s an inconvenience but hardly a showstopper (as is the difficulty of launching the iPad simulator from the command line).

DPI

I look forward to seeing comprehensive device information, including DPI, available in Lime. In the meantime, are there best practices in OpenFL for developing interfaces that adapt naturally to different screen sizes? It’s a nasty problem, and every app probably requires a custom solution, but general advice from experienced app developers would be welcome.

Filters

I think I’m using only glow and blur filters, which work just fine in legacy. Moving this stuff to shaders will be fantastic. I noticed that full-screen Gaussian blur is reasonable on iOS but super slow on Android, for reasons that I haven’t looked into yet.

Text

The legacy TextField seems to work well enough for my needs, so no worries. Still, I think it’s very important that you’re moving in the direction of richer text support in Lime. I was disappointed by (lack of) font metrics in OpenFL, but I attribute that more to the original goal of emulating the Flash API than anything else. Font handling in Cairo (or rather, Pango?) is excellent, so I hope we’ll see a lot more functionality.

Shape Flag

Fortunately, I can ignore this deficiency in the current OpenFL by sticking with legacy. But yes, I consider this kind of hit testing to be important (am I really the only one?). I can implement hit testing manually if need be, and for my current app it wouldn’t be too hard, but it belongs in the API.

Transparency

Aha, double-multiplying the alpha is a perfect explanation for what I’m seeing. I look forward to the fix (but again, it’s not urgent at this point).

Font

Let me see if I can isolate the bug. If so, I’ll send it in on github. But I think it only crashes in iOS, not neko, which is even more suspicious. Maybe I’m misreading the stack trace in XCode (it’s going through some kind of cffi dispatch in the ExternalPrimitive class, which makes tracing a bit hard).

Retina display

I assume when you say “Does anyone else have the same problem you have”, you’re referring to the fact that on a retina display, all OpenFL programs are half-size, stuck to the bottom-left of the window. This isn’t confined to iOS – it happens with mac and neko targets too. It definitely seems related to the retina display. Most explicit evidence: when I plug the same laptop into an external monitor and run the app there, the problem disappears. See also the link to the github discussion at the end of my previous post in this thread.

Thanks again.

#6

Hi. I have a related question: What is the difference of using DrawTiles with TILE_TRANS_2x2 in legacy? The sprites seem to be placed in different place and from a different position in the texture. Thanks.

#7

It seems that the problem is because I am re-utilizing the arrays