Forum Replies Created
-
Posts
-
Don’t be like that. I’m sure the community just needs a a push, you’ve come such a long way. I would hate to see all going to waste.
I don’t have too much time either but I could try to do my part. Got an idea; I’ve been writing a book on programming for a few years now and if It helps I could use the Monkey programming language as the focus.
It will focus also on Web and probably Node as back-end, and lot of work has been put into it already. It will be a serious one. Also It covers embedded programming and will have a authentic retro vibe but with a modern touch.
The book could double as an easy-to-read reference for Monkey?
Look, I’m sure you have many followers that are just waiting for the next step. You’ve always set a good standard. It’s a good idea to use other sites of course, but don’t give up now.
Another way might be to use the web platform, then you might use Chrome’s API to access the Serial port.
https://developer.chrome.com/apps/serial
It may be that SDL2 is not an easy API to deal with, there’s a lot of confusion and questions from many people how to handle things, It is not very well documented.
This is one of those areas where people ask lot of questions about, how to handle Operating System delays correctly.
SDL2 is so much different from SDL, e.g. you have to throw out repeated events yourself and make sure only the last one is left in the queue.
btw the reason I use Monkey2 v06 (June) is maybe because of the threads, which also made ted feel slower, and the whole packages slowed down, if you have a weak computer you can actually notice it. But mainly because of this code change which seem to do made more harm than good if you ask me.
https://github.com/blitz-research/monkey2/commit/fdaa6092e9209544a970264a8e87396f77838f60
I want to say that I’m trying to get faster touch input which is very important for the current project. The input must match perfectly to what is on the screen. The project is very picky and that is my main driving force.
A bonus would of course to also get smoother graphics compared to what Monkey2 currently allows, as I do know that it’s possible, but it is not a must. It’s fine.
I keep Monkey1 for my OCD that I have about perfect smoothness hah.
Monkey2 gives you a busines so I forgive it for not being OCD-Smooth (Im old school and like that kind of shite).The only example I have on this computer is closed source.
I’ve said this so many times and no-one seem to care. But sure, one last time.. This is the complete list of ONE SINGLE problem.
* Timers are limited to 90-120 times per second. Monkey2 seems to use SDL2 user-events to implement them, and that’s how all this is weave together to all the rest.
* Sometimes timers crash ios and Android. The easy fix is to comment away any timers but I do not know why this happens. Windows and macOS always run code with any timers without any problem, but they will give you an error message on exit instead. I read that even TED itself has this problem, probably bc it uses timers.
* Touch and Mouse always are always at least one or two frames behind what it should be (other events is not synchronized either).
* Graphic updates as events are processed, and events seem to try to catch up now and then. Keyboard releases, downpresses, mouse actions, touch and timers, they all have control over graphic updates.
The last one is important, because it allows some kind of visual test how event affects even the screen. It’s not the best test for this, but it shows what needs to be shown. I include a zip with source code for Monkey2, and also a Monkey1 version for those who happen to have that laying around, for contrast..
Monkey1 handles everything mentioned above perfectly, even if the test in the zip-file only shows how events affects screen updates, it should be noticed that the problem goes far deeper than that. But still the screen becomes a good reliable indicator.
Wasm might be the executable of the future but if we’re talking about the situation as it is right now then we still need true native code, and we will for a couple of more years..
The quality of the user experience would otherwise go down too much, and the marketplace is not ready for it.
Sure some things could be done but that would downgrade Monkey into some kind of Authorware.
this seem to be what has changed to increase the security in Android filesystem, i dont have any pacakaged solution yet as i dont have much time before Christmas. But it might give an idea to ppl.
https://developer.android.com/reference/android/support/v4/content/FileProvider
if setting it to targetSdkVersion 21 works fine, then we have the same problem. working on it
Isn’t version different? What if you use version 16.0.0?
Btw I recently updated my old Note2 samsung to Nougat 7.1 (the.1 is important becuase that fixes not just graphics and overall execution speed but input lag is reduced aswell). This was a great leap from the old Android versions. Monkey2 runs almost as good as on the other platforms onit. You could not say this about older Androids
As how Monkey2 works allaround..
I tried to compile to all versions of all platforms and these are the best ones, best as in they are quick and incredibly smooth.iOS 12 (had to use tricks to use older xcode and rely om the opengl to metal2 conversion, but it works increidbly well)
macOS Mojave (Maverick El Capitan Sierra are all on close 2nd place, but you can do more in Mojave)
Windows 10 (I cannot tell any specific verions that are best here as I have not found any differences on the updates)
Android 7.1 (huge difference from the older Androids, it also gives old Android phones a new life) Great software update if you code Monkey2.
I have the same question and the same goals. I want Monkey mainly for android and ios but I use it for macos and Windows too in my sparetime. I love Monkey1 for its stablity and solid smoothness.
Okay I can give my view on the matter.. sure.
I love Monkey2 for syntax, and how close it gets to be Monkey1 in its quality but it is NOT there yet. So when I need perfect smoothness and fast touch, i use Monkey1.
The Mojave + Monkey1 is to die for. Its perfect. But I need Monkey2 for creating on ios and Android.Make it work without any orobkems on latest Android and iOS.
Fix the event system inside and out, this would fix everything wrong with Monkey2 and I could throw Monkey1 away. The timers would work faster than 90-120hz, there would also not be any weird error messages anymore (those errors btw makes code nonexecutable android and ios sometimes), touch would be better and smoothness of the graphics would finally match Monkey1.Actually I’m trying to use some of my time to convert the event-system from m1 into m2 myself becuase im sick and tired of waiting but yes it is a nice language otherwise I would never be bothered tryging to fix it. I’m happy for Marks sake that he got what ssem to be a good fully paid job but noone else knows this machine inside and out so things are kind of.. stuck?
Yup it is the same thing.
I’ve been trying to convert some nice M1 scroll code to m2 code but the event API does not seem to generate events that are as synchronized as you would need.
For further comparison i used the m2 inertia scroller coder that was supplemented by one of the ppl om the blitzlab I think, (which is the best ive seen in Monkey2 so far) but I went back to trying to convert the nice m1 code. I conclude that the m2 event engine is totally messed up. This is one of those scenarios where you really need the touch events to match perfectly with the refreshrate of the screen.
Ya.. but it is not too hard.
Update to Mojave and update all the apps including Xcode, as usual.
Then download a version of xcode that works well with Monkey2, I use 9.4.x. Xcode always wants to overwrite itself so just be careful to change the name by hand before moving it into apps or it will overwrite the new one.
One more thing I forgot, never run both Xcode at once, don’t put them in direct sunlight, and never..ever.. feed them after midnight.
Heres the Apple archive with all the Xcode versions available.
https://developer.apple.com/download/
I can answer as it is a big deal for me as a macos/ios developer.
There are issues And it is a mess but i can tell you what I learned and use.
First of.. as I care for event handling and vertical blanking, and to have smooth graphics I need to use an older version (the newer versions claim to fix this in macos but, they are not fixed far from it. So I use June version (v06) until a new stable M2 pops up, which might be never.. I do reliase.
Sierra and High Sierra is the last ones that works nicely. Sierra especially. When you update to Moave to be able to compile for ios12 os or other reason you may update xcode as usual. But to use M2 you need to download the older version the last one that worked was in High Sierra 9.4
1 i think it is (am not at a computer now). So that’s a good one to hve as an alterbative to the latest version of xcode.You download the xip from apples archive and unpack in the download folder, NOT in the apps folder, rename the created xcode folder to eg. xcode941 and THEN you move it to app folder.
Whenever you wanna compile M2 you need to start any of the xcode versions and go to settings to select (in the locations tab) the xcode linetools version that you wanna use. Use the v9 for m2 and v10 for everything else.
I wanna point out that i do this to ve able to run rhe last m2 version that I consider stable and that I like.
After this version It grew out of hand.. its just a pile of patching bugs with new bugs.
With this you can compile macos and ios12, and it works as they shpuld.
Actually Mojave is the most excellent version so far. Incredible smooth graphics (the last m2 version sorry but I have to say it.. sucks ass, so dont judge Mojave by that, try June or some totally other multiplatform language.
It is really wonderful. Almost the double performance of my older macos favorite versikns (El Capitan, Maverick and Sierra).
After Mojave there’s no returning back btw so download the OS from the shop and put them on sticks before you upgrade, in case you need an older version.
Hope that helps!
