Profile

Member Since
November 28, 2011

Search Members

  

crayfellow

204
@

Badges

This user hasn't earned any badges yet.

Posts

Viewing 1 to 20 (204 Total)

Re: web flash template error

Hi there,

Thanks for reporting! That is a bug in the command line tools. The fix will be in the github version shortly.

In order to work around the issue in the short term, just add this to your NMML:
<window parameters="{}" if="flash" />

That workaround will not be necessary for the next public haxelib release of NME.

cheers,
Patrick

Posted on January 31, 2013 at 1:12 PM

Re: Installing actuate on MacOSX

The issue is in the method parseOSXConfiguration in this file in haxe std source:
http://code.google.com/p/haxe/source/browse/trunk/std/neko/net/Prox...

So.. it must think you have a proxy configured. I'm going to need to review his machine to see if I can find anything interesting with the way his network connection is setup. Several other developers with identical hardware and OS X had no such issue.

Posted on January 25, 2013 at 4:37 PM

Re: Installing actuate on MacOSX

Hi Rob, a guy on my team (named Robb, coincidentally) also ran into the "Invalid value type 'date'" issue using haxelib. I looked at it myself and it shows up with "haxelib search", "haxelib install", pretty much anything except for "haxelib list".

I recompiled haxelib from source, reinstalled haxe from scratch, copied things from other machines, and nothing seemed to work.

Were you ever able to get haxelib working on your machine?

Thanks!
Patrick

Posted on January 25, 2013 at 4:33 PM

iOS build mystery issues?

Anyone having weird mysterious issues building otherwise working projects for iOS?

Building both at the command like ('nme test') and in Xcode ('nme update') I have a host of oddities with XML files no longer being found (../../../../src/com/myapp/model/SomeXmlBasedDefinitionProxy.hx:8: characters 60-94 : XML File not found : assets/defs/someDefinitions.xml
), errors with public static inline properties (../../../../src/com/myapp/controller/SomeCommand.hx:21: characters 58-74 : com.alleni.myapp.model.#SomeProxy has no field NAME
), etc.

This same app builds for C++, Android, Flash, and HTML5. I have been out of the game for awhile but this is a large-scale application that definitely built for iOS at one time.

Does this spark anything for anyone?

Thanks!
Patrick

Posted on January 18, 2013 at 1:08 PM

Re: Problem with building NME

as far as I can tell, the SVN version of NME/hxcpp is currently unstable and cannot be built for iOS or OS X. I am trying to sort through it and will report back as soon as I have more information.

Posted on November 20, 2012 at 10:19 AM

Re: Icons and Launch Images

OK. can't hurt to upgrade to the version dispatched by the Mac App Store, makes it easier to keep up to date, too. Unless you have a reason to hold on to 4.1 that is what I would recommend.

Cheers!
Patrick

Posted on September 06, 2012 at 3:03 PM

Re: Icons and Launch Images

There's nothing in the plist that is specific to 5.1. In fact, it will work (and I have used it) back to iOS 4.x.

The differentiator is your Xcode version. What are you using?

As for Android, no, this does not cover Android, but that will not be difficult to add.

Thanks,
Patrick

Posted on September 06, 2012 at 2:58 PM

Re: TextField.INPUT for HTML5?

I do not advise implementing this in the canvas-rendered text. Even when canvas-rendered text is used, input should be handled conventionally using an input tag. I built a "native text" class that does this over the top of the HTML5 TextField. Even when canvas rendered text is used, upon transitioning to editable text, it can be replaced dynamically with an input field, then switched back to rendered text once the editing session is complete. One tricky part with this will be keeping typeface and formatting consistent.

The W3C agrees that using standard HTML input field handling is the best way to go. Fromhttp://www.w3.org/TR/2dcontext/... :
Authors should avoid implementing text editing controls using the canvas element. Doing so has a large number of disadvantages:

Mouse placement of the caret has to be reimplemented.
Keyboard movement of the caret has to be reimplemented (possibly across lines, for multiline text input).
Scrolling of the text field has to be implemented (horizontally for long lines, vertically for multiline input).
Native features such as copy-and-paste have to be reimplemented.
Native features such as spell-checking have to be reimplemented.
Native features such as drag-and-drop have to be reimplemented.
Native features such as page-wide text search have to be reimplemented.
Native features specific to the user, for example custom text services, have to be reimplemented. This is close to impossible since each user might have different services installed, and there is an unbounded set of possible such services.
Bidirectional text editing has to be reimplemented.
For multiline text editing, line wrapping has to be implemented for all relevant languages.
Text selection has to be reimplemented.
Dragging of bidirectional text selections has to be reimplemented.
Platform-native keyboard shortcuts have to be reimplemented.
Platform-native input method editors (IMEs) have to be reimplemented.
Undo and redo functionality has to be reimplemented.
Accessibility features such as magnification following the caret or selection have to be reimplemented.

Posted on August 21, 2012 at 11:37 AM

Re: munit and nme.display.Sprite not working?

As of the latest munit on haxelib (0.9.5.1) the cpp target does work!

The issue you ran into here is that the HTML5 target was not finding the base div element it expects to in order to set up the stage. I have local changes I need to commit in order for this to work, but you can expect it in the next NME release.

I am also exploring integrating munit support into NME, since munit would need to run after the nme build and hxml have been defined in order for all target-specific nme code to work. I don't expect it to be too difficult, so I will post back once I have a timeline in mind.

Regards,
Patrick

Posted on August 20, 2012 at 5:56 PM

Re: munit and nme.display.Sprite not working?

I think munit is an awesome undertaking, so much so that I hoped to create some tight integration for it in the NME stack.

In my experience, I had some unexpected issues that made it difficult to use. Given more time, I'm sure these could be overcome.

