Benefits of Monkey / BMX 2, for me

Community Forums/Monkey2 Talk/Benefits of Monkey / BMX 2, for me

JoshKlint(Posted 2015) [#1]
I can't speak for all the different kinds of users out there, but there are two potential benefits of Monkey 2 that would appeal to me.

Rapid development of C++ applications
-Time-savings with auto-generating header files, always initializing variables, etc.
-Ease of integration with C libraries.
-Quality and readability of outputted C++ code.
-Ease and transparency of debugging.
-Built with 64-bit support in mind. As far as I'm concerned, 32-bit support can be dropped.

Easy-to-use built-in cross-platform libraries
-GUI, for Windows and Mac at least (if you think there is any decent option out there, you don't know enough about this subject. QT is the closest thing to a cross-platform library, but it's a huge bloated invasive development framework.)
-Cross-platform creation of modern OpenGL contexts in the GUI.
-File format loaders, savers, etc.

BlitzMax has been my secret weapon to that lets me write software it would otherwise take huge development teams to write, so a modern equivalent is interesting to me.


Samah(Posted 2015) [#2]
@JoshKlint: Ease of integration with C libraries.

Agreed, this is a good thing.

@JoshKlint: Quality and readability of outputted C++ code.

Irrelevant if the debugger can work with Monkey 2 source. The only time you'd really need to look into the generated source is for externs, which would just be copied verbatim.

@JoshKlint: ...As far as I'm concerned, 32-bit support can be dropped.

People are already complaining about dropping HTML5, and you want to kill off even more of the potential userbase? There are still thousands of casual gamers using antiquated computers that will only run Windows XP 32-bit (or less!). If you're writing a simple card game that doesn't need the latest and greatest hardware, I don't see why you would alienate these users.

@JoshKlint: QT is the closest thing to a cross-platform library, but it's a huge bloated invasive development framework.)

And it gives you the middle finger as soon as you plug in a graphics tablet. Agreed, there are no fit-all GUI options. There would need to be some kind of "plug in whichever GUI you want" wrapper module so that you could keep the one codebase but use whichever GUI is more appropriate for the target and for your requirements.

@JoshKlint: Cross-platform creation of modern OpenGL contexts in the GUI.

Hopefully this shouldn't be too hard to implement.

@JoshKlint: File format loaders, savers, etc.

In a lot of cases I think it would be better to bind these to native implementations for speed and accuracy, but yes it would be nice to have these features.


JoshKlint(Posted 2015) [#3]
Also would like support for more variable types, as I do use these:
Unsigned Long
Signed Byte
Signed Short
Unsigned Int


EdzUp(Posted 2015) [#4]
Josh: +1 on ya posts, another thing I would like is inline c++ as an example:
Function MyFunc( var:int, var2:ulong )
inlineCpp{
   unsigned long myvar;

   //do something here
   myvar = var +var2;
   cout << "woohoo my var is " << myvar << endl;
}

return( myvar );
end function


would be translated to when compiling:
void MyFunc( int var, unsigned long var2 ) {
   unsigned long myvar;

   //do something here
   myvar = var +var2;
   cout << "woohoo my var is " << myvar << endl;

   return( myvar );
}


obviously this is a ludicrously simple example but being able to call raw C++ code and functions would extend MX2 no end and allow us to do all manner of things that the base libraries werent created for.

Maybe even a inlineASMx86{...} but thats just dreaming ;)


JoshKlint(Posted 2015) [#5]
I'm not really a fan of options. Would rather just have one way that works.


Richard Betson(Posted 2015) [#6]
Signed Byte

+1, OMG please. :)

I like the inline C option suggestion. That would be cool.
I would love to have the ability to change display resolutions via command.
Networking support! Enet, something, anything.


ziggy(Posted 2015) [#7]
The idea of inlining C or C++ in a Monkey source code document looks plain wrong to me. It feels like adding lots of inconsistency to the language. The fact that it uses C++ as its back end is, IMHO, a detail of implementation, and I'm not sure it is a good idea to be tied to it. This makes even more sense with the idea of inlining assembler. That would additionally tie the language to a given architecture, which is, in my honest opinion, even a worse idea.


Samah(Posted 2015) [#8]
@ziggy: The idea of inlining C or C++ in a Monkey source code document looks plain wrong to me. It feels like adding lots of inconsistency to the language.

I'm starting to get this feeling too. The more I look the language feature requests the more I'm thinking "you could just write your game in pure C++ and be done with it".
If all the targets are C++ based, remind me again, why are we doing this project? For the sake of wrapping an ugly language with a clean one?


Richard Betson(Posted 2015) [#9]
^I think It was more along the lines of an easy way to augment Monkey2, But I see your point.


Skn3(Posted 2015) [#10]
Massive plus one to monkey2 GUI. There really are no "nice" solutions for developing "apps" across desktop/mobile. At least not ones that any sane person would enjoy programming with.

I am trying to imagine a scenario where inline cpp code would benefit? If we can call extren functions, what benefits could inline cpp offer?


therevills(Posted 2015) [#11]
Massive plus one to monkey2 GUI. There really are no "nice" solutions for developing "apps" across desktop/mobile. At least not ones that any sane person would enjoy programming with.


Have you seen FeathersUI for Starling?

http://feathersui.com/


Danilo(Posted 2015) [#12]
+1 for Inline-Target-Code.

Some other languages used '!' at start of line for that. If a line starts with '!', the complete line
goes directly (unmodified) to the output. In PowerBasic and PureBasic (FASM) this was used for direct ASM, and in
MX/MX2 it should go directly to the target (C++, JavaScript, whatever, ...).

ASM could be done with C++'s Inline-ASM then. Very powerful for writing low-level stuff (in the underlying language),
without the need to create and import a new file every time.

!#pragma comment(lib, "MSVCRT -VERBOSE")
!#pragma comment(linker, "<linker options>")
!#pragma comment(lib, "xxx.lib")

!#include <freeglut.h>

Function MyFunc(var:int, var2:ulong)
    ! unsigned long myvar;
    !
    ! // do something here
    ! myvar = var + var2;
    ! cout << "woohoo my var is " << myvar << endl;
    !
    ! return myvar;
End

Function SHR(var:int, value:int)
    ! return ((unsigned int)var >> value);
End

Function InlineAsm()
    !//
    !// C++ code
    !//
    !asm {
        #if COMPILER_PROCESSOR = MX2_PROCESSOR_X64
            #if COMPILER_OS = MX2_OS_MACOSX
                ! 64-bit ASM code for Mac
            #elseif COMPILER_OS = MX2_OS_LINUX
                ! 64-bit ASM code for Linux
            #elseif COMPILER_OS = MX2_OS_WINDOWS
                ! 64-bit ASM code for Windows
            #else
                CompilerError "unsupported target"
            #endif
        #elseif COMPILER_PROCESSOR = MX2_PROCESSOR_X86
            #Select COMPILER_OS
                #Case MX2_OS_MACOSX
                    ! 32-bit ASM code for MacOSX
                #Case MX2_OS_LINUX
                    ! 32-bit ASM code for Linux
                #Case MX2_OS_WINDOWS
                    ! 32-bit ASM code for Windows
                #Default
                    CompilerError "unsupported target"
            #EndSelect
        #elseif COMPILER_PROCESSOR = MX2_PROCESSOR_ARMv7
            ! ARM target code
        #else
            CompilerError "unsupported target"
        #endif
    !}
    !//
    !// more C++ code
    !//
End

CompilerError() outputs a message and stops compilation.
CompilerWarning() outputs a message and continues compilation.


EdzUp(Posted 2015) [#13]
Ah that works too, I come from Turbo C++ days (yes I am that old) and with that you had things like:
void Beep( void ) {
asm {
PROC USES AX BX CX
	IN AL, 61h  ;Save state
	PUSH AX	  

	MOV BX, 6818; 1193180/175
	MOV AL, 6Bh  ; Select Channel 2, write LSB/BSB mode 3
	OUT 43h, AL	 
	MOV AX, BX	
	OUT 24h, AL  ; Send the LSB
	MOV AL, AH	 
	OUT 42h, AL  ; Send the MSB
	IN AL, 61h	 ; Get the 8255 Port Contence
	OR AL, 3h		
	OUT 61h, AL  ;End able speaker and use clock channel 2 for input
	MOV CX, 03h ; High order wait value
	MOV DX 0D04h; Low order wait value
	MOV AX, 86h;Wait service
	INT 15h			
	POP AX;restore Speaker state
	OUT 61h, AL
	RET
};
};


Seeing as monkeyX2 is using c++ it would be nice to inline stuff for compiling as pure code :)

code borrowed from http://www.dreamincode.net/forums/topic/23986-generating-sound-in-assembly/ :)


Skn3(Posted 2015) [#14]
Have you seen FeathersUI for Starling?

http://feathersui.com/


This looks nice but it is not native UI. There are so many cool native UI widgets readily available for iOS and Android.
https://www.cocoacontrols.com/
It would be awesome to have this kind of stuff at our fingertips!

ASM could be done with C++'s Inline-ASM then. Very powerful for writing low-level stuff (in the underlying language),
without the need to create and import a new file every time.

I can see the advantage that it is quicker to implement native stuff, but I think it would be quite an undertaking for Mark and IDE dev's just for the sake of convenience. It may also alienate users a little, the ones that are not so versed in other dialects. Are there any uses for inline code that cant be done with external files?

I remember back in the days when I used TheGamesFactory and MMF, looking at code was incredibly daunting. Blitz was such a nice step into programming because the dialect was so clean and well thought out. I am trying to imagine myself back all those years ago again, and I reckon seeing cpp/asm inlined with basic would freak the hell out of me.


JoshKlint(Posted 2015) [#15]
I don't have any use for it, but a cross-platform native mobile GUI would also be awesome. That right there would be a enough to make a very successful product. Think how many people would like to make an app but can't make heads or tails of Objective-C.

I care about the quality of the outputted C++ code because:
-I want to be able to move a project over to C++ development, if needed. I understand that is a one-way trip.
-I want a well-formatted C++ source code I can license to other companies.


ziggy(Posted 2015) [#16]
a cross-platform native mobile GUI
Isn't this a contradiction? I don't think it's possible easily, not even the Xamarin guys managed to do it, Qt team ended with a non native solution. It seems Microsoft is preparing *something* in this regard, according to some rumors, but it seems it's going to be based on XAML (which is not a bad thing).


Danilo(Posted 2015) [#17]
JoshKlint wrote:
-I want a well-formatted C++ source code I can license to other companies.

You could use a source formatter/beautifier for this, for example:
- ClangFormat
- Artistic Style

You could also use UniversalIndentGUI as a GUI for Artistic Style.


Richard Betson(Posted 2015) [#18]
I am working on this GUI system for Monkey and BlitzMax.
http://www.monkey-x.com/Community/posts.php?topic=9566

It's written in native Monkey-X code, has it's own window and gadgets frameworks. It works with Android, IOS and GFLW as well as HTML5. I prefer GUI's be written in native code for lots of reasons the top two being efficiency and adaptability. It's a good start and and far enough along that probably this weekend I will post the GUI code and some examples. I will release the Monkey-x version first and then the BlitzMax version later. It's all alpha but usable and should be fun to test. I will of course port this to Monkey2.

I am releasing this as free to use (commercial OK - http://creativecommons.org/licenses/by-nd/4.0/) and will setup a site/page (maybe github but probably on my site) for it.


JoshKlint(Posted 2015) [#19]
If the decision was made to only support a GUI on Windows and Mac, using the native UI on each, I could understand the reasons for that.


Richard Betson(Posted 2015) [#20]
For me using the native OS's GUI is great for applications (non-game) but fails horribly with games at least on desktops. Maintaining and even choosing a GUI library is difficult and many have lackluster performance and dubious architectures. What is Monkey2's objective games, applications or both? If games a GUI written in native Monkey2 code has the best shot at surviving in the long run. Using external libraries for a GUI is just asking for long term problems over time. That said applications (non-game) do benefit from the OS's native GUI.


Gerry Quinn(Posted 2015) [#21]
Yes, a native GUI in games will actually turn people off because it looks too much like office software!


Skn3(Posted 2015) [#22]
I somehow get the impression that monkey2 is branching back into app development instead of soley focused on gaming. At least it would seem like that is a logical choice if you are not limiting yourself with HTML5 and Flash.


wiebow(Posted 2015) [#23]
If that is the case then I will probably won't be using it. I want to make games. :<


k.o.g.(Posted 2015) [#24]
When mark plans the architecture of mx2 good, it's possible to make an module like mojo with SDL and port it to emscripten...


wiebow(Posted 2015) [#25]
yes, and??

Just to be clear: If I have to program my own mojo like module (and that even did not contain image-image pixel collision by default for monkey 1) then ... I'm lost.


k.o.g.(Posted 2015) [#26]
i think, wenn mx2 runs good, anyone will make a graphics module, but for now, mx2 must have a good base!


wiebow(Posted 2015) [#27]
Sorry, but thinking that anyone (who?) will make a graphics module is unrealistic. I think you don't understand where I come from. I want to make games, and not to make modules. :) But we'll see how things go. It's still early days.


DruggedBunny(Posted 2015) [#28]

> Will it ship with some kind of mojo equivalent?

marksibly
Yes, I've been working on this for a while, announcement coming soon.



From here


wiebow(Posted 2015) [#29]
Thanks Drugged James!


JoshKlint(Posted 2015) [#30]
I didn't take this too seriously at first, probably because it's building off the weaker "monkey" brand and not Blitz, but if it works out and has a GUI this could save me a lot of money and time. Paying Mark a monthly payment would be very cost effective, for me. Will be curious to see what direction this takes.


rebelas(Posted 2015) [#31]
@wiebow
I think adding and enhancing OOP features are not toward end users, in our case game programmers; it is toward third party developers. Generally, I wish there were no concept of third party developers for Blitz products. I like all tools to be incorporated into Blitz product, so when you download your software, you get them all and you are sure all parts are compatible.

Look at this:

glfw for windowing
opengl for graphics
glew for opengl extensions
irrklang for audio
physfs for filesystem
raknet for networking
SOIL for image loading
glm for math
assimp for 3D asset loading
bullet for physics

Now imagine that raknet quits or its bug fixing is only once a year!!


DruggedBunny(Posted 2015) [#32]
These are all tried and tested components that can be easily swapped out in the event that one mysteriously stops working... which won't happen.


Samah(Posted 2015) [#33]
@rebelas: Now imagine that raknet quits or its bug fixing is only once a year!!

So you wrap it as a service so you can plug in another implementation.


rebelas(Posted 2015) [#34]
@DruggedBunny, @Samah,
You guys might be right, but that doesn't change the fact that I, as a game programmer, should not care about a language which actually is evolving in the service of tool makers. Suppose Unity3D is written by Monkey 2. Then, all I need is C# not Monkey 2. The reason Monkey 2 doesn't make sense to me is that its success is irrelevant to me as game programmer; just like C++ which is irrelevant to Unity3D end users because they should work with C# script or JavaScript. For tool developers, Monkey 2 may make sense, and they are those who should help it. Under some conditions I may help Monkey 2. So far, nothing tells me to do so. I might be wrong or Monkey 2 might have brilliant future, for now, this is my position and feel my obligation is fulfilled. I have always been a fan of Blitz products, I still work with Blitx3D and BlitzMax. Monkey X is a great language. I believe Basic language should be the only application programming language; we don't need C or C++ beyond system programming, and I don't think virtual machine base languages are good. So, hopefully, I am wrong, Monkey 2 will prevail and I will join in future.


Samah(Posted 2015) [#35]
@Samah: So you wrap it as a service...

In this sentence, by "you" I mean the maintainers of Monkey 2.

@rebelas: ...as a game programmer...

Based on this statement I am assuming you would be an end user in the sense of "don't care how internals work as long as they work". That's fine, but you should have more faith in the maintainers of the language/modules to provide you the functionalities you want.

@rebelas: Suppose Unity3D is written by Monkey 2. Then, all I need is C# not Monkey 2

I'm assuming this statement is along the lines of "Unity is a self contained product and not dependent on 3rd party libraries". You just listed off ten libraries that Mojo 2 could use for its native implementations. You cannot expect Mark et. al to develop platform independent implementations for each of these. Unity has a huge team of developers and backers. BRL does not. To be honest I think Mojo is brilliant given it was mostly a one-man job.

@rebelas: Under some conditions I may help Monkey 2. So far, nothing tells me to do so...

No-one's telling or forcing you to do anything of the sort. You're absolutely welcome to follow it on the forums and decide at a later time if you want to make a positive contribution or even back it on Patreon.

@rebelas: I believe Basic language should be the only application programming language; we don't need C or C++ beyond system programming, and I don't think virtual machine base languages are good...

The right tool for the job. Each of these languages has its place, and there's nothing wrong with VM-based languages.

@rebelas: So, hopefully, I am wrong, Monkey 2 will prevail and I will join in future.

I hope so too! :)


rebelas(Posted 2015) [#36]
@Samaha
No Unity3D is not a self contained product. I just don't think that I have to pay for its components, then pay for its final product as well. This is why I differentiate an end user product from tools that are producing that product. Suppose Unity3D is made of the above 10 products. It does not make sense to me to pay for each then to pay $1500 for The Unity itself. I will wait to see what will be the outcome. However, I would pay for Monkey X if it goes the way I like it. Another example is MS Word. I shouldn't pay for C++ or C#, I should just pay for MS Word. Those who produce software like Word, should pay for C++.

For sure, after Monkey 2 becomes something different from Monkey X, you won't see me saying anything against it, or most likey you won't see me at all. But, we are still IN Monkey X forum and I an a person who has paid for it. Of course I like to have saying about whete Monkey X should go, and I already said it shouldn't go toward Monkey 2. If it wants to go that way, I as end user, not as tool maker, won't support it.

But, Most likely I am right. Check me out in two years.


ziggy(Posted 2015) [#37]
we don't need C or C++ beyond system programming, and I don't think virtual machine base languages are good.
The fact that a language uses a VM or not does not determine the language quality. It's an implementation detail. Lots of modern compilers for C++ are based on the LLVM (see CLANG as an example), or the XCode compilers for MacOs, which are based on LLVM too. You're mixing tow unrelated things. Compiling C++ code into a non VM based compiler doesn't make the code or language used any better. In the other hand, some VM based compilers do produce more efficient machine code than traditional fixed architecture based ones, but this is related to compiler design, not the language itself.


rebelas(Posted 2015) [#38]
I am not mixing two unrelated things, any language and its virtual machine are one thing. Java and JVM are one thing. If you find a Java that works natively, then that Java is not the other Java. I like basic languages that work natively. However, that is beside the point. I have clarified what I wanted to say to "wienow" above or people in his situation:
I think you don't understand where I come from. I want to make games, and not to make modules. :) But we'll see how things go. It's still early days.



ziggy(Posted 2015) [#39]
I am not mixing two unrelated things, any language and its virtual machine are one thing. Java and JVM are one thing. If you find a Java that works natively, then that Java is not the other Java.
Like the GNU native Java compiler that has been there for decades? Also, notice that not all VM are used to compile bytecode during runtime. Most compilers use a VM to provide ahead of time compilation that produces native output. that's very common on modern compiler design, and this has nothing to do with the languages they compile. Then, some runtime VM run on interpretation, and others are compiled to native code using a JIT (as Orace's Java VM, or regular.NET), others use ITC (install time compilation) like .Net with NGEN, or ART on android, which is again native as traditional C++ or assembler, but allow for even better optimizations, etc...

Again, one thing is the language design, and another thing is the way the compiler handles it. This goes to the point that some VM for interpreted languages can actually run faster than C code compiled ahead of time (that was shown on a intense calculations example written in OCalm, C++, Java, etc.) OCalm interpreted was a lot faster than compiled code. And OCalm AOT compiled was absurdly fast.


rebelas(Posted 2015) [#40]
@ziggy,

Ok, as you insist...

You wrote and sold Blide and Jungle. What language did you use?


ziggy(Posted 2015) [#41]
I missed this question!
I used a mix of C#, vb.Net and a tinny bit of C++/CLI for development (languages), then I'm using NGEN for native compilation at install time (This install script was done in Inno Script), so both applications are natively compiled and do not use any JIT VM at runtime, despite they being written in what you call VM languages. (not sure C++ fits in this category, but I guess it does as it was C++/CLI). Not sure what you would considere compiled JavaScript, or C++ compiled with emScriten, etc. Again, one thing is the language, another thing is the compiling strategy (JIT, AOT or Install Time), and even another thing is the machine (virtual or not) where it runs.