|
Viewing 561 to (2136 Total) |
|
Try using nme.Lib.getURL, it should work on all these platforms 
Posted on November 03, 2012 at 10:10 AM
|
|
It sounds like SFML may be compatible with WinRT. We obviously would need to handle DirectX rendering, but it would be nice to keep a baseline of other functionality. I believe that people have used SFML for BlackBerry, I'm not sure about other mobile platforms.
I wonder if it would help improve sound, and resolve some of the problems we've had with windowing:
http://www.sfml-dev.org/features.php...
Posted on November 02, 2012 at 1:28 PM
|
|
I've tried another go on the dependency libraries. So far I can compile zlib, Freetype, libpng, libogg and libvorbis.
cURL will not compile. I think it is relying on WinSock?
libjpeg fails to compile because it cannot find "win32.mak" ... I'm looking into this to find if it is one of its own file, or something that its expecting to find on the system.
smpeg cannot find a reference to "SetThreadPriority" ... this is probably a Win32 API?
...and of course, SDL is not going to be compatible with WinRT.
Posted on November 02, 2012 at 1:20 PM
|
|
(I should probably be writing on a different thread, but I'll continue)
I am having difficulty finding information on the subject, but it sounds like /ZW enables a special Microsoft variation on C++, which doesn't work properly with these C-based libraries? I'm trying again using the usual /MT flag. Is that allowed for WinRT applications?
Posted on November 02, 2012 at 1:01 PM
|
|
Compiling NME for WinRT appears to work fine, but it would need to link WinRT versions of the supporting libraries.
I made some changes in sdl-static to see if any of the supporting libraries will compile for WinRT, but none of them will compile with the /ZW option. I suppose this is necessary for running in Metro?
Posted on November 02, 2012 at 12:36 PM
|
|
Thanks Hugh
Previously a standard build was throwing errors about OpenGL and missing Win32 APIs. Perhaps there was a flag I was missing, or things have changed since the first release I tried some months back?
Everything appears to work perfectly if you have Visual Studio 2012 Express for Windows Desktop installed, so I have changed the tools on the repository so it will not block their use anymore. I'm also beginning to play with compiling NME to WinRT again...
Posted on November 02, 2012 at 11:41 AM
|
|
That's part of it.
The other side of running as a Metro app is that it needs (to my knowledge) to be compatible with WinRT and it needs to leverage DirectX instead of OpenGL.
Packaging an HTML5 app is pretty easy. I'm investigating ways to help automate this process. However, the performance on native is obviously much better. Hugh has begun to do some work in NME and HXCPP to support WinRT and the new APIs for paths. We will need to patch or get upgraded versions of some of our dependency libraries, like cURL, which reference Win32 APIs and are not compatible with WinRT. Then the big remaining issue is hardware acceleration.
Posted on November 01, 2012 at 3:04 PM
|
|
This is a good idea.
I'm undergoing a rebuild of the command-line tools, so perhaps this is something I can consider as part of the rewrite
Posted on November 01, 2012 at 3:00 PM
|
|
Yep! Absolutely
Here is a little "cheat sheet" that may help when translating some of the Flash-based projects and tutorials you may find out there:
http://www.haxenme.org/developers/documentation/actionscript-develo...
In the future, I hope we'll have more content here for you
Posted on November 01, 2012 at 2:54 PM
|
|
This would probably be simpler if you went with a formal extension. Unless the API is available from C++, unfortunately I don't think there would be a nice way to add Objective-C code inline. However, you might be able to create the bindings inline if you wanted, but probably going the route of a regular extension would be the cleanest to compile and use. Then it could be bundled up as a nice haxelib when you're done, anyway
Posted on November 01, 2012 at 2:52 PM
|
|
There may be a native WebView coming in the future for BlackBerry C++ projects, without using Cascades. That would be the simplest to implement.
The other alternative would be a modification of NME to be able to run inside of the Qt/Cascades ForeignWindow interface, so instead of putting a WebView in your NME application, you really would be putting NME inside of Cascades, which could then launch a WebView or anything else. There's a lot that could open up, but first NME would have to be compatible with the Qt main loop, and I'm not sure if it would affect performance.
Or maybe there's another way to accomplish what you had in mind? What would you like to do that requires a WebView in NME?
Have a great day
Posted on November 01, 2012 at 2:51 PM
|
|
Hi!
I'm sure the easiest approach would be to round-trip with a web server, but that isn't the most practical.
Haxe does have support for sockets, so it could be possible to perform some kind of UDP connection. I haven't gotten into socket and network programming much myself, but this is something I would love to see for NME -- the ability to create the same application for such different target platforms instantly opens up the idea of making them work together.
Another idea would be for both to access something over a local network or to use an API like DropBox, but again, a direct file approach would be nicest long-term, especially for making them communicate beyond file transfers, such as multiplayer or smart interaction
Posted on November 01, 2012 at 2:46 PM
|
|
Yeah, if you can include them as assets, then nme.Assets can help resolve the proper path names.
Otherwise you're not able to write new files to the application package on iOS, but you can use the nme.filesystem.File class to get references to the OS storage directories. Assuming you have the proper path, you can use "sys.FileSystem", "sys.io.File" and other core Haxe classes to manipulate files
Posted on November 01, 2012 at 2:43 PM
|
|
Try replacing it with Reflect.callMethod:
Reflect.callMethod (_callback, null, args);
I forget if you can pass "null" for the scope, however. You might be able to pass "_callback" as the scope as well, or "this"
Posted on November 01, 2012 at 2:40 PM
|
|
Try using nme.net.URLLoader, kind of like this:
import nme.net.URLLoader;
import nme.net.URLRequest;
...
var request = new URLRequest ("http://www.haxenme.org");
var loader = new URLLoader ();
loader.addEventListener (Event.COMPLETE, loader_onComplete);
loader.load (request);
...
private function loader_onComplete (event:Event):Void {
trace (event.data);
}
Posted on November 01, 2012 at 2:37 PM
|
|
Do you know if event.target works properly on native targets?
We can copy code over pretty easily between native and HTML5, so if it works in one and not the other, we could look at migrating some changes. I thought it worked for C++
Posted on November 01, 2012 at 2:34 PM
|
|
If you haven't seen it yet, this may also be helpful:http://www.haxenme.org/developers/documentation/actionscript-develo...
Posted on November 01, 2012 at 2:19 PM
|
|
Okay, a few ideas of things you can try.
First, you could try and add snapping (I forget the exact name... Actuate.tween ().snapping () I think) in order to animate only to even pixel positions, instead of fractional positions. Animations like Quad and Expo also tend to look smoother, if the animation does not have to be constant. You can also try animating only one tile at a time (if it is larger than the screen dimensions) then removing it and adding the next tile when it comes time to do it.
You can check <window fps="60" /> to make sure its set high enough.
If it will always be a constant amount of movement, you might also consider doing the animation manually in an Event.ENTER_FRAME listener, updating the X position then automatically removing and adding tiles as necessary.
Posted on November 01, 2012 at 2:04 PM
|
|
Yep, I would expect that Type.resolveClass would be looking for the fully qualified name.
Does it work, though, if your target class does not have a package?
Posted on November 01, 2012 at 1:59 PM
|
|
Hmm, does this freezing lock the main thread of your application, or does the URLRequest remain unresponsive while the rest of the application continues to run?
If this is actually freezing the application then this is definitely an issue. If it is only on the request (because I thought it worked on a different thread), then perhaps we can pass some different settings to cURL, which we use for network requests on the native targets. Speaking of which, I think we also need to see if there's a way we can make it automatically follow redirects...
Posted on November 01, 2012 at 1:54 PM
|
