|
Viewing 101 to (2129 Total) |
|
You can also use "mouseChildren = false"
Posted on March 26, 2013 at 3:37 AM
|
|
Alright, saying it cannot find "arm-linux-androideabi-g++" means there is a path issue with the Android NDK.
1.) Do you have the Android NDK installed?
2.) If you open ".hxcpp_config.xml" in your user directory (C:\Users\<your name> or ~/), is the path correct?
3.) Do you have a recent version of the Android NDK?
If you have the NDK and the path is correct, you may have an older version, which you can support using (if memory serves correctly) -DNDKV7 or -DNDKV6, but having a recent Android NDK should work fine.
Posted on March 26, 2013 at 3:36 AM
|
|
I have been working with filters a bit today
I added ColorMatrixFilter support, and it did work with BitmapData.applyFilter. Your code is not working for native platforms?
Posted on March 25, 2013 at 2:36 PM
|
|
If you are using a 64-bit distribution, you will need to recompile some binaries for 64-bit Neko, since they are distributed in 32-bit form.
Check out the install script and you should find the steps that recompile haxedoc and haxelib to use 64-bit
Posted on March 25, 2013 at 2:33 PM
|
|
But again, for most uses, SharedObject is probably the easiest, best way to go for saving data
Posted on March 25, 2013 at 2:45 AM
|
|
@timrichardson
Sorry for the delay, the Haxe File class might look like this:
var output = File.write ("new-file.dat");
output.writeInt (100);
output.writeString ("Hello");
output.close();
var data = File.getBytes ("new-file.dat");
There should be more data online, such as the Haxe API documentation, or you can find examples of it in use in some of the classes located under the NME /tools directory 
Posted on March 25, 2013 at 2:44 AM
|
|
Run "nme setup webos" to install the webOS PDK, and if you are on Windows, the CodeSourcery G++ toolchain that you'll also need in order to compile.
If you have already installed and are having this problem, you may need to reboot your system in order for your environment variables to be updated. Interestingly, my output looks like this:
arm-none-linux-gnueabi-g++ -oApplicationMain -O2 -s -rdynamic -LC:\Program Files
(x86)\HP webOS\PDK/device/lib @all_objs -lpthread -ldl
So it is similar, but the drive name is uppercase
Posted on March 25, 2013 at 2:41 AM
|
|
Did you check nme.Assets.cachedBitmapData? By default, the nme.Assets class will keep a reference to the BitmapData, so repeated "Assets.getBitmap" calls will return the same BitmapData object instead of continuing to consume memory with multiple copies of the same file. If you want to clear everything out, that will need to be removed in order for garbage collection to remove it
Posted on March 25, 2013 at 2:27 AM
|
|
Hi!
I'm sorry you're experiencing problems, is there any way you could provide a sample project that reproduces this issue, so I could test here?
I haven't had problems with removeChild before.
Posted on March 25, 2013 at 2:26 AM
|
|
By the way, you probably know this already, but NME itself is basically a big native extension. You'll find "ndll", top-level class folders, haxelib.xml and include.nmml in the NME directory, just as example extensions will be.
Also, if you are working from the source and would like to make a new extension, try "nme create extension NameOfYourExtension" to create a template you can follow, to make the process go faster. This isn't available in 3.5.5 but will be in the next version we release
Posted on March 19, 2013 at 6:19 PM
|
|
If you want to publish an extension on haxelib, you'll want to use the following format:
1.) The top-level directory is automatically included as a Haxe classpath. If your code is under "com.mycompany.MyExtension", make sure the "com" folder is at the top-level in your folder
2.) Haxe looks for "ndll" in the top-level directory for native binaries, so make sure you put your compiled libraries under this folder, correct for each target platform
3.) Add a "haxelib.xml" file, with your author, URL, project name, version, version description, etc. You can pull a haxelib.xml file off an existing project to make this easier
4.) Add an "include.nmml" file at the top-level, so NME can realize it is an extension, and pick up your <ndll name=""/> tags or other properties you need to set in order to make the extension work properly.
You zip up the directory, and use "haxelib submit <path to zip>" to post it. If you haven't posted to haxelib before, you may need to also run "haxelib register" to create your haxelib user name and password.
If there is anything you need in your extension which cannot be handled by NMML or by your code at runtime, please let me know. The idea is that haxelibs will include precompiled binaries, so users only need to have <haxelib name="of-your-library" /> to plug in the functionality. If you need to tell users to modify their template files or if they have to do post-update steps in order to make things work, please let me know! We want NME to be able to propagate those necessary changes so users don't have to fuss over them
Posted on March 19, 2013 at 6:18 PM
|
|
I am currently working to make this process easier. The SWF library NME uses for native targets cannot run on HTML5, but I have a better SWF library that is currently being developed which already works on HTML5.
In the meantime, going to spritesheets will probably be your best bet, or rendering shapes, though bitmaps may tend to have higher performance. I don't know of a library that respects embedded ActionScript code right now, but if you are only using it for adjusting the playhead (stop(), gotoAndPlay(), gotoAndStop()) then perhaps the new SWF library could be made to support this feature.
If you are putting all of your code in Flash files, I might recommend trying to refactor to external AS files? This would be more similar to the common workflow using Haxe, where you have Haxe class files (like you would have ActionScript class files) which are external to the FLA, which reference named symbols that are embedded.
It would also be helpful to know if you are moving primarily UI elements, or character animations, and if the animation is simple or contains lots of small, reused parts. These differences can help us recommend the best spritesheet tool, while the full SWF -> HTML5 library is not finished yet
Posted on March 19, 2013 at 11:59 AM
|
|
Hi xastor
The first.
The project is compiled as C++ using the Android NDK. We then package the application using the Android SDK, along with a layer of Java that enables the project to run (initialize the context, access assets, play sound, etc)
Let me know if you think there's a reason to look at using another method of supporting the platform, or if you have more questions
Posted on March 18, 2013 at 10:59 AM
|
|
You may look at the code for webOS or BlackBerry code paths, since these are similar to the Linux target, but use OpenGL ES instead of OpenGL for rendering. If you need any other help, please let me know
Posted on March 18, 2013 at 10:54 AM
|
|
How integrated would you like this to be with NME?
For example, I could imagine an editor using only an NME project file and pulling (or possibly populating) its assets from the project. I would like to expand "nme display" so that there are options for getting the data you need about an NME project without having to parse the project yourself, since the "if", "unless" and asset iteration logic could be difficult to replicate. We could look at doing a new <library /> type, in addition to SWF and XFL, if you have a new output type we could use to pull from at runtime.
One possible point of integration would be the "Assets.getMovieClip" API, to get an instantiated version of what someone developed in the editor, but I have also thought of "Assets.getLayout" for something that would describe the objects and properties, but not instantiate them, so the developer has more control over its application.
How have you liked wxWidgets so far, apart from the issue you mentioned?
Posted on March 14, 2013 at 12:37 PM
|
|
Oh, and Philippe is right -- the native platform support is all hardware accelerated. Instead of using software for most things (Sprites, DisplayObjects, Buttons, Graphics), these are handled by OpenGL by default, but there is a software fallback for platforms with 3D acceleration is not running.
There are a few spots where software may still be used, like adapting a texture when the GPU requires power-of-two textures, or some of the bitmap filters, but the current version of NME has shaders which handle some of the places (radial gradients, etc) which used to only be handled in software. You can also force software using "cacheAsBitmap = true;"
The advantage of an API like drawTiles is that you are able to make a batch rendering call... with one texture and as many geometries as you want, which performs well with a GPU. Each DisplayObject by default will be its own render call, so having less render calls will allow you to have even better performance, but a lot of projects will perform fine using the display list
Posted on March 11, 2013 at 9:34 AM
|
|
Hi!
Yep, you can use "flash.display.Sprite" and it should compile for all platforms, but your code completion will work better if you use the "nme" package.
Here's a quick overview of how things work on a technical level:
1.) Flash
We compile your project to Flash, using the Haxe compiler. We add a preloader to the project, and embed all of your assets into the SWF, after Haxe compiles it. Then at runtime, your project should show a preloader and have access to all assets without downloading them separately.
Most of NME's classes will be typedefs to the Flash alternative, so "nme.display.Sprite" will literally compile as "flash.display.Sprite", so we're basically done when you target Flash, because it already has support for these core classes.
2.) Native
We convert your source code to C++ or compile to Neko, based on the flags you use, using the Haxe compiler. If you are building a C++ project (which is the default), the source code will be compiled for a target platform using HXCPP, which is integrated in the Haxe build process for C++.
There is precompiled native binary we use to power NME on native platforms. This is where initialization, event handling, OpenGL rendering, sound and other aspects of NME (the stuff Flash Player would normally handle) are defined. A lot of NME's classes for native (most "nme" classes are typedefs to the "native" class package) are thin wrappers for the native versions we have compiled in this library. In the code, "nme.Loader" is the glue between Haxe and the native C++ symbols, using a format called "CFFI" to link them together.
Depending on the target, we then bundle the new native application with your assets, template files for the platform, then perform additional compiling, packaging, installing or running, for either your desktop or for the mobile platform you are targeting. This is all handled by the NME command-line tools
3.) HTML5
Your source code is compiled to JavaScript, using the Haxe compiler. The "nme" class package is redefined to "browser", which includes browser versions of these classes, so Sprite will use canvas and URLLoader will use XHR, etc... it's all setup for the browser. This is compiled with your project to JavaScript as well. Once that is done, we have a system of processing fonts so they can be used at runtime, then copy a template index.html so you can run your project.
If you have more questions, please feel free to ask
Posted on March 11, 2013 at 9:29 AM
|
|
Are you trying to build an SWC library to use this with an ActionScript project, or did you want to build an NME project?
If you're interested in trying NME, you'll want to use the NME build and test commands rather than using Haxe directly. Otherwise, there is probably a way to get it to compile for use with a Flash-only project
Posted on March 10, 2013 at 5:44 PM
|
|
Hi!
The community is growing, and larger than one might think.
There are a variety of libraries, depending on what you are looking for. If you had one in particular you were interested in, we might be able to help. There are also examples included with NME. Check out the download page, it lists some samples you can create on your local system using "nme create", such as the Pirate Pig example.
I've been using NME for more than three years, and am thankful for what Hugh Sanderson has built in the native rendering and what Neil Drummond has done with the creation of the HTML5 platform target. There are a lot of projects that are built using NME, and more everyday
Posted on March 10, 2013 at 5:42 PM
|
|
Perhaps the HTML5 target doesn't support the use of a Loader as a DisplayObject right now... the command design pattern is to load the graphic using Loader, then to create a new Bitmap using the BitmapData object loaded into "contentLoaderInfo.content"
Posted on March 09, 2013 at 10:52 AM
|
