openfl / lime

A foundational Haxe framework for cross-platform development

Lime

Lime is a flexible, lightweight layer for Haxe cross-platform developers.

Lime supports native, Flash and HTML5 targets with unified support for:

• Windowing
• Input
• Events
• Audio
• Render contexts
• Network access
• Assets

Lime does not include a renderer, but exposes the current context:

• Cairo
• Canvas
• DOM
• Flash
• GL

The GL context is based upon the WebGL standard, implemented for both OpenGL and OpenGL ES as needed.

Lime provides a unified audio API, but also provides access to OpenAL for advanced audio on native targets.

License

Lime is free, open-source software under the MIT license.

Installation

First install the latest version of Haxe.

Development Builds

When there are changes, Lime is built nightly. Builds are available for download here.

To install a development build, use the "haxelib local" command:

haxelib local lime-haxelib.zip

Building from Source

Clone the Lime repository, as well as the submodules:

git clone --recursive https://github.com/openfl/lime

Tell haxelib where your development copy of Lime is installed:

haxelib dev lime lime

The first time you run the "lime" command, it will attempt to build the Lime standard binary for your desktop platform as the command-line tools. To build these manually, use the following command (using "mac" or "linux" if appropriate):

haxelib install format
haxelib install hxp
lime rebuild windows

You can build additional binaries, or rebuild binaries after making changes, using "lime rebuild":

lime rebuild windows
lime rebuild linux -64 -release -clean

You can also rebuild the tools if you make changes to them:

lime rebuild tools

On a Windows machine, you should have Microsoft Visual Studio C++ (Express is just fine) installed. You will need Xcode on a Mac. To build on a Linux machine, you may need the following packages (or similar):

sudo apt-get install libgl1-mesa-dev libglu1-mesa-dev g++ g++-multilib gcc-multilib libasound2-dev libx11-dev libxext-dev libxi-dev libxrandr-dev libxinerama-dev

To switch away from a source build, use:

haxelib dev lime

Sample

You can build a sample Lime project with the following commands:

lime create HelloWorld
cd HelloWorld
lime test neko

You can also list other projects that are available using "lime create".

Targets

Lime currently supports the following targets:

lime test windows
lime test mac
lime test linux
lime test android
lime test ios
lime test html5
lime test flash
lime test air
lime test neko
lime test hl

Desktop builds are currently designed to be built on the same host OS

lime's Issues

Unresolved symbols for emscripten target

Ran into this problem on a previous project, then tried it in the default OpenFL project template. After compiling the OpenFL libraries for emscripten and upon compilation of the main js file, I get the following warnings:

...which turn into errors in the js console:

Any ideas? Would appreciate any help!

Lime cannot take framebuffer of main screen in iOS.

Like openfl/openfl-native#137, I cannot get main screen's framebuffer in iOS. Because I cannot use GL_FRAMEBUFFER_BINDING.

Continue cleanup of C++ code

Everyone has their own opinion about code style, and what leads to the best workflow, but as a matter of standards, I think it would be best to refactor the C++ project code (over time) to confirm to a single class, with its own header, per file. This additional structure may make it harder to perform sweeping changes within the codebase, but it should make it simpler to maintain, and hopefully lead to less mistakes, and cleaner/clearer pull requests.

Question: NME search

I just did a quick search to see how nme is/may still be in use. I thought lime was a complete fork and next evolution of nme, basically nme > lime. But I still see a few references to nme hanging around https://github.com/openfl/lime/search?q=nme

Are these mostly dead files?

Tried to rebuild tools and failed

Hi,

Maybe I'm doing something wrong, but where is lime.ndll?
I trie to rebuild tools and got following errors:

zerg@rush ~/src $ openfl rebuild tools
Warning: Source path "/usr/lib/haxe/lib/lime/git/ndll/Windows/lime.ndll" does not exist
Warning: Source path "/usr/lib/haxe/lib/lime/git/ndll/Mac/lime.ndll" does not exist
Warning: Source path "/usr/lib/haxe/lib/lime/git/ndll/Mac64/lime.ndll" does not exist

