One more commit to OpenFL, now bitmapData.draw supports colorTransform. I was worried because I did not see something in Cairo that would translate over, when I remembered, we have bitmapData.colorTransform support already, so I’m handling with an intermediate step, looks great
1 Like
Perfect. Thanks. So for having everything to work, do I just need to use openfl git version or do I also need to use lime git version too (did you performed all the changes into openfl source or does it affect lime too?)
EDIT: I just upgraded to openfl git version but I assume it is broken because I now have the error message:
C:/HaxeToolkit/haxe/lib/openfl/git/openfl/_internal/text/TextEngine.hx:173: characters 118-159 : openfl.text.Font has no field __fontPathWithoutDirectory
So I will just wait until the next public version of openfl, containing the fix, is puplished
If you don’t want to build Lime yourself (it’s not hard, it’s lime rebuild windows (etc) after a GIT recursive clone) you could try a recent Lime build here: http://www.openfl.org/builds/lime/
You can haxelib local path/to.zip to install a build, or haxelib dev lime path/to/git/clone to use a checkout 
Ok I will do this.
Rather than using git directly, I usually perform a “haxelib git lime https://github.com/openfl/lime.git”. I assume it is using the “git clone --recursive” command as I see info messages for a list of submodules beeing downloaded too
(
like:
Submodule path ‘project/lib/cairo’: checked out '2fd93965af0d7d55bc060a5b5108e4b1dfbb8a4e’
Cloning into ‘project/lib/curl’…
remote: Counting objects: 544, done.
remote: Total 544 (delta 0), reused 0 (delta 0), pack-reused 543
Receiving objects: 100% (544/544), 1.35 MiB | 859.00 KiB/s, done.
Resolving deltas: 100% (210/210), done.
Checking connectivity… done.
Submodule path ‘project/lib/curl’: checked out '7084474ab4eb76efa3ba1dc6eb4e407ae07a72ba’
Cloning into ‘project/lib/freetype’…
and so on…
)
Didn’t knew I had to perform a lime rebuild for each target platform though (thought would be done automatically the first time I call lime for a new target). Will do it ;).
When compiling with dev openfl and lime (git versions) I have this error:
Called from ApplicationMain::main ApplicationMain.hx line 146
Called from ApplicationMain::create ApplicationMain.hx line 59
Called from lime.app.Application::exec lime/app/Application.hx line 218
Called from lime._backend.native.NativeApplication::exec lime/_backend/native/NativeApplication.hx line 104
Called from lime._backend.native.NativeApplication::handleRenderEvent lime/_backend/native/NativeApplication.hx line 259
Called from lime.app.Event_Void_Void::dispatch lime/app/Event.hx line 139
Called from *::_Function_2_1 lime/app/Application.hx line 107
Called from lime.app.Application::render lime/app/Application.hx line 675
Called from openfl.display.Stage::render openfl/display/Stage.hx line 1074
Called from openfl.display.DisplayObjectContainer::__broadcast openfl/display/DisplayObjectContainer.hx line 645
Called from openfl.display.DisplayObject::__broadcast openfl/display/DisplayObject.hx line 967
Called from openfl.events.EventDispatcher::__dispatchEvent openfl/events/EventDispatcher.hx line 463
Called from flixel.FlxGame::onEnterFrame flixel/FlxGame.hx line 506
Called from flixel.FlxGame::draw flixel/FlxGame.hx line 808
Called from flixel.FlxCamera::render flixel/FlxCamera.hx line 401
Called from openfl.display.Tilesheet::drawTiles openfl/display/Tilesheet.hx line 194
Called from openfl.display.Graphics::drawTiles openfl/display/Graphics.hx line 856
with a “Null object reference” popup on windows. Don’t have any error when compiled with openfl 3.3.3 and lime 2.6.2. So just check you didn’t break anything in Graphics.hx…
I made some changes here yesterday that are still in-progress, try pulling from OpenFL one more time, I think I fixed what was causing this
OK. I performed the checkout and it works now.
One question I have concerning the getPixel() and getPixel32() methods. According to the openfl API, it is supposed to return UInt values: http://www.openfl.org/documentation/api/openfl/display/BitmapData.html
However, in the code source of openfl 3.3.3 and git version, it appears to return Int values. Is there a good reason for that?
Because as a consequence, doing some test like:
if (bitmapdata.getPixel32(x,y) == 0xFF000000)
results in an error when trying to compiled for flash:
Comparison of Int and UInt might lead to unexpected results
It works for cpp target though…
That’s caused by Flash returning UInt values, at one point, we forced all the UInt values in Flash to be Int values, so that we could avoid these types of headaches. I think this might work on Flash:
if (bitmapData.getPixel32 (x, y) == new UInt (0xFF000000))
1 Like
Text works for me only with -Dlegacy, otherwise even regular text (TextFieldType.DYNAMIC) field doesn’t show up.
And my test app crashes with -Dhybrid.
Are there any other dependencies, I might missed?
So “AddingText” and “PiratePig” show no text for you?
which version of lime and openfl are you using?
Can you prompt
haxelib list
in a console and copy the result here?
I’ve just reinstalled haxe and openfl/lime, everything is latest version.
actuate: [1.8.6]
box2d: [1.2.3]
extension-amazonads: [0.0.2]
extension-multiads: [1.0.2]
extension-share: [2.1.0]
format: [3.2.0]
hxcpp: [3.2.102]
layout: [1.2.1]
lime-samples: [2.6.0]
lime: [2.6.2]
openfl-admob: [1.4.1]
openfl-gps-lib: [1.0.4]
openfl-samples: [3.3.0]
openfl: [3.3.3]
roxlib: [1.1.3]
svg: [1.0.8]
swf: [2.0.2]
Give me 10 minutes, I’ll try AddingText and PiratePig.
Ok, AddingText works for me.
Looks like, font file and font-embeding are required with new OpenFL. Thank you!
And entering Cyrillic text is working now, a bit buggy, but working! 
I have some new issue with openfl next. This time, it concerns TextField.
Given the following code:
var randtext:String = "Facilisis nonummy vivamus faucibus, pretium augue tincidunt pede ac laoreet hendrerit, fermentum nibh in pede volutpat in sed, lacus sit ultrices felis, feugiat amet ac augue tellus blandit venenatis.\nAuctor vitae malesuada massa id dictumst, sollicitudin quis ut.";
var format:TextFormat = new TextFormat ("prototype_font", 26, 0xFFFFFF);
format.align = TextFormatAlign.CENTER;
var textField:TextField = new TextField();
textField.defaultTextFormat = format;
textField.width = 450;
textField.height = 700;
textField.wordWrap = true;
textField.text = randtext;
addChild(textField);
Here is what I get:
As you can see, line 5 is shifted to the right (whith the consequence of it beeing truncated).
This bug appears only on certain conditions. So if you change the font, the font size or the text content, it might or might not appear… (usually, if you test different font size with a multiline text content, you will see it appear for some of the font size tested)
The font used in this example is this one: http://www.1001freefonts.com/prototype.font in case you want to reproduce the issue
Got it 
1 Like
Still having this “word wrap” issue on android and windows with latest public versions of openfl (3.3.6) and lime (2.6.5).
It’s working here:
package;
import openfl.display.Sprite;
import openfl.text.TextField;
import openfl.text.TextFormat;
import openfl.text.TextFormatAlign;
class Main extends Sprite {
public function new () {
super ();
var randtext:String = "Facilisis nonummy vivamus faucibus, pretium augue tincidunt pede ac laoreet hendrerit, fermentum nibh in pede volutpat in sed, lacus sit ultrices felis, feugiat amet ac augue tellus blandit venenatis.\nAuctor vitae malesuada massa id dictumst, sollicitudin quis ut.";
var format:TextFormat = new TextFormat ("prototype_font", 26, 0xFF0000);
format.align = TextFormatAlign.CENTER;
var textField:TextField = new TextField();
textField.defaultTextFormat = format;
textField.width = 450;
textField.height = 700;
textField.wordWrap = true;
textField.text = randtext;
addChild(textField);
}
}
(before the above commit I did see it wrapping improperly like your screen)
Well I don’t really understand, I just retested it on windows (in order to make a screenshot) and now it works (but I tested it 1h ago with the exact same conf and it didn’t)…I probably forgot the -clean flag in my first command, which might explain. I don’t see any other explanation…
On android I still have the bug though (line 6):
I use the exact same code as you (exept the font color wich I set to black rather than red) with openfl next version 3.3.6 and lime 2.6.5
and I compiled with the lime test android -Dnext -clean command (the -Dnext flag is probably not necessary as I think openfl, unlike haxeflixel, use openfl next by default. Right?)
Oh and I tested with openfl legacy on windows and I don’t even have the textefield that display (full white screen)… without any error in the console: lime test windows -Dlegacy -clean -debug
I tried on Android and got an empty screen. I realized I was not using the right font name. I changed “prototype_font” to “Prototype” and now it looks correct on Windows and Android for me
well I have this in my project.xml file:
<assets path="Assets" rename="assets">
<font path="fonts/Prototype.ttf" id="prototype_font" />
</assets>
So using prototype_font as a name should be ok for me. right?
Whatever, on android it do not work as expected (word wrap issue) and on windows with openfl legacy, the text do not display (not tested on android with legacy yet)