Blog Post - Update time! Posted on April 7th, 2016

Community Forums/Monkey2 Talk/Blog Post - Update time! Posted on April 7th, 2016

therevills(Posted 2016) [#1]
http://monkey2.monkey-x.com/2016/04/07/update-time/

There have also been a few questions asked recently about how monkey2 will work on ios/android. And the truth is I don’t know yet. My current thinking is for monkey2 to generate a static (or dynamic) lib that contains all the app code (and only needs to expose a bbMain), that can be dumped into a ‘target project’, ie: an Android Studio or XCode project. The SDL code might end up in the target project too, so it can be properly initialized at the right time and hacked if necessary to deal with app suspension or whatever.

I also think target specific code and libs such GooglePlay, AppStore, Ads etc should be in the target project, NOT monkey. These often have weird requirements for adding them to projects such as having to modify linker settings etc, and while I tried in monkey1 to modularize this stuff I think ultimately it just didn’t work very well.

I also want to avoid the situation I got into with the ‘app config’ settings stuff in monkey1. This basically allowed you to modify a limited subset of project properties (such as android manifest settings or ios info.plist vars) via ‘#SOME_VAR=SOMETHING’ in monkey code. The compiler then attempted to hack these settings into the target project using a variety of unholy techniques.

This was based on my initial flawed thinking that ‘it would be nice if the user only had to deal with monkey’. But it just wasn’t worth it – it was a nightmare to maintain and IMO just made it harder when you ineveitably needed to add something to the target project that wasn’t supported via app config settings. So in monkey2, if you want to modify the android manifest or ios info.plist, you will need to do so OUTSIDE of monkey2. The simplest way being of course to use android studio or xcode – which are designed for exactly this stuff.


Whilst I can understand Mark's decision regarding Android/iOS, it is a bit disappointing and I hope that within the Monkey IDEs we can still build/run the Android/iOS targets, similar to Unity and other tools.


Danilo(Posted 2016) [#2]
IDE's could provide menus to run external tools before and after building, to run pre-processors
and project-generators etc.
You could visually edit options like SCREEN_ORIENTATION, APP_LABEL, APP_NAME with an external tool, started from inside the IDE.
The tool generates app.config file in the project directory, for example. Another tool, that is executed automatically by the IDE after building,
will take the app.config and generate/change the iOS or Android project before the package finally gets packed and executed.

Inspired by UltraEdit, I included such a tools menu into the PureBasic IDE 12 or 13 years ago (the IDE was open-source back then),
and it's still very powerful. The guys added later special points that trigger the time an external tool is executed.
Events to trigger the tool:
- Menu or Shortcut
- Editor Startup
- Editor Closing
- Before Compile/Run
- After Compile/Run
- Run compiled program
- Before Create Executable
- After Create Executable
- SourceCode loaded
- SourceCode saved
- SourceCode closed
- New SourceCode created
- ...


therevills(Posted 2016) [#3]
I dont want to leave the MX2 IDE to build Android/iOS and I'm hoping the IDEs will have options like this:










Danilo(Posted 2016) [#4]
Yeah, exactly what I had in mind.


Gerry Quinn(Posted 2016) [#5]
This system-specific stuff is horrible for sure, but that's why auto-magically doing it is such a selling point...


muddy_shoes(Posted 2016) [#6]
It's just another case of deja vu from Monkey and the gap between a language + some libs and a modern full-fat gamedev toolkit. Mark has consistently put things like multi-target project management out of scope of what he does (he might enable it at a library/compiler level, but he's not going to write a tool to do it). Realistically, he couldn't do it even if he wanted to as there's enough on his plate already. There's always been some sort of vague expectation that someone else will come along and fill the gaps but it just hasn't happened for a number of reasons (one of which being that vagueness of expectation).

Playniax has mentioned some intent to build up to a broader game editor toolset so there's some hope there. Unfortunately it's a closed effort so there's no way to know really what the direction is or dip in and help out/nudge it along/broaden it.


Playniax(Posted 2016) [#7]
Playniax has mentioned some intent to build up to a broader game editor toolset so there's some hope there.

I was just gonna say it could be a job for a third-party but I can't say if Playniax will step up to the plate for this.
I do intend to develop tools, editors, etc. hell maybe even a full IDE eventually for Monkey 2 but really is to early to say.
I have a clear roadmap for the next 6 months and after I will see what is next.
I am sure the Diddy guys will come up with some useful stuff too :)


Skn3(Posted 2016) [#8]
The update sounds good and bad. Good in that extern is expanding massively ... But bad because of the whole self managed project files.

One of the main issues I have found with monkey module development, is that we don't really have a organised way to integrate external libs for platform specific features. Monkey code modules or libs that were designed to be self contained, are generally fine. The issues comes when we want to combine a handful of libs that require these modifications to a project file. It becomes a real pain in the ass!

If there was some sort of official project file builder/updater tool this would be great! It could even have its own API which modules could integrate with. What if a module could have a projectAPI.json file. In this file we can *somehow* define Actions that get built into the project, via the API. So for example:

Modules/skn3/mymodule/projectAPI.json

In this json file we can define targets supported. For each target we can define various hooks. When the ProjectTool runs, and is building a certain part of the project, it will ask the module if it has the required hook. If it does, it can then act upon the building project.

A defined hook could contain 1 or many actions to perform.

Actions to perform could be as simple including a file or block of text. You could even have regex built in to do advanced search and replace within project files.

Actions could also define a set of user editable properties. These would get added to the ProjectTool interface. We could then reference these values with our actions. Eg someone defines a "show_phone_toolbar" checkbox for iOS and android targets. We can then have he action do a regex search on a specific file and replace with $show_phone_toolbar value.

Modules could even define custom hooks that get called. So mymodule_myhook gets called. All modules that then implement that hook, then get to interact with something mymodule has done. A module I write might makes a change to add its own bits of code, to inform other modules that there is a specific piece of code has been injected, we call the custom hook. A 3rd party module can then modify this code. Module developers could document their hooks with bbdocs, explaining what 3rd parties can intercept and change.

Another thing to consider is to utilise something like v8/chakra(edge browser) JavaScript libs to allow scripting of the project builder. A type of action could reference a .js file that gets executed. With this we could perform very advanced modifications to a project; provided the ProjectTool offers a curated set of features it can perform with a JavaScript API.

Depending on how mx2 could cope, it could even be done via mx2 code instead of JavaScript.

Basically there is a problem in that monkey1 became too difficult to maintain project files for you and the community. You don't want to repeat this maintenance hell. What if you build the toolset/API to allow the community to do the heavy lifting in a modular/extendable/sharable way!


Skn3(Posted 2016) [#9]
perhaps it could be created in node for rapid development...
http://enclosejs.com/ releasable as a binary!


dmaz(Posted 2016) [#10]
tools that do these things that you guys are describing have been around for decades... make,ant,rake...


taumel(Posted 2016) [#11]
Focus on OS X and Windows first (don't waste resources on browser nonsense), get things rolling there and make it a smooth A to Z experience, include focused sfx/2d/3d engines running stable, offer reasonable docs, don't screw up the language too much, ... and it might be some fun. Currently monkey 2 sounds hardcore for beginners and offers little for more experienced devs. Offering no 3d solution for monkey 2 is a bummer.


Tibit(Posted 2016) [#12]
I totally see a gap between language and desired developer experience. I do not think Mark wants to make a Monkey "Game Studio" (nor have the UX design skills too), so it got me inspired to pickup where I left my game studio project for monkey1 and last week I started building a "hackable" crossplatform IDE/studio for monkey 2.

I have a little initial blog here: Nucleus Game Studio for Monkey2 on Medium.com

I got compilation, file explorer, docs, syntax coloring going but I wanted it to be more modular, hackable and extendable. So I started from scratch building the editor up using "modules". So now the idea is to build and run everything from the welcome screen, syntax coloring to each top bar menu item from a module-system that any one with rudimentary javascript, html and css skills can understand and add too. So my hopes is to provide the within-reason best possible dev experience for Monkey2 and its community. Adding a "target" settings panel, or a framework template generation, or running any command line tools to pack/ship/publish/deploy/test should be quite simple!

Right now I am coding and designing the "signal" system that modules will use and how to deal with loading a module's dependancy - pretty much what Danilo showed above from UltraEdit. Modules talks to the editor with jQuery and on-the-fly rendered html-templates, and a simple api for dealing with files, command-line tools and signals from other modules.

I am keeping things as bare bones simple as possible yet I hope pretty much anything can technically be built with that. A script can even start new windows containing map-editors, texture maps, or simply command-call external tools that do that.

To me it makes sense were Mark draws the line between where Monkey should end and external tools should start considering how it went in Monkey1. I just so so much hope he will make it easier to integrate debug and devtools by allowing access to the AST. On a language-semantic level I think Monkey2 already are on a better starting point.

It is early days on this project, but unless I hit a snag I am in for it long term, and if Monkey2 does not pan out I'll readjust this to work making games directly in javascript. I did build an visual-studio equivalent editor for Monkey1, so I'm fully aware of the problem space and hopefully won't make the same costly mistakes I made that time around.

I hope to have something usable and really cool to show in a few weeks.


Paul - Taiphoz(Posted 2016) [#13]
Disappointed, but not surprised at all.


Danilo(Posted 2016) [#14]
From BlitzMax Forum: Who will be interested in using Monkey 2?

Danilo wrote:
Mark is moving some of the complex build things, that are very different for
Android and iOS, out of the compiler. If this special platform-dependend things get moved into
some sort of package-builder (.apk etc.) that is run automatically after MX2 build process,
the "hit build" -> "app starts on device" is the same for you.

I think it's a change in the compiler internals Mark is talking about, and end-users shouldn't be too worried about. ;)

Removing the ability to hit "F5" -> "app starts on device" wouldn't make any sense at all.


Danilo wrote:
To me it sounds like there will be a template-project for Android and iOS (like MX1).
MX2 then copies the template project to output directory, compiles the output code,
and "dumps the output into the template project".
Now it can automatically be packaged and executed.

But, if you want to change some specific project settings, you may have to modify
the template or output project.
This can be done most easily by using Xcode or Android Studio etc.
For example, open the iOS project using Xcode, go to project settings and fill out
your developer ID information for app signing, before releasing into AppStore.

That's actually the same with MonkeyX1 already. You can open the output project
and change many settings before re-compiling. The difference is that MX1 hacked
some very few settings (AppTitle, AppOrientation) into the output project (which is
a hassle according to Mark), but many other Android- and iOS-specific settings
are not accessable/changeable using MX, so you change it in Xcode anyway.

Maybe the community can automate that project hacking/modifying, using a app.config + GUI system.



Pakz(Posted 2016) [#15]
There wil be little snippets in the docs I expect. I probably wil not understand how to use a lot of what can be done. Monkey 1 is hard to learn to. Took me months to learn the Object Orient way of coding. Learned it mostly from the forums. I waited a couple of years before starting in Monkey 1. I skipped Blitzmax.


Nobuyuki(Posted 2016) [#16]
Tibit: Interesting idea, but I don't believe in "web backend" technologies for a desktop application. Seems crufty faddish and not-monkey-like. I'd be interested to see if a full RAD toolchain could be made from and with mx2. I understand the need to not re-invent the wheel; perhaps Scintilla can be used as the editor backend.


Danilo(Posted 2016) [#17]
@Pakz: Are you coming directly from procedural Blitz3D?

Don't worry, jumping from one programming paradigm to the next level is always not easy.
ASM, Procedural, Object-Oriented, Functional, and many more... everything takes its time to learn and get used to it... ;)

Haskell:
sq :: (Floating a) => a -> a
sq x = x^2
ringArea :: (Floating a) => a -> a -> a
ringArea r1 r2 = pi*(sq r1- sq r2)

Scheme:
(define (ringarea r1 r2)
 (define pi 3.14)
 (define (sq x) (* x x))
 (* pi (- (sq r1) (sq r2)))
)

F# and OCaml:
let ringarea (r1, r2) =
  let pi = 3.14 in
  let sq x = x*x in
  pi*(sq r1 - sq r2)


When I was round about 18 years old, I wanted to jump from C64 Assembly Language directly
into Amiga Maxon C++, and I just couldn't understand the very first page of the Maxon C++ Manual,
because it was talking about 'streams' - a concept I didn't know from low-level ASM with thinking
in memory cells and registers. Paid 179,- for the package and simply couldn't understand it... :D
Few years later, after already using procedural PureBasic, I tried again... and had no problem anymore
learning and understanding object-oriented C++, C#, Java, etc.
Of course, many new concepts to learn, but it became logical after a while, and it made sense.

Just don't give up! Getting fully used to a completely new paradigm and language (including templates, operator overloading, etc.)
can *easily* take 2 or 3 years sometimes... no problem. ;)
Even 'Masters' who use a language for 5+ years can learn new things and sometimes discover
new tricks and ways of using a language. It's life-long learning at its best... just enjoy it. ;)


Tibit(Posted 2016) [#18]
I still remember first time I started programming in blitz basic, what back then made it work for me was the abundance of examples and cross-references in the manual, it was awesome! I mostly got things to work after a copy-paste, and then changing one thing at a time since my severe lack of understanding made me break anything all the time. I have a little non-secret plan to write at least one example for each major command in Monkey2, if nothing else just for making future me more productive.

@Nobuyuki, yeah I am with you, it hurts that the minimum filesize is 100mb, I'm also fearing that once things gets more complicated that performance issues pop up. I'm still very new to web-as-desktop stuff, and it's more that I can reuse my web-knowledge to get features out of the door quickly than a choice that gives control or performance.


marksibly(Posted 2016) [#19]
> I probably wil not understand how to use a lot of what can be done.

Don't worry about it!

Monkey2 is mostly backward compatible with monkey1, so you should be able to use it more or less the same way you used monkey1 - think of it as a sort of 'super strict' monkey1.

You don't HAVE to learn the new stuff to be able to write useful code, but it's there if you're curious. You may even find yourself using it without fully understanding it, eg: by copying/pasting example code, and that's fine too. Some modules may require you to learn the odd new feature to make full use of them, but you can just learn these things on a 'case by case' basis as you go.

I don't really consider monkey2 to represent any great 'shift in paradigm' or anything like that. The new stuff is really just things I've wanted to add as I've used monkey1 over the years. Of course, once you start using some of the new features you may start approaching problems a bit differently, but that's sort of the point.


Richard Betson(Posted 2016) [#20]
^Very, well said. ;)


Richard Betson(Posted 2016) [#21]
In case you had not noticed there is a new blog post (May 7th) on the Monkey2 website. Mojo2 details, check it out. :)


therevills(Posted 2016) [#22]
Thanks for the link - I sometimes forget about the new site...


impixi(Posted 2016) [#23]
Only recently have I had the opportunity to do extensive coding with MonkeyX and the Mojo2 library and I must say I’m both surprised and impressed with its capabilities - a vast improvement over Mojo1. I’d say Mark is wise to make only minimal changes for its port to MX2.

Save the big changes for Mojo3, maybe 12 months from now, based around Vulkan/Metal/DX12(?), and possibly a “rewritten from scratch” library architecture that facilitates optimal performance on those next generation APIs.

Mark’s May 10 tweet:


Changed to freetype for font rendering - *much* crisper fonts now!



This is great news. I’m working on a text-heavy project in MonkeyX/Mojo2 and it’s a cursed hassle making text look crisp across multiple resolutions with varying PPI values. Hopefully enough of freetype’s functionality will be available so the hassle is minimised.


Richard Betson(Posted 2016) [#24]
Changed to freetype for font rendering - *much* crisper fonts now!

Nice addition. I'm hoping for better text/font performance on Android. Speaking of which Mark mentions an improvement in Android Mojo2 performance might be in the mix when Android makes it in as a target for Monkey2.


GW_(Posted 2016) [#25]
I just noticed that the Monkey2 github repo has been updated..
It's not working yet it seems, as the mojo module fails to compile do to a missing overload.
..modules/monkey/native/bbmonkey.h:21:7: error: no match for '
operator>' (operand types are 't_std_geom_Vec4_1f' and 't_std_geom_Vec4_1f')
if( y>x ) return -1;
^



Playniax(Posted 2016) [#26]
Working fine here!


therevills(Posted 2016) [#27]
I just noticed that the Monkey2 github repo has been updated..
It's not working yet it seems, as the mojo module fails to compile do to a missing overload.


I'm getting the same... fresh copy of MX2 from Github and GCC:

In file included from H:/Dropbox/CodeMonkey/Monkey/MonkeyXPro86e/monkey2-master/modules/mojo/mojo.buildv004/build_cache/desktop_debug_windows/../../desktop_debug_windows/mojo_app_2window.h:5:0,
                 from H:/Dropbox/CodeMonkey/Monkey/MonkeyXPro86e/monkey2-master/modules/mojo/mojo.buildv004/build_cache/desktop_debug_windows/mojo_app_2window.cpp:2:
H:/Dropbox/CodeMonkey/Monkey/MonkeyXPro86e/monkey2-master/modules/monkey/native/bbmonkey.h: In instantiation of 'int bbCompare(X, Y) [with X = t_std_geom_Vec2_1i; Y = t_std_geom_Vec2_1i]':
H:/Dropbox/CodeMonkey/Monkey/MonkeyXPro86e/monkey2-master/modules/mojo/mojo.buildv004/build_cache/desktop_debug_windows/mojo_app_2window.cpp:87:54:   required from here
H:/Dropbox/CodeMonkey/Monkey/MonkeyXPro86e/monkey2-master/modules/monkey/native/bbmonkey.h:21:7: error: no match for 'operator>' (operand types are 't_std_geom_Vec2_1i' and 't_std_geom_Vec2_1i')
  if( y>x ) return -1;
       ^
H:/Dropbox/CodeMonkey/Monkey/MonkeyXPro86e/monkey2-master/modules/monkey/native/bbmonkey.h:22:10: error: no match for 'operator>' (operand types are 't_std_geom_Vec2_1i' and 't_std_geom_Vec2_1i')
  return x>y;
          ^
H:/Dropbox/CodeMonkey/Monkey/MonkeyXPro86e/monkey2-master/modules/monkey/native/bbmonkey.h: In instantiation of 'int bbCompare(X, Y) [with X = t_std_geom_Rect_1i; Y = t_std_geom_Rect_1i]':
H:/Dropbox/CodeMonkey/Monkey/MonkeyXPro86e/monkey2-master/modules/mojo/mojo.buildv004/build_cache/desktop_debug_windows/mojo_app_2window.cpp:87:157:   required from here
H:/Dropbox/CodeMonkey/Monkey/MonkeyXPro86e/monkey2-master/modules/monkey/native/bbmonkey.h:21:7: error: no match for 'operator>' (operand types are 't_std_geom_Rect_1i' and 't_std_geom_Rect_1i')
  if( y>x ) return -1;
       ^
H:/Dropbox/CodeMonkey/Monkey/MonkeyXPro86e/monkey2-master/modules/monkey/native/bbmonkey.h:22:10: error: no match for 'operator>' (operand types are 't_std_geom_Rect_1i' and 't_std_geom_Rect_1i')
  return x>y;
          ^
cc1plus.exe: warning: unrecognized command line option "-Wno-parentheses-equality"


***** Fatal mx2cc error *****



therevills(Posted 2016) [#28]
Just tried again and now I get this:


So the only errors standing out are:

Makedocs error: Can't resolve link 'Eachin'
Makedocs error: Can't resolve link 'Eachin'


How do I use Ted to compile MX2? Ah ted didnt like monkey2-master folder... now to rebuild again... takes a bloody long time to rebuild! LOL!


impixi(Posted 2016) [#29]
I'm also seeing those errors (on MacOS X) with today's git update. Yesterday's update worked fine and in fact I'm experimenting with that right now and all the "bananas" run as expected.


therevills(Posted 2016) [#30]
Success!



I had to rename the mx2 from monkey2-master to just monkey2, download TDM-GCC-64-4.9.2 and extract in the devtools folder of mx2... then recompile all twice.


therevills(Posted 2016) [#31]
Testing the mojo examples, in the viewlayout if I double click the title bar I get a MAV in release mode:

***** Building app 'H:/Dropbox/CodeMonkey/Monkey/MonkeyXPro86e/monkey2/modules/mojo/bananas/viewlayout/viewlayout.monkey2' *****

Parsing...
Semanting...
Translating...
Compiling....
Linking H:/Dropbox/CodeMonkey/Monkey/MonkeyXPro86e/monkey2/modules/mojo/bananas/viewlayout/viewlayout.buildv004/desktop_release_windows/viewlayout.exe
Running H:/Dropbox/CodeMonkey/Monkey/MonkeyXPro86e/monkey2/modules/mojo/bananas/viewlayout/viewlayout.buildv004/desktop_release_windows/viewlayout.exe
Window Resized to:640,512

***** Uncaught Monkey 2 Exception: Memory access violation *****


Raise the first issue:
https://github.com/blitz-research/monkey2/issues/1


GW_(Posted 2016) [#32]
I was finally able to build the modules. Turns out you have to compile everything twice.
I discovered another problem. Compiling a Monkey2 program via the Monk ide (v86e) causes the compiler to use the system global gcc (i have 5.1.0).
Meaning the monkey2 compiler is ignoring both "..devtools\TDM-GCC-64-4.9.2" and the path setup in the "env_windows.txt" (also pointing to 4.9.2)

Edit: Finally got it working but had to use another mingw version for part of the process.


therevills(Posted 2016) [#33]
Moved to new thread