Mojo2 is happening!

Monkey Forums/Monkey Programming/Mojo2 is happening!

marksibly(Posted 2015) [#1]
Hi,

Mojo2 is on the way!

http://marksibly.blogspot.co.nz/

This is only for GL compatible targets, ie: desktop, ios, android and html5, but this allows for some very cool new features, like render to image, lighting etc.

I've tried to keep it mojo-ish - eg: there's an Image class and the drawing commands are pretty much the same - but I've changed/added things we're it seemed sensible to do so in order to make it more functional.


ImmutableOctet(SKNG)(Posted 2015) [#2]
This sounds absolutely amazing, Mark. Makes me really want to look into making a GLSL target for Monkey.


therevills(Posted 2015) [#3]
Sounds great Mark... I am surprised you are giving it away free though...


dawlane(Posted 2015) [#4]
@marksibly: One question. Will grab image be rewritten to allow us to grab images that are scattered on an image atlas?


Gerry Quinn(Posted 2015) [#5]
Excellent!


tiresius(Posted 2015) [#6]
Just when I thought I knew what was going on here, POW there is a big Monkey1 enhancement.
Very cool


Skn3(Posted 2015) [#7]
Interesting news! Can't wait to have a play around.


ziggy(Posted 2015) [#8]
That's awesome news!!
By the way, a FontMachine for mojo2 is on the way too.


Rieha(Posted 2015) [#9]
This is great news! Looks now likely that I'm keeping on with Monkey after my current project.


Neuro(Posted 2015) [#10]



Amon(Posted 2015) [#11]
Cool stuff on the horizon. Can't wait. :)


Whiteball(Posted 2015) [#12]
Top Man!
Sounds great, can't wait.


Danilo(Posted 2015) [#13]
Where are the Tony @ Playniax news Mark was talking about? Ignition X 2?


DruggedBunny(Posted 2015) [#14]
Woo-hoo!


dragon(Posted 2015) [#15]
cooooooooooooool


CopperCircle(Posted 2015) [#16]
Looking forward to this, brilliant!


Playniax(Posted 2015) [#17]
http://www.monkey-x.com/Community/posts.php?topic=9762


Soap(Posted 2015) [#18]
Cool news Mark and Playniax!

I interpret this as "Monkey 2" being completely free to everyone and "Mojo2" being a part of the "Monkey" paid package and free to current Monkey owners. That right? If so that's a good idea. Patreon when?


nullterm(Posted 2015) [#19]
"render to image"

W00T!!!!


marksibly(Posted 2015) [#20]
> I interpret this as "Monkey 2" being completely free to everyone and "Mojo2" being a part of the "Monkey" paid package and free to current Monkey owners.

Yep, monkey1 sales are effectively helping to fund monkey2 dev.

> Patreon when?

When I get my s#!@ together!

I wanted to wait until I had something for people to play with, but that might be a month or so away yet so I think I'll just start the Patreon anyway.


marksibly(Posted 2015) [#21]
> @marksibly: One question. Will grab image be rewritten to allow us to grab images that are scattered on an image atlas?

Not quite sure what you mean, but there are basically 4 ways to create an image:

* New Image( width:Int,height:Int )
* New Image( atlas:Image,x:Int,y:Int,width:Int,height:Int ) 'kinda like GrabImage?
* Image.Load:Image( path:String ) 'loads an 'atlas' image
* Image.LoadFrames:Image[]( path:String,numFrames:Int,padded:Bool )

An image doesn't have multiple frames in mojo2, so you must manage your own arrays of images for animation. This all got way too messy in mojo1 (adding an extra 'frameNum' parameter to everything) and meant that image frames couldn't have independent sizes/handles.

Image.LoadFrames is a helper function that loads a simple 'animation strip'. Mojo2 doesn't attempt to load image frames laid out in a grid in a subrect of an atlas the way mojo1 did - you'll need to do this yourself via New Image( atlas... ).


degac(Posted 2015) [#22]

I wanted to wait until I had something for people to play with, but that might be a month or so away yet so I think I'll just start the Patreon anyway.


Don't think, Just put it on Patreon! :)


abakobo(Posted 2015) [#23]
I'm so happy!
Thanks for all the Basic lovers (the ones who know monkey and the ones that will discover it). I love you work and philosophy.
I read (on your blog?) that you would crowdfund for monkey2. I WANT to participate. If you don't crowdfund please let me know how I can donnate. Because I always donnate for free softs i use. And i'll use it!


Amon(Posted 2015) [#24]
Can I beta test mojo2 in its current state if I promise to abide by any rules, restrictions etc? I have a working game that I want to try the new features on; l I can send you the source if you wish?


Skn3(Posted 2015) [#25]
An image doesn't have multiple frames in mojo2, so you must manage your own arrays of images for animation.


I potentially championed this way back when monkey was being created. I remember championing grabimage and no frames...and really glad it's now happened. Keeping the "image" class away from "frames" is a good move! Treat the image like a texture instead of an entity.

Speaking of entities, have you considered adding some kind of entity object to mojo? With the ability to nest children, inherit scale/rotation/etc? It might be scope of a framework...I believe it does have a real place In a game lib like mojo. Imagine it like blitz3D entity system! It would have to either be really flexible or extensible though. I think the minimum we would be able to parent children to arbitrary points on the parent and then selectively inherit scale/rotation/position. Being able to query position/scale/rotation in local and world space would also be good.

Also what kind of shader/advanced GL support can we expect?


dawlane(Posted 2015) [#26]
An image doesn't have multiple frames in mojo2, so you must manage your own arrays of images for animation.
This is basically what I was doing with mojo1 and the reason for the question I asked. I couldn't see the point of having a frames array within the Image class with no way to add addition frames from an atlas. Will this also mean that mojo2 will do away with the Image.LoadFrames method?

Speaking of entities, have you considered adding some kind of entity object to mojo?
I don't know; talk of entity objects and virtual scene managers. Mojo2 will end up being a full fledged game engine before long with all the bells and whistles ;-).


Gerry Quinn(Posted 2015) [#27]
Agree about frames - maybe an absolute beginner might get some use out of them but to everyone else they are mostly just a nuisance parameter,


nullterm(Posted 2015) [#28]
Super happy about "draw to image."

Will there be a way to override the vertex & fragment GLSL shader? That opens up a ton of effects.


Skn3(Posted 2015) [#29]
I don't know; talk of entity objects and virtual scene managers. Mojo2 will end up being a full fledged game engine before long with all the bells and whistles ;-).


Very true although if a bare minimum entity system could be included in core,frameworks could extend from it. Imagine blitz3D if we had to do all those bits ourself, everyone designing their own entity from scratch.

Example code:
Local player := new Entity()
Local sword := new Entity()

player.Attach(sword)
player.Move(30,30)
player.Update()
player.Render()



Difference(Posted 2015) [#30]
BIG WISH!
Will Mojo 2 let me DrawTriangles(points:Float[],indexes:Int[]) or let me code my own, without hacking Mojo2 ?
This has been a big wish for a long time, because it is the only way to do proper vector graphics, and hacking Mojo with each update is a real pain.

Basicly just glDrawElements( GL_TRIANGLES,indexcount ,GL_UNSIGNED_SHORT,triangleIndices );

for stuff like this SVG parser and accompaining tesselator/triangulator.

http://www.monkey-x.com/Community/posts.php?topic=8035&post=83369&view=all#83369

A Mojo hack for this ( could be better! )



marksibly(Posted 2015) [#31]
> Also what kind of shader/advanced GL support can we expect?

Not much - it's very much geared towards GLES2.0, and most of the functionality is hardcoded in via a 'mega shader'.

You can however write simple shaders that fetch textures etc and produces values for use by the lighting equations, eg: here's mojo2's 'fastshader':

//shader for simple unlit sprites.

uniform sampler2D ColorTexture;

void shader(){

	b3d_Ambient=texture2D( ColorTexture,b3d_Texcoord0 );   //texture fetch
	
#if GAMMA_CORRECTION
	b3d_Ambient.rgb=pow( b3d_Ambient.rgb,vec3( 2.2 ) );
#endif

	b3d_Ambient*=b3d_Color;	//apply vertex coloring

	b3d_Alpha=b3d_Ambient.a;	//extract alpha
}


This code gets 'injected' into the mega shader (a the top of the fragment shader) which uses the output b3d_Ambient and b3d_Alpha values to produce fragments.

You can't modify vertex processing, lighting etc, but you can change the monolithic mega shader template.

> Very true although if a bare minimum entity system could be included in core,frameworks could extend from it.

There is no scene graph in mojo2, but there are 'hooks' for one via the Renderer system. A scene graph is a huge undertaking - an efficient, flexible, extendable one even more so.

> Will Mojo 2 let me DrawTriangles(points:Float[],indexes:Int[]) or let me code my own, without hacking Mojo2 ?

Currently, no, but I think it's a good idea. I was thinking of something like:

Canvas.RenderPrimitives:Void( order:Int,count:Int,vertices:DataBuffer,verticesOffset:Int ) 'unindexed points, lines, triangles, quads...
Canvas.RenderTriangleMesh:Void( count:Int,vertices:DataBuffer,verticesOffset:Int,indices:DataBuffer,indicesOffset:Int )

Vertices would be in the format:
float x;float y;
float s;float t;
int rgba;

Indicies would be shorts.

I think databuffers are more flexible for this sort of thing than arrays - agreed?


DruggedBunny(Posted 2015) [#32]
Mark, will it be possible to read the depth buffer at all? Loved playing with that in Max3D...


Skn3(Posted 2015) [#33]
This code gets 'injected' into the mega shader (a the top of the fragment shader) which uses the output b3d_Ambient and b3d_Alpha values to produce fragments.

You can't modify vertex processing, lighting etc, but you can change the monolithic mega shader template.

> Very true although if a bare minimum entity system could be included in core,frameworks could extend from it.


The megashader approach sounds like a good fit for mojo2. As long as there is some small access to the inner workings, people will find a way to extend for their needs.

Can we get more module developer support within mojo? For example access to the texture handle, callbacks for at key points in the setup/pipeline. It would be good if there were some module level API's, for example being about to flush the batch draw operation with a public method/func via native code.

With the batch draw, is there any reason it has to be hard coded. What if there was a batch draw class. So we could build multiple batch layers and then render them in the order we want?

There is no scene graph in mojo2, but there are 'hooks' for one via the Renderer system. A scene graph is a huge undertaking - an efficient, flexible, extendable one even more so.

How do the hooks work? I have a pretty decent scene graph in my current engine code, it would be interesting to know how this might be implemented.


Nobuyuki(Posted 2015) [#34]
being able to perform a flush without native externs would def. be useful. Just something to make using gles20 easier and have it play nice with mojo2. (Flushing was the only thing I had to resort to native externs for in nDrawExts2; everything else could be done using the gles11 module)


skid(Posted 2015) [#35]

Canvas.RenderPrimitives:Void( order:Int,count:Int,vertices:DataBuffer,verticesOffset:Int ) 'unindexed points, lines, triangles, quads...
Canvas.RenderTriangleMesh:Void( count:Int,vertices:DataBuffer,verticesOffset:Int,indices:DataBuffer,indicesOffset:Int )



Maybe Mojo2 could be more of a MojoGL - exposing GL names of textures and allowing us to call flush could allow all sorts of stuff be implemented in Monkey without having to hack Mojo, In theory it could expose a large chunk of the GL API for us to use directly.


marksibly(Posted 2015) [#36]
> Mark, will it be possible to read the depth buffer at all?

No, it doesn't even use the depth buffer right now - it's a purely 2d 'compositing' engine.

> With the batch draw, is there any reason it has to be hard coded.

Because it simplifies things 1000%, both for myself and for users. More flexibility=more complexity, to the point where a 100% flexible engine reduces down to...opengl!

> being able to perform a flush without native externs would def. be useful.

Yes, you can - in fact have to - do this.


Difference(Posted 2015) [#37]
>Currently, no, but I think it's a good idea. I was thinking of something like:

Canvas.RenderPrimitives:Void( order:Int,count:Int,vertices:DataBuffer,verticesOffset:Int ) 'unindexed points, lines, triangles, quads...
Canvas.RenderTriangleMesh:Void( count:Int,vertices:DataBuffer,verticesOffset:Int,indices:DataBuffer,indicesOffset:Int )

Vertices would be in the format:
float x;float y;
float s;float t;
int rgba;

Indicies would be shorts.

I think databuffers are more flexible for this sort of thing than arrays - agreed?

Great!
I'd love a simple DrawTriangles(points[]:Float,indexes[]:Int), but any approach that solves this without hacking Mojo is a winner in my book :-)


Playniax(Posted 2015) [#38]
Looks like a good idea!


Richard Betson(Posted 2015) [#39]
Awesome cant wait.


Salmakis(Posted 2015) [#40]
Cant wait!
all my monkey coding mood is on hold, since i dont want to use mojo (1) anymore for now :(


skape(Posted 2015) [#41]
This is amazing, and completely unexpected. I have to echo, though: free? Really? I'm all for free stuff, but I'm all for paying for deserving things! (Guess maybe I'll have to buy another Monkey-x license.) :)


DruggedBunny(Posted 2015) [#42]

maybe I'll have to buy another Monkey-x license



@Unlikely: Alternative, in case you haven't seen it -- just spread the cost... :D

http://www.monkey-x.com/Community/posts.php?topic=9772&page=1


Dabz(Posted 2015) [#43]
Personal wish... Grabbing an image where the source is the GC ala blitzmax styleeee That was a biggggggg miss in monkey v1 for me,

Dabz