Lime 7 Release!


#1

We have a new major version of Lime out, I will try and find the time to write a blog post, but for now, here’s the changelog:

7.0.0 (08/09/2018)

  • Major API re-design to improve workflow outside of command-line tools
  • Migrated the core of the command-line tools into a new project called HXP
  • Updated Freetype to 2.9.1
  • Updated Android minimum SDK to API 14 and the default target SDK to API 26
  • Updated window defaults to always enable depth and stencil buffers
  • Updated window defaults to use a 32-bit (instead of 16-bit) backbuffer
  • Removed lime.graphics.Renderer, functionality moved to Window
  • Removed lime.app.Config, moved app.frameRate to Window
  • Removed lime.graphics.format.*, functionality moved to image.encode
  • Removed lime.utils.compress.*, functionality moved to lime.utils.Bytes
  • Removed lime.ui.Mouse, functionality moved to Window
  • Renamed lime.app.Preloader to lime.utils.Preloader
  • Removed lime.text.TextLayout, replaced with native Harfbuzz bindings
  • Moved lime.project types into lime.tools
  • Moved lime.utils.GLUtils functionality to GLProgram and GLShader
  • Added new lime.graphics.RenderContext with more lightweight API bindings
  • Divided OpenGL support into separate OPENGL, OPENGLES and WEBGL types
  • Compatibility APIs are provided in one direction (GL -> GLES -> WebGL)
  • Added lime.ui.WindowAttributes with broader context creation control
  • Sub-classing Application now requires no window argument for most methods
  • Multi-window applications should listen to app.onWindowCreate instead
  • Added support for Haxe Eval target, and beta support for HashLink (on dev)
  • Added Windows 64-bit support, Android ARM64 support, progress on WinRT support
  • Added bindings for the Harfbuzz native text layout library
  • Added lime.ui.MouseButton and lime.ui.MouseWheelMode
  • Added MojoAL support (as an alternative to OpenAL-Soft) in dev builds
  • Added cURL Multi support
  • Added support for <config:air languages="" />
  • Exposed window.stage and window.element on Flash/HTML5 targets
  • Improved native build times by not relying on macros for CFFI
  • Improved mouse event bindings, improved consistency of mouse wheel behavior
  • Improved HTML5 fullscreen exit to dispatch a restore, not a resize event
  • Improved lime.math.* classes to allow for less GC activity
  • Improved support for Electron on Linux to allow for WebGL on more drivers
  • Improved quality for HTML5 frame rate when set to lower than VSync
  • Improved HTTPRequest to dispatch a progress event when loading locally
  • Fixed some cases where allocation could occur during native GC
  • Fixed use of future.then when the result is an error condition
  • Fixed issues with some of the equations in lime.math.*
  • Fixed warning in Chrome caused by default HTML5 template
  • Fixed unnecessary AL cleanup message on exit
  • Fixed replay of existing native AudioSource sounds
  • Fixed Unicode paths on Windows when returning paths from the system
  • Fixed pasting Clipboard data when application first launches
  • Fixed webfont loading on mobile Safari
  • Fixed issue with AL.source3i types
  • Fixed support for iOS entitlements paths that include spaces

#2

oh, does it mean won’t work on api 9 anymore ? :frowning: Is it totally broken, or it just some features that won’t work ?


#3

We upgraded our internal version of SDL, which we use for native windowing, rendering and events. They have upgraded their minimum on the NDK-side to API 14 (Android 4.0), this was done a version or two ago, but we had some runtime errors with old devices because the minimum SDK API level wasn’t increased to match.

We’re supporting 99.8% of Android devices in the Play Store currently

Are you targeting any older devices?


#4

Hmm. In fact I am doing an education app ( been a few years already …) I was planning to “recycle” old tablets and put my app on it to give them to people who need it. But maybe not so many old androids are left …
Saying this I forgot my old gingerbread phone somewhere, so it’s been a while I haven’t tested on it.


#5

Great updates!

Any way to still get name, version, packageName, rootPath etc. in code?

Application.current.config.rootPath
this obviously no longer works

thank you


#6

There’s a new app.meta object, which can be used for storing application meta-data. The default template uses these values:

(…though perhaps it should use “package” instead of “packageName”?)

EDIT: Looks like we’re missing “version”, but it could be added

EDIT2: If you use lime.embed, it appears that { rootPath: "path/to/asset/root" } should be available on window.config.rootPath, but it’s not strictly typed


#7

Hi, @singmajesty, Can the SWF library be used to cancel the export of resources in jpg format? Can I use the png format all?


#8

Currently, we follow the format encoded in the SWF. If you set something to “lossless” in the Flash library, then it should be PNG in the SWF, otherwise it’s JPEG, or JPEG + ALPHA, which we encode as a JPEG and a PNG alpha file. It would be possible to do more, but currently we let the SWF file dictate what format to use


#9

@singmajesty

Looks like we’re missing “version”, but it could be added

Please add it back : it is needed for crashdumper reports, and I find very helpful to be able to display it inside a running application :slight_smile:


#10

Please add it back : it is needed for crashdumper reports, and I find very helpful to be able to display it inside a running application

Done!


#11
lime.app.Application.current.meta.get("version");

I’ve tried that, but still get null, am I doing something wrong?
I’ve also downloaded latest Lime build from here: http://builds.openfl.org/


#12

I added it in the develop branch of Lime, but for OpenFL, I added it to a working branch I have while I’m doing some breaking changes, until it stabilizes.


#13

Hi, I want to know if there is a way to get the number of drawCalls? :smiley:

The GLStats.totalDrawCalls method doesn’t seem to work.


#14

I’m running into problems like this when I updated. Any reason why? Is there an build of Away3D I need to get as well?


#15

Could you double-check if you’re running the latest versions? It may include a fix that should help. You can also try -Dopenfl-share-context to see if that makes a difference


#16

I just did a haxelib update and downloaded latest and greatest. I also tried try -Dopenfl-share-context as well and still same effect. This happens when I update the texture on the folder.


#17

Hmm, strange. Native or HTML5? If HTML5, are there any errors in the console? What kind of texture is it (Texture, RectangleTexture, PNG, JPEG, ATF, etc)? Does adding -Dopenfl-disable-context-cache make a difference?


#18

It’s the HTML5 export and using an textured JPEG that is being applied on roll over and out. I also added -Dopenfl-disable-context-cache and it’s having the same effect.


#19

Errors in the browser console?


#20

Nope, no errors. I just double checked again in fact.