Modifying the mojo Canvas Class

[AngusParticipant]

 

 

I’d like to use the Canvas class slightly differently, having my own objects transform vertices and pass them in.

Basically I want to expose a pair of methods like AddDrawOp and AddVertex.  They’d be almost identical to the ones that exist, but public and the AddVertex wouldn’t perform the transform.

Extending the class doesn’t work as the methods need to access private fields of Canvas (_vp for example)

I tried making my own version of Canvas with the methods added but got the following error:

Parsing…
Semanting…
Caught signal:Memory access violation

Though it’s not a preferred option, I then tried adding the methods to the Canvas class itself and got the same error as long as they were public.  Not if they are private, but then that defeats the purpose

These are the methods I’d like to use, they’re virtually identical to the existing private methods:

Monkey

Method NewVertex( tx:Float,ty:Float,s0:Float,t0:Float,c:Int,ix:Float=0.0,iy:float=0.0 ) _vp->position.x=tx _vp->position.y=ty _vp->texCoord0.x=s0 _vp->texCoord0.y=t0 _vp->texCoord1.x=ix _vp->texCoord1.y=iy _vp->color=c _vp+=1 End Method NewDrawOp( shader:Shader,material:UniformBlock,blendMode:BlendMode,primOrder:int,primCount:Int ) If _drawVB.Length+primCount*primOrder>_drawVB.Capacity Flush() Endif If blendMode=BlendMode.None blendMode=_blendMode If shader<>_drawOp.shader Or material<>_drawOp.material Or blendMode<>_drawOp.blendMode Or primOrder<>_drawOp.primOrder 'pad quads so primOffset always on a 4 vert boundary If primOrder=4 And _drawVB.Length & 3 _drawVB.AddVertices( 4-(_drawVB.Length&3) ) Endif _drawOp=New DrawOp _drawOp.shader=shader _drawOp.material=material _drawOp.blendMode=blendMode _drawOp.primOrder=primOrder _drawOp.primCount=primCount _drawOp.primOffset=_drawVB.Length _drawOps.Push( _drawOp ) Else _drawOp.primCount+=primCount Endif _vp=Cast( _drawVB.AddVertices( primOrder*primCount ) ) End

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

Method NewVertex( tx:Float,ty:Float,s0:Float,t0:Float,c:Int,ix:Float=0.0,iy:float=0.0 ) _vp->position.x=tx _vp->position.y=ty _vp->texCoord0.x=s0 _vp->texCoord0.y=t0 _vp->texCoord1.x=ix _vp->texCoord1.y=iy _vp->color=c _vp+=1 End   Method NewDrawOp( shader:Shader,material:UniformBlock,blendMode:BlendMode,primOrder:int,primCount:Int ) If _drawVB.Length+primCount*primOrder>_drawVB.Capacity Flush() Endif   If blendMode=BlendMode.None blendMode=_blendMode   If shader<>_drawOp.shader Or material<>_drawOp.material Or blendMode<>_drawOp.blendMode Or primOrder<>_drawOp.primOrder   'pad quads so primOffset always on a 4 vert boundary If primOrder=4 And _drawVB.Length & 3 _drawVB.AddVertices( 4-(_drawVB.Length&3) ) Endif   _drawOp=New DrawOp _drawOp.shader=shader _drawOp.material=material _drawOp.blendMode=blendMode _drawOp.primOrder=primOrder _drawOp.primCount=primCount _drawOp.primOffset=_drawVB.Length _drawOps.Push( _drawOp ) Else _drawOp.primCount+=primCount Endif   _vp=Cast( _drawVB.AddVertices( primOrder*primCount ) ) End

Why would these methods create such an opaque error?

Also, am I allow to alter the mojo code this way?  I don’t want to break license agreements…

[AngusParticipant]

Ok, more hunting and it seems these changes aren’t what’s causing my problem. I’ve no idea what is, but I’ll keep looking.

What would that error interrupting a check or compile usually mean?

Parsing…
Semanting…
Caught signal:Memory access violation

[abakoboParticipant]

Did you rebuild mojo after your change? When you modify a module you have to rebuild it or the change won’t be taken into account. Maybe you’ve messed up your monkey2 sources and should startup with a fresh install?

One antother important thing to know is that private behaves a bit different than in C++/java more like in D. i.e. things within the same .monkey2 file are allowed to share private things anywhere across the file. So there’s not only private things within classes/structs but you can have a private function to the file (function that is not the member of any class so it looks global but technicaly it’s not. Or you can have a class that is private to the file!).

About the error message, it looks like it’s a crash of mx2cc, the monkey2 compiler itself (not your executable)! Of course a compiler should not crash but return an error with the code line. You really don’t see that often so it is very interresting developpement wise. Very hard to debug if you are not writter of the compiler though. It be nice if you could post a little example code that generates it, ideally on github issues.
“Memory acces violation” is not a compile error but a runtime error. Here it happens during the semanting part of the build process while mx2cc is running.

A normal build process will:
Parsing… (monkey2 job)
Semanting… (monkey2 job)
Translating… (monkey2 job)
Compiling… (C++ compiler job) Here you can have c++ error that looks more verbose than mx2 errors. But it should not happen ideally. It usually happesn when you play around with extenal stuffs.
Linking ~your_executable path~ (Linker job) I wish you to never have an error here while playing with externals because linking is a real PITA. One of the super strong sides of MX2 is it’s doing it for you.
Application built:~your_executable path~ everything worked ok, so now if there’s a runtime error you probably messed up somewhere but the different build stages could not help you detecting it. You have to build in debug mode if you want to be able to track the problem.

