|
Viewing 1 to (52 Total) |
|
Grabbing hxcpp from googlecode i now have hxcpp built for 64bit, sdl-static built for 64bit (haxe,haxelib,neko are also 64bit)
but how the heck do i get nme rebuild to build 64bit version of nme??
Posted on January 28, 2013 at 3:38 PM
|
|
Okay, found out that 'nme setup linux' was failing, and guessing that is the problem.
Except that the command doesn't work on LMDE due to multiarch meta-package not being available. I installed the associated packages seperateld, and tried to modify the build tool, but the haxelib nme doesn't seem to work with haxe nightlies and i couldn't rebuild the tool.
Trying to build nme from source I'm getting an error now after resolving other things like getting svn hxformat
g++: error: unrecognized command line option ‘-W,l--unresolved-symbols=report-all’
running haxelib run nme rebuild
g++ is version 4.7.2
----
edit: it seems that g++ will accept -Wl,--unresolved-symbols=report-all so it seems the comma is in wrong place?
Posted on January 28, 2013 at 3:02 PM
|
|
I'm building on linux64. Latest nme + hxcpp available on haxelib. Currently on a very recent haxe nightly, but also tried with haxe 2.10
Posted on January 28, 2013 at 12:10 PM
|
|
bumpdump
Posted on January 25, 2013 at 5:37 PM
|
|
I've suddenly started getting this error when I tried to compile a small nme program i have:
I've tried with haxe nightlies, and with haxe 2.10
I've tried with nme 3.5.4 and 3.4.4
(And combinations thereof)
Everytime its the same thing, Null Function Pointer in neash ByteArray::__init__
This happens before my main method is even called.
(Compiling to c++)
Posted on January 18, 2013 at 2:24 PM
|
|
http://haxe.org/doc/neko/threads
doc is for neko, but same app exists in cpp.vm
The one thing to really watch out for, is that nme is 'not' threadsafe, so any api calls to nme need to be done from main thread, not one of your worker threads.
Posted on April 29, 2012 at 5:25 AM
|
|
What do you mean by preloader? for flash and html5 it means having a screen there whilst the rest of the app is downloading, but for other targets there is nothing 'downloading' the app is already all there on the device?
If you mean a loading bar whilst things like graphics and assets are loaded into ram, or pre-computations are being performed then you need to use a different thread to perform the loading of assets into memory, and pre computation, whilst the main thread simply renders the loading bar.
Posted on April 28, 2012 at 12:12 PM
|
|
That was the first thing I tried 
At present I've resorted to an older version of hxcpp (and haxe) when I need to compile something with hxcpp I'm going to try again when the haxe nightlies are working properly again since the latest I could try with was r4305
Posted on April 18, 2012 at 5:00 AM
|
|
http://pastebin.com/Zw4CmKqD
Posted on April 16, 2012 at 2:18 AM
|
|
one more reason to add a -float32 flag? ;p
Posted on March 24, 2012 at 2:21 PM
|
|
bumpadibumpbump.
I can only test from AS3 on an ipad1 as I have no mac or other device.
But through AIR for iOS I can get 100 boxes at default iterations (10+10) running at 45-48fps on an ipad 1.
Given that on my 3ghz desktop, i can get 820 boxes at about 80fps on average; I would imagine that haxe-c++ on ipad 1 should get 100 boxes at significantely more than 48fps if we take an approximation like: 80fps/3 for 1ghz cpu = 27fps, and a very conservative estimate that 100 boxes is 8x faster than 820 boxes (infact it should be a much larger increase in speed than 8x) to give 160fps?
Posted on March 23, 2012 at 8:22 AM
|
|
I notice that hxcpp still outputs code with things like hx::AddEq(x,y) instead of x += y, I can't remember what/if there was ever a reason for that?
Posted on March 10, 2012 at 9:19 AM
|
|
Got the arrays branch on github set up with compiler switch -D NAPE_ARRAYS to have almost all of the internal lists using an array underneath instead of a linked list.
Doesn't give any performance difference on desktop (slower if you enable it on flash), not sure what will happen with mobile!
-----
Also, in hxcpp, using Array::sort() is causing a segmentation fault, so on c++ when using -D NAPE_ARRAYS you must set space.sortContacts to false and avoid it calling it
Posted on March 10, 2012 at 8:49 AM
|
|
nape doesn't 'need' double precision really, box2d certainly gets away with single precision just fine.
I'm guessing since you mentioned it Huge that there's some hxcpp option to compile with single precision floats?
Posted on March 08, 2012 at 3:03 PM
|
|
Which examples? if you mean the ones in the documentation/github then they are up to date, whether using -lib nape from haxelib, or binaries (In fact it's part of my release script to ensure they do still compile before releasing an update).
There are parts of nape that could be multithreaded sure, trivially the impulse calculations can be split into the islands that exist which in most cases (the pyramid demo not being one them) allow more than one thread to be running. Having multithreaded impulse calculations for things like the pyramid demo where there is only 1 island would require partitioning the contact graph at runtime which I cannot imagine being an improvement in speed
Posted on March 07, 2012 at 8:33 PM
|
|
Though i'd post this here as well.
Though I have no mobile device on which to test nape, I hope other people can come up with those tests.
At present i'm testing with desktop at least and thus far I have these results (Using nape's stresspyramid demo)
nape-flashplayer: ~35fps
nape-haxe-c++: ~95fps
compared to (so far):
native-box2d-c++: ~180fps
And hoping I can do tests with box2d, and box2d-alchemy of the same exact demo, and also haxe port of box2d with flashplayer and haxe-c++ also and also physaxe with flashplayer and haxe-c++, though with physaxe it will be a lot harder to come up with an 'equivalent' test as it uses different algorithms for computing contacts and impulses so it will be based on getting the same 'quality' of simulation, rather than using same parameters.
Posted on March 07, 2012 at 1:39 PM
|
|
no blobbiness when redrawing without changing width/height of container, though there are some spurious pixels drawn where the blobs would normally be in a vertical direction:
http://i.imgur.com/jHKfk.png
Posted on December 08, 2011 at 3:52 PM
|
|
eg:http://i.imgur.com/gfLmm.png
Posted on December 08, 2011 at 9:59 AM
|
|
hardware mode, drawing with Graphics, when zoomed in (by zooming in i mean the sprite is scaled up, rather than flash player style zooming) there are blobs at each line join (including generated lines internally from cuveTo's).
I cannot yet find the point in the source where line joins are batched to try and find the problem.
Posted on December 08, 2011 at 9:21 AM
|
|
I always use svn versions (bar haxe itself when i'm using about a month old nightly since all versions in the last month or so have some fairly serious issues my code evokes which are yet to be fixed).
Posted on December 05, 2011 at 1:23 PM
|
