Mojo2 is happening!
Monkey Forums/Monkey Programming/Mojo2 is happening!
| ||
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. |
| ||
This sounds absolutely amazing, Mark. Makes me really want to look into making a GLSL target for Monkey. |
| ||
Sounds great Mark... I am surprised you are giving it away free though... |
| ||
@marksibly: One question. Will grab image be rewritten to allow us to grab images that are scattered on an image atlas? |
| ||
Excellent! |
| ||
Just when I thought I knew what was going on here, POW there is a big Monkey1 enhancement. Very cool |
| ||
Interesting news! Can't wait to have a play around. |
| ||
That's awesome news!! By the way, a FontMachine for mojo2 is on the way too. |
| ||
This is great news! Looks now likely that I'm keeping on with Monkey after my current project. |
| ||
|
| ||
Cool stuff on the horizon. Can't wait. :) |
| ||
Top Man! Sounds great, can't wait. |
| ||
Where are the Tony @ Playniax news Mark was talking about? Ignition X 2? |
| ||
Woo-hoo! |
| ||
cooooooooooooool |
| ||
Looking forward to this, brilliant! |
| ||
http://www.monkey-x.com/Community/posts.php?topic=9762 |
| ||
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? |
| ||
"render to image" W00T!!!! |
| ||
> 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: 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... ). |
| ||
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! :) |
| ||
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! |
| ||
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? |
| ||
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? |
| ||
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 ;-). |
| ||
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, |
| ||
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. |
| ||
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() |
| ||
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! ) |
| ||
> 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? |
| ||
Mark, will it be possible to read the depth buffer at all? Loved playing with that in Max3D... |
| ||
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. |
| ||
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) |
| ||
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. |
| ||
> 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. |
| ||
>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 :-) |
| ||
Looks like a good idea! |
| ||
Awesome cant wait. |
| ||
Cant wait! all my monkey coding mood is on hold, since i dont want to use mojo (1) anymore for now :( |
| ||
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.) :) |
| ||
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 |
| ||
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 |