Experimental v71c now up! [MONKEY NEWS]
Monkey Forums/Monkey Programming/Experimental v71c now up! [MONKEY NEWS]
| ||
| Hi, [edit]Just uploaded v71b - see VERSIONS.TXT below for details[/edit] [edit]Just uploaded v71c - see VERSIONS.TXT below for details[/edit] Highly experimental! Ok, the main change here is that I've added a new Socket class and nuked pretty much all of the existing tcp/async stuff. See bananas/mak/echoserver_tcp, echoserver_udp and brl.httprequest code for examples of using Socket. tcp client/server and udp sockets all seem to be going ok, *except* on 'win store 8' apps, which only currently support tcp client sockets. Win phone 8 is OK though - yes, udp echo server runs on win phone 8! tcpstream survives, but it's now just a wrapper around a socket and can only be used synchronously. Not sure if having this is even a good idea if it can cause apps to be rejected? Perhaps it could be glfw/stdcpp only? In addition, brl.asyncdataloader has been replaced by DataBuffer.LoadAsync. These are some pretty major changes, but I think they're for the best and worth getting out of the way *now* instead of later. This kind of represents a 'clean start' for the network stuff, but if I've removed something you were using, and can't find a way to do the same thing with a Socket, please let me know and we'll see what can be done. There's also a new continuous GC mode (see CPP_GC_MODE below) and a few changes to the GC system. GC now occurs every CPP_GC_TRIGGER bytes allocated (defaults to 8Meg) and the algorithm used to determine how much to mark incrementally has been tweaked/improved/simplified. ***** V71c ***** Fixed Win8 mouse event handling. Fixed Win8 device orientation issues. Added PeekShorts, PokeShorts, PeekInts, PokeInts, PeekFloats, PokeFloats to DataBuffer. ***** V71b ***** Added ReceiveAll and ReceiveAllAsync to Socket for receiving known length messages. ReceiveFrom, Send and SendTo are already implictly 'all'... Version 1 of WinRT UDP sockets implemented - nasty stuff thanks MS, may not be 100% right! Fixed flash Print security exception. Fixed trans "Unsafe call!!!!!" bug. ***** V71a ***** Update admob SDKs to android=6.4.1, ios=6.4.2. Removed modules: brl.asyncdataloader, brl.asyncstream, brl.asynctcpstream, brl.asynctcpconnector. Added DataBuffer.LoadAsync. Changed brl.httprequest to use a brl.socket under the hood. Changed brl.tcpstream to use a brl.socket under the hood. Added brl.socket for all your tcp/udp needs. Fixed filestream on stdcpp target. Fixed win8 tcpstream. Added CPP_GC_MODE app config setting, one of: #CPP_GC_MODE=0 'Disable GC #CPP_GC_MODE=1 'Incremental collect every OnWhatever (default) #CPP_GC_MODE=2 'Incremental collect every GC allocation (adds some runtime overhead). CPP_GC_TRIGGER now controls how much memory is allocated before a GC 'sweep' occurs. Increase this for faster GC at the cost of more 'wasted' memory. Defaults to 8M. Added CPP_GC_MAX_LOCALS app config settings. This is used with GC_MODE 2 to track local object vars and defaults to 8192. Trans uses 445 locals to build itself, so this should be plenty for most apps but if you're doing something very recursive you might want to bump this. Tweaked makedocs. |
| ||
| #CPP_GC_MODE=2 'Incremental collect every GC allocation (adds some runtime overhead). nom nom nom! |
| ||
| Thanks Mark, that's pretty cool! |
| ||
| Version changes for 70.g are not mentioned. Aren't there any? |
| ||
| That's awesome. Specially the GC!!! By the way, care to mention wht are the makedocs tweaks? |
| ||
| I guess the html5 audio problem i reported earlier sneaked its way back into v71 :-/ Why was MServer altered again? |
| ||
| Ok, i get AudioError in html5 and IE even in 70f. Now i dont know, me confused. edit. Guess i need to switch to mp3s on IE. |
| ||
| Ok, i get AudioError in html5 and IE even in 70f. Now i dont know, me confused. edit. Guess i need to switch to mp3s on IE. |
| ||
| @MikeHart: Now Monkey has a user agent detector and looks for specific audio file formats depending on browser. I don't think there's an audio file format that can be used on all browsers (maybe wav, but not sure). |
| ||
| GC options. Awesome, many thanks! |
| ||
| good stuff :D |
| ||
| Thank you, Mark. That's a huge update. |
| ||
| Great changes! |
| ||
| Can anyone explain to this dummy (me) whats the difference\benefits of these #CPP_GC_MODE=x options? I know what they're for but why would I pick one option over the other? |
| ||
| Target "C++ Tool": cc1plus.exe: error: unrecognized command line option "-Wno-free-nonheap-object" TRANS FAILED: Error executing 'g++ -Wno-free-nonheap-object -o main_winnt main.cpp -lwinmm -lws2_32', return code=1 ? |
| ||
| whats the difference\benefits of these #CPP_GC_MODE=x options? Generally you'll need option 1, but option 2 is best explained by Ziggy here: http://monkeycoder.co.nz/Community/post.php?topic=3610&post=48680 option 1= games, option 2 = heavy processing apps also, neither of these are for concurrency yet. |
| ||
| > Version changes for 70.g are not mentioned. Aren't there any? Oops - forgot. 70g is exactly the same is 70f, only with the iOS DisableKeyboard fix added. |
| ||
| Something seems not right with new GC for Cpp. I have a pretty fast computer and in the past I've never had any performance issues with cpp or glfw. With this new version, any of the gflw target examples just can't hold 60 fps and have a lot of stuttering. If I look at the windows task manager while a mojo/glfw app is running and enable the option to 'show kernel times' I can see that 80% to 90% of processor usage is being used by the windows kernel, which usually means memory allocations. I've tried many different settings for the new GC options but always with the same results. Anyone else seeing this? |
| ||
| Great!! Thanks a lot Mark. |
| ||
| > If I look at the windows task manager while a mojo/glfw app is running and enable the option to 'show kernel times' I can see that 80% to 90% of processor usage is being used by the windows kernel, which usually means memory allocations. Very strange, not having any such problems myself. Does it happen with the firepaint demo? I've tested that pretty thoroughly and it appears to be going roughly the same as it was. What are you getting memory consumption wise with firepaint? I'm getting around 40Meg here with lots of 'bits' flying around. The new GC should certainly not being causing any extra memory allocation - memory allocation should (still) be completely up to your program. |
| ||
| any chance to see native bluetooth support ? |
| ||
| What about https, like for secure REST services? |
| ||
| Hey Mark, could you consider properly adding the "Inline" keyword to Monkey? Correct me if I'm wrong, but from what I've heard, it's not actually implemented. Am I right about this, or have I overlooked something? If it isn't a feature right now, but will be in the future, could you make "Trans" ignore it temporarily? If it just ignores it, then code written while the "Inline" keyword isn't implemented would become more efficient later down the road. Technically, all of the in-lining could be done by "Trans", so it really wouldn't be an issue when it comes to the differing targets. This could potentially give Monkey-based programs better performance. If this is/will be implemented, I'm guessing it would look like this: Function Test:Void() Inline ' Or something like that.Assuming it isn't there already, I may just do it myself; and that could get annoying when Monkey gets more updates. |
| ||
| [edit] forget it ... i'm an idiot .... ;) [/edit] |
| ||
| This could potentially give Monkey-based programs better performance. i think every compiler for every target does this automatically (except the BlitzMax target). |
| ||
| Yes, Adam is right. Inline is just a suggestion anyway and the compiler is free to ignore it. PS: If you want any class methods to be inlined you should declare them Final, virtual methods can't be inlined by the compiler (by gcc at least). |
| ||
| I'm having problems after building my Alcatraz game for Win8. I'm testing it on the simulator (I don't have a WinRT tablet) and when I rotate it, the display gets messed up: If I start the game on portrait mode it starts ok... (is there an option to lock it to landscape?), but if I rotate the simulator, this happens:  Same thing if the other way around: I start at landscape and rotate the device, to get this:  I'm using autofit, if that's anything - game works fine on all targets. Another thing: even if I'm not in the simulator, the mouse position isn't updated properly. I just have in my game:
#If TARGET="glfw" Or TARGET="html5" Or TARGET="win8" Or TARGET="flash" Or TARGET="xna"
IGGraph.drawImage imgMouse, VMouseX(), VMouseY()
#End
But on Win8 the mouse position only gets an update when I'm pressing it down. Surely, at least on Win8 on PCs it shouldn't behave this way?? (IGGraph.drawImage is just a wrapper for DrawImage, nothing fancy about it) Edit: Got a sample code to reproduce the problem: Mouse won't move unless you press the left button, and if you rotate the display, it will be rendered in a wrong way. Edit 2: Even locking the game to landscape mode in the manifest file, It is still rendered wrong when rotating: (apparently the simulator doesn't care if you lock the rotation or not...)  |
| ||
| I don't trust compilers to know when something should be inlined. |
| ||
| I don't trust compilers to know when something should be inlined. Although it might be hard to admit, compilers are much smarter than us most of the time :P |
| ||
| from http://stackoverflow.com/questions/8450030/can-modern-c-compilers-inline-functions-that-are-defined-in-a-cpp-file "I jump between being impressed by my C++ compiler's (MSVC 2010) ingenuity and its stupidity. Some code that did pixel format conversion via templates, which would have resolved into 5-10 assembly instructions when properly inlined, got bloated into kilobytes(!) of nested function calls. At other times, it inlines so aggressively that whole classes disappear even though they contained non-trivial functionality." And I'm pretty sure HTML5 wouldn't compile so fast if it used any sophisticated inlining algorithms. |
| ||
| And I'm pretty sure HTML5 wouldn't compile so fast if it used any sophisticated inlining algorithms. Mozilla has a great article on its js compiler. it's an interpreter at first, then as the program runs, it collects data and starts to compile sections at a time. https://blog.mozilla.org/javascript/ I'm all for an inline declaration, but there are more important things that monkey needs at the moment. |
| ||
| I agree, it is not as if we got Monkey so we could 'hit the metal' anyway! I must experiment a bit and see if inlining would be useful - it's easy enough to test. |
| ||
| UDP! Awesome stuff. - Rich - |
| ||
| > I'm having problems after building my Alcatraz game for Win8. I'm testing it on the simulator (I don't have a WinRT tablet) and when I rotate it, the display gets messed up: I've just uploaded v71c which should have much better Win8 display orientation handling. You can ignore the glitching in the simulator when display rotates - I've tested on a 'real' device and it's much smoother. To 'lock' rotation, use the same config setting as win phone 8, eg: #WIN8_SCREEN_ORIENTATION=2 for landscape only. |
| ||
| Thank you so much for continously enhancing your product. |
| ||
| Thanks Mark! As soon as I'm done with University tests this week, I'll try it! |
   |