|
Viewing 501 to (2135 Total) |
|
I have just committed an improvement so these details will appear in -verbose output, so we will be able to diagnose this type of problem more easily in the future.
In the meantime, looking at the source, it appears that if something is flagged as type "sound" or "music", it will check the format based upon the file extension. If it is "mp3" it handles it as MP3. Otherwise it sends it to the WAV reader.
Is there any chance you have *any* files that could be flagged as one of these types, that is not an MP3 or WAV file? It could be something like a .hidden file in one of your asset directories (and your <assets /> node specifically forces a type) or perhaps you have files of another format, like OGG, that could be the culprit?
Posted on December 23, 2012 at 12:48 PM
|
|
I believe that "fruitstrap", the tool we use to install to devices without launching Xcode, may have been updated with NME 3.4.4. If you would like to give that or 3.5.0 a try, I believe it might help
Posted on December 23, 2012 at 9:47 AM
|
|
Hi Zaphod,
I just checked out your example project.
The font works. I did add "tf.embedFonts = true;" in order to see the font embedding on Flash, however.
There is a bug here with HXCPP. I apologize -- Hugh would probably say it wasn't quite ready. NME has been long overdue for a release, and it relies on it. When I wrapped "bitmapHash.get ('testKey')" with "cast (bitmapData.get ('testKey'), BitmapData)" it compiled and worked just fine.
We'll see if we can get this resolved
Posted on December 23, 2012 at 9:39 AM
|
|
Interesting, is it processing your MP3 file as a WAV?
Posted on December 23, 2012 at 9:29 AM
|
|
BTW, NME 3.4.4 is also on haxelib now
Posted on December 23, 2012 at 9:28 AM
|
|
I have just made the fix. We'll get this released soon so no one else will have this problem.
Thank you so much for reporting! 
Posted on December 23, 2012 at 9:27 AM
|
|
Ah, interesting.
The command-line tools assume you have an ".hxcpp-config.xml" file in your user directory.
Open a command-prompt, then run "haxelib run hxcpp". Then compilation from FlashDevelop will work fine.
I'll see if we can fix it so this is no longer necessary. Sorry for the trouble!
Posted on December 23, 2012 at 9:23 AM
|
|
Okay, should be uploaded.
Sorry about that
Posted on December 22, 2012 at 3:54 PM
|
|
Indeed!
Apparently OS X did not overwrite "NME.mpkg" on the build system when requested. That is the 3.4.4 installer, not the 3.5.0 installer.
I'm uploading the 3.5.0 installer package now. In the meantime I've linked the Mac download to 3.4.4 to prevent confusion
Posted on December 22, 2012 at 3:28 PM
|
|
Did this work differently with NME 3.4.4, or were you using an older version?
Posted on December 22, 2012 at 1:41 PM
|
|
Can you send me an example project that recreates either of the issues?
Posted on December 22, 2012 at 1:40 PM
|
|
Thanks!
I addressed the first two issues this morning, but could not replicate the third issue. I used Courier on my system, and it embedded fine for Flash and worked so long as I used the write path ID. I accidentally had the wrong casing at first, which gave me the same "There is no Font asset..." error.
Posted on December 22, 2012 at 1:24 PM
|
|
Does it act differently if you use a WAV file?
"music" and "sound" use two separate APIs
Posted on December 22, 2012 at 1:21 PM
|
|
Would you mind updating to NME 3.5.0?
The current versions of NME and HXCPP should be reading the "bbndk-env" script to pull out the host and target paths dynamically
Posted on December 22, 2012 at 1:20 PM
|
|
Perhaps you could try building r2245 of NME.
My most recent commits added SWF support for HTML5, but it requires a development build of SWF, but for difficult to track reasons, it currently compiles and runs 100% perfectly only on Neko 2 and development builds of Haxe. That revision should still be compatible with the release version of the SWF library so you can move on and get running
Posted on December 21, 2012 at 9:05 AM
|
|
Which version of NME?
The native code should use the "fromBytes" method, while the NME tools embed bitmaps into the SWF then pull them out later.
In Flash Player, I believe you have to export the pixel data as a ByteArray the import it in order to create a Bitmap. Otherwise something like a JPG can only be loaded if you use the Loader class, which has a way to load bytes.
Perhaps you can disable encryption when targeting Flash Player, or perhaps there is a way we could build encryption into NME
Posted on December 19, 2012 at 12:18 PM
|
|
Weird. That's just like mine.
Does "nme rebuild clean,mac" help?
You should be able to add defines when you compile. HXCPP automatically reads your paths and defines MACOSX_VER and DEVELOPER_DIR internally. If you add "-D" after an "nme rebuild" command, you should be able to push defines to the process. Perhaps it is defining these values incorrectly, somehow?
Posted on December 18, 2012 at 4:03 PM
|
|
Hmm, the MacBook here is running the same version of Xcode, and it is compiling.
When you get errors that "string.h" or "math.h" do not exist, this normally means that the path to your toolchain does not exist, or it has been moved.
Does /Applications/Xcode.app/Contents/Developer//Platforms/MacOSX.platform/Developer/SDKs/ exist, and what directories are there?
You might also be able to try forcing -DMACOSX_V=10.8 or -DDEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer
Posted on December 18, 2012 at 3:55 PM
|
|
Do you have Xcode installed?
Are you using the SVN copy of HXCPP? (checkout, then "haxelib dev hxcpp path/to/hxcpp/checkout")
If you are sure you are using the development version of HXCPP and have Xcode installed on your system, try running "xcode-select" and make sure it points to the proper directory.
Posted on December 18, 2012 at 1:58 PM
|
|
Try "nme rebuild" to compile nme.ndll for your operating system, then try it again
Posted on December 18, 2012 at 1:42 PM
|
