|
Viewing 1 to (14 Total) |
|
Hello Hugh,
thx for that, I should have spotted that GetNextWake is checking timers.
I will retest once I'm back from holiday.
Regards
Jiri
Posted on February 12, 2012 at 7:02 PM
|
|
Joshua,
 , ok I will try to explain it one more time, I'll give you some reasoning: I am trying to send some data over network every 15ms.
It has nothing to do with FPS of my project (so not when Event.ENTER_FRAME occurs).
Your Actuate library, as you know, works with ENTER FRAME event, and I think that's wrong as well, although if use it only for graphics, you can go with it.
I guess is hard for you (and maniacdev) as flash devs to grasp the fact that I want (and is usual out of the flash world) logic/networking/whatever to run 3 times faster and independently of fps (Event.ENTER_FRAME).
Posted on February 10, 2012 at 7:45 PM
|
|
Hello Hugh,
no, I am saying that you cannot have
haxe.Timer working with interval SMALLER and INDEPENDENT of fps.
You actually can on some platforms, and not on some others, and I think the problem is in event loop part of code I posted earlier.
Regards
Jiri
Posted on February 10, 2012 at 7:29 PM
|
|
I would pretty much called that a bug.
So instead of saying "that's ok, you can do something else" (your advice is off anyway) I had a look into sources.
In SDLStage there is :
// Sleep if required...
double next = sgSDLFrame->GetStage()->GetNextWake() - GetTimeStamp();
if (next > 0.001)
{
int snooze = next*1000.0;
sgTimerActive = true;
sgTimerID = SDL_AddTimer(snooze, OnTimer, 0);
event.type = -1;
SDL_WaitEvent(&event);
if (sgTimerActive && sgTimerID)
{
SDL_RemoveTimer(sgTimerID);
sgTimerActive = false;
sgTimerID = 0;
}
ProcessEvent(event);
}
So it does sleep :
double next = sgSDLFrame->GetStage()->GetNextWake() - GetTimeStamp() * 1000.0;
That's exactly what I was expecting when running my simple project.
If I took the naive approach and just decreased the sleep time, my timer is working and I get perfect results on Linux:
TimingProject.hx:43: onEnterFrame : 1001
TimingProject.hx:42: onTimeChange : 207,200,200,199,194,
TimingProject.hx:43: onEnterFrame : 2001
I will fill bug inhttp://code.google.com/p/nekonme/issues/list...
Regards
Jiri
Posted on February 08, 2012 at 7:54 AM
|
|
The haxe.Timer does not work on some platforms as expected, and is affected by the FPS setting for the project.
Here is sample project demonstrating the issue : http://min.us/mXgf7Mue2
In the sample project, the FPS is set to 1 second, and the timer to 200ms. For webOS and flash I am getting acceptable results, not so for Linux and Windows.
webOS : [ok]
TimingProject.hx:43: onEnterFrame : 1003
TimingProject.hx:42: onTimeChange : 216,196,216,201,172,
TimingProject.hx:43: onEnterFrame : 2004
Linux: [ko]
TimingProject.hx:43: onEnterFrame : 1000
TimingProject.hx:42: onTimeChange : 18,0,0,1,980,0,0,0,1,
TimingProject.hx:43: onEnterFrame : 2000
Windows: [ko]
TimingProject.hx:43: onEnterFrame : 1000
TimingProject.hx:42: onTimeChange : 33,0,0,0,970,
TimingProject.hx:43: onEnterFrame : 2003
Posted on February 07, 2012 at 3:03 PM
|
|
You don't need to pollute the forum with whole output .
You need to checkout the sdl-static svn and it has to be next to your nekonme dir.
Did you bother RFTM? http://www.haxenme.org/developers/source/...
Posted on February 01, 2012 at 11:44 AM
|
|
I get this error when running in wrong directory (basically the error says it cannot read Build.xml). Did you change to project dir?
Posted on February 01, 2012 at 11:37 AM
|
|
Hello Joshua,
could you please please fix the documentation
http://www.haxenme.org/developers/source/...
because is wrong, as explained above.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
Linux installer installs stable binary release so that's completely off topic, but it is rather strange anyway. It's actually Ubuntu installer as it expects apt package manager, and the "magic" it does with neko is not clear to me either. If hxinst-linux installs 32 bit version of neko itself, then trying to uninstall using apt makes no sense. Anyway, I am using neko from repo, can do what install script does 10 times manually, still not able to built command-line tools with well known error
Called from core/IO.nml line 233
Exception : Overflow(read_i32)
Error : Neko compilation failure
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
But as I said, that's completely different story, my point is that it took me few hours to build nme from sources just because the documentation is misleading. I am pushing for documentation update, because the last thing you want is punish people for ReadingTFM , and honestly, last thing you do is disbelieve the instructions.
Regards
Jiri
Posted on January 31, 2012 at 6:40 AM
|
|
Hello Joshua,
the 32/64 default is really just a minor issue.
What really needs to be fixed in thehttp://www.haxenme.org/developers/source/... is:
1) the command-line tools have to be built AFTER the binaries are built
2) copying run.n from different release will generally not work so suggest that is wrong I think
The point 1 seems/is is just stricter version of point 2, but surprisingly the documentation explicitly suggest that, as If command-line tools and ndll binaries are not tightly coupled (they very much are).
Could you please fix that yourself or forward this info to someone? It might save some other people quite some time. I know it was harder for me as I could not built command-line tools on my box. Is actually someone looking into this 64bit unixes (Linux, OS X) neko issue?
Anyone thanks a lot for you work and looking after this issue
Regards
Jiri
Posted on January 30, 2012 at 4:09 PM
|
|
Ok, solved.
The command line tools have to be built after building the binaries.
The documentation needs to be fixed :http://www.haxenme.org/developers/source/....
I would also change the part saying "for your current desktop run : haxelib run hxcpp Build.xml" and "for other targets .... ... haxelib run hxcpp Build.xml -DHXCPP_M64"
as my desktop is 64bit linux and the former command fails for me as the latter is my current desktop and not any other.
Thanks Jiri
Posted on January 30, 2012 at 9:14 AM
|
|
Hello,
I am trying to use the svn version for the exact same reason (to test the new swf feature) but I have different issue.
Uncaught exception - load.c(352) : Primitive not found : ... nme-svn/nme//ndll/Linux64/nme@nme_curl_create(5)
I found this IRC discussing the same problem you had Joshua:http://echelog.matzon.dk/logs/browse/haxe/1326668400...
I did update sdl-static, recompiled everything I know of
nme-svn/nme/project# haxelib run hxcpp Build.xml -DHXCPP_M64
nme-svn/hxcpp/runtime# haxelib run hxcpp BuildLibs.xml -DHXCPP_M64
with no luck. Do you know exactly what gets compiled against what? Anything else to recompile? My haxelib dev path is set ok (checked it is using dev version of run.n and ndll).
Also I have 64bit Ubuntu, so had to get run.n (compiled from svn) from my win box [annoying  ]. You mentioned that you had to recompile the command line in order to fix this issue. In this light, the advice given herehttp://www.haxenme.org/developers/source/... "or copy "run.n" from a public release of NME into your SVN directory." is wrong isn't it? You would endup having svn version of ndll and release version of run.n.
Thanks a lot for help
Posted on January 30, 2012 at 5:56 AM
|
|
Hello,
I have just started with the Actuate example when testing haXe/NME as a development frmwk, but the example does not work on my Pixi Plus. Is there sth thats need to be changed/configured for it?
I compiled it using
haxelib run nme test Actuate\ Example.nmml webos
it compiles fine, it is installed on the device, but does not run.
Thanks
Posted on September 11, 2011 at 7:17 PM
|
|
Hello,
I have just started with the Actuate example when testing haXe/NME as a development frmwk, but the example does not work on my Pixi Plus. Is there sth thats need to be changed/configured for it?
I compiled it using
haxelib run nme test Actuate\ Example.nmml webos
it compiles, it is installed on device, but does not run.
Thanks
Posted on September 08, 2011 at 6:54 PM
|
|
Indeed, the XML got parsed out somewhere on the way, so your solution is not part of the content 
Posted on September 08, 2011 at 6:48 PM
|
