Working on more documentation for OpenFL and Lime

[Joshua Granick]

Hey everyone,

We are in the process of working on more documentation for Lime and OpenFL, first, it is important to me to provide more communication in how pieces are connected, the way each platform works, and how someone may be able to help contribute to growing these projects. This documentation is beginning in the Lime layer, but should flow over to the OpenFL side in time.

Due to the way OpenFL and Lime are separated, the Lime documentation will include more of the command-line tool, project file, platform mechanics and other more specific documentation. The OpenFL documentation will likely grow to be more specific to how the Flash API works, how to write applications, etc.

It's a long road ahead, but I would love to have your input and feedback to make sure that things are being communicated well, that we are not missing things that are important for understanding things at a deep level, to make things stronger.

These are some pages that have been updated:

https://github.com/openfl/lime (README)
https://github.com/openfl/openfl (README)

https://github.com/openfl/lime/wiki/Roadmap

Platform documentation pages (https://github.com/openfl/lime/wiki)


Thanks everyone! We are excited about finding more ways to contribute code in ways that help the whole community grow as a whole, building support for more platforms and solidifying the existing support, so we can move forward together as the best solution for cross-platform ;)

[David LE JOLLY]

Thanks for the effort !

[Tarwin Stroh-Spijer]

Yeah, thanks mate. Finally understand what LIME is :D

Tarwin Stroh-Spijer
_______________________

phone: +1 650 842 0920

Developer at Fanplayr Inc. (Palo Alto)

Original at Touch My Pixel (touchmypixel.com)
_______________________

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/groups/opt_out.

[Brennan Kinney]

Been transitioning to OpenFL and the Haxe Language coming from a background of AS3/AIR using Starling and FeathersUI frameworks.

Rendering bitmapData, memory usage and context loss:

I understand that with OpenFL native targets get GPU rendering with drawTiles()? but with flash this isn't the case(no way of optionally using stage3D? or is performance worse?), when using the GPU is the bitmapData that is uploaded to the GPU memory also stored in RAM? Or is it disposed of after the upload to GPU? I'm just curious if additional memory is being used and how context loss is handled, if a copy is in RAM I imagine it would be resent to the GPU, and if not then reloaded from the file source if available? Or do we have to handle this ourselves?

This GPU/CPU rendering behaviour depending on target, is it safe to assume any framework such as HaxeFlixel/HaxePunk and I think Awe6? would behave in the same way? Does OpenFL provide a texture atlas class to minimize draw calls or is that the frameworks/our responsibility to provide? 

ASSETS:

I still need to go over existing documentation a bit, but with assets rather than use a meta tag like in AS3 for embedding, I define it in the project.xml and refer to it with openfl.assets?(documentation currently refers to nme/nmml), what if I don't want to embed my assets? 

I might be misunderstanding the definition of "embedding" in the documentation for assets, I'm not sure if it's the same, but for example with android when using AIR, the app would not do anything until it finished loading all embedded assets into RAM I think, so if I have 1x, 2x, 3x versions and I'd only want to access the ones I need when I need them, thus I used URL Loaders for external asset files(still within the apk) rather than embedding into the app/swf via meta tags.

I'm using FlashDevelop as my IDE. So I'd like to know 

-both methods of embedding into the app and external files that are loaded into memory only when I request them.

-which one of those two are considered embedded by the project.xml/openfl.assets method described in the documentation.

-how to handle the other method of assets not described by the documentation and if that method is unsupported or needs to be handled differently by specific platforms.

-with the other method not described in the documentation if available at all, where do I put the files/assets?

I take it due to GPU/CPU renderer for the platform, I don't need to convert bitmapData into the equivalent of Starling's Texture type? I'm not sure how to handle a texture atlas this way, in Starling I could provide a .png and .xml to create a texture atlas that would create a Texture and provide many SubTextures that all referenced the same Texture data, this was then provided to a quad class called Image and added to the stage.

Scaling:

I've noticed the app does automatic scaling? I have the scale mode set to NO_SCALE, and in the project.xml set the width/height to half my phones resolution, removed the unless mobile conditional and the app scaled to fill my screen? I would have expected it to only take a quarter. I've used a default FlashDevelop template for OpenFL. I've noticed PiratePig has some custom scaling code and passes that down to the game class sprite to handle resizing there. I'm used to having my resize logic do similar with a viewport class provided by Starling, so my expected outcome might be a misunderstanding.