About the license, you’re free to modify stuffs, you may make a fork of the original code via github. If you like the language there is a patreon page or a donate link.

[abakoboParticipant]

Using latest dev branch, I could comment all “private” tokens in canvas.monkey2. Then rebuild mojo. Then access the private canvas fields with no compilation crash.. You could set the members you want to acces to “protected” so you can extend.. or just play with your own modified Canvas class. If I where you I would build mx2 from latest dev brach as it is version 1.08 wich is a bit more stable than the latest ich release.

[Mark SiblyKeymaster]

Ok, not sure what’s happening (mx2cc shouldn’t crash!)  but the above code will not work with the upcoming version of monkey2 v1.1.08 anyway as I have modified how vertexbuffers are written. Which is exaclty why all this stuff was/is private…

But NewDrawOp appears to be the same as the existing AddDrawOp anyway. What exactly are you trying to do?

[AngusParticipant]

Yes, NewDrawOp is exactly the same but public. I want to be able to start new operations and pass individual vertexes using my own graphics objects outside of the Canvas class.

I now realise that my code is generating the compiling error seperate to the Canvas class issue though and I suspect they’re not related. I’m sure I can find a way to do what I want once I’ve found the source of this problem

I’ve been translating a lot of code at once, so I’m in the process of isolating what’s causing the compiler error. I’ll post some code that replicates it when I’m more sure.

[Mark SiblyKeymaster]

Have you looked at DrawPolys? I have also been considering adding a version that takes Vertex2fs for max flexibility+speed. Plus, the API would be much cleaner!

You are free to mess with whaever you want to of course, but just be aware that AddDrawOp (or indeed anything private) could be changed or even removed in future from the BRL version of Canvas.

[AngusParticipant]

Looking through pages of hastily translated monkey code, I found the line that was causing the compiler crash and it’s embarrassingly stupid. This’ll do it:

Monkey

[crayon-5cba83c6b612a844899238 inline="true" ]Function Main:void() Local i:Int[]=New Int[](0,1,2,3,4,5) Local s:Int[]=i.Slice<Int>[1,2] End

1 2 3 4 5 6

[crayon-5cba83c6b612a844899238 inline="true" ]Function Main:void() Local i:Int[]=New Int[](0,1,2,3,4,5) Local s:Int[]=i.Slice<Int>[1,2] End

[/crayon]

Serves me right for just piling into converting heaps of code without much testing. This is a combination of not understanding Slice (<> not reqd in this situation) and mistakenly using square brackets by daftness.
Not sure any action required to “solve” this problem with the compiler. Is it fair to cater to every weird thing a user might type?

For DrawPolys, it’s close to what I need, but all of the private AddVertex methods transform the vertices by the matrix, I think I’m right in saying.
I’m stubbornly using my own matrix tree and display transformation code I’m super glad to have mojo construct that nifty display list, not to mention manage textures and shaders, but I like the feeling of positioning my own vertices. My feelings about it might change!

I understand that I play with those parts at my own risk. Is very interesting stuff.

For now I’ve plenty more embarrassing errors to find…

edit… I obviously don’t understand the code tags, sorry will figure it out.

[Mark SiblyKeymaster]

Nice bug, will fix it!

For DrawPolys, it’s close to what I need, but all of the private AddVertex methods transform the vertices by the matrix, I think I’m right in saying.

The idea is it would still transform positions, colors etc if it had to (ie: if matrix was non-null and/or color was non-white). This is pretty much the same as the existing DrawPolys methods, only with more convenient Vertex2f style parameters.

I’m stubbornly using my own matrix tree and display transformation code

No problem, glad you find the rest of it useful, go nuts!

[AngusParticipant]

Am delighted to say that I’ve got it working as the Canvas module stands, I’ll take my chances that I can cope with any changes that occur under it’s hood.

More pleased than ever that mojo is doing most of the heavy lifting.  Understanding what to do meant reading through a lot of the code.  Intimidating stuff!

Also delighted to see the monkey GUI I was working on brought back to life!  When I realised moving to mx2 was inevitable I wondered if I’d use mojox, but like my transform and display code I think I’ll stubbornly carry with what I have.  I know I can make it much nicer to use with mx2’s features.

Anyway I’m just wittering cos I’m chuffed to see a file requester and a pointless red square.  Better things to come

Edit:  Meant to comment on how satisfying it is to think of all those neatly stitched together triangles… simple things, eh?

Attachments:

1. 

   screenshot.png
   

[abakoboParticipant]

Looks cool! Hope you’ll share.

[AngusParticipant]

Well, it does a lot less than mojox.  I looked through the mojox code as well and let’s just say it’s significantly more mature than my code   Some things about structure of mx2 will allow me to make my own source much nicer.

I’m going some distance to make those changes just now.  If I manage to make the code not too embarrassing I’ll be happy to share it, it’s nothing special.  I don’t want to get too distracted perfecting a GUI though, I want to move on to project for which I started the GUI initially…

I’ve started using splines and other functions to define the shapes of some of my graphics objects, and those things are a pain to set up.  Not to mention configuring physics objects!  The GUI is to run an editor for these things, my hope is that the products of the editor will be more presentable than the editor itself

[Author]

Posts