|
Viewing 41 to (554 Total) |
|
Hi,
I think there has been an update to the samples Main.hx to fix this:
http://code.google.com/p/nekonme/source/diff?spec=svn77376eb9bf5997...
Hugh
Posted on March 24, 2013 at 9:43 PM
|
|
Hi,
nme.filesystem.File.userDirectory.nativePath should give you somewhere to start.
Hugh
Posted on March 24, 2013 at 9:37 PM
|
|
Hi,
Yes, rebuilding from flash-develop will not normally rebuild the nme.dll.
To do this, go to the nme/project directory, and run:
haxelib run hxcpp Build.xml
Hugh
Posted on March 18, 2013 at 10:25 PM
|
|
Hi,
If you are compiling yourself you could try changing the line th TextFeild.cpp:
mCaretGfx->lineStyle(1,0x000000);
to
mCaretGfx->lineStyle(1,0xffffff); or whatever.
I guess it should be using the default text colour?
In which case, maybe this is the correct code:
mCaretGfx->lineStyle(1,textColor);
Hugh
Posted on March 17, 2013 at 9:37 PM
|
|
Hi,
Bitmap data have to be uploaded to the GPU from the main (opengl) thread, so if you do a whole lot all at once, you could get a stall. However, jpeg decode could be done in the background, which should be an improvement. Do you know which of these effects is greater?
Hugh
Posted on March 12, 2013 at 10:25 PM
|
|
Hi,
Putting waxe in you nmml will include waxe lib which will turn on the "waxe" define.
This define then gets used in "templates/default/haxe/ApplicationMain.hx" which will create the waxe managed stage.
Since waxe (wxWindows) manages keyboard accelerations, it will swallow some of these events.
I suggest that if you want to use waxe, use it for menus too. On these menus you can have shortcuts, and callbacks, which will allow the key to call directly into your app, and the user can use the menu if they want.
Double clicks also get interpreted by wx. These should actually be able to generate separate events, which you should be able to respond too.
So generally, I think you could move some of your logic over to the native(wx) code, rather than processing the raw events from managed stage.
Hugh
Posted on March 12, 2013 at 10:21 PM
|
|
Hi,
The event model will tell you when the mouse enters or leaves objects. This takes some CPU to work this out.
If you are using your physics engine to perform hit tests etc, then you could try using mouseEnabled = mouseChildren = false on your game layer, and add the event watchers to the stage and do the whole mouse thing yourself in pixel coordinates.
Hugh
Posted on March 11, 2013 at 10:05 PM
|
|
Hi,
Sometimes this can happen when the app actually crashes (eg, null object access) - rather than dumping out, the system keeps the process alive but not responsive. For android, be sure to check the full, unfiltered logcat which might have more info. Also, try compiling with "-debug" for the null-object checks.
Hugh
Posted on March 10, 2013 at 10:19 PM
|
|
Hi,
Integrated graphics will still use opengl - and will probably be faster - when hardware=true. Furthermore, the texture memory is shared with the CPU so you are seeing both copies show up in task manager, whereas you might not with a discrete graphics card since it has its own memory.
Hugh
Posted on March 10, 2013 at 10:12 PM
|
|
Hi,
Yes, I guess loading android assets from a thread is a little too funny for NME at the moment.
Did the stack-overflow snippet help?
Hugh
Posted on March 04, 2013 at 10:56 PM
|
|
Hi,
I'm pretty sure this happens when pixels are blended together when one has alpha and one does not.
The simple equation uses (average red, average green, average blue, average alpha), but it should in fact be alpha-weighting these values.
So your image contains a bright-green pixels with zero alpha next to a black pixel with 50% alpha, you end up with a green-ish pixel with 25% alpha.
One way to fix this would be for NME to use pre-multiplied alpha, but this is not done.
You should be able to fix this by setting the RGB of the pixels with zero alpha to the rgb value of the nearest pixel with non-zero alpha. If you can do this at authoring time the problem should go away.
Hugh
Posted on March 04, 2013 at 10:51 PM
|
|
Hi,
Make sure you are using a debug build - this will help xcode find stuff.
Hugh
Posted on March 04, 2013 at 10:44 PM
|
|
Hi,
It sounds like the command-line build and the xcode build are using different directories. I'm not sure how the command-line build works, but if you start with:
nme update project.nmml ios
This will update the assets, but not create the source code. Then, you can open xcode and use the build command, and you should end up with only the one set of files. If you run and hit the "break"/pause button, xcode should place you inside on the of the cpp files - maybe you will need to look up the callstack a bit.
Once you have found one cpp file, you should be able to work out the locations of the other relative to the first.
Hugh
Posted on March 04, 2013 at 10:42 PM
|
|
Nice work - congrats.
Hugh
Posted on March 04, 2013 at 10:33 PM
|
|
For the emulator, these need to be compiler for x86, rather than arm.
Currently, there is not a good way to do this.
Hugh
Posted on February 27, 2013 at 9:36 PM
|
|
- do haxe/NME support associative array? or should I use some class that function as an associative array like Map class in Java?
myArray["index"]= 100;
haxe2 (current)
var myArray = new Hash<Int>();
myArray.set("index",1);
haxe3 (soon)
var myArray = new haxe.ds.StringMap<Int>();
myArray.set("index",1);
- why there's no protected keyword?
It is against Nicolas's philosophy
- is static inline keyword behave the same as const?
"static inline var" is like a const
"inline function" (static or not) gets merged in line you would expect an inline functionto be
- how do I get the keyboard input from user?
NME: new TextField();
or:
stage.addEventListener(KeyboardEvent.Key_Down, ... etc
Hugh
Posted on February 26, 2013 at 10:16 PM
|
|
Hi,
You can get fast Add blend mode with the drawTiles API. Not quite sure how you could use this to draw lines - maybe a series of point blobs spaced closely together.
The flash API implies that objects are first composited and then added, which really means this has to be done via texture. I could probably add some new blend mode that means each polygon is simply added which would be less complicated and more like what you want.
Hugh
Posted on February 25, 2013 at 9:13 PM
|
|
That seems a bit strange.
Are you doing anything funny on startup, like accessing JNI?
Also, have you tried compiling with the -debug flag? this may give some more info.
Hugh
Posted on February 24, 2013 at 9:53 PM
|
|
Hi,
I still think useCache should certainly default to false.
Slow performance is much easier to detect and diagnose than extra memory usage, and the bitmap will probably be cached in the DisplayObject while it is actually needed.
Hugh
Posted on February 24, 2013 at 9:45 PM
|
|
All current devices can handle image/textures at least as big as their screens.
If you add the assets as exact-size bitmaps, you can create as few tilesheets as possible by packing them at runtime according the the max-texture-size of the device that you are on.
Hugh
Posted on February 19, 2013 at 9:56 PM
|
