MonkeyPro V66 now up! [MONKEY NEWS]
Monkey Forums/Monkey Programming/MonkeyPro V66 now up! [MONKEY NEWS]
| ||
| Hi, MonkeyPro V66 is now up! File streams have been added to the brl module (not supported in html5/flash). Use standard file paths on desktop targets, or prefix file paths with "monkey://internal/" to access internal storage on android, ios, xna and psm. Note that you wont be able to open files in "monkey://data/" on all targets, so this will mainly be of use for caching data etc on non-desktop targets. I've also had a bit of a play around with update rates and syncing, particularly on the PSM where things will hopefully run a bit smoother now. It turns out the PSM appears to have a slightly strange vsync mechanism - it will vsync, unless 1/60 of a second has passed since the last render, in which case it wont! Or something. Anyway, Monkey should deal with this better now, but please note that the PSM target (and XNA if you have #XNA_VSYNC_ENABLED=True) will no longer issue multiple updates per render if things appear to be slowing down - I just couldn't work out how to get it working usefully/cleanly with the PSM's vsync mechanism. I'm starting to think the whole 'multiple updates to catch up' idea isn't so hot anyway - esp. when things are vsynced. With vsync on, there's a chance executing extra updates will just cause the next render to miss the next vsync, and therefore be forced to wait for the one after that, resulting in an even bigger lag. I'll think about this a bit more, but right now I'm tempted to make update rate a 'max FPS' rate, and leave it up to clients to deal with slowdowns - ie: as long as your code executes within the given update rate, everything works. If not, you're own your own! In a lot of cases, you may not give a stuff if things chug a bit here and there, and NOT doing the multiple updates thing will mean it gets back to normal sooner. Finally, there are some Mac fixes in there and the opengl samples should work again. I also had a quick hack at minib3d and got the demos going although I had to prefix file paths with "monkey://data/". Modules: brl - added filestream module. psm/xna - tweaked update rate logic, should be a bit 'cleaner' now esp. on PSM. Added XNA_VSYNC_ENABLED config var (defaults to false) to XNA. Use this + 60FPS update rate to get 60FPS on WP7. xna/psm mojo - changed SaveState/LoadState filename to '.mojostate'. Targets: Added monkey://internal/ support to glfw, stdcpp, android, ios, xna and psm targets. Fixed ios view controller orientation issue with ios6.0. Trans (V1.42): Improved support for spaces in preprocessor stmts. ios target now creates a Documents dir on simulator for use by //internal/. |
| ||
| Thanks Mark! It becomes better and better. |
| ||
| Thanks! Do you plan to add 'inline' in Monkey? As I know 'inline' word reserved by Monkey language. Maybe this code structure can increase some FPS (+1 or +2). |
| ||
| Amazing. My game is running perfectly at ~60FPS on my Lumia 900 Windows Phone now. Seriously, Christmas has been coming about once a week for a few weeks around here. Mark, thank you so much for your hard work and dedication to your users and to Monkey!!!!! |
| ||
| Merged monkey-ext with v66. Mac/Linux users will need to compile trans themselves (development branch will only ever have the latest winnt build; stable merges will have all three builds). |
| ||
| Thanks. Much appreciated. |
| ||
| Thanks, Mark! :) |
| ||
| Wow. The rate you push out these huge updates is incredible. Thanks a lot. |
| ||
| excellent stuff StuC |
| ||
| Great stuff, so many updates :)) |
| ||
| Thanks Mark. BTW, it may be time now to move the WP XNA project up to 7.1 (Mango). |
| ||
| Thanks Mark your continues and quick efforts! |
| ||
| I see that the Android target now supports file streams - does that mean that I can write HTML files with Monkey on Android now? |
| ||
| "I'm starting to think the whole 'multiple updates to catch up' idea isn't so hot anyway - esp. when things are vsynced." The only point I'd make here is that AFAIK people can easily bypass the multiple updates as it is, by ignoring the standard OnUpdate() and instead calling an update function at the start of OnRender(). [Also allows use of ReadPixels() during update!] So there's probably no special need to take the current version out if it's doing no harm. But as you say, it's probably not doing a great deal of good either. In many cases chug would be preferable to a big graphics catch-up. Catch-up is fine if your enemy moves 10mm across the screen instead of 2mm between renders; not if he jumps 7 cm instead of 1! |
| ||
| Awesome, last night i just finally updated my Mac version of Monkey to v65 lol. But anxious to test out the PSM render updates later today :)! |
| ||
| I agree with Gerry Quinn that right now, it's really easy to control whether the OnUpdate happens in OnRender or not, so I hope it doesn't change. To go back and forth, I simply rename my OnUpdate to OnUpdateFromRender, then call that from the top of OnRender, and make an empty OnUpdate. To switch back, I just swap where I call it from. It's super easy as it is, and there have been some cases where I needed my game to worry more about the Update than the Render and "skipping" a render frame needed to happen because having the game slow down screwed with the clock that was timing you. |
| ||
| vbnz wrote: Thanks! Do you plan to add 'inline' in Monkey? As I know 'inline' word reserved by Monkey language. Maybe this code structure can increase some FPS (+1 or +2). oh yes, I hadn't even realized this. It wouldn't be easy to quantify gains, but I'm sure there would be some with things like vector classes. |
| ||
| I'd like inline too: there are some cases where I'd like to use a function but just couldn't bear looking at the inefficiency! Even if 99% of the time it wouldn't matter. Things like Max and Min would probably benefit from inlining too. |
| ||
| Mark the feature set is not really transparent. Can you add a table, where we can see direct what platform/target support and what not like this: |Windows|MacOS |iOS |Android|... | FeatureA| | | | | | FeatureB| | | | | | FeatureC| | | | | | |
| ||
| I think it would be great if the compiler could throw a sort of warning when you use a feature (a class or whatever) that is not supported in all targets, so you don't get the problem later when deploying for an speciffic target |
| ||
| Arghhhhhhh!!! All the updates are too much for my little brain to handle, am I complaining, erm... NO! Many thanks Mark! Good stuff! |
| ||
| Can you add a table, where we can see direct what platform/target support and what not +1 here. |
| ||
| Firehose mode: on. Well, I know what the week end will be made out of :) |
| ||
| Hi, > I see that the Android target now supports file streams - does that mean that I can write HTML files with Monkey on Android now? Theoretically, but I've only tested files written to monkey://internal/ so far. But nothing else can read them I think? Writing files elsewhere should be possible but is likely to involve permissions twiddling. Also, streams don't support text well yet, so you'll have to deal with writing chars/UTF-8 etc yourself. I plan to add yet another bunch of text/UTF-8 routines to help with this soon. > I agree with Gerry Quinn that right now, it's really easy to control whether the OnUpdate happens in OnRender or not, so I hope it doesn't change. Well, it's already changed on PSM and XNA-with-vsync which, as mentioned above, no longer attempt to 'catch up' with multiple updates. And I'm not convinced it's a good thing to even attempt on vsynced (or perhaps any) targets, esp. on the PSM with it's freaky vsync system. In general, if things are 'maxing out' and you throw in more updates per render, there is a good chance, esp. on vsynced systems, that you are just making things worse. Monkey wont execute more than 8 updates per render anyway (after which the system resets itself) so unless something gets destroyed pretty soon, chances are all you've done is slowed things down even more for no real benefit. Another issue is how do you even detect skipped frames? On a vsynced system, every update/render will take 16.66ms - but timers can't measure this *exactly* (oh for a vblank interupt!) and it's all to easy to 'mis detect' a slowdown. When this happens, an extra update gets thrown in and things will appear to speed-up or lurch for a frame every now and then for no apparent reason. This is the problem I encountered when I attempted to reintroduce 'catch ups' to the PSM target - every misdetected 'slowdown' (which will happen regardless of how much is actually going on) resulted in a noticable lurch. I started messing around with epsilons and stuff here, but it just got ugly...esp. since only the 'first' render is vsynced on PSM. And I think I only really noticed this because things are now going so sexily smoothly on PSM/WP7! Yes, there are probably some situations where the catch up system works/helps. But I suspect there are also many where the system is responsible for worse slowdown and random lurches. IMO, the only 'safe' way to deal with slowdown is to use time scaling. Yucky, but true. Of course, you can always just write to a frame rate and ignore slowdown... I'll keep hacking, but please be aware that PSM/XNA+vsync, for now anyway, will only perform one update per render. > Can you add a table, where we can see direct what platform/target support and what not Yes, I've been trying to think how this could look for a while now - will get onto it. > I think it would be great if the compiler could throw a sort of warning when you use a feature (a class or whatever) that is not supported in all targets, The brl modules now include a 'compatibility' #If at the top that will cause an error if you try and use them on the wrong target. You can still just Import brl and it will conditionally import target-valid features only though. The compiler can't really check for invalid URIs or filetypes, as these can be in variables, eg: Local image:=LoadImage( path+"/myimage.png" ) 'is path legal for this target? |
| ||
| The feeling of smoothness to the player is everything when talking about performance and latency in my oppinion - and I take that from networking. Players playing with a latency of higher but smooth latency complain less than those at really low latencies that vary - even if the variation is below the higher one. It is the irregularity people then to "notice". So if one way of framefixing makes things "feel" smoother over "math" precision then I would vote for the first myself :) |
| ||
| Well, it's already changed on PSM and XNA-with-vsync which, as mentioned above, no longer attempt to 'catch up' with multiple updates. And I'm not convinced it's a good thing to even attempt on vsynced (or perhaps any) targets, esp. on the PSM with it's freaky vsync system. I'm a new kid on the Monkey block but I don't think it's a big deal to change to the new method. The only case I can think of where a perfect timed OnUpdate() (i.e. guaranteed to be X times a second) is needed is for predictable physics behavior with the math for forces, gravity, cooldown, etc. over time. If needed then Fixed rate logic can be forced in OnUpdate() by the app maintaining its own timer and calling its own update several times, if needed. That might bring us back to square 1, though. I see why people are calling OnUpdate() in OnRender() as it has secured a smoother play but perhaps the new changes have negated that need? I also like the MC+V model of Monkey... one of the things that drew me to it. Call me crazy but I would even go for an OnInput() that was only called when the player (or message pump) did something, to make it a true MVC! :) |
| ||
| As I produce music education software, I need a very stabil OnUpdate(). The 16.6msec of a 60Hz are already a lot of time for accuracy of corresponding audio events (f.e. a drum player). It would better to have 200Hz, which reduces the latency to 5msec. But in monkey the OnRender() is connected to the same rate. And this often is to short to get the display painted. There are cases where I have to reduce rate to 30Hz on slower targets. But with this 33.2msec the latency and inaccuracy is now really problematic. I made experiments with skipping some OnRender()... [monkeycode]OnRender() Step=(Step+1) Mod 5 If Step>0 Then Return .....[/monkeycode] ...because I often have nothing to draw new.... ...but this caused heavy flickering on android target. It seems that there are two backbuffers. And when you skip OnRender() you see the both buffers rotational. So for me would be perfect an independent rate for OnUpdate() and OnRender(). So, if you plan to change the accuracy behavior of monkey, please include also my considerations. |
| ||
| In BlitzMaz I've always run my game logic at 200Hz and render at 60Hz. It would be cool to be able to do something similar in Monkey although of course 200Hz may not be suitable for slow mobiles. |
| ||
| Hey Grey! Stop posting on the forums and get back to working on the Monkey Grey Alien Framework! :) Gutted I ever sold the BlitzMax version! :/ |
| ||
| Thank you a lot Mark ! Files stream was a point i was really waiting for. When Monkey will manage text files stream it's going to be a real paradise in my head! :) |
| ||
| MidiMaster, have you tried hacking mojo? I think I suggested this before, maybe to you or maybe to somebody with a similar problem. It is not too hard to find where the render decision is made in native code (if you like, just search for magic number 7!), and reducing the number of renders should be easy. However I think you really will need to go a bit further here. Your fundamental problem is that rendering takes too long. What you really need, I believe, is to do some updates actually during a render. Of course if keys are pressed you need not change any drawing until the next render cycle, but you can record the time and/or adjust the sound output. Now I think of it, have you tried calling an update function several times during the rendering process? Perhaps that is all that is needed. I mean something like: I would definitely try experimenting with the above. Try adding a function that just records the time, and see how it works. |
| ||
| Actually, Midimaster, now that I think about it, I am 99% sure that the above is what you need. Monkey/mojo aren't going to have threading anytime soon, if ever - so something like the above (a simple form of cooperative multi-tasking) is the only way to go. |
| ||
| yo, could you put the same keyboard shortcuts in Ted as in Monk? |
| ||
| Here is your solution, MidiMaster, I think! I decided to test it out and it works very well. Tested in HTML5, release mode: Output at start: > 28 29 30 31 32 33 33 34 35 36 37 > 59 60 61 62 63 65 69 73 76 80 83 > 89 92 95 Output at end: 4838 4849 > 4860 4870 4880 4891 4901 4912 4922 4933 4944 4954 4965 > 4976 4987 4997 5009 It takes a bit longer over time, because of all the printing. But as you can see, the temporal resolution, on this platform ar least, is very good. You can see it sometimes takes a little while to copy to screen, but that may well be different (for better or worse) on your target platform. Hope that helps, anyway. |
| ||
| Thank you Garry Quinn for your tests. I did'n t dare ignoring the rule that all action should go to OnUpdate() in monkey. Isn't there no reason to do it? Does't it care? So..what is it good for use OnUpdate()? I will give them a try. But the kernel of my problem remains. I will have longer periods of waiting between the vsyncs: ... 37 > 59 ... OK... if i am able to "slowdown" my drawing to 10msec, I only have to wait for further 7msecs until the next OnRender() starts. But is this useful? The main problem remains, that I have to draw something on each OnRender(), even if there is nothing new to draw. Hacking mojo is not my thing... each update I would need to repeat the hack. A optimal solution would be a OnUpdate() rate of 120 and a OnRender() rate of 30. Is it difficult for Blitz-Research to de-couple both rates? |
| ||
| Since the update rate you want is a nice multiple of your render rate, can't you do something like: * Set the update rate at 30 to match the rendering * Move your update code into an Update() function * Call Update() 4 times from OnUpdate() That would be the easiest way of having two separate rates. However, if you want to make sure the updates don't get slowed down by the rendering, that would involve threading, and I guess that's why there is only 1 update rate. |
| ||
| MidiMaster, I think you probably don't have to do any hacking. A solution like what I gave is probably the best for you. Try running the code on your target device, except instead of all the printing - which may slow things down - keep stats on how long the gaps are, and just print them out at the end. If you're lucky, your targets will copy the backbuffer fast. If they don't, hacking is your only option to improve it further as you will have to access threads on the target. Which might very well not even be available to you anyway. I think the reason it says to do updating in OnUpdate() is just to advise you of standard coding practices, and of course you would get the benefit (if any) of the skipped renders that were talked about earlier in the thread if rendering is too slow. It is difficult to separate OnUpdate() from OnRender(). You would need threads, for a start - and then there is the problem of what to draw in OnRender() when you don't know if you are in the middle of an update! It makes things complicated for normal purposes. The best solution is to have a fast update rate, so the machine is kept busy all the time rendering. If you can't get a fast enough rate, you may have to deliberately increase the amount of drawing you do to slow down rendering. This will prevent it idling between calls to OnRender(). Then, if you divide your rendering into approximately equal sized blocks, you will have mini-updates at something close to the rate you require. Of course you must check the time at each mini-update, because they will not be perfectly regular, but that should not be too much of a problem for a keyboard simulator. There is another issue as well: you will have to do some arithmetic with keypresses, as they are only reset to zero at the end of the standard OnUpdate(). I don't think you have to hack anything here, but you will have to monitor the changes in your mini-updates, rather than the totals. [That is another reason people are advised to use OnUpdate(), I guess.] |
| ||
| Hi, > So..what is it good for use OnUpdate()? The idea of OnUpdate is to use it to process user input and advance game time/logic. KeyDown/KeyUp etc states are updated just before OnUpdate is called, so this is the place to check keypresses. The idea of OnRender is to refresh graphics. Note that OnRender may be called even when your app is suspended (eg: if the desktop needs to be repainted when a window is moved), in which case you should not update anything or the app will appear to continue to 'run' in steps/spurts even when it's suspended. > There are cases where I have to reduce rate to 30Hz on slower targets. But with this 33.2msec the latency and inaccuracy is now really problematic. There is probably little/nothing you can do about this - during OnRender, no user input is updated/processed (semi target dependent) so even calling multiple OnUpdates inside OnRender will not help with 'input lag'. As Gerry mentions, threads could help with this but they wont be appearing in Monkey any time soon, if ever. So your only choice here is really to speed up rendering. Some ideas: * If the scene is static between keypresses, you could try just copying the entire backbuffer to an image with ReadPixels/WritePixels whenever it changes, and just draw this single image when it doesn't change. This should reduce lag, but the cost of generating the image might be high... * Precache as much as possible in a static image and only draw changes, eg: if you're drawing a keyboard, create an image of the keyboard with all keys 'off', then draw this + all 'on' keys when rendering. |
| ||
| Thanks mark for this nice release :) |
| ||
| Great stuff, Mark! golomp wrote: Files stream was a point i was really waiting for. When Monkey will manage text files stream it's going to be a real paradise in my head! :) Ditto. I too will know Monkey bliss once filestream handles strings. :) |
| ||
| Hi, Not sure what people are expecting 'text stream' wise here...ReadString/WriteString? What else? Streams aren't really 'parsers', so if you're expecting ReadInt() to parse an int from a string it probably wont happen in streams. The best way to deal with text files right now is probably just to use LoadString (which should now work with file paths) and parse the string yourself. |
| ||
| It sound like the java way of writing and reading to me in a binary format. I am wrong ? |
| ||
| Yes, files are 'binary' blobs of data. So are DataBuffers. To read a text file, you're probably best off to just use LoadString. |
| ||
| Yeah i think so. I think the problem lie in the fact that you actually see what in the textfile comparing to when writing in binary format. But i may be wrong :) Either ways you still can encrypt it using some algorithms around.. |
| ||
| Mark Sibly wrote: "There is probably little/nothing you can do about this - during OnRender, no user input is updated/processed (semi target dependent) so even calling multiple OnUpdates inside OnRender will not help with 'input lag'." Are there not native functions you could call on most platforms to read keydown/touchdown status at least? Input is certainly being recorded (otherwise tap input would go dead if rendering was intense, and it doesn't). Surely there must be functions you can call to get at them even during OnRender()? |
| ||
| @mark that is exactly what I thought until today morning, when some people began talking about moving update related code to OnRender(). But your word clearified: game action code should remain in OnUpdate(). Only drawing things go to OnRender(). The creating of temp. images with WritePixels() indeed already helps with performance problems. This feature is very helpful and makes it possible use 60Hz also in "a lot of text"-based apps. @Kalakian A multiple call of Updates() in OnUpdate() helps nothing. With this I have 4 very fast Updates() and then again a lag of 33msec (at 30Hz because to much grafic in OnRender() )until the the next four. but I would need a Update() every 8msec! In fact the 16msec of a 60Hz timer are not a as big problem as the fact, that 60Hz OnRender() often cause heavy grafic card problems (rendering>17msec) and a skip of the next timer tick. But I see, there is no chance to reduce the frequency of OnRender() independent. ...the future will bring faster devices and solve the problems by itsself.. |
| ||
| marksilby wrote: Not sure what people are expecting 'text stream' wise here...ReadString/WriteString? What else? Streams aren't really 'parsers', so if you're expecting ReadInt() to parse an int from a string it probably wont happen in streams. The best way to deal with text files right now is probably just to use LoadString (which should now work with file paths) and parse the string yourself. Mark, my impression was LoadString was glfw only, since its part of the os module. That's what I was hoping a future filestream with its own ReadString/WriteString would get around, allowing reading/writing of multiple files on ios, android and glfw using the same mechanism. Or am I misunderstanding? |
| ||
| @jjsonick LoadString is also part of mojo.App, but until recently that version only handled data relative to the data folder and deeper. os.LoadString's a different function which takes a full filesystem path. |
| ||
| @Nobuyuki Ah, ok - so for mobile I use LoadString with a path suited to the sandboxed app's relative paths (which can now extend further than just the data folder), and for gflw, I use LoadString with a full windows/OS X system path, is that correct? I still need WriteString (so I can use multiple files instead of the monolithic .monkeystate via SaveState), but if that was added to mojo instead of filestream, I'd be just as happy. |
| ||
| Hi, > Are there not native functions you could call on most platforms to read keydown/touchdown status at least? On some targets, input events are polled. On some, they're event driven. On most event driven targets, events are only delivered on the same thread - ie: when control returns from OnBlah. Android may be the exception here as render happens on a different thread BUT I would like the freedom to be able to move OnUpdate to the same thread in future etc. Feel free to hack this stuff, but I'll likely maintain the update/render separation for the sake of consistent multi-target behavior. > Mark, my impression was LoadString was glfw only, since its part of the os module. Ah, OK. Mojo LoadString should be more flexible now, but may not yet be able to read from anywhere in the filesystem yet. I'll have a look at this soon. Ultimately, there will be only one LoadString! |
| ||
| Sorry for the double-posting, but this may be the better thread. Here's my plea for a LoadImageAsync for multiline spritesheets/frames. That would be just an overload of LoadImageAsync() that's equivalent to LoadImage() with frameWidth, frameHeight and frameCount. Currently there's only Function LoadImageAsync:Void( path:String,frames:Int=1,flags:Int=Image.DefaultFlags,onComplete:IOnLoadImageComplete ) |
| ||
| Any idea how to get portrait apps running on the Vita, anyone? |
| ||
| Mark said: "Feel free to hack this stuff, but I'll likely maintain the update/render separation for the sake of consistent multi-target behavior." I was just exploring the possibilities. I think I would look into doing it this way if I were making a keyboard-type application, but it looks like your suggestion of speeding up rendering is much preferable for the original poster anyway, and is working for him. My current project is a roguelike and mojo fills pretty much all my needs out of the box. Not a big fan of the hacking myself as a rule, but sometimes you have to show the software who's boss ;-) |
| ||
| Gerry, Would you contact me at the email address in my profile? I am interested in your project. Eric |
| ||
| Mark, Can you add this or something similar to graphics.monkey in the next release please? I want to store and reset the scissor using a cached array rather than creating a new one every frame. You already have one for GetMatrix(). [monkeycode]Function GetScissor( scissor#[] ) scissor[0]=context.scissor_x scissor[1]=context.scissor_y scissor[2]=context.scissor_width scissor[3]=context.scissor_height End[/monkeycode] |
| ||
| Ok, so I'm implementing the CONFIG changes. I see that when I use #CONFIGVAR+= "whatever" it automatically adds a semicolon ";" after everything. This doesn't work for everything and probably not ideal. The way I'm using this is for multi-line CC_OPTS to the compiler exports You probably could just check for the keyword toke="REFLECTION_FILTER" if that's where the semicolon is needed. |
| ||
| Hey mark do you plan to add html 5 async http get too ? Thanks! :) |
| ||
| Wow...alright, I've been waiting like 3 weeks to be able to test the new PSM update on the Vita and just finally did it now (my day job has been keeping me quite busy). The update definitely did help quite a bit. Framerates went from a stuttering 10-15fps to a steady and very playable 40fps right off the bat. It was still able to maintain about 29fps with 50 moving animated sprites on screen also. While its not quite optimal, i'd say its definitely a vast improvement! Thanks mark! |
| ||
| Neuro,Congratulations on your purchase! Do you like PSP Vita? |
| ||
| I also had a quick hack at minib3d and got the demos going although I had to prefix file paths with "monkey://data/". Mark, I tried that as well and although it works fine with GLFW I don't see any textures on my Android device. Did that work for you? |
| ||
| It says "Fixed ios view controller orientation issue with ios6.0." But I am still getting this error on a brand new game.build/ios/ folder Anyone else get this problem? I wonder if it's the fault of some Gamecenter code or something but it doesn't tell me where that exeception is being thrown and I have no clue at the moment how to catch it. :\ |
| ||
| Did you delete you build folder? |
| ||
| Neuro,Congratulations on your purchase! Do you like PSP Vita? Had it for a while now. Incredible portable game system, lack of games though. Hopefully the upcoming PSM App store can have something worthwhile to checkout. |
| ||
| Ah, I turned off the Gamecenter code and it's working fine now, so I just need to figure out how that is messing up.. |
   |