Mojo2 is out! [MONKEYNEWS]

Monkey Forums/Monkey Programming/Mojo2 is out! [MONKEYNEWS]

marksibly(Posted 2015) [#1]
Hi,

[edit]new version v84e now up - see VERSIONS.TXT below[/edit]

I've just uploaded experimental monkey v84a which includes mojo2!

Please see the 'overview' and 'samples' links on the help home page for an intro to mojo2.

I am also after more bananas! If anyone does any cool demos in mojo2 and is OK with them being added to the release, please let me know.

I have also added a 'glfw3_angle' target. This uses the 'angle' library (an 'opengl-in-directx' layer used by many browsers to implement webgl) so you can write mojo2 apps that effectively use directx. This does add some overhead to releases (approx 5M) but solves all sorts of problems such as translating shaders from glsl to directx, and dealing with both d3d9 and d3d12.

Note: there's already one bug in there I forgot to fix - you MUST create a canvas (or renderer) before using any other mojo2 classes, as this is where initialization is performed. Will fix, although I am sure there will be other issues...

Have fun!


***** v84e *****

Fixed issue with Mojo2 html5 texture loading.

Mojo2 Shader.OnLoadMaterial now returns a Material so it can signal failure.

Mooo2 DrawList.DrawPoint and DrawList.DrawLine coords offset by .5


***** v84d *****

Mojo2 DrawList.Color now returns a copy. Added DrawList.GetColor.

Tweaked android_new target so OnUpdate always happens on render thread.


***** v84c *****

Added versions of DrawList.DrawPrimitives/DrawList.DrawIndexedPrimitives with texcoords:float[] param.

Canvas.RenderDrawList NOT affected by current blend mode - blend modes used to create DrawList always used.

Canvas.RenderDrawList now always affected by current color/alpha.

Canvas.RenderDrawList now always affected by 2d matrix.

Canvas.RenderDrawListEx renamed to Canvas.RenderDrawList.

Mojo2 2d matrix stack now quietly wraps around.

Added DrawList.SetMatrixStackCapacity.

Replaced all #BLAH_FILES="..." with #BLAH_FILES+="..." in all target CONFIG.MONKEY files so they don't fail if code sets a custom file type filter.

Added 'VBO orphaning' to mojo2 for improved performance on at least ios/mac.


***** v84b *****

Mojo2 DrawOp's now allocated from a pool.

Undid fancy but broken reflection fixes.

Fixed some mojo2 issues, including IE11 and Safari fixes.

***** v84a *****

Ted now prompts for rebuild docs at startup if docs/html not found.

Added f1 cycle through helps for a keyword to Ted.

Added shift-f5 to kill app to Ted.

Updated stb libs to latest version for all glfw targets.

Updated glfw3 lib to latest version for glfw3 targets.

Bumped glfw3 target msvc projects to msvc2013e. Note: msbuild has moved, see/update config.winnt.txt

Added brl.requesters for simple modal requester support (Glfw3/Pc/Mac only)

Glfw3 builds on macos can now use Objective C.

Lots of opengl tweaks.




Playniax(Posted 2015) [#2]
Awesome!


Soap(Posted 2015) [#3]
!!!!


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

This made my weekend. Doing low res games for jams or release just became wickedly easy and cleaner. And on HTML5 too!


Luis(Posted 2015) [#5]
mojo2 no module in the github in v84a


mjcamerer(Posted 2015) [#6]
Having a blast playing with all the new stuff. Thanks Mark!


Richard Betson(Posted 2015) [#7]
Awesome!

Downloading msvc2013e (or at least the latest free version). Off to test HTML5. ;)


Xaron(Posted 2015) [#8]
Nice! Will check it out!

@Richard: Mojo2 uses opengl for rendering, and as such can only be used on the desktop, ios and android targets.


Playniax(Posted 2015) [#9]
You need a WebGL enabled browser and it will work on HTML5

I also found with chrome mobile on my phone I needed to enable 'Override software rendering list' found at 'chrome://flags/'

This is Mojo 2 + Pyro on HTML5 at work.


dawlane(Posted 2015) [#10]
Nice!
@Xaron: Didn't Mark say somewhere that webgl was being supported. Just test Mojo2 samples with HTML5 and they work.


Xaron(Posted 2015) [#11]
Well I took that sentence out of the official help documentation. ;)


therevills(Posted 2015) [#12]
Do I need anything special for GLFW+Angle target?

I can compile the Mojo2 examples with GLFW3, but when I compile for GLFW+Angle I get the following:



degac(Posted 2015) [#13]
GREAT!

Mark, you can't release a such thing on monday! I must work :P


EdzUp(Posted 2015) [#14]
Does it still work with MingW and GCC, I see loads of stuff about vc++ just wanted to know before I upgrade.


impixi(Posted 2015) [#15]
@therevills:
For GLFW3+Angle target I think you need the MS VS Studio 2013 Express compiler. You're using MinGW 4.8.2?

@marksibly:
Thanks. This is awesome. I tried all the samples with HTML5, GLFW3 and GLFW3+Angle (VS Express 2013 compiler) and they ran great!


impixi(Posted 2015) [#16]
@EdzUp:

I just tried compiling all the Mojo2 samples (GLFW3 target) with MinGW64 GCC 4.9.2 (bundled in the latest Dev C++ release). No problems noticed.


dawlane(Posted 2015) [#17]
@therevills: As you are using a 64bit variant of MinGW and getting 'skipping incompatible' . Have you tried modifying the Makefile and passed the -m32 option in CPPFLAGS and LDFLAGS?

Your only other solution is to rebuild the angle libraries.
Assuming this is what Mark used.
https://github.com/google/angle
https://code.google.com/p/angleproject/wiki/DevSetup

Note for Linux users
The supplied Ted binary may crash. Just rebuild it for your system. You may need to install the 'international components for unicode' development files. For Debian/Ubuntu libicu-dev.


EdzUp(Posted 2015) [#18]
@impixi: thanks will get round to whacking Star Rogue through it :) just gotta finish some segments then I can release another demo, there isn't enough time in the day though :/


peterigz(Posted 2015) [#19]
Looks very good :) I'll get TimelineFX into mojo2 asap, doesn't look like it'd be much work. I did notice that the LoadFrames function doesn't support a columns/rows style of sprite sheet which I'd need, only image strips. I can't see mojo2 on github to do a pull request so here's an extra function I put in the image class which seems to work fine alongside the original:

	Function LoadFrames:Image[] (path:String, numFrames:Int, cellWidth:Int, cellHeight:Int, padded:Bool = False, xhandle:Float = 0.5, yhandle:Float = 0.5, flags:Int = Image.Filter | Image.Mipmap, shader:Shader = Null)
	
		Local material:=.Material.Load( path,flags|Texture.ClampST,shader )
		If Not material Return[]
		
		If cellWidth * cellHeight * numFrames > material.Width * material.Height Return[]
		
		Local frames:= New Image[numFrames]
		
		If cellHeight = material.Height
			Local x:=0,width:=cellWidth
			If padded x += 1; width -= 2
			
			For Local i:=0 Until numFrames
				frames[i] = New Image(material, i * cellWidth + x, 0, width, cellHeight, xhandle, yhandle)
			Next
		Else
			Local x:= 0, width:= cellWidth, y:= 0, height:= cellHeight
			Local columns:= material.Width / width
			If padded
				x += 1
				y += 1
				width -= 2
				height -= 2
			End If
			
			For Local i:=0 Until numFrames
				Local fx:Int = i Mod columns * cellWidth
				Local fy:Int = i / columns * cellHeight
				frames[i] = New Image(material, fx + x, fy + y, width, height, xhandle, yhandle)
			Next
		EndIf
		
		Return frames
		
	End



Richard Betson(Posted 2015) [#20]
Just woke up and immediately finished unwrapping mojo2 (like Xmas morning :D) . All examples run for Glfw3 (+angle as well, have DX9 here and Win 7) and Html5 with no issues so far. Just love the lighting and shadow effects. :). I will start to adapt my current gaming framework to exploit it.

I will try to make a couple of demos for mojo2. But only after I catch up and see what she can do. I want to make something cool. :)

Awesome stuff Mark. Just seeing the examples work has fired me up. :)

I'll get TimelineFX into mojo2 asap

+1 ;)


Edit: for those looking for msvs2013e go here:
https://msdn.microsoft.com/en-us/library/dd831853.aspx?f=255&MSPPError=-2147217396
https://www.visualstudio.com/en-us/products/free-developer-offers-vs.aspx


Nobuyuki(Posted 2015) [#21]
Hey! Anyone know where the mojo2 samples are hiding? I'm a little blind (and was pretty tired when I tried this out last night). Couldn't get any of the mojo1 examples to compile using the Angle target. (Disclaimer: I have VSExpress 2013 but for this version I explicitly pointed to the MSBuild that comes with MSBuild Tools 2013 when configuring trans.)

What needs to be installed to make it work? I need the DX SDK? Oh, and also, everything still defaults to MinGW when compiling with Jungle, not sure if that's a Jungle thing but I don't remember there being a default switch for that in the trans config file. I'm surprised that the Angle target doesn't default compiling to MSBuild if it's a requirement, though I'm not sure if it is or isn't.

I can't wait to dig into this; I'd love to see if I can make some interesting demoscene-style intro or something of that nature.

@peterigz: Image frames are being depreciated from mojo2. You'll probably have to implement your own spritesheet handling for it eventually! (Most people here end up doing that anyway since image atlases already preclude using the built in image frame functions in many situations)


Richard Betson(Posted 2015) [#22]
Image frames are being depreciated from mojo2.

Hmmm, really. True? What is LoadFrames() for then? Just getting up to speed and would like to know.


peterigz(Posted 2015) [#23]
Well, a quote from Mark regarding frames:

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... ).


So rather than all of the image frames being stored within the image itself, you instead make your own arrays of images to manage yourself. I just thought there can't be much harm in an extra overloaded function to handle columns and rows. Easy enough to do a stand alone function to handle it though so either way...


Richard Betson(Posted 2015) [#24]
@peterigz
OK thanks. So just use LoadFrames() with an image array.

I just thought there can't be much harm in an extra overloaded function to handle columns and rows.

I tend to agree and this is one example of how thinning the language down (or whatever you want to call it) has an impact certainly on BlitzMax users that may start using mojo2 and MX2 (when it starts to live). I don't mind managing it but some mindsets might find it unappetizing.


dawlane(Posted 2015) [#25]
Hey! Anyone know where the mojo2 samples are hiding?
There's a link in the documentation and you will find them in the mojo2 modules directory under....... bananas.


taumel(Posted 2015) [#26]
Dunno if things got faster before already but i do get serious speed bumps with this one/Mojo2.

Did some quick tests, for instance the stars (64k of stars within 16ms, soft 60fps here vs. 36ms in Max 1.49, though Max compiles a lot faster).

@Mark
Nice!



Neuro(Posted 2015) [#27]
Coolness!!!!!


Richard Betson(Posted 2015) [#28]
I just cut and pasted (twice to make sure I had it all) and compiled the above and it cashes FireFox in Hrml5 and fails in Glfw3 with the following:




Difference(Posted 2015) [#29]
In reference to http://www.monkey-x.com/Community/posts.php?topic=9760&post=103460

marksibly wrote:
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 )



I found a DrawPrimitives(), in this release, - what does that do?
But anyway, really looking forward to the two functions mentioned above. Are they in the pipeline?


taumel(Posted 2015) [#30]
@Richard Betson
Oh, i made my tests with desktop Glfw3 (not interested in HTML5) and there things run very fine.


Skn3(Posted 2015) [#31]
Wow this is exciting! Now if only I didn't have my wedding to plan id be all over this!

Look forward to having a play!


Richard Betson(Posted 2015) [#32]
@ taumel
Which version of msvs are you running? Interested if my msvs2013e is the issue cause of string to long error. Shortening that long string at the end allows it to work. Feels like a 32 vs. 64bit issue


taumel(Posted 2015) [#33]
OS X, if the string is the problem then it might work to feed tex_stern with a png and comment the five lines below.


Richard Betson(Posted 2015) [#34]
@taumel
Thanks. It's interesting to note that on OSX that string is no problem. Anyway worked with image. Neat.


FBEpyon(Posted 2015) [#35]
Well looks like I have been out of the loop for a while, I have been working on my programs in BlitzMax of late and didn't even look at the monkey-x site.. Looks like I have a new toy to play with tonight :P

*Edit*

Finally got a chance to play around with it, and from what I have seen this is GOLD!! I love the canvas approach, and that fact the Virtual Resolution is in without needing autofit, this is PURE GOLD..

Thanks so marksibly!!


Nobuyuki(Posted 2015) [#36]
hey hey!

This may not be the correct thread for this, but I figured "heck, why not". I've made a little icon for those of you who were waiting for Monkey to support shaders before digging into serious GLSL. Surprisingly, I wasn't able to find an already-existing icon for this format! Anyway, it's based off the resources included in the vs2013 Image Library, and carries the same license.

https://s3.amazonaws.com/uploads.hipchat.com/11212/31746/VMygVq3obzEymky/glsl_file.ico

Now you can associate the glsl files used with mojo2 to go with your favorite editor, and have a spiffy icon to go with that, too ;)

(I'm using n++ with a plugin for glsl at the moment, though I presume Jungle support will be forthcoming?)


FBEpyon(Posted 2015) [#37]
Yep I'm sold I would pay another $120 for this like I did before (or whatever I paid lol)!!

@Mark : If I wasn't going on vacation this year, I would be throwing you money like a mad man!! This is pure PLATINUM, gold doesn't even compare to this anymore, I was able to completely port my Max program over by changing out the Types to Class, and using my new Component system. Everything you have done here is fixed everything I didn't enjoy about Mojo1, and plus x1000!

All I can say is keep it up, and hope to see more updates.. I don't see the point in adding any more platforms (of course if you want to) because having what you have done already is just GREAT!! I look at this way I already have Mojo1 for the other platforms, and that is good enough for me.


Dabz(Posted 2015) [#38]
Gonna have a play tonight... But it just looks like mojo2 ticks quite a few buttons! :)

Yummmmmmyyyyyyyy

Dabz


Danilo(Posted 2015) [#39]
Awesome and exciting times, thanks Mark! :)


JaviCervera(Posted 2015) [#40]
@Nobuyuki: Great icon! Which font have you used for the GLSL text?


therevills(Posted 2015) [#41]
impixi
@therevills:
For GLFW3+Angle target I think you need the MS VS Studio 2013 Express compiler


Thanks.. I haven't had time to play again but I'll have a go with VSE.


Skn3(Posted 2015) [#42]
I sneakily had a look today (even though i should be working). Awesome stuff!
As others have already commented: the canvas approach is really clean!

Good job Mark!

Edit:
Oh wow we have some drawlist stuff in there :D awesome.
Also more blend modes, woo hoo!


Snader(Posted 2015) [#43]
Already looks amazing!


Nobuyuki(Posted 2015) [#44]
@Javi

It's Chalet, with the "S" rotated :)


DruggedBunny(Posted 2015) [#45]

the Virtual Resolution is in without needing autofit


NoooOOOOOooooo!!! How will I ever get to be part of a BAFTA-winning production again?!

Mark, is there any chance that MX2 could include a custom shader language (a very limited subset of Monkey), so it could spit out GLSL from a ShaderFunction () written directly in Monkey source? It would make shaders accessible in a way nobody's really done, AFAIK, making it a very attractive feature... can't imagine it would be overly difficult for you, considering how limited GLSL is! (He said, ignorantly... )

Going to be playing with Mojo2 tonight, anyway... looking awesome, and a winner all-round by all accounts.


taumel(Posted 2015) [#46]
Hmm, is the canvas approach clean?

Dunno, when i see shadows i instantly have to think in 3D.


Richard Betson(Posted 2015) [#47]
Bouncy aliens the rotation addition :) - http://www.monkey-x.com/Community/posts.php?topic=9829#105554
Having fun:D

Edit: On IE all I get is a black screen (app display). Chrome and Firefox are OK. Bug? I do something wrong?


FBEpyon(Posted 2015) [#48]

Edit: On IE all I get is a black screen (app display). Chrome and Firefox are OK. Bug? I do something wrong?



You need to make sure you have the latest IE I had this problem as well, but all accounts it works way better than I had expected. I'm halfway though adding my new code to it, and its so seamless..

BTW drawing canvas to image is a huge PLUS


Richard Betson(Posted 2015) [#49]
@FBEpyon
Running IE 11, isn't that the latest for Win 7?


FBEpyon(Posted 2015) [#50]
@Richard
Yes that is the latest.. That is strange, I wonder if there is something missing in the add ons.. I'm running Windows 8.1 on everything.. hmmm


Richard Betson(Posted 2015) [#51]
^One of my team also reported it not working on IE11 and 8.1. So I'm not sure what to make of it. I know I am up to date through windows update (latest update - kb3058515 6/9/15).


TeaBoy(Posted 2015) [#52]
@Richard,

I'm not sure if all the demos aren't working on IE11, but this site seems to suggest you need
to enable WebGL via registry, although I have no clue, I use Firefox here.

http://withinwindows.com/blog/2013/3/30/blues-clues-how-to-enable-webgl-in-internet-explorer-11


marksibly(Posted 2015) [#53]
If you're having trouble with IE, use Chrome or FIrefox for now...I'll take a closer look at IE later.


Richard Betson(Posted 2015) [#54]
@Mark
Many of the other examples run in IE for example renderdemo and directlight but mojotest and bouncyaliens do not. So maybe an issue. :) Fine without IE. Never use it.


FBEpyon(Posted 2015) [#55]
I was finally able to run a full test on my own stuff today, and the SetProjection2D = GOD SEND!!

http://www.thegaminguniverse.org/FBEpyon/game/ -- Check it out for your self... its not much as of right now doing some rewrites

Left/Right - walk
A/D - walk
Space - jump

@Mark
Thanks again for this amazing upgrade you have so kindly made..


skape(Posted 2015) [#56]
Yes, amazing! Thank you so much for the upgrades Mark! You truly do rock. ;)


Arthur(Posted 2015) [#57]
Works perfect in Glfw3, but direct light sample does not work in Safari 8.0.6 (10600.6.3) on MacOS 10.10.3 (14D136)

Here is error message:
Monkey Runtime Error : GL ERROR! err=1280
/Users/Arthur/Desktop/Projects/Monkey/MonkeyXPro84a/modules/mojo2/glutil.monkey<13>
/Users/Arthur/Desktop/Projects/Monkey/MonkeyXPro84a/modules/mojo2/graphics.monkey<936>
/Users/Arthur/Desktop/Projects/Monkey/MonkeyXPro84a/modules/mojo2/graphics.monkey<1753>
/Users/Arthur/Desktop/Projects/Monkey/MonkeyXPro84a/modules/mojo2/graphics.monkey<1841>
/Users/Arthur/Desktop/Projects/Monkey/MonkeyXPro84a/modules/mojo2/graphics.monkey<1861>
/Users/Arthur/Desktop/Projects/Monkey/MonkeyXPro84a/modules/mojo2/graphics.monkey<2277>
/Users/Arthur/Desktop/Projects/Monkey/MonkeyXPro84a/modules/mojo2/graphics.monkey<2183>
/Users/Arthur/Desktop/Projects/Monkey/MonkeyXPro84a/modules/mojo2/bananas/directlight/directlight.monkey<36>
/Users/Arthur/Desktop/Projects/Monkey/MonkeyXPro84a/modules/mojo/app.monkey<113>


Neuro(Posted 2015) [#58]
^One of my team also reported it not working on IE11 and 8.1. So I'm not sure what to make of it. I know I am up to date through windows update (latest update - kb3058515 6/9/15).


Confirmed on my end.


JaviCervera(Posted 2015) [#59]
Mark, my game does not build with this update. I have posted a bug report here:

http://www.monkey-x.com/Community/posts.php?topic=9825


Shinkiro1(Posted 2015) [#60]
First of, mojo2 looks pretty cool :)

I messed around with the render to image code and I can't get it to draw images on a render target.
My code is basically identical to the bananas example, just that instead of using
canvas.DrawRect(0, 0, 100, 100)

'I use
canvas.DrawImage(img, 0, 0)

canvas.Flush()


Tested on html5 and desktop targets.

Here is the OnRender from the example:
Method OnRender()
		
		Local start = Millisecs()
		'render to image...
		For Local x:=0 Until 16
			For Local y:=0 Until 16
				If (x~y)&1
					icanvas.SetColor Sin( Millisecs*.1 )*.5+.5,Cos( Millisecs*.1 )*.5+.5,.5
				Else
					icanvas.SetColor 1,1,0
				Endif
				icanvas.DrawRect x*16,y*16,16,16 '<<<<< replacing this with DrawImage
			Next
		Next
		icanvas.Flush
		Print Millisecs() -start
		
		'render to main canvas...
		canvas.Clear
		canvas.DrawImage image,MouseX,MouseY
		canvas.Flush
	End



edit: Image loads fine, I can render it to the main canvas just fine.


Difference(Posted 2015) [#61]
How do I transform a DrawList when using Canvas.RenderDrawList ?

with
Local canvas:Canvas
Local vectordrawing:DrawList

canvas.Rotate() and vectordrawing.Rotate(), seems to have no effect on the rendered Drawlist.
I'm not Flushing vectordrawing, it's made in OnCreate()

canvas.RenderDrawList(vectordrawing)


marksibly(Posted 2015) [#62]
> How do I transform a DrawList when using Canvas.RenderDrawList ?

To do this, you will need to mess with the ModelMatrix as all 2d transformations are performed when drawing to drawlist, not when rendering.

I could add simple x,y,z coords to RenderDrawList (which would perform the ViewMatrix stuff for you), but this would not be affected by current 2d matrix/blend mode/color etc. But if this is useful..?

The other alternative would be to add something like DrawDrawList, which would go through a given drawlist and transform vertices for you, but at this point you may as well just redraw the input drawlist.


marksibly(Posted 2015) [#63]
Ok, I've taken another look at this and have added the following convenience method to canvas:

Canvas.RenderDrawListEx( drawList:DrawList,tx:Float=0,ty:Float=0,rz:Float=0,sx:Float=1,sy:Float=1 )

This will render a drawlist transformed by the canvas' current 2d matrix and the given tx, ty, etc. Rendering wont however be affected by the canvas' current color, blendmode, shader etc, as that would require rebuilding the drawlist since these are stored per drawing op or, in the case of color, per vertex.

This will be a bit slower than plain RenderDrawList as it needs to upload some shader params, but I can still see it being useful for rendering complex geometry quickly.

Look out for render drawlist demo in next release!


Difference(Posted 2015) [#64]
Ok, I've taken another look at this and have added the following convenience method to canvas:
Canvas.RenderDrawListEx( drawList:DrawList,tx:Float=0,ty:Float=0,rz:Float=0,sx:Float=1,sy:Float=1 )


Great. I think it can be quite useful for stuff like parallax backgrounds composed in their own functions.

BTW: I've found out how to use DrawPrimitives() for drawing triangles, but I have to copy my indexed vertices to use it.
IME this will at some point cause breakup/small gaps in the rendering, that indexing does not.

Could an overload solution (for the syntax :-)) be

or does indexing only make sense for triangles on the lower levels of Mojo 2 ?


marksibly(Posted 2015) [#65]
> Great. I think it can be quite useful for stuff like parallax backgrounds composed in their own functions.

You can do this by directly modifying the canvas modelview matrix, which will be (a bit) faster. Pyro does this sort of thing to implement parallax layers.

> IME this will at some point cause breakup/small gaps in the rendering, that indexing does not.

IME it wont - as long as the vertex values are identical, it makes no difference whether they're read from 2 separate vertices or from the same vertex via 2 indices. Either way, the same data is read. Indexing is a bit faster though, as the GPU can cache transformed vertices. And of course it can be more compact.

Also, mojo2 currently uses a single static index buffer for drawing quads, but that's it. Everything else is drawn unindexed. There's no facility for index buffers in drawlists or canvas etc, so there's no easy way to add DrawIndexed (beyond just 'unpacking' the indexing as you're doing).

RenderIndexed is more possible, but it'd be messy, eg: you'd probably have to add the vertex data as points, and be very careful not to change drawlist state along the way etc, at which point I start to wonder whether it should be in mojo2 at all, or if you should start thinking about just using direct GL.


Difference(Posted 2015) [#66]
Thanks for the explanation.
I'll unpack my triangles and make a nice Banana vector demo with https://github.com/Difference/tesselate-monkey included :-)


marksibly(Posted 2015) [#67]
I'll keep thinking about something like RenderPrimtives/RenderIndexPrimitives though. I can see it being very useful for stuff that morphs in realtime. It's just a bit trickier than I initially thought...

And if you are morphing triangles, ie: updating vertices every frame, probably best just to draw them directly to the canvas, instead of via a drawlist.


Difference(Posted 2015) [#68]
I can see it being very useful for stuff that morphs in realtime.

That's *exactly* what I'm doing. I have an SVG parser that lets me draw in Illustrator with cleverly named paths, and morph between them in Monkey.

The way I hacked the indexedtriangles into Mojo 1, was by having a new order type (5?) and another indexbuffer besides the one for quads.


marksibly(Posted 2015) [#69]
New version v84b now up with some fixes for IE and Safari.

Also, I've added DrawIndexedPrimitives. This still unpacks the vertices so indices aren't actually used for rendering, but it should be considerably faster than doing it yerself via DrawTriangle, DrawTriangle etc...

I've also added 'count' params to DrawPrimitives and DrawIndexedPrimitives so you can reuse a single 'max length' array to draw batches of primitives.


Richard Betson(Posted 2015) [#70]
^Looking good so far. Both 'bouncyaliens' and 'mojo2test' both run (didn't before) on IE as well as Glfw3. Looking good.


Difference(Posted 2015) [#71]
Great addition!
I have to change DrawIndexedPrimitives to this to make it work like I expect it to:



Richard Betson(Posted 2015) [#72]
Hi,

As I understand SetVertices() I can just use an array of vertices that outlines the shadow caster image. Is that right? How many vertices can I add? If so it would be actually similar to the method in Phoenix USC I use for collision. Which means it's plus, plus, plus for me as my editor can generate these vertices.

I am also wondering how I could use the shadow caster framework for collision.. just musing. :)


marksibly(Posted 2015) [#73]
> I have to change DrawIndexedPrimitives to this to make it work like I expect it to:

I prefer indices to be 'vertex index' not 'float index'. 'p' is also 'dead'...?

> As I understand SetVertices() I can just use an array of vertices that outlines the shadow caster image. Is that right?

Yes, it's basically a 2d polygon, aka closed edge loop. I plan to add 'modes' for vertices, eg: closed edge loop, open edge loop, edge soup etc.

> How many vertices can I add?

As many as you want, speed permitting.


Richard Betson(Posted 2015) [#74]
@Mark
Right on... This will work well with my stuff as I am using the exact same concept (2D poly's) for collision.

I plan to add 'modes' for vertices, eg: closed edge loop, open edge loop, edge soup etc.

Awesome.


Richard Betson(Posted 2015) [#75]
@Mark
Should we be posting mojo2 questions here continually ? edit- (LOL, that being when we have questions. although it might feel like it's continues)

I was working with the displaylist and it appears that I can avoid using a canvas by using 'drawList.DrawImage' for example as you do in the 'renderer' demo. Is it faster (better performance) to use displaylist? I am trying to get my head around just how all this is laid out structure wise (mojo2) and where areas of my GUI code for example might overlap with features included in mojo2. What I am thinking is that I already manage what essentially is a canvas (images and other graphic objects) for windows in my GUI and perhaps using displaylist is the best fastest option for performance.

Looking for a little guidance. Thanks.


Difference(Posted 2015) [#76]
> I have to change DrawIndexedPrimitives to this to make it work like I expect it to:
I prefer indices to be 'vertex index' not 'float index'. 'p' is also 'dead'...?


Ok. Dividing my indexes by 2 solves it for me,
Thanks again for the posibillity to render triangle arrays. It's been my top Monkey wish for a long time!


Salmakis(Posted 2015) [#77]
hey, just downloaded 84b and now i got the error:
Monkey Runtime Error : Can't find //@vertex chunk

it seems like no glsl files are copied into build data folder
(when i copy them by myself then it is working well)

edit:
#TEXT_FILES+="|*.glsl"
fixed this issue to me


skape(Posted 2015) [#78]
@Salmakis
Thanks for the filter tip. I was running into this as well!


Shinkiro1(Posted 2015) [#79]
Does anybody know how to draw images on a render target?
(See previous page for details)


skape(Posted 2015) [#80]
@Shinkiro1
I'm not sure what is not working for you. This works for me:



If loading from a file, are you using the Image.Load(...) method of mojo2? Demo also works for me if I do drawimg = Image.Load("testimg.png").


marksibly(Posted 2015) [#81]
> Monkey Runtime Error : Can't find //@vertex chunk

The CONFIG.MONKEY file in the mojo2 target 'template' dirs should now include *.glsl as a valid text file type - is this missing?


marksibly(Posted 2015) [#82]
> Does anybody know how to draw images on a render target?

There is one 'wrinkle' with this in html5 - you will have to wait for the image to load before drawing it (unless you are drawing it every frame - it's OK to draw an image while it's loading, nothing will happen).

For example, this:
Method OnCreate()
   ...
   Local image:=LoadImage(...)
   canvas.DrawImage image...
End

May not work on html5. To fix, you'll need to do something like...
Method OnCreate()
   ...
   image=LoadImage(...)
End

Method OnUpdate()   'or OnRender
   If image.Loading Return
   ...safe to use image now...
   canvas.DrawImage image...
End



marksibly(Posted 2015) [#83]
> Is it faster (better performance) to use displaylist?

It's the same - a canvas 'is' a drawlist (ie: it extends DrawList) so when you DrawImage to a canvas, you're really DrawImage-ing to a drawlist. All a canvas really does is 'auto-render/reset' it's drawlist when you make a canvas state change, such as change viewport, lighting etc.

So just using a drawlist for all drawing is fine, and is probably the cleaner approach for 'pure' drawing that doesn't affect viewport, lighting etc.


Richard Betson(Posted 2015) [#84]
^Thanks. I use a very similar approach in managing my GUI windows.


Shinkiro1(Posted 2015) [#85]
@Mark
> There is one 'wrinkle' with this in html5 - you will have to wait for the image to load before drawing it

Thanks, that solved it.

edit:
when i call Image.ImagesLoading() i get
/monkey/modules/mojo2/graphics.monkey<1119> : Error : Identifier '_textures' not found.

image.Loading() on an instance works fine.


marksibly(Posted 2015) [#86]
> /monkey/modules/mojo2/graphics.monkey<1119> : Error : Identifier '_textures' not found.

Update to v84b...


Luis(Posted 2015) [#87]
Where can I download the module Mojo2, that is not in the github?


ImmutableOctet(SKNG)(Posted 2015) [#88]
@Luis: Mojo 2 is only for "Pro users", you're going to need to buy the full version of Monkey.


Richard Betson(Posted 2015) [#89]
84b
-----
I have tried a few of the examples on Android 5.0 and all is well so far. Running 1000 bouncy aliens with a virtual resolution of 1280x720 (SetProjection2d). I get a steady FPS of 58 on my Android tablet for both update and render. Weather running 100 or a thousand the FPS is 58. Maybe my GPU refresh rate is lower then 60?

On Glfw3 I am running into a problem when I change the 'Config.Monkey' to a different valid display resolution it will sometimes fail on build. When this happens I can no longer build the app unless I remove the Glfw3 folder and start a new (even when changing the display resolution back to what it was). Not quite sure why this happens yet but it seems to be when I change display size in 'Config.Monkey' , build and then change the display size to something lower and then build and then it crashes fails. I am using the bouncyaliens demo in this case. I will try to isolate the problem. Maybe someone else has had this issue?


Beaker(Posted 2015) [#90]
I've just converted AngelFont to Mojo2 and I have 2 issues.

1) On Firefox if I compile for HTML5 it looks fine, but then if I refresh the page it corrupts the render. See below:
Before refresh:

After:

This persists across compiles and eventually fixes itself until I refresh again. Safari doesn't have this issue.

2) You can also see in the images above that the white text is rendered light blue. This happens in both Firefox and Safari. Any ideas?


Beaker(Posted 2015) [#91]
I've just realised that the color issue is because SetColor now expects values between 0.0 and 1.0.


Richard Betson(Posted 2015) [#92]
@Beaker
I need to learn how to use AngelFont. That first image looks sweet font wise.

SetColor now expects values between 0.0 and 1.0.

Thanks.. Solves my other issue. :D


rIKmAN(Posted 2015) [#93]
<oops wrong thread lol>

I go away for a little while and when I get back what the hell has happened!?

Mojo2 sounds AWESOME!!!!!
I have only had time to run a couple of samples so far but I'm sat here with a big grin on my face reading through these threads, very excited for the future!

Thanks Mark.


Salmakis(Posted 2015) [#94]
@ Mark,
ty for mojo2


Richard Betson(Posted 2015) [#95]
Got some serious performance issues compared to mojo1 when drawing images.

So running the 'mojo1' (82b) bounceyalines demo I can run 10,000 bouncy aliens at 60 FPS. Running mojo2 at 10,000 bouncey aliens I get 22 FPS (84b - render rate). I am setting the display to 1280x720 in 'config.monkey'. I was noticing some issues with performance and this I think verifies it. I have included the modified demo (bouncyaliens both 82b and 84b) so you can compare. I ran the demos both in Glfw3 (angled slightly slower). I am hoping this is a bug or something I did wrong. I absolutely need the same performance drawing images as mojo1 has.

Additionally after deleting the Glfw directory I built/ran the 84b bounceyalines demo. Then changed the display resolution to 1280x720 in config.monkey, saved it, rebuilt demo and it failed with a "Monkey Runtime Error : Memory access violation". So something is up there. Here is the full debug error and it looks like mojo2 cant create a shader.

Edit- After posting this I tried to build above in release and it crashed Window 7 (reboot).


.
82b slightly modified bouncyaliens demo


84b slightly modified bouncyaliens demo.



Richard Betson(Posted 2015) [#96]
^Just to check I ran this in 84a and it ran about the same 22 FPS but the update rate was 60 FPS which is cool that it does that. It was not in the above and both the update rate and the render rate were 22 FPS.


marksibly(Posted 2015) [#97]
Mojo2 performance is likely to be better on more modern hardware, eg: mojo2 runs like a dog on my old android nexus 7 tablet, but blitzes mojo1 on a new nvidia shield tablet.

Here on my mac mini, both mojo1 and mojo2 bouncyaliens do about 13000 before dropping below 60FPS.

Another thing you can try is adding...

Shader.SetDefaultShader Shader.FastShader()

...before loading any images. But this shader doesn't support lighting etc, and doesn't make any apparent difference here on my mac mini with bouncyaliens, which I'm guessing is fill rate limited.

> I absolutely need the same performance drawing images as mojo1 has.

You absolutely wont get it across all hardware!

> Then changed the display resolution to 1280x720 in config.monkey, saved it, rebuilt demo and it failed

I have no idea why some people are having problems with CONFIG.MONKEY. Does a 'clean' build result in a CONFIG.MONKEY file like this? In particular, does the TEXT_FILES filter include *.glsl?

'----- bouncyaliens.buildv84b/glfw3/CONFIG.MONKEY -----

#GLFW_USE_MINGW=True

#GLFW_WINDOW_TITLE="Monkey Game"
#GLFW_WINDOW_WIDTH=640
#GLFW_WINDOW_HEIGHT=480
#GLFW_WINDOW_SAMPLES=0
#GLFW_WINDOW_RESIZABLE=False
#GLFW_WINDOW_DECORATED=True
#GLFW_WINDOW_FLOATING=False
#GLFW_WINDOW_FULLSCREEN=False

#GLFW_SWAP_INTERVAL=-1

#OPENGL_GLES20_ENABLED=False
#OPENGL_DEPTH_BUFFER_ENABLED=False

#MOJO_AUTO_SUSPEND_ENABLED=True
#MOJO_IMAGE_FILTERING_ENABLED=True

#TEXT_FILES="*.txt|*.xml|*.json|*.glsl"
#IMAGE_FILES="*.png|*.jpg"
#SOUND_FILES="*.wav|*.ogg"
#MUSIC_FILES="*.wav|*.ogg"
#BINARY_FILES="*.bin|*.dat"



marksibly(Posted 2015) [#98]
> Just to check I ran this in 84a and it ran about the same 22 FPS but the update rate was 60 FPS which is cool that it does that. It was not in the above and both the update rate and the render rate were 22 FPS.

This may be related to SetUpdateRate. Using an update rate of '0' puts Monkey into 'free running' mode, where it just updates/renders as fast as it can, with 1 update per render. Best used with SetSwapInterval 1 in glfw, or custom timing code...

SetUpdateRate N will make sure there are N updates per second.


Richard Betson(Posted 2015) [#99]
You absolutely wont get it across all hardware!

Will mojo1 run with Mx2? If so I would be happy with that, else I will have to rethink things. I mean I get less then half the performance on my desktop and my new tablet. With half the performance missing it's just not going to deliver the performance I would need. If I cant run mojo1 in MX2 then mojo2 puts things in the 'you must have new awesome video hardware" genre which is a death nail for mass market delivery. Really just deflating my expectations a bit and just kills off what I am currently developing at least with mojo2.

Shader.SetDefaultShader Shader.FastShader()

No good effect with that.

include *.glsl

I must have missed/forgot that. I will give it a try.


marksibly(Posted 2015) [#100]
>Will mojo1 run with Mx2?

It should be easy to convert, but I will be concentrating on mojo2.5-ish.

> No good effect with that.

What does that mean?

> I must have missed/forgot that. I will give it a try.

*.glsl should be in there already - is it?

If not, what does your targets/glfw/template/CONFIG.MONKEY file look like? Does it include *.glsl?


Richard Betson(Posted 2015) [#101]
It should be easy to convert, but I will be concentrating on mojo2.5-ish.

OK. I hope things workout where I have an option to use mojo1 or an added path within mojo2 to get similar mojo1 image draw performance. My project hinges on mojo1's wonderful image draw performance. Which in my book trumps lighting, shadows or whatever. I get what you are up to architecture wise with mojo2 (supporting the future and industry current standards) but the cost for me is a bit hard to swallow.

What does that mean?

Sorry (was a little tilted reading above). I tried putting 'Shader.SetDefaultShader Shader.FastShader()' in OnCreate() before any images loaded and there was no improvement in image draw performance.

*.glsl should be in there already - is it?

I had taken that as I needed to add it (*.glsl). When I did a fresh build and checked it is there. It was also there in the above code build.
TEXT_FILES="*.txt|*.xml|*.json|*.glsl"



marksibly(Posted 2015) [#102]
> When I did a fresh build and checked it is there. It was also there in the above code build.

And the app is still crashing, even with *.glsl in there?


Richard Betson(Posted 2015) [#103]
And the app is still crashing, even with *.glsl in there?

When I do a fresh build it will run great (talking about the boucyalien demo 84b). If I then go and look in config.monkey '*.glsl' is there. If I then change the display width and height to say this:
'From this
#GLFW_WINDOW_WIDTH=640
#GLFW_WINDOW_HEIGHT=480

'To this

#GLFW_WINDOW_WIDTH=1280
#GLFW_WINDOW_HEIGHT=720


... then save the config.monkey file (exiting notepad, file not open), rebuild/run the 'bouncyaliens' demo it will then fail with the error I posted previously. When I go look at config.monkey after the failed build '*.glsl' is there and is 'not' missing. I modified the code for more sprites and for a WIDTH and HEIGHT (constants) of 1366x768 (was hoping you used posted code, but FYI in case you didn't). I hope that helps :)


marksibly(Posted 2015) [#104]
Ok, tried your bouncyalien demos and have no problems changing window size so I have no idea what's up there.

Does the letterbox banana run OK when you dynamically resize window?


Richard Betson(Posted 2015) [#105]
@Mark
The leterbox demo works fine even when changing the compiler directives to change the window display size.
#GLFW_WINDOW_WIDTH=
#GLFW_WINDOW_HEIGHT=


So I included them into the bouncyalien demo code I posted and it works fine there to using the directives to change the displays width and height. So I'll just include them from now on in my code. The old school change config.monkey approach seems to be a problem here.


Richard Betson(Posted 2015) [#106]
Also I should add that adding:
#GLFW_WINDOW_RESIZABLE=True
#GLFW_WINDOW_RENDER_WHILE_RESIZING=True

... to the code in demo allows resize of window but does not draw while resizing. This may be a demo issue and I have not checked yet.


Beaker(Posted 2015) [#107]
BTW. Even tho *.glsl is in the CONFIG.MONKEY file I still needed to add the line:
#TEXT_FILES+="|*.glsl"
to my main app source file (angelfont_example.monkey).

I also needed to add this line there as well (to get angelfont running), whereas with mojo1 I added it in the angelfont.monkey library file:
#TEXT_FILES+="|*.fnt"

(On Mac)


Hezkore(Posted 2015) [#108]
This might be a stupid question...
But is DrawImageRect not supported in Mojo2?
That's basically the only function I used when drawing my images.


ImmutableOctet(SKNG)(Posted 2015) [#109]
@Hezkore: It's been renamed, and is now an overload of 'DrawRect'. It seems to work the same way, though. To my knowledge, the only major differences are the name and argument-order.


Hezkore(Posted 2015) [#110]
Ah phew, I thought I had to redo my whole game hehe.
Seems like it would be an overload of DrawImage though... Unless draw DrawTriangle and all of those also have Image support I guess.

Some of my images are drawn as black squares, but only on Android API 10. (API 3 crash on every example)
But everything is drawn fine on GLFW and HTML5.
It seems to mostly happen on images loaded late in the game, cause if I load the same images at start, they work fine.
This didn't occur with Mojo 1.


Richard Betson(Posted 2015) [#111]
I am doing some conversion of my code to support mojo2 and I am getting an error I don't understand. So I thought I would ask.

When I build my code I get an 'Array index out of bounds' error in mojo2 graphics.monkey. The error occurs in the method PushMatrix(). Here is the error output.


I am not sure how I might be causing this error or if maybe its a bug. The line <581> is my code and a canvas.DrawImage() call. This error occurs only in Debug and in release I can see my GUI images on screen then they disappear replaced by a black screen, no error and no crash. Just stays that way.

Edit- In release mode it eventually has a 'Memory access violation".


ImmutableOctet(SKNG)(Posted 2015) [#112]
@Richard Betson: You're properly popping the matrices you pushed, and are calling 'Flush' on your canvas by the end, right? Because technically, the current 'PushMatrix' and 'PopMatrix' setup uses an array directly, and it doesn't really check the validity of the call. All it does is move the matrix-stack offset, and transfer some variables back and forth. If you want to debug this, you could output to the console in 'mojo2.graphics', or do something similar.


skid(Posted 2015) [#113]
Not enough pops or maybe even too many. Should be relatively easy to audit.

mojo2 could possibly detect a non empty stack at end of OnRender and inform you that your game is leaking.


Richard Betson(Posted 2015) [#114]
@ImmutableOctet(SKNG)
I am sure I am as all this worked on mojo1 and basically I am just modifying the code to work with mojo2. I do a canvas.Clear(), then all my render, then a canvas,Flush() at the end with these to calls being made before and after PushMatrix()/PopMatrix().

The odd thing is I can see my GUI running and appearing to function, even scrolling a tileimage window. It gets going for 60 frames or so then errors. I will go through and try to verify the order of each PopMatix/PushMatrix call, but I think they are all good.


marksibly(Posted 2015) [#115]
You probably needs to match pushes/pops, or the stack will blow up. I'll do something about this soon...not sure what yet.

Mojo1 resets render state at the start of OnRender, but mojo2 doesn't - renderstate is completely 'persistent' in mojo2.


peterigz(Posted 2015) [#116]
Are you definitely doing "canvas.PushMatrix"? Pretty sure I got a similar error because I'd forgotten to use the canvas method.


Salmakis(Posted 2015) [#117]
Is something like this planned to be added?
(drawing primtives with texcoords)
would be great for pre builded texts, windows, sprites etc :)

	
	Method DrawPrimitives:Void(order:Int, vertices:Float[], texcoords:Float[], image:Image)
		Local material:= image._material
		Local count:=vertices.Length/2/order
		If count<1 Or count*order>MAX_VERTICES Return
		
		Local p:=0
		For Local i:=0 Until count
			BeginPrim material,order
			For Local j:=0 Until order
				PrimVert vertices[p], vertices[p + 1], texcoords[p]/image._width, texcoords[p + 1]/image._height
				p+=2
			Next
		Next
	End


and another question:
will there be some simple way to use VBO like thingies, on a cool BRLish way.
like we push some vert arrays to the gpu and then get an object
and just call this to be object.draw, or tell object.clear to remove the VBO from gpu and stuff.
this might speed up complex drawings alot in some cases, or not?


Richard Betson(Posted 2015) [#118]
Are you definitely doing "canvas.PushMatrix"?

I am going through them all today. This GUI use a lot of them (PushMatrix/PpoMatrix). Based on above I would guess it's was working in mojo1 but wont work with mojo2 because perhaps push/pop was out of order using mojo1 and still working.


Salmakis(Posted 2015) [#119]
cool, i just found out that we can now set filter options for each image on load, also we can set the shader :O
so, fastshader is faster? without light and stuff (for guis as example?).


Richard Betson(Posted 2015) [#120]
Just FYI, it was indeed a PushMatrix/PopMatrix order problem with my issue above. Got my GUI working with mojo2.:) ^Thanks.


marksibly(Posted 2015) [#121]
> so, fastshader is faster?

A bit - will probably depend on GPU.

The source is all there in the mojo2/data dir, but basically fastshader only does the one texture read for ambient/diffuse color, while bumpshader does 3 reads, with 'specular' and 'normal' textures set to 1x1 default textures.

> Just FYI, it was indeed a PushMatrix/PopMatrix order problem with my issue above.

I think I should probably make the matrix stack 'wrap' in mojo2? Allowing it to grow forever the way it does in mojo1 (which was OK because it got cleared every OnRender) could be dangerous. Perhaps with a DrawList.SetMatrixStackSize too?


Richard Betson(Posted 2015) [#122]
@Mark
In running the bouncy aliens demo with 100 sprites in mojo2 I get an average CPU usage of 55-60% (on my duel core system Win 7). Running the 82b mojo1 version of the demo I get a CPU usage of 12-15%. Built with Glfw3 with SetUpdateRate(60) and SwapInterval(0)
Edit- still testing this out on other demos and conditions.

I think I should probably make the matrix stack 'wrap' in mojo2?

This would be cool to include just for the sake of mojo1 to mojo2 conversions and would make that process easier (I know LOL). I will +1 the same for DrawList.SetMatrixStackSize.


Richard Betson(Posted 2015) [#123]
Edit- still testing this out on other demos and conditions.

The CPU usage looks pretty good on my on my Android tablet (CPU Monitor Advanced is a great app for this). On the PC I guess maybe shaders are using CPU (DX9 level GPU). Upgrade on the way as a my DX9 level GPU just isn't cutting it with mojo2.


skape(Posted 2015) [#124]
I get similar (in some cases better with mojo2) CPU performance with mojo2 and mojo on my 3 year old Macbook Air with Intel HD 4000 integrated graphics. Bouncyaliens gives me 3.5% CPU with 100 aliens (max of 15000) with both versions (GLFW3, SwapInterval 0, SetUpdateRate 60).


Richard Betson(Posted 2015) [#125]
Hi,
I was able to build my project in Android and Glfw3 but in Glfw3+Angle I get this error.



dawlane(Posted 2015) [#126]
Added brl.requesters for simple modal requester support (Glfw3/Pc/Mac only)
I see no Linux, so a little work in progress.


Shinkiro1(Posted 2015) [#127]
In the directlight example how does mojo2 know that it should use a bumpmap shader for the loaded image? (Image.Load is given no other arguments than the path basically)


ImmutableOctet(SKNG)(Posted 2015) [#128]
@Shinkiro1: For some reason it's not documented, but you can pass a 'Shader' object as the last argument. If no shader is supplied, it will use the default shader. The default shader is currently 'Shader.BumpShader'.


Richard Betson(Posted 2015) [#129]
^It's in there. ;) From Canvas documentation,
In addition, for lighting to work correctly images and materials drawn with lighting enabled will need to be correctly setup for lighting.
The easiest way to load images for use with lighting is to use the matte shader when loading an image, eg:
Local image:=Image.Load( "myimage.png",.5,.,5,Image.Filter|Image.Mipmap,Shader.MatteShader() )
This will allow simple images with no specular or normal maps to be used with lighting.



Shinkiro1(Posted 2015) [#130]
@ImmutableOctet(SKNG)
I thought FastShader was the default but after dabbling in the source I found that for images it's the BumpShader.


marksibly(Posted 2015) [#131]
Image.Load and Image.LoadFrames docs fixed for next release...


Sicilica(Posted 2015) [#132]
It seems that if you change resolution at runtime (via SetDeviceWindow()), you lose the OS window border on GLFW3. I don't see any callback in mojo2 that I should be using to repair it, so I assume that was just an oversight?


Richard Betson(Posted 2015) [#133]
Hi,

I am using SetProjection2d() to set a master virtual resolution in my project which works well when the display size is changed. I am able to use TransformCoords() to get the mouse coordinates from a canvas OK. SetScissor() uses view port coordinates and does not seem to be transformed to SetViewPort()'s matrix (display size). Is there a way I can get SetScissor() to scale up or down to be transformed to SetViewPort()'s matrix (display size) in mojo2?

What I am up against is while using SetViewPort() will change the view port dimensions, SetScissor() will not automatically match and scale to the new view port dimensions. So I will have to scale all the input variables I supply to SetScissor() to scale to the new view port size. I was wondering if there is an easier (better / more efficient) way to do this.


Wiering(Posted 2015) [#134]
Hi, I was playing with the RenderDrawList demo and it seems like that function doesn't use the current Alpha value, is this intentional? For example:
	canvas.SetAlpha 0.25
	canvas.RenderDrawListEx drawList,MouseX,MouseY,Millisecs*.01
	canvas.SetAlpha 1
	canvas.RenderDrawListEx drawList,MouseX,MouseY,Millisecs*.02

Everything gets alpha 1, whereas it does use the current FogColor.


ImmutableOctet(SKNG)(Posted 2015) [#135]
@Wiering: Fog and lighting is handled by the 'Canvas' itself, so it's not relevant to the 'DrawList' you're using. Thus, it's applying when you use a 'DrawList'. That being said, 'DrawLists' handle their own alpha/color internally, and that's what's used when using 'RenderDrawListEx'. I'd be interested in Mark adding an option to use the parent 'DrawList' for color-data, though.


marksibly(Posted 2015) [#136]
> I'd be interested in Mark adding an option to use the parent 'DrawList' for color-data, though.

This'd effectively mean 'redrawing the drawlist' (since color is stored per primitive) at which point there's no benefit in using the drawlist at all and you may as well just redraw everything.

To do this efficiently, there'd need to be a global color modulator added to the shaders. Might look at adding this in future...


Richard Betson(Posted 2015) [#137]
@Mark
Polygon Sprites. I came across this on the cocos2d site, it looks like a very interesting way to increase sprite / image performance.
http://discuss.cocos2d-x.org/t/new-feature-meshsprite-polygonsprite-updated/21153

Is this something you might be interested in adding to mojo2? Really nice performance using this method and the indications in that link are that this method can double to near triple fill rates.

Edit- I bet the same polygon data could be used for collision as well. Perhaps adding sprite class to support above.


Beaker(Posted 2015) [#138]
Richard - that'd be a great addition. This is increasingly the common way to go for 2d sprite stuff.


Richard Betson(Posted 2015) [#139]
This is increasingly the common way to go for 2d sprite stuff

It is a great way to provide much better fill rates for sprites on mobile devices and older hardware on PC's. Really a good solution I think and fits in with mojo2's architecture.


Difference(Posted 2015) [#140]
Yes, vectormonkey Try it out here: http://scheutz.dk/stuff/monkeywiggle/






CopperCircle(Posted 2015) [#141]
That looks great!, just need to get anti-alias for primitives on iOS and Android as it always looks nicer in HTML5.


Salmakis(Posted 2015) [#142]

@Mark
Polygon Sprites. I came across this on the cocos2d site, it looks like a very interesting way to increase sprite / image performance.
http://discuss.cocos2d-x.org/t/new-feature-meshsprite-polygonsprite-updated/21153

Is this something you might be interested in adding to mojo2? Really nice performance using this method and the indications in that link are that this method can double to near triple fill rates.

Edit- I bet the same polygon data could be used for collision as well. Perhaps adding sprite class to support above.



i think the trick is that they can just skip any alpha test with this, so they dont need to discard any texels (?)

this can be done actually with 82b,
see the code i posted on like page 5 (where i asked if this will be added (textured primitives)).
you just now need an algo or editor to create the arrays and uv arrays :)
editor should be very easy, algo would be nicer but not easy :O
but i think this is all only worth if we get some VBO´s :O wich we can draw.


Richard Betson(Posted 2015) [#143]
@Difference - Sweet.

@Salmakis
i think the trick is that they can just skip any alpha test with this, so they dont need to discard any texels (?)

Right, so the first step is to find non-transparent texels.No texels are discarded.

Although this might be doable with primitives it makes way more sense for Mark to include this into mojo2. One, it's the kind of feature that will be used all the time. Two, it offers a much faster fill rate for mobile (so needed). Three, some of the overhead can be used for collision and other useful things. I just see plus, plus, plus adding this to mojo2.


marksibly(Posted 2015) [#144]
> Yes, vectormonkey Try it out here: http://scheutz.dk/stuff/monkeywiggle/

Great stuff!

Can I add it to bananas?


Playniax(Posted 2015) [#145]
Cool stuff indeed. How do you create the vector data?


marksibly(Posted 2015) [#146]
Ok, v84c is now up!

Main points:

* Added versions of DrawList.DrawPrimitives/DrawList.DrawIndexedPrimitives that use texcoords arrays.

* RenderDrawList now affected by current color - not blendmode though, ie: blendmodes used to create drawlist are used.

* RenderDrawList now always affected by 2d matrix.

* RenderDrawListEx renamed back to RenderDrawList.

Forgot to add dawlane's linux requesters though - next time!


dawlane(Posted 2015) [#147]
@marksibly I've upload the requesters to github. This looks OK and works, but could do with someone more familiar with GTK/GDK and C/C++ to look it over. I was originally going to use the Athena widget set, which is guaranteed to be installed on every Linux distribution as it is maintained by the X org foundation and is part of the X windowing system. But unfortunately the Monkey String class clashes with the Athena String definitions.

Note I'm still get use to how this git thing works with Linux I would have thought that the git gui tools would have been more simpler.

Edit: Mark to use the requesters for Linux, trans will need the CCOPTS and CCLIBS enabling in the glfw builder. This also opens it up to add a few external libs to those that wish to do so.
In src/trans/builders directory
	glfw.monkey modifications in GCC section:
		Delete
			Local ccpots:=""
	Replace with:
		Local OPTS:="",LIBS:=""
		Local cc_opts:=GetConfigVar( "CC_OPTS" )
		If cc_opts OPTS+=" "+cc_opts.Replace( ";"," " )			
		Local cc_libs:=GetConfigVar( "CC_LIBS" )
		If cc_libs LIBS+=" "+cc_libs.Replace( ";"," " )
	Change:
		ccopts+=" -O0"
		ccopts+=" -O3 -DNDEBUG"
		Execute cmd+" CCOPTS=~q"+ccopts+"~q OUT=~q"+casedConfig+"/MonkeyGame~q"
	To:
		OPTS+=" -O0"
		OPTS+=" -O3 -DNDEBUG"
		Execute cmd+" CCOPTS=~q"+OPTS+"~q CCLIBS=~q"+LIBS+"~q OUT=~q"+casedConfig+"/MonkeyGame~q"
In targets/glfw/gcc_linux/Makefile and targets/glfw3/gcc_linux/Makefile
	Append $(CCLIBS) to LDLIBS. Note that this must be placed last. Libaries need to be linked in the correct order



Difference(Posted 2015) [#148]
@marksibly Thank you, ☺ yes please add to bananas.. Expect a little cleanup later.

@playniax I made a SVG parser, and run the shapes it reads through my tesselator.

@marksibly: Texturecoords demo comming soon! Really exited about this.

Mojo2 is truely fantastic!


Shinkiro1(Posted 2015) [#149]
In a custom shader is there a way to get the xy frag position in the range from 0..1.
I could just find the input vars b3d_ViewPosition and b3d_ClipPosition.


Hezkore(Posted 2015) [#150]
I've updated Monkey to v84c, but a lot of images on Android are still being loaded as black squares when using Mojo2.

It only seems to happen with images that are loaded "later" in the game.
It works fine on all other targets, even HTML5 viewed via Android!


marksibly(Posted 2015) [#151]
> I've updated Monkey to v84c, but a lot of images on Android are still being loaded as black squares when using Mojo2.

What SetUpdateRate are you using?

Can you try SetUpdateRate 0?


Hezkore(Posted 2015) [#152]
I'm using 30.
If I set it to 0, I can't progress in the game and try it out.


marksibly(Posted 2015) [#153]
Do any of the bananas work with SetUpdateRate 0 (on android)?


Beaker(Posted 2015) [#154]
Shouldn't the canvas.Color property return a copy instead of the actual array?


Richard Betson(Posted 2015) [#155]
I just noticed the new version up. Will test Bananas at SetUpdateRate 0 and more.


Richard Betson(Posted 2015) [#156]
Hi,

I have tested the bouncyaliens, renderer and mojotest demos with SetUpdateRate(0) add to OnCreate(). They all worked fine on my Android 5.0 tablet. I will try to test some others and my own code here soon.

Edit - My GUI test code also works well.


Beaker(Posted 2015) [#157]
Question: is it possible to get shadows going without fiddling with drawlists and renderers?


Hezkore(Posted 2015) [#158]
@marksibly
You were right, it's the UpdateRate that does it!
I thought UpdateRate 0 would just update 0 times (not move forward)
But trying it, I see that it simply doesn't limit the game speed, and the images no longer turn into black squares!
30 and 60 causes the black squares, but at 0 everything seems to work great.

I've also noticed similar problem with HTML5.
After a while of loading and unloading a lot of images, every image starts having white squares around them.
But setting UpdateRate to 0 doesn't fix it. (Could it be my Windows 10 GPU drivers?)


A fix for this would really help me out of a sticky situation.


DruggedBunny(Posted 2015) [#159]
EDIT: Didn't read properly... projection matrix is "zero, width, zero, height", and not "zero, zero, width, height"!


marksibly(Posted 2015) [#160]
> I've also noticed similar problem with HTML5.

Are you discarding images with Image.Discard()?


Hezkore(Posted 2015) [#161]
Yeah I am mark, but I think maybe it's a problem with Opera?
The same effect doesn't seem to happen in Microsoft Edge (IE) (although it has some other issues)

But the black square problem on Android is the real problem.


Beaker(Posted 2015) [#162]
Is it possible Hezkores issue is related to my issue mentioned in a previous post?:
http://www.monkey-x.com/Community/posts.php?topic=9823&post=106022


marksibly(Posted 2015) [#163]
No idea what's up with html5 texture issues - webgl takes care of all texture management so I'm inclined to blame webgl/browser for any 'lost texture' issues.

There is some 'crash simulation' code in there, but it shouldn't do anything unless you call 'CrashGraphics()'! It's also disabled in release mode, so perhaps try a release build?


Hezkore(Posted 2015) [#164]
Sadly I'm always using release build, so it's not debugs fault at least

Any news on the Android black square problem?
We want to release our game pretty soon, but the black squares are sorta holding us back right now.


Richard Betson(Posted 2015) [#165]
Any news on the Android black square problem?

So far I can not duplicate this problem on Android 5.0 (GLES 2.0 I think) tablet. Testing bananas demos and my code. Hezkore, can you whip up a demo that loads and destroys (unloads) images that breaks mojo2?

@Mark
Demo soon. Upgrading system this weekend to a Radeon HD5770, new case and psu. All for mojo2. ;)


marksibly(Posted 2015) [#166]
> Any news on the Android black square problem?

I've just uploaded v84d that includes a potential fix for this in the android_new target.

It's a semi-major change so I haven't updated android_ouya with it yet - please let me know if it works!


Richard Betson(Posted 2015) [#167]
Got it will test on Android and Windows. ;)


Hezkore(Posted 2015) [#168]
Well done Mark!
It now works great on Android.
Thanks a million for the quick fix!

Obviously the HTML5 issue is still there, but I'm only using HTML5 as the test build.
So it's not important to me right now.
I can however say that after Discard() and reloading the same image, I always get those weird white edges.
They're slightly less visible on Microsoft Edge than on Chrome/Opera, but obviously something is still weird there.
People have reported the same white edges using Firefox too.


Beaker(Posted 2015) [#169]
I think I've fixed my issue with refresh in Firefox removing the alpha from my AngelFont text. The solution was to invert the color (white>black) of just the transparent pixels in an image editor. This also means that you can use the FastShader() shader with these textures (otherwise only white blocks show).


Raudius(Posted 2015) [#170]
Hey @Beaker

Do you plan on releasing Angelfont for mojo2. I was gonna work on adapting the module for my project, but if you are planning on releasing it I'll hold off for a bit.

Thanks a lot!


Beaker(Posted 2015) [#171]
I will release it at some point. It's pretty simple to convert over tho (mostly just passing in a canvas object when you create your font, and a few other bits).


Raudius(Posted 2015) [#172]
Sweet.

I gave it a go this morning but I ran into the same issue you did a couple of posts ago. Did you find out how to fix it?


It only seems to happen with one font for me :/ works fine with all the others I've tested.


EDIT: Upon further testing it seems to only occur with fonts that have just one page.


Beaker(Posted 2015) [#173]
Two possibilities:
1) SetColor now requires colours between 0.0 and 1.0.
2) The alpha of the image needs all of the fully transparent pixels to be switched from white to black.


Raudius(Posted 2015) [#174]
@Beaker
I figured out what the issue is.

The problem comes from Image.Load(..) defaulting to a 1px*1px image when it cant succesfully load anything (instead of returning null). So all the "Char" areas are returned as a "full color image" and it then addopts the width and height of the character that its supposed to be.

So in the angelfont code, when checking if the image has been loaded (for single image files) the null check is moot:

image[0] = Image.Load(url+".png",0,0)
If image[0] = Null image[0] = Image.Load(url+"_0.png",0,0)


I just got rid of the condition as I always load "_0". But I guess the check could be changed to something like: if Image[0].Width()=1.



PS: I'm not sure what practicality it has to default Image.Load to a blank 1px image. Perhaps it should just return null?


DruggedBunny(Posted 2015) [#175]

Image.Load(..) defaulting to a 1px*1px image when it cant succesfully load anything



I'd report that as a bug, should almost certainly be returning Null!


marksibly(Posted 2015) [#176]
Just uploaded v84e with fixes for several issues, possibly even the html5 glitches!


Richard Betson(Posted 2015) [#177]
@Mark
Tested all the bananas examples in HTML5 / Glfw3 (HTML5 Firefox) and all working (Windows 7 64bit) except for vectormonkey which fails on Glfw3 and works on HTML5 ( see compiler output below). My code seems to work well (GUI test Glfw3).

Glfw3+Angle still an issue as seen here.
http://www.monkey-x.com/Community/posts.php?topic=9897

Vectormonkey output:



Difference(Posted 2015) [#178]
error C2026: string too big,

I can change Vectormonkey as needed. Is there a better way to include/inline data in Monkey-X, we dont have Defdata/ReadData, do we?


Richard Betson(Posted 2015) [#179]
error C2026: string too big,

Vector monkey works on HTML5 and Android. Why does it fail on Glfw3? 32bit issue?

@Mark
On Android Mojo2test seems to be off on the display width as I do not see the red line / border on the right side of the display. I see it in Glfw3 and HTML5.


Hezkore(Posted 2015) [#180]
@Mark
The white HTML5 squares a working a lot better.
I am however getting them in some very rare cases on some images, but it's about 99% better now.
Well done!


marksibly(Posted 2015) [#181]
> I can change Vectormonkey as needed. Is there a better way to include/inline data in Monkey-X, we dont have Defdata/ReadData, do we?

I've changed it to used LoadString instead.

> On Android Mojo2test seems to be off on the display width as I do not see the red line / border on the right side of the display. I see it in Glfw3 and HTML5.

Works OK here but always has. Are you using v84e? This includes some tweaks to line coords.


Richard Betson(Posted 2015) [#182]
Works OK here but always has. Are you using v84e?

84e, yes (all above posts). On Android DeviceWidth() returns 1368 on my 1366 wide display. So something is not right.

Edit - This is an issue with my tablet. Other system information software also reports my display at 1368 in width. Must be a firmware issue.


marksibly(Posted 2015) [#183]
> DeviceWidth() returns 1368 on my 1366 wide display

Yes, I can see how that could cause problems!


Salmakis(Posted 2015) [#184]
Hey, anyone got experiences with light and rotated stuff?
(note: i edited to not double post)
here is my test https://dl.dropboxusercontent.com/u/195739381/mojo2light/MonkeyGame.html
here are the source graphics:
diffuse
normals

the light is somewhere in one of the corners, but the "light" is rotating with the boxes.
since primvert is saving no information about the rotation of the matrix at the moment of drawing, it seems like its actually not possible to have that without hacking mojo2?
or am i wrong?

ok, i try hacking mojo2 for it, my approaches would be:
1.)
modify primvert that it also saves the normals for drawen rect and read them in the vertex shader, push them to the fragment shader and calculate them there with the fragment normals from the texture.
the biggest con is, that i would need to calculate it out of the current matrix rotation on drawRect call direct on the CPU i think thats not cool?
also the normal should be 0,0,-1 anyway wich is not helpfull

2.)
my second aproach would be to do the similar but just adding 1 float to the primvert for a pseudo z (just to get 1 more float value per vertex) and write the current rotation of the canvas matrix (in the moment of primvert was called) into this slot, and then calculate it with the lightVector.
but im not sure how to push data from vertex2fragment for fragment related to vertex (not the same for all) in glsl (only did this in cgprogramm)

well thats alot of math, and im not sure if this would work as i think, and if i will be able to do this with my current knowlege.

Maybe i just did not saw something? and this is allready possible without hacking mojo2 and its shaders?
or there is a more easy way someone can tell me? =)


marksibly(Posted 2015) [#185]
Yes, I ran into this late in development, couldn't find a way to deal with it that wouldn't slow things down massively, and promptly forgot about it!

However, after reading your post I think I have a reasonably efficient way of handling this, although it'll only work properly with uniform scale/rotation matrices. I'll give it a shot later today.


nullterm(Posted 2015) [#186]
Is there any way to turn off filtering in mojo2? I'm trying to draw to one low res Canvas, then scale it up to the screen.

Mac, Win, HTML5 all result in blurred pixels.






skid(Posted 2015) [#187]
bufferImage = New Image( 256, 240, 0, 0, 0 )


nullterm(Posted 2015) [#188]
@skid, Thank you! Works perfectly now.


nullterm(Posted 2015) [#189]
One more qvestion. Are mojo2's Shader glsl programs compatible with iOS and Android? I've only used the split vertex (.vsh) & fragment (.fsh) shader programs with OpenGL ES 2.0.


ImmutableOctet(SKNG)(Posted 2015) [#190]
@nullterm: Anything that supports GLSL supports Mojo's shaders. They just have a small API on top of normal GLSL fragment shaders. Case in point, I ported this with minimal edits. The original version(s) can be found here. The downside here is the lack of vertex shader access, but it's not like that'd be too useful for 2D stuff, anyway.

So, in other words, if OpenGL ES 2 was working for your own code, it'll work with Mojo 2 (At least, fragment shaders will).


skid(Posted 2015) [#191]
@nullterm: did you know that NES pixels are not square?

According to this the canvas will need to be stretched horizontally by 292:256 on to the display.


Richard Betson(Posted 2015) [#192]
Hi,

Is there a way I can add or subtract lights using the 'interface' method used in the renderer demo? It seems like I can only have a fixed number of lights.

Thanks


ImmutableOctet(SKNG)(Posted 2015) [#193]
@Richard Betson: What do you mean? Just don't send the 'ILight' into 'EnumLayerLights'. The lights are pretty basic, and don't really represent anything natively. So, treat them like normal objects, and ignore or pool them.

In the case of the "rendererdemo" banana, it has its own stack of lights that it enumerates and pushes into the 'EnumLayerLights' stack. So, for that situation, you'd just remove the lights from the 'layer0' object's 'lights' stack. Just keep in mind that this demo uses 'Get' in 'OnRender' for the light movement; so you'd have to ensure 'light' exists in 'OnRender'. That's basically it, don't push the lights you don't want displayed. From what I understand, 'ILights' are abstracted from GL lights, so you don't have a limit. They're just potentially slower if you have too many.


Richard Betson(Posted 2015) [#194]
@ImmutableOctet(SKNG)
I am adding light and shadow support to my GUI/Gaming framework and need to manage them independently for each window in my GUI. I want to be able to have the option to use one 'Renderer' instance for all windows in my GUI. Adding the following (adding lights but could subtract as well) seems to work and I think is cool with garbage collection. For me this would be a preferable method rather then adding more light objects and sorting through them. I'm just trying get my head around it all. :)

Method OnUpdate()
'NUM_LIGHTS changed to a global

	If KeyHit(KEY_A)=True
		NUM_LIGHTS=NUM_LIGHTS+1
		Self.lights=New MyLight[NUM_LIGHTS]
		For Local iz:Int=0 To NUM_LIGHTS-1
			lights[iz]=New MyLight
		Next
		Print NUM_LIGHTS
	Endif	
End Method



MikeHart(Posted 2015) [#195]
Holy fecking hell. I am porting/developing the next generation of fantomEngine and so implementing mojo2 right now. I couldn't believe how frickin fast mojo2 can render stuff. WOW!


Richard Betson(Posted 2015) [#196]
I can only seem to create a mojo2 object in 'OnCreate'. So this is OK..
Class Test
Field _renderer:Renderer
End Class

and this is 'not'.
Class Test
Field _renderer:Renderer=New Renderer
End Class


So I can't seem to create an instance of a class for mojo2 when defining a field. Is that just how it is?


nullterm(Posted 2015) [#197]
@Richard, guessing that it needs to happen after Monkey/Mojo2 has finished initializing.


Richard Betson(Posted 2015) [#198]
^I thought that might be the case, still I hope it can be changed to support in 'Field' creation. I'll wait for Mark to poke his head up and maybe catch this. ;)


Qube(Posted 2015) [#199]
This is probably a really dumb question, but... Does Mojo2 have a built in command for handling scenarios like the AutoFit demo for Mojo1? or do we still have to write our own routines for this?


ImmutableOctet(SKNG)(Posted 2015) [#200]
@Qube: This should help. Mojo 2 has some nice features for this kind of thing, but if you still need 'autofit', I made a work-in-progress Mojo 2 port. (Works with both Mojo and Mojo 2)

Also, this may interest you.


therevills(Posted 2015) [#201]
Also, this may interest you.

Very interesting...


Qube(Posted 2015) [#202]
@ImmutableOctet(SKNG)
That's great, thanks. The main reason for the auto fit type code is for the varying resolutions of the iPhone / iPad. I'll be able to whip up a specific requirement from these so thanks once again for your help.


Salmakis(Posted 2015) [#203]
hey, any update on the "Rotation with light" issue? :)


marksibly(Posted 2015) [#204]
> hey, any update on the "Rotation with light" issue? :)

Should be fixed in recent versions - see new bumptest banana.


lom(Posted 2016) [#205]
Is it possible to grab an animation frames from image atlas with Mojo2 ?


ImmutableOctet(SKNG)(Posted 2016) [#206]
@lom: Yes, it would be a lot harder to use without it. That is, you can extract the frames, at least. Mojo and Mojo 2 don't have animation frameworks, only the tools to make them. You can either use 'Texture' and 'Material' objects directly, or use 'Image' objects to simplify things. Simply make a new 'Image' object using your atlas ('Image' or 'Material') as an argument, along with the origin (X and Y) of the animation/area, and the width and height of the area. To break it into an animation, you would grab segments of the area you first grabbed. Alternatively, you can grab individual images based on the parameters you give, moving through the atlas via the coordinates used to grab a sub-image.

Loading individual files for animations is terrible, but more so if you're not re-packing them in memory. That's also possible with Mojo and Mojo 2, but it's a lot easier (And faster) to pack everything beforehand, rather than every program execution. Although, you could technically re-save an atlas as a cache, but that's also an unneeded step.

For a reference on how Mojo 'image grabbing' behavior relates to Mojo 2, and in particular, how to perform a basic 'grab' on an atlas, click here.


lom(Posted 2016) [#207]
ImmutableOctet(SKNG),

Thanks for the explanation!


lom(Posted 2016) [#208]
I have one more question:
Is it possible to set handle for image in pixels ? Because Mojo2 specifies handles in fractional values.


ImmutableOctet(SKNG)(Posted 2016) [#209]
@lom: No, but you can do it yourself like this. As a side note, your particular example isn't bad, but Mojo 2 is closed source, even if Mark intends to release it publicly later on. In other words, please do not post code snippets of Mojo 2.


APC(Posted 2016) [#210]
I need Help with MOJO2 Write Pixels, please refer to this post http://www.monkey-x.com/Community/posts.php?topic=10382


pit(Posted 2016) [#211]
Dears,

question: is there some "rules" to follow in order to convert program using Mojo to Mojo 2 ?
should be interesting all those who want to convert their app.

Pit


ImmutableOctet(SKNG)(Posted 2016) [#212]
@pit: It's a graphics-only change. Everything using something like 'mojo.input' or 'mojo.audio' will already work without modification. However, your imports need to reflect this. You can't use 'mojo' as the only import, as you're importing conflicting code. Not to mention the old codebase, which could stop the build on GLFW+ANGLE.

In situations where only 'mojo' was imported, just change it to 'mojo2'. That'll do the same thing as Mojo 1 did, only with the new imports. If you've got code using specific sub-modules, then you only need to change 'mojo.graphics' to 'mojo2.graphics' if used.

Please keep in mind that this is a major API difference. They aren't compatible, just similar. For example, 'Image' objects must be handled per-frame, meaning you're commonly using arrays in place of Mojo 1's 'Image' class. Mojo 1 did this behind the scenes, so it's not all that different. This does mean there's no "frame" arguments for functions, though. Just give it the right image and you'll be fine. In particular, going the array route means you can just use an index instead of a separate parameter.

Another pitfall is that colors are now represented as 0.0 to 1.0. This was always done natively with OpenGL, so it made sense for Mojo 2. Mojo 1 used a weird RGB-esque color system, even though it was floating-point for performance reasons. Basically, colors work like 'SetAlpha' now.

You'll also have to pass a 'Canvas', or in most cases, a 'DrawList' object where you need graphics. I handle this through method arguments, which allows for proper encapsulation. For compatibility, most people sadly end up going with fields. 'Canvases', or more specifically, 'DrawLists' have most of the methods you're used to inside of them. Again, not fully API compatible, but most of the same functionality.

There's some other details, like much better text/font performance, but these are the basic ideas. If you're interested, I wrote a module that converts 'mojo' calls to 'mojo2'. I did this for WebGL and DirectX/ANGLE mainly, but it's an effective way to see how things differ. The module's called 'mojoinmojo2'. It's a very direct API layer, even supporting import compatibility. It's missing a few details, but it can help with the transition to 'mojo2'.


Angus(Posted 2016) [#213]
I'm getting back into Monkey after a long break and am integrating mojo2 into my old code.

Looking through it has been a great way to learn some things about OpenGL as well. I'm still pretty lost, but hey.

I did experience a problem for a while today. After implementing an early set of bumpmapped objects, a shadow of my "shiny" material's color texture was stretched across the canvas. Not knowing anything about what I was doing I stumbled around till I found the change that fixed the problem.

In "mojo2/graphics.monkey": moving the command "glUniform1i shadowTexture,7" from line 582 to just after that "if" block, so that it's called regardless.

I've made some other tiny changes to the mojo2 code, but I don't think they'll effect this section. Am I breaking other parts of the system by doing this?

Should say that in spite of this hiccup, mojo2 is lots of fun. And I'd forgotten the joy of Monkey too, silly me.

I'm running it on Ubuntu16.04.


MikeHart(Posted 2016) [#214]
If it works, it isn't broken.


Angus(Posted 2016) [#215]
That's generally my default mode of operation. But god knows I've been stung by ignorance and over-confidence before :)


Angus(Posted 2016) [#216]
And it has again :D

After some time of working, compiling to html5 now generates the following error:

Argument 1 of WebGLRenderingContext.uniform1i is not an object.

...at my changed line. Serves me right for meddling.