In your particular case, I'll have to try this but it looks like munit is attempting to validate every available property of the object you give it. Because this is a display object, dimensions are not necessarily established immediately at app startup. In the case of HTML5 output, this means the HTML element doesn't exist yet.

That's just my guess, but because I'm interested in making unit testing easier with NME, I'll have a look as soon as I can and write back with more specific findings!

Cheers,
Patrick

Posted on August 18, 2012 at 8:27 AM

Re: Is there stable gesture lib?

I've got one I have not released yet because mine is a bit specific to my own framework. I have found it to work nicely and more universally for iOS and other targets. I'd be happy to send it along if it would help you build a generalized form. I doubt it'd be tougher than porting from AS3.

multitouch gesture detection is deceptively complex, so I'm happy none has been "standardized" and rolled into the framework. I firmly believe it should always be a separate plugin/lib to allow for tweaking and to prevent extra (code and cpu) weight on the framework for those who might be less interested in such things. I know Flash/AIR has it so some suggest it should be in NME by default, but I never found that one to work well and would have built my own on that side as well.

Patrick

Posted on August 13, 2012 at 1:33 PM

Re: Unicode / Internationalization

Hi Jon,

I too have an engine going international, eventually so I'd like to see what we can do in the near term to help with this. Do you have some examples of the sorts of things (locale/character) that are crashing certain targets, and which targets those are?

If you have a simple example to post that would be awesome. Thanks!
Patrick

Posted on August 08, 2012 at 9:41 PM

Re: Gm2d - Rectangle Packing Class

Very impressive. Thanks for posting!

Posted on August 08, 2012 at 9:35 PM

Re: Accessibility in Jeash

That would not be a huge deal, and it's a nice idea to get things started.

Two things I would want to keep in mind:
* our desire to follow as closely as possible the Flash API (since this would be a deviation) as a standard lots of people are accustomed to
* since this is a cross platform framework, it would be cool to have a solution that would work for all targets.

Of course 508 compliance is out of the scope of a quick thread but it'll also be good to look at tab indexing, finding some way to maximize friendliness to screen readers, and alternate content where appropriate.


Anyway, cool idea. Any other thoughts?

Posted on August 08, 2012 at 9:32 PM

Re: seeking help with simultaneous sounds

since sound is implemented differently between Android, iOS, and SDL (Mac, Windows, etc.) targets, it would help to know what you are seeing per target for what time of file with a small code sample.

Sound has improved recently in general, and I had spent a lot of time on the music side of Android sound which used to have no ability to even account for more than one music file at a time, but haven't yet gotten into the sound side of things much.

Thanks,
Patrick

Posted on August 08, 2012 at 9:26 PM

Re: ios warning seen: "it should support at least one orientation"

I double checked this and it is indeed working properly.

You're just seeing Xcode (CORRECTLY) warning you about shouldAutorotateToInterfaceOrientation, which is deprecated for iOS6.

Orientation for the device (which is set with the window tag in NMML) is not the same as orientation which can be set per view controller, which used to be set via shouldAutorotateToInterfaceOrientation and now uses supportedInterfaceOrientations which takes a mask. These are, and should be, handled separately.

You want to tell the device what orientations your device supports in general, then specify per view what orientations make sense at runtime.

We still use supportedInterfaceOrientations along with supportedInterfaceOrientations because this way we can maximize iOS versions supported by NME. With or without the warning, what is there works as well for iOS6 as it does for older versions.

So if you can, watch this innocuous warning scroll past and enjoy building applications smiling

Cheers,
Patrick

Posted on August 08, 2012 at 6:05 PM

Re: ios warning seen: "it should support at least one orientation"

this is actually a little bit volatile as we are between ios 5 and 6. What is there should be backward compatible but this is handled a little bit differently for UIViewController in iOS6.

What version of iOS and NME are you using?

Thanks,
Patrick

Posted on August 08, 2012 at 5:51 PM

Re: Stuttering movement with touch events on iPod Touch

I'm sure you already know this but I wouldn't recommend installing a beta version of the OS on a device you depend on. I also wouldn't necessarily advise using beta OS's for performance testing as the results are often inconsistent and may leverage code that won't even end up in the production release. For what it's worth, I've been running iOS6 on a 3rd-gen iPad since WWDC and it's been on par with iOS 5 in terms of performance. I'm sure you're aware the 3rd beta is not close to a release-ready fit and finish.

Posted on August 02, 2012 at 3:59 PM

Re: Stuttering movement with touch events on iPod Touch

I finally got around to building with the svn version of nme, but I'm still getting the same issue of touch stuttering on the iPod. Here's what it looks like when I'm trying to draw circles. Sometimes it works on right, and often it doesn't on the left.


Hi there, I have the same question for you I had asked Jon: I am assuming you have tried editing the default scheme and changing the "Build Configuration" to "Release" as opposed to "Debug". Is this the case?

Posted on August 02, 2012 at 3:12 PM

Re: Stuttering movement with touch events on iPod Touch

Thanks, that did the trick for me and makes it now start up quickly each time.

My question now is this - what do I edit within NME itself to make this the default for me, so I don't have to set it each time? This info gets stored inside the project's bundle under the schemes subfolder. All I see under tools/command-line/iphone/PROJ.xcodeproj is a lone project.pbxproj file that doesn't seem to control this.


I played around with that last time I updated the iOS installer and project wrapper for the newer folder layout and Xcode project format. It would be possible to inject schemes, but really these are application-specific and the kind of thing you'll want to create depending on what you are doing. It would add an element to the number of things that already need to be maintained in the wrapper, and that may not be sustainable.

Next time I come up for air I'll look into making this a little bit more streamlined. "Debug" is currently the default without injecting schemes when the project is created.

Posted on August 02, 2012 at 3:10 PM
« Previous123456...11Next »