|
Viewing 1 to (35 Total) |
|
Most NME functions and classes should work for all NME targets, when looking at other functions and classes (not part of NME) that "Available in" will tell you if an implementation is available for that function on a given target language.
For example if I'm coding an NME project and aiming it at HTML5, should I need a function outside of NME, I would check to see that it is available in JS.
Posted on June 01, 2012 at 2:41 AM
|
|
Great script thanks 
I had to change it slightly to get it to run on my mac though:
<property name="nmePath" location="/usr/lib/haxe/"></property>
<target name="buildFlash">
<echo message="NME Test Flash"></echo>
<exec executable="${nmePath}/haxelib">
<arg line='run nme test "${nmmlFile}" flash'></arg>
</exec>
</target>
With regards to using FDT for nme development, are there any other tips you know of which can help make it a nicer experience?
I had to change the project settings to point to the debug.hxml file generated in the Export/flash/haxe/ folder in order to get it to stop showing compile errors.
Any tips on how to get the auto-complete working better? (At the moment for me I can't get it to auto-complete the projects own classes, functions or variables, though it will auto-complete some of the flash ones).
FlashDevelop is a much much nicer place to be, but being a mac user it's not really an option 
Posted on January 14, 2012 at 2:17 AM
|
|
Again, does for solid objects but not for sensors... hmmmm
Posted on October 26, 2011 at 5:23 PM
|
|
After a bit of playing about, it seems that the function doesn't get called when one of the bodies colliding is set as a sensor. When the two are set as solid bodies the contact listener fires like normal.
Thanks for the example Joshua, I've tried it with and without a constructor but it doesn't seem to effect it.
Posted on October 26, 2011 at 5:10 PM
|
|
I've edited lines 414 and 429 of file project.pbxproj (within the PROJ.xcodeproj package in nme install-tools/iphone) to include 'armv6'
This seems to work fine for my iOS5 phone and 4.3 xcode.
Here's the file - linky link
Posted on October 26, 2011 at 4:48 PM
|
|
Hi joshua, thanks for the speedy reply, I thought that about garbage collection myself, but no luck after making the contact listener more permanment.
I have a few other traces and they're coming through just fine. It really is the oddest thing. Does this work for you on your cpp targets?
Posted on October 26, 2011 at 4:29 PM
|
|
This is really strange, custom contact listener also doesnt work on iOS build... is there something im missing perhaps. I have this just to test:
package com.levelbylevel.frog.physics;
import box2D.dynamics.contacts.B2Contact;
import box2D.dynamics.B2ContactListener;
class TestContactListener extends B2ContactListener {
override public function beginContact(contact:B2Contact) {
trace("Foo Foo Foo");
}
}
And I'm setting the contact listener using:
GameHelper.world.setContactListener(new TestContactListener());
Where world is a static initialised B2World.
This works fine in flash on my mac, but not in flash on my windows machine and not on an iOS build of the app.
Does anyone have any ideas at all? this is really holding me up
Posted on October 26, 2011 at 4:22 PM
|
|
Is there a way to make this permanent?
When I run 'haxelib run nme update "[nmml file]" iphone, the xcode project gets overwritten and so does this armv6 setting, which is a little annoying
Posted on October 26, 2011 at 4:06 PM
|
|
I have a strange issue where when I compile for a flash target on my mac everything works fine, but when I compile to flash on my Windows machine my custom contact listener won't fire when a collision occurs. Odd. My Windows machine is using the latest version of HaXe and all my haxelib libraries are upto date. Any ideas?
Posted on October 25, 2011 at 6:27 PM
|
|
Joined and posted
Posted on October 25, 2011 at 6:21 PM
|
|
After looking into it further it seems that while the bounding rectangles work on cpp targets now, the functions used to check the pixels overlap do not, so the reason its out when running on a cpp Target is that as soon as the bounding rectangles touch the function returns a collision rectangle. Effectively making the function just an expensive aabb collision test
Most of the alternate solutions I've found online for as3 pixel perfect collision are actually essentially just this solution but in various forms, using the same bitmap methods. I fear that until these methods are improved for cpp we won't be able to use pixel perfect collision using these approaches.
I'll be more than happy to re-look at this class after future nme releases, or even try another pixel perrfect collision approach if anyone knows one? Food now though in the interest of moving on in my project I'm going to have to find an alternate (probably hacky) solution
Posted on October 18, 2011 at 1:58 AM
|
|
That is infact gold:
Since the width and height of the rotated DisplayObject are actually the correct values. All we need to use that fantastic little diagram (which has now been saved for many a years useful service) for is calculating the correct point for the top left corner. I ended up with the following, which is a bit wordy, sorry:
public static function GetBoundingRectangle(object isplayObject):Rectangle {
var rotation = object.rotation;
if (rotation < 0) {
rotation = 360 + rotation;
}
var position = new Point(object.x, object.y);
if ((rotation > 0) && (rotation < 360)) {
if (rotation < 90) {
position.x -= object.height * Math.sin(rotation);
}
else if (rotation == 90) {
position.x -= object.width;
}
else if (rotation < 180) {
position.x -= object.width;
position.y -= object.width * Math.sin(rotation);
}
else if (rotation == 180) {
position.x -= object.width;
position.y -= object.height;
}
else if (rotation < 270) {
position.x -= object.height * Math.sin(rotation);
position.y -= object.height;
}
else if (rotation == 270) {
position.y -= object.height;
}
else {
position.y -= object.width * Math.sin(rotation);
}
}
return (new Rectangle(position.x, position.y, object.width, object.height));
}
It's not particularly ellegent looking code, but it does seem to work on flash (on iPhone it's collision detection seems a little off, ill look into this).
It does make the, somewhat limiting, assumption that the two DisplayObjects your checking for collision against are children of the same DisplayObjectContainer.
I'll work on it some more but for now, I've updated the .zip and here's the linky link.
Night night all.
Posted on October 14, 2011 at 9:18 PM
|
|
I've drawn a rubbish diagram to show what I need. If anyone knows any high-school level maths to help me, id well appreciate it, lol
Picture here
Posted on October 14, 2011 at 7:53 PM
|
|
Nice drawing
I can calculate the width and height of the rotate displayobject, but where I struggle is in getting its position. How're you doing that?
I found whose code it was to begin with, it's the AS3 CollisionDetectionKit (available here) by Corey O'Neil. In case anyone's interested
Posted on October 14, 2011 at 7:41 PM
|
|
I did try something similar to that, made my display objects disappear from the stage for some reason :p To be fair the attempt was lost amongst a million different "solutions" with lots of traces and lots of commented out code :p
Posted on October 14, 2011 at 7:17 PM
|
|
Alas, lol, back to the drawing board...
I can of course just define a rectangle using localToGlobal on the stage for the object's coordinates then it's width and height variables. The problem comes the minute you rotate the object.
I need to come up with a method of getting and axis aligned bounding box for any display object that takes into account it's rotation. But its late and my trigonometry has never really been up to par ;)
Posted on October 14, 2011 at 7:10 PM
|
|
Ok, I've sort of fixed the class... ... ... I think... ... (would need more testing maybe).
I did this by cobbling together a getBounds type system of my own using the following two functions:
public static function GetBoundingRectangle(objectisplayObject):Rectangle {
var rect = object.transform.pixelBounds;
ApplyParentScaleToRectangle(rect, object.parent);
return rect;
}
public static function ApplyParentScaleToRectangle(rect:Rectangle, parentisplayObjectContainer) {
rect.x = rect.x / parent.scaleX;
rect.y = rect.y / parent.scaleY;
if (parent.parent != null) {
ApplyParentScaleToRectangle(rect, parent.parent);
}
}
It works with the test cases I have and the class now compiles to cpp without any moaning (havent run it on a device just yet).
I've updated the .zip file with the new class. Here's the linky link.
Any thoughts?
Posted on October 14, 2011 at 6:57 PM
|
|
Not at all good stuff
Posted on October 14, 2011 at 5:59 PM
|
|
Hi guys,
I'm trying to port in an old pixel perfect collision detection class from AS3 into HaXe and I'm running into issues where cpp targets don't have the DisplayObject.getBounds(...) function. Flash targets do but cpp don't.
Does anyone have any suggestions to a workaround for this?
Cheers
Posted on October 14, 2011 at 7:54 AM
|
|
Zaphod, give it one of these:
#if flash
alpha1.draw(alpha2, null, null, BlendMode.LIGHTEN);
#else
alpha1.draw(alpha2, null, null, "LIGHTEN");
#end
The tricky bit for me is getting the bounding rectangles, since the cpp targets don't have the function DisplayObject.getBounds(...)
Been trying to replicate the getBounds function but not having too much luck at the moment.
Any ideas anyone?
Posted on October 14, 2011 at 4:40 AM
|
