Small update...

Community Forums/Monkey2 Talk/Small update...

marksibly

(Posted 2016) [#1]

Hi,

Just a quick update on what I've been up to lately.

I've mainly been at work converting the mx2 compiler to monkey2, which has been pretty painful as there are a lot of bugs in there (and here was I thinking it was pretty stable after doing a defender clone) and all I've got in terms of a debugger is a c++ stack dump! This has been kind of frustrating, but it's also made me very aware of what I did wrong the first time around and the end result should be pretty solid. This side of things is about 70% complete now.

In terms of general development...

There's a new website almost ready to go (just a wordpress quicky, but it at least gives mx2 a home) which will have some kind of roadmap page, but the short version is that my main priority right now is to get something usable together in terms of an IDE/compiler/debugger dev environment - all in 100% mx2. I'd like to see a 'module manager' in there too sooner rather than later.

I don't want to make any promises on when this will happen, but hopefully 2-3 'releases' away, ie: I'll still be doing demo releases along the way but they wont be completely usable for a while yet.

After that, I'm likely to spend some time cleaning/finishing up modules (esp. std) and doccing stuff before adding anything majorly new, although I'll probably do a conversion of the monkey audio module at some point along the way.

And at this point, mx2 will have hopefully matured from 'usable' to downright 'releasable'!

After *that*, I think it's probably best to wait until people have had a play with 'version 0.1' before deciding what to tackle next and in what order, but my personal wishlist is pretty much the same - reflection, threading, 3d graphics.

Danilo

(Posted 2016) [#2]

Thanks for the update on progress! I'm playing with MX2 all time... it's great and fun. ;)

GC-Martijn

(Posted 2016) [#3]

make it as stable as possible ! a good solid program for the future ;)

Richard Betson

(Posted 2016) [#4]

This side of things is about 70% complete now.

I am anxious to start porting.:) Be sure to mention when it is feasible to start converting Monkey X1 code.

3d graphics

+1

@Danilo - What are you using for 3D?

CopperCircle

(Posted 2016) [#5]

I have a new commercial project coming up I would love to do in mx2, it would fund some module creation and it is an application not a game, this is like nearly all my commercial Monkey projects that tend to be apps not games.
It would be great to see how the new GUI works cross platform using more complex layouts and more components. I built a fairly complete custom HTML renderer in Monkey as part of my app framework, truetype fonts were a hack to get working and required creating an atlas and rendering each character on the native side. I hope it will be easier now to hook up modules and have better control of render views/layering.

taumel

(Posted 2016) [#6]

@Mark
Nice, maybe you can keep us up to date in a weekly manner, just like Ron (hey, he's old too).

Actually i was doing a few tryouts with the kids this weekend. First a simple (but fun) avoid&collect game and then a more Robotron like one (screen) with mojo2. I was using different structures, playing around with the lightning and trying out stuff. Sometimes things looked kind of weird (expected a different look when dealing with normal/specular/diffuse maps), loading images sometimes was weird.

I hope Ted2 will get Retina support as soon as possible.

Anyway it was fun.

marksibly

(Posted 2016) [#7]

> Thanks for the update on progress! I'm playing with MX2 all time... it's great and fun. ;)

Wow! What 3d engine are you using...and how?!?

> make it as stable as possible ! a good solid program for the future ;)

That's the plan. I think there's enough in there now to start work on stabilizing everything before adding (too much) new stuff.

> I hope Ted2 will get Retina support as soon as possible.

It's coming...love your take on robotron too, looks crazy!

Also, meant to mention this earlier, but do you know about PushMatrix/PopMatrix in mojo2? These can be used to save/restore current scale+transform+rotation so you don't need to 'unscale' after doing a bunch of scaled draw-ops.

TeaBoy

(Posted 2016) [#8]

Woooooo, looks like the Irrlicht Engine (atleast the map is used in Irrlicht).

I hope you're using Irrlicht, Irrlicht is a good engine :)

@Mark, Why not use The Banana Bread Engine for the web side of things!

https://github.com/kripken/BananaBread/

therevills

(Posted 2016) [#9]

Thanks for the update, cant wait to get stuck in :)

Danilo

(Posted 2016) [#10]

@TeaBoy: You are right, it's Irrlicht. :D
@Mark: Just tested it yesterday. I'll look tomorrow if Import is enough, or if a wrapper is required. Many C++ pointers used. (->) Does this work with Xyz Ptr?

marksibly

(Posted 2016) [#11]

> (->) Does this work with Xyz Ptr?

Not yet - it will do, but for now instead of...

p->x

...use...

p[0].x

...which means the same thing.

Also, you may run into problems with the order of struct members, eg: this:

Struct Vec4
Field x:Float,y:Float,z:Float,w:Float
End

...is not guaranteed to produce a struct with the elements in the same order.

[edit]
This doesn't matter if the struct is extern, or if you are accessing the fields individually, so it's probably not that big a deal. But I ran into this issue when trying to send a Vec4f to opengl via:

Local v:Vec4f
glUniform4f( Varptr v.x )

...gl expected a [x,y,z,w] array, but mx2 had rearranged the fields to [w,x,y,z]!
[/edit]

Richard Betson

(Posted 2016) [#12]

You are right, it's Irrlicht. :D

Wow the dream lives... importing other third party frameworks. GO MX2. :)

rIKmAN

(Posted 2016) [#13]

@Mark: Just tested it yesterday. I'll look tomorrow if Import is enough, or if a wrapper is required

Danilo that looks great!
Just wondering how you have those 3D demos running from MX2, but you don't know whether Import is enough or whether wrappers are required?

Also I just went to see if there had been an update for MX2 since xmas, and although the header on the download page says V3, the Windows version is actually still V2. Is it a mistake or is there a v3 knocking round somewhere for Windows?

The Mac version is named V3 on the download page also.

Bit confused.

Sammy

(Posted 2016) [#14]

Good chance of official 3D, now I'm interested!

nullterm

(Posted 2016) [#15]

Irrlicht lives!!!!

How'd you do the binding?!?

Danilo

(Posted 2016) [#16]

Compiled Irrlicht to libIrrlicht.a archive. That means statically compiled into the result, no external depencies.
That should also work with GCC on Windows, and on Linux. For VC++ it seems to include a DLL version.
Had to find out what Frameworks are required and included the Irrlicht headers:

' empty line
#If __HOSTOS__="macos"
    #Import "<Foundation.framework>"
    #Import "<Cocoa.framework>"
    #Import "<IOKit.framework>"
    #Import "<Carbon.framework>"

    #Import "<OpenGL/gl.h>"
    #Import "<OpenGL.framework>"
#Endif

#Import "libIrrlicht.a"
#Import "include/irrlicht.h"

For quickly testing if everything works, without writing complicated imports first, i simply took
"Irrlicht Tutorial 2: Quake3Map", renamed the file and main function to testmain, and called it.

So the above .monkey2 files continues:

#Import "testmain.cpp"
#Import "testmain.h"

' Resources
#Import "map-20kdm2.pk3"


Extern
    Function testmain:Int()
Public

Function Main()
    Print("MX2::Irrlicht")
    testmain()
End

testmain.h:

int testmain();

Works. It just means Irrlicht is useable with MX2. How, depends on how the Import of Classes and Pointers goes.

Writing a procedural (C-like) wrapper with it is 100% possible. Maybe a function set like Blitz3D or MiniBlitz3D
or something like that (don't know much about those engines). So it could be made easy for some guys to port
their older stuff to MX2.

About the direct Importing of the classes:
First, C++ templates are used. Don't know if such thing can be directly imported (compatible with MX2 templates?):

IrrlichtDevice *device = createDevice(driverType, core::dimension2d<u32>(800, 600), 32, false, false, false);

Because core::dimension2d<u32>() is always used for this function, it's probably easier to wrap it,
so we can just write (in MX):

device := createDevice(driverType, 800, 600, 32, false, false, false)

The other thing I mean (sorry, was at work, writing from mobile phone):
Irrlicht heavily uses C++ '->' pointers, like:

device->getFileSystem()->addFileArchive("/theFullPath/map-20kdm2.pk3");
...
scene::IAnimatedMesh* mesh = smgr->getMesh("20kdm2.bsp");
...
device->getCursorControl()->setVisible(true);

I wanted to know if this is supported. So if C++ uses a Type like IAnimatedMesh* (a pointer),
is the MX2 equivalent "IAnimatedMesh Ptr", and is this compatible?

I know it's all undocumented atm. Questions come to mind, f.e. inheritance of external/imported classes etc.
Do my .cpp classes need to inherit bbModule or bbObject (for GC management)... it's such things that I didn't
figure out yet. It's required to know exactly what is managed and unmanaged, and if we can make external
imports managed when inheriting from bbObject. I guess the destructor virtual ~bbObject() is called when MX2 GC
frees the objects, so we could do our cleanup stuff there. Etc. Etc. Etc. - still many things to test and figure out. :)

Also, I read that there may exist Irrlicht OpenGL ES versions for Android and iOS:

The Irrlicht Engine is platform independent, currently there is official support for:
* XP, XP64, Vista, CE, Windows 7,Windows 8 and Windows 10
* Linux
* OSX
* Sun Solaris/SPARC
* All platforms using SDL

For the serious mobile developer there are work-in-progress OpenGL ES drivers,
which have enabled the Irrlicht community to develop iPhone, Android and Nokia Symbian ports.
The Engine works with all supported platforms in the same way. The programmer only
has to write the game/application code once, and it will run on all supported platforms
without the need to change one single line of code.

IrrEdit is the old World Editor for Irrlicht. Functionality is now included in the newer CobberCube.
The 14-day-Trial of CobberCube does still allow Irrlicht export, even after the trial period.
CopperLicht is their free Open Source WebGL 3D engine - IrrKlang the sound library...

Danilo

(Posted 2016) [#17]

OK, importing it seems to be straight forward. Working MX2 code looks like this:

' Frameworks
#Import "Irrlicht.monkey2"

' Resources
#Import "map-20kdm2.pk3"

Function Main()
    Print("MX2::Irrlicht")

    Local device := irr.createDevice()
    
    If device = Null
        Print("createDevice failed.")
        Return
    Endif
    
    Local driver       := device.getVideoDriver()
    Local sceneManager := device.getSceneManager()
    
    'sceneManager.addCameraSceneNodeFPS() ' captures the mouse cursor!
    
    While device.run()
        If device.isWindowActive()
            driver.beginScene()
                sceneManager.drawAll()
            driver.endScene()
        Else
            device.yield()
        Endif
    Wend
End

C++ device->getVideoDriver() converts directly to MX2 device.getVideoDriver() - NICE! :)
(this answers my last question about the '->' pointer stuff)

taumel

(Posted 2016) [#18]

I would like to see a modern tiny 3D engine from Mark (or ...) instead.

Irrlicht was in bugfix-stealth-mode for years. It reminds me of all the usual suspects, half backed 3d engines/wrappers which used to pop up every few months/years for Max, none of them was reasonable and lasted, please not again.

@Mark
Hey thanks, the distribution is weird on the screen but it looks good in motion (no hickups either).

Danilo

(Posted 2016) [#19]

> please not again.

OK.

taumel

(Posted 2016) [#20]

Hey, don't get me wrong, enjoy yourself with whatever you want to add to monkey2 and i'm sure others will enjoy your work as well. It's just my point of view based on the experiences made with Max.

Danilo

(Posted 2016) [#21]

;)

marksibly

(Posted 2016) [#22]

> C++ device->getVideoDriver() converts directly to MX2 device.getVideoDriver() - NICE! :)

I'm a bit surprised, it probably shouldn't! Can you post the 'extern' block for device?

Currently, if you declare an extern class, mx2 expects it to be a 'normal' mx2 class, ie: it should extend bbObject. Otherwise, gc (at least) will get confused.

Extern is pretty simple right now - it assumes the thing you are declaring is compatible with stuff output by the translator. Sometimes you'll be able to get away with with externing stuff that is not mx2 compatible, but only up to a point.

Blitzmax/monkey allowed you to use 'Extern Null' with extern classes to indicate that a class is 'native' which I may resurrect. But this only really solves the 'extends bbObject' issue (which is a biggy) and doesn't help with 'freaky param types" (like core::dimensions2d<u32>) and a bunch of other issues.

> compatible with MX2 templates?

Not really - all mx2 generics are converted to 'normal' classes by the translator, ie: it generates classes like Stack_Int, Stack_Float etc. You can extern generic class instances though, eg:

Extern
   Struct dimension_2d_u32="core::dimension_2d<u32>"
      Method New( x:uint,y:uint )
   End
End

This would at least allow you to go:

Local t:=New dimension_2d_u32( 10,10 )

But then, passing 't' to an extern method may or may not work, depending on how the method param is declared by the native API ('by value','const ref', 'ref' etc) so it may not be useful in this situation. Also, having to declare EACH dimension_2d (uint, float etc) would be a PITA so this isn't much of a solution! Perhaps in some cases though...

It wouldn't be THAT hard to instantiate extern generic classes, but all these special cases are starting to pile up and I go back to thinking some kind of 'tool' that does a bunch of dirty hacky stuff like this and generates an extern .monkey2 file (and stub .cpp and .h files if necessary) for you is a better solution.

Please continue experimenting!

Danilo

(Posted 2016) [#23]

> I'm a bit surprised, it probably shouldn't! Can you post the 'extern' block for device?

namespaces/irr.monkey2:

Namespace irr

#Import "irr_video.monkey2"
#Import "irr_scene.monkey2"

'Using video

Extern
    Struct u32 = "u32"
    End

    Function createDevice:IrrlichtDevice() = "irr::createDevice"

    Class IrrlichtDevice = "irr::IrrlichtDevice"
        Method run:Bool() Abstract
        Method yield:Void() Abstract
        Method sleep(timeMs:u32, pauseTime:Bool = False) Abstract
        
        Method getVideoDriver:video.IVideoDriver() Abstract
        Method getSceneManager:scene.ISceneManager() Abstract
        
        'Method setWindowCaption(text:String) Abstract
        Method isWindowActive:Bool() Abstract
        Method isWindowFocused:Bool() Abstract
        Method isWindowMinimized:Bool() Abstract
        Method isFullscreen:Bool() Abstract
        
        Method closeDevice:Void() Abstract
    End
Public

BTW:
When I used full namespace for getVideoDriver() and getSceneManager(), it crashed the compiler:

Method getVideoDriver:irr.video.IVideoDriver() Abstract
Method getSceneManager:irr.scene.ISceneManager() Abstract

Removing the "irr" from return type fixed it.

EdzUp

(Posted 2016) [#24]

Nice, now I have a i3 laptop I will dive into this and have a look ;)

Danilo

(Posted 2016) [#25]

Something I noticed about the namespace crash:
MX2 compiler crashes always if I specify a return type that starts with the namespace that I'm currently in.
If I am in namespace 'xx', and I specify the return type 'xx.something':

Parsing...
Semanting...
Monkey Runtime Error : Memory access violation

Test source (.monkey2):

Namespace nspc

Extern
    'Function abc:type(Void)        ' OK, not using nspc
    '                               ' Error : Identifier 'type' not found

    'Function def:blah.type(Void)   ' OK, not using nspc
    '                               ' Error : Identifier 'blah' not found

    'Function ghi:nspc.type(Void)   ' COMPILER CRASH, return type starts with 'nspc',
    '                               ' the current namespace
Public

Function Main()
    Print("Hello World!")
End

Danilo

(Posted 2016) [#26]

marksibly wrote:
Blitzmax/monkey allowed you to use 'Extern Null' with extern classes to indicate that a class is 'native' which I may resurrect.

Would be nice to get 'Extends Null' for external classes.

I'm getting crashes and weird side effects now (memory consumption grows 2GB per second, etc).
I think I have to wait and procrastinate until the next demo with 'Extends Null'. ;)