If I tried to test project I got:

zerg@rush ~/src/openfl-extension/T $ openfl test android -debug
Called from flash/utils/ByteArray.hx line 717
Called from flash/Lib.hx line 233
Called from flash/Lib.hx line 308
Called from flash/Lib.hx line 180
Called from /usr/lib/haxe/std/neko/Lib.hx line 30
Uncaught exception - load.c(237) : Failed to load library : lime.ndll (lime.ndll: cannot open shared object file: No such file or directory)

haxelib run openfl setup also not work:

zerg@rush ~/src $ haxelib run openfl setup
Called from flash/utils/ByteArray.hx line 717
Called from flash/Lib.hx line 233
Called from flash/Lib.hx line 308
Called from flash/Lib.hx line 180
Called from /usr/lib/haxe/std/neko/Lib.hx line 30
Uncaught exception - load.c(237) : Failed to load library : lime.ndll (lime.ndll: cannot open shared object file: No such file or directory)

Dynamic sound not working properly on native targets.

To demonstrate the problem, I have created this example project https://github.com/PaulGene/PitchShiftingSound

Flash: everything works as expected.

Windows: Works most of the time but sometimes SampleDataEvent.SAMPLE_DATA stops being fired when lime_sound_channel_needs_data(__handle); returns false at https://github.com/openfl/openfl-native/blob/master/flash/media/SoundChannel.hx#L114

Antroid: SampleDataEvent.SAMPLE_DATA gets fired about 3 times then we have the same problem as Windows, lime_sound_channel_needs_data(__handle); returns false at https://github.com/openfl/openfl-native/blob/master/flash/media/SoundChannel.hx#L114

iOS: lime_sound_channel_create_dynamic(request.data, soundTransform); always returns null at https://github.com/openfl/openfl-native/blob/master/flash/media/Sound.hx#L186

Evolve the joystick API

I believe we should have a higher level gamepad API, that works above the existing joystick events.

Rather than subscribing to be notified when a device hits a certain key, this API should allow for profiles in order to translate events into buttons, and (ideally) should allow polling, if you wish to see which controllers are connected, listen to specific controllers only, at any point in time, check the state of a particular controller, etc.

Partially this will require implementation in Lime, and will also require new APIs to manage it either at a Lime level or in OpenFL.

Support multiple windows

Antialiasing causing crash on Intel GMA graphics cards

I've been getting reports of my game crashing on startup on lower end Intel cards. After some investigation this turns out to be due to the fact that I'm using MSAA.

These cards do not support AA at all, so not having it there isn't a big deal. But, as far as I can tell there's no way for me to fix this short of distributing two different versions of the game executable.

The ideal behavior here would be falling back to a surface without AA if it's not supported. Having a runtime argument to supply to the program to disable AA would probably be easier to implement, but not as practical for end users.

I'll look into adding the fallback myself, but I'm creating this Issue just to have a place to discuss it.

TextFields and Drawing API causing crashes on nvida cards under windows

I have discovered a rare but reproducible issue that seems to relate to TextFields. I had testers experiencing crashy behaviour from my game once they'd played for a while and after much digging I found the issue and wrote this small test to reproduce it:

https://gist.github.com/grapefrukt/8409627

Basically, by drawing enough rectangles (in this test >489) the game will crash inside nvoglnt.dll (I only have access to XP computers with nvidia graphics). If I comment out the line creating the TextField, it will run well past 10.000 rectangles. Padding the TextField with more characters will make it crash sooner.

The debugger claims the error is thrown on this line: https://github.com/openfl/lime/blob/master/project/src/renderer/opengl/OpenGLContext.cpp?source=c#L541

So, it's reasonable to suspect something goes wrong with that nearby glDrawArrays call.

XP is an old OS, but it's still used by a large number of users, so I feel this might be worth looking into. Especially since everything else works so well.

