OpenFL -Dnext building fails because ByteArray.hx can't find cpp.NativeArray

singmajesty · May 14, 2015, 11:41pm

Just implemented support for lower frame-rates, so we can knock that off the list

cactusanctuary · May 15, 2015, 6:45pm

@singmajesty I ran into an issue. The legacy SharedObject uses these two classes:
sys.FileSystem;
sys.io.File;

However, I have no idea where they are. I looked in the openfl as well as lime packages but can’t find any sys namespace, and it’s not located in root of haxelib either. A hint?

ibilon · May 15, 2015, 6:52pm

These are haxe standard library classes,
http://api.haxe.org/sys/FileSystem.html

github.com

HaxeFoundation/haxe/blob/development/std/neko/_std/sys/FileSystem.hx

/*
 * Copyright (C)2005-2018 Haxe Foundation
 *
 * Permission is hereby granted, free of charge, to any person obtaining a
 * copy of this software and associated documentation files (the "Software"),
 * to deal in the Software without restriction, including without limitation
 * the rights to use, copy, modify, merge, publish, distribute, sublicense,
 * and/or sell copies of the Software, and to permit persons to whom the
 * Software is furnished to do so, subject to the following conditions:
 *
 * The above copyright notice and this permission notice shall be included in
 * all copies or substantial portions of the Software.
 *
 * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
 * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
 * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
 * DEALINGS IN THE SOFTWARE.

This file has been truncated. show original

cactusanctuary · May 15, 2015, 7:03pm

Thanks ibilon!

Just downloaded OpenFL 3.0.6 and there are some changes where instead of using sys.io.File, it’s using openfl.filesystem.File. I’ll continue with that.

singmajesty · May 15, 2015, 7:22pm

sys.io.File sounds right, you just need to #if sys #end around the import, so it doesn’t break Flash or HTML5 compilation

cactusanctuary · May 15, 2015, 7:52pm

What, but it complained that sys.io.File didn’t have the property applicationStorageDirectory! Which indeed it doesn’t. So we do need a separate openfl.filesystem.File, which I’ve copied over from _legacy.

I’m trying to build it now to see if loading the shared object works. But I’m having some issues with my dev environment. I forked openfl, then set up the local repository in my /usr/lib/haxe/lib/openfl, so I have it in a folder named dev, right next to my 3,0,6. I thought I could haxelib set openfl dev but then when I try to run openfl test mac, it fails: “Error: Could not find haxelib “openfl”, does it need to be installed?” I get the same result just by running openfl in Terminal. Is there any guide on setting up for contributing?

ibilon · May 15, 2015, 7:58pm

applicationStorageDirectory can be found in lime.system.System http://docs.openfl.org/lime/system/System.html

Maybe doing a haxelib dev openfl dev would work better.

singmajesty · May 15, 2015, 8:49pm

I’ve also just done an initial implementation of the GameInput API

cactusanctuary · May 15, 2015, 10:08pm

Thanks ibilon, I’m a noob! I’m now properly set up with dev environment

lime.system.System.applicationStorageDirectory is a string, while openfl.filesystem.File.applicationStorageDirectory is a File instance. The file instance’s nativePath is what is used in legacy, but there’s an inconsistency:

System.applicationStorageDirectory -> /Users/x/Library/Application Support/Xavier Stamps-Lafont/TheMission/
File.applicationStorageDirectory. nativePath -> /Users/x/Library/Application Support/TheMission

So System uses the company attribute from the project.xml meta element and the title attribute to form the path, while File only uses the title attribute. I’m finding it in Lime, but a bit shaky about modifying it since I don’t know what all the implications are…

cactusanctuary · May 15, 2015, 10:15pm

Should the application storage use the company/title in the path, or just the title?? I would think the title, both because it’s a bit clearer file structure, and because it would maintain backwards compatibility. But probably it’s a call for @singmajesty

singmajesty · May 15, 2015, 11:12pm

Currently using this C++ code (with SDL2) to get the storage path:

github.com

openfl/lime/blob/master/project/src/backend/sdl/SDLSystem.cpp#L47-L50


	static int id_refreshRate;
	static int id_supportedModes;
	static int id_width;
	static bool init = false;

I suppose we could test and see what happens if the company is set to an empty string, to see if it matches. I wonder, though, how it compares on mobile

cactusanctuary · May 16, 2015, 10:36am

Hey I got it to load my shared object data!

For testing it, I changed this:

github.com

openfl/lime/blob/master/lime/system/System.hx#L493


				
			}
			
			return Reflect.getProperty (Type.resolveClass ("flash.filesystem.File"), propertyName).nativePath;
			
		}
		
		#end
		
		return null;
		
	}
	
	
	private static function __registerEntryPoint (projectName:String, entryPoint:Function, config:Config):Void {
		
		if (__applicationConfig == null) {
			
			__applicationConfig = new Map ();
			
		}

To:
return lime_system_get_directory (SystemDirectory.APPLICATION_STORAGE, “”, file);

And that loaded fine. The path ended up being like /Users/x/Library/Application Support//TheMission///ControlsConfig.sol but the extra / are ignored.

I’m not sure about mobile. I can’t spend much time on this, if it’s fine to just get it working on desktop (assuming it’s consistent across Mac/Windows/Linux?) and make a pull request for that, then somebody else can resume for other platforms.

Also, are there unit tests for these?

singmajesty · May 17, 2015, 4:22am

That’s fine, get it working for desktop (perhaps #if desktop on the Lime change) and send over the pull requests. We can always continue to tune things as we go

cactusanctuary · May 18, 2015, 9:57pm

Hmm I donno if it’s that simple, the conditional in the Lime change. Currently it’s like this:

github.com

openfl/lime/blob/master/lime/system/System.hx#L492


				default: "userDirectory";
				
			}
			
			return Reflect.getProperty (Type.resolveClass ("flash.filesystem.File"), propertyName).nativePath;
			
		}
		
		#end
		
		return null;
		
	}
	
	
	private static function __registerEntryPoint (projectName:String, entryPoint:Function, config:Config):Void {
		
		if (__applicationConfig == null) {
			
			__applicationConfig = new Map ();

Does desktop target mean cpp and neko only? I can’t seem to find the conditional compiling documentation on OpenFL anymore.

singmajesty · May 18, 2015, 9:59pm

That’s fine, I forget, I thought #if desktop was defined, but honestly we should have an #if cffi or perhaps we should consider using #if sys for these

singmajesty · May 18, 2015, 10:00pm

Oh, I meant #if desktop because I’m not sure this applies to mobile, for example:

lime_system_get_directory (SystemDirectory.APPLICATION_STORAGE, #if desktop "" #else company #end, file);

cactusanctuary · May 25, 2015, 4:58pm

Hm I’m still not sure what conditions to use. It’s odd to have this:

#if (cpp || neko || nodejs)
return lime_system_get_directory (SystemDirectory.APPLICATION_STORAGE, #if desktop "" #else company #end, file);
#else
return null;
#end

It’s odd to have these conditionals within each other, also makes it difficult to read the code. I’d rather:

#if (desktop)
return lime_system_get_directory (SystemDirectory.APPLICATION_STORAGE, "", file);
#elseif (nodejs || ?????)
return lime_system_get_directory (SystemDirectory.APPLICATION_STORAGE, company, file);
#else 
return null;
#end

Isn’t there documentation for what all conditionals there are?

singmajesty · May 26, 2015, 9:00pm

You could do the latter if you want, keep it as #elseif cpp || nodejs

cactusanctuary · June 12, 2015, 5:31pm

Sorry about the really late response, been very busy recently.

I updated to latest Lime and OpenFL so that I could continue on this SharedObject stuff, but now have some other issues.

Primarily the text is placed differently, which is very odd. It seems the actual TextFields are placed at double the x and y values that are set, and maybe the width and height are also reported as double what they used to be in -Dlegacy. I get these traces when compiling:

Could not find primitive lime_cairo_set_font_face__2.
Could not find primitive lime_cairo_set_font_size__2.
Could not find primitive lime_cairo_set_font_options__2.
Could not find primitive lime_cairo_get_font_options__1.
Could not find primitive lime_cairo_show_text__2.
Could not find primitive lime_cairo_rotate__2.
Could not find primitive lime_cairo_scale__3.
Could not find primitive lime_cairo_ft_font_face_create_for_ft_face__2.
Could not find primitive lime_cairo_font_face_destroy__1.
Could not find primitive lime_cairo_font_options_create__0.
Could not find primitive lime_cairo_font_options_get_antialias__1.
Could not find primitive lime_cairo_font_options_get_subpixel_order__1.
Could not find primitive lime_cairo_font_options_get_hint_style__1.
Could not find primitive lime_cairo_font_options_get_hint_metrics__1.
Could not find primitive lime_cairo_font_options_set_antialias__2.
Could not find primitive lime_cairo_font_options_set_subpixel_order__2.
Could not find primitive lime_cairo_font_options_set_hint_style__2.
Could not find primitive lime_cairo_font_options_set_hint_metrics__2.
Could not find primitive lime_buffer_get_native_pointer__1.

Do I have to rebuild something for the text to work properly?

The other issue I already mentioned earlier in this post, my input layer isn’t working properly, I’ll look into that.

singmajesty · June 12, 2015, 6:38pm

Are you using source? If so, make sure you git submodule init && git submodule update and rebuild

Or try a newer version, your error looks like something that was fixed