I can also provide crash dumps of this error if need be.

Memory leaks related to FreeType (iOS target)

I found the issue if we scale a text field with a free type font we have the memory leaks. It seems that we have memory leaks every time we change the font of a text field.

I create a mini project to demonstrate it - https://github.com/ngrebenshikov/FreeTypeMemLeak

There is a dump of leaks - https://github.com/ngrebenshikov/FreeTypeMemLeak/blob/master/leaks.txt

Could you give the high priority for this issue?

Move more functionality from OpenFL into Lime, as appropriate

Most specifically, there is duplication right now in the /templates folders, as well as some classes (such as ByteArray and Assets) which should possibly be merged so that OpenFL extends Lime, rather than using a completely different class.

Make a build server for Lime/OpenFL

Using our Linux-based VPS, we are able to make builds for most platforms, and export ZIP packages for haxelib automatically, but we still need to build the Windows and Mac binaries manually and upload them to the server to kickstart the process.

We should have a build server that can integrate the Linux, Windows and Mac components of the build process (or possibly implement cross builds in order to build, say, Windows from Linux) and connect this to commit hooks so that we can automatically create builds as the projects change.

This would be useful for exposing regular development builds, and for supporting the environment we need for automating the creation of all-in-one platform installers.

Ideally this system would not require a monthly cost, and have a minimum level of maintenance to keep it working, but these are negotiable as ultimately its the result that matters most. We could integrate on the existing server, but have not decided on a good system.

Support connecting and disconnecting gamepads while running

We need to support on-the-fly connecting and disconnecting of gamepad or joystick devices.

Add profiles to handle mapping for common gamepad devices

Consider support for more formats outside of OGG or WAV?

Hidden mouse cursor reappears when toggling fullscreen/windowed (OSX)

If you hide the cursor with flash.ui.Mouse.hide(), then toggle fullscreen/windowed, the cursor will reappear. If you try to hide it again at this point, nothing happens and it stays visible.

Probably due to the cached member "mShowCursor" of SDL2Stage not being updated:

SDL2Stage.cpp:

   void ShowCursor(bool inShow)
   {
      if (inShow!=mShowCursor)
      {
         mShowCursor = inShow;
         SetCursor( mCurrentCursor );
      }
   }

The workaround is to jog mShowCursor by showing it, then hiding it again on resize:

    private function stage_onResize(e:Event):Void
    {
        flash.ui.Mouse.show();
        flash.ui.Mouse.hide();
    }

Support user-programmable shaders for managed surfaces (OpenFL)

Recent changes have changed the way that shaders are generated, instead of being hard-coded based on a few factors, there is now dynamic shader generation, based upon what is needed for a specific surface.

In addition to the internal behavior of the managed surfaces within Lime (which OpenFL uses), we would like to add support for user-programmable shaders, for custom rendering.

Support for touch input in Emscripten target

Investigate better support for generative (dynamic) audio

JNI.hx contains invalid dependencies lime.core.Libs

current https://github.com/openfl/lime/blob/master/lime/utils/JNI.hx contains invalid import lime.core.Libs. This class does not seem to exist.

Write more documentation

It should be clear how Lime fits together, how to begin using Lime from the source, as well as how to develop with Lime as a user.

First priority is to enhance the documentation around "how things work" as well as how to use the tools. Then, over time, documentation should evolve as the direct Lime API (wrapper API) develops.

Documentation should be kept under https://github.com/openfl/lime/wiki.

Support more miscellaneous mobile APIs

Investigate dropped surfaces on Firefox + Emscripten (Chrome works)

Port android java extention to lime from NME

I'm trying to port my android java extention to lime from nme
i got on app output
E/lime ( 7025): lime_jni_create_method - failed
E/lime ( 7025): lime_jni_create_method - failed
Here is link to extention
https://github.com/zaynyatyi/tinymic
It worked fine with openfl 1.1.1 and nme
i just changed imports in java file to
import org.haxe.lime.GameActivity;
import org.haxe.lime.HaxeObject;

Support accelerometer in Tizen target

Add mouse locking

We were previously blocked on adding good mouse blocking (I believe) due to poor support in SDL 1, but in SDL 2 I believe we should be able to implement support. This should be useful for immersive or first-person games.

I'm not sure yet what the higher level API for this should look like, but we can at least support it at the lower level, and ensure it works properly. I think SDL 2.0.0 had some minor issues with this, but perhaps in the newer builds it is resolved

Support for automatically handling touch gestures

Consider Xbox One support

"lime test" successfully builds but fails to run projects with a space in the name

Making a simple Hello World test.

>lime test flash
'Hello' is not recognized as an internal or external command,
operable program or batch file.

What's interesting to me is that it DOES build the project successfully, so at least for part of the process it is handling names with spaces just fine. It is only the final step where it stops working.

I tried flash, neko, and windows as targets. All built successfully, and all failed to run after.

Rendering inconsistency between flash and native when using rotation and scrollRect

When displaying the following texture:

Using the following code:

var bitmapData = Assets.getBitmapData("img/cover.png");
var bitmap = new Bitmap(bitmapData);
addChild(bitmap);
bitmap.x = 100;
bitmap.y = 100;
bitmap.rotation = 30;
bitmap.scrollRect = new Rectangle(64, 64, 128, 128);

The output looks different between Flash and Windows native:

I would say the Flash output is the expected behaviour.

GLObject isValid returns true when error creating shader object

glCreateShader returns 0 id on error not null so GLObject isValid returns true even though it fails.

I'm using windows target.

Improve support for unicode

In SDL 2, the keyboard event and text input were divided into separate events, with good reason:

In order to properly handle input for unicode, you cannot expect one character to map to one key stroke. Currently, keyboard input is being handled, then being manually translated to ASCII. We need to support the unicode text input, and connect this to the managed TextField classes.

Under this scenario, if you listen only for events from the keyboard, you will get the key code, as well as a (best guess) translation to ASCII, but if you want to handle true input, you use a TextField element and that will be able to tell you when glyphs are being inputted/removed.

In addition to this, other aspects of the API may need to be analyzed for wchar (versus char) style support

Support full rotation for managed TextField surfaces (OpenFL)

Add gamepad support for iOS and BlackBerry

Consider PS4 support

Investigate ANGLE support for DirectX targets (Windows 8 tablet, Windows Phone 8, Xbox)

Further development of Nintendo Wii U target

Expansion of unit testing

Improve pre-multiplied alpha

Recent changes within Lime allow for pre-multiplied alpha, per surface, but due to graphic and blending improvements, we would like to look at what would be required to support pre-multiplied alpha for a complete title.

This may require some toggling of shaders to blend/fade properly, as well as changes to make sure that BitmapData-style APIs are able to set/read pixels properly, even if the surface is pre-multiplied.

Linux build exits with "AL lib: (EE) alc_cleanup: 1 device not closed"

I can't tell if this is a harmless warning (resources will get cleaned up automatically) or a sign of something bigger (segfault before exit routines run).

Edit: Same exit message on Windows.

Lime Sample "SimpleOpenGL" fails on html5 (using version 0.9.2)

Here is the error:

lime test html5
Source/Main.hx:143: characters 2-86 : lime.gl.GLUniformLocation should be Int
Source/Main.hx:143: characters 2-86 : js.html.webgl.UniformLocation should be Int
Source/Main.hx:144: characters 2-84 : lime.gl.GLUniformLocation should be Int
Source/Main.hx:144: characters 2-84 : js.html.webgl.UniformLocation should be Int
Source/Main.hx:145: characters 2-65 : lime.gl.GLUniformLocation should be Int
Source/Main.hx:145: characters 2-65 : js.html.webgl.UniformLocation should be Int
Source/Main.hx:155: characters 34-39 : lime.utils.ByteArray should be haxe.io.Bytes
Source/Main.hx:155: characters 34-39 : lime.utils.html5.ByteArray should be haxe.io.Bytes
Source/Main.hx:155: characters 34-39 : For function argument 'b'
Source/Main.hx:198: characters 22-45 : Int should be lime.gl.GLUniformLocation
Source/Main.hx:198: characters 22-45 : Int should be js.html.webgl.UniformLocation
Source/Main.hx:198: characters 22-45 : For function argument 'location'
Source/Main.hx:199: characters 22-44 : Int should be lime.gl.GLUniformLocation
Source/Main.hx:199: characters 22-44 : Int should be js.html.webgl.UniformLocation
Source/Main.hx:199: characters 22-44 : For function argument 'location'
Source/Main.hx:200: characters 16-28 : Int should be lime.gl.GLUniformLocation
Source/Main.hx:200: characters 16-28 : Int should be js.html.webgl.UniformLocation
Source/Main.hx:200: characters 16-28 : For function argument 'location'

I could fixed most of them by specifying lime.gl.GLUniformLocation instead of Int in the declaration of the variable

But the following error remained :

Source/Main.hx:155: characters 34-39 : lime.utils.ByteArray should be haxe.io.Bytes
Source/Main.hx:155: characters 34-39 : lime.utils.html5.ByteArray should be haxe.io.Bytes
Source/Main.hx:155: characters 34-39 : For function argument 'b'

Add support for checking joystick/gamepad name

We need to make it possible to check the name of a connected joystick/gamepad device, in order to better anticipate how it will behave.

Allow more control over poll rate and enabling/disabling sensors

Any Lime Sample for Flash target (not using OpenGL ) ?

I notice there is no sample app for flash.
As I would like to investigate a way to target flash/js/cpp without using the Display list API, maybe by making a WebGL like API on top of stage3d API. a sample app for flash could be a good starting point, if it is possible ?
Thanks

Analyze performance of OpenAL on Android

We are currently using the "openal-soft-1.13" branch of https://github.com/apportable/openal-soft for the Android target. Due to reports of issues on the Android target, specifically, I think it would be sensible to look at whether a different OpenAL implementation for Android would help.

Perhaps the master branch, or possibly using int instead of float values (as the repository can be compiled for that optimization) may improve performance here.

As a fallback, we could consider going back to Android Java APIs for Sound, but due to headaches/restrictions we suffered there, it would definitely be ideal if OpenAL could be evolved to work more appropriately.

Duplicate GameActivity definition lime/openfl-native

It seems that android templates (and I'm guessing others) are duplicated between lime and openfl-native.

I would be certainly clearer (and safer?) to remove them from openfl-native ASAP, unless there's a very good reason for that I don't see?

THanks
Thomas
Motion-Twin

Revisit resolution mode switching

In SDL 2.0.0, switching display modes was too unreliable to support. The current implementation uses the "full desktop" mode of fullscreen, which does not change the mode of the user's display, but instead stretches to the desktop resolution, and hides other applications.

If SDL 2.0.1/2.0.2+ improves this, I think we should reconsider support.

When you specify a window size, and do not specify fullscreen in the project parameters, the application should start windowed, at a sensible location, with the correct size.

When the user toggles fullscreen (such as Alt+Enter) then it should enter fullscreen, using the full display resolution by default. Ideally, the developer should then be able to choose a different resolution at this time. When the user (or application) toggles off of fullscreen, back to windowed mode, it should return to the same location, at the same size it was before (respecting if the window was relocated or resized)

With the above parameters, we could not get mode switching working properly, but perhaps newer SDL versions have improved upon this. This behavior must also be consistent between Windows, Mac and Linux.

It is for this reason that #4 has remained open (with my apologies to Rob), since after thorough testing, this seemed impossible without fixes in SDL. Perhaps, by now, this has happened.

Investigate possible audio issues in Emscripten target

Additional improvements in Emscripten support