When to convert MX1 code?

Community Forums/Monkey2 Talk/When to convert MX1 code?

Richard Betson(Posted 2016) [#1]
I was taking a stab at converting MX1 code and I can see that somethings are missing or have changed. For example with mojo (converting form MX1 mojo2) the method TransformCoords() is not in the canvas class so is it gone or not there yet or maybe superseded by another method? Looking over the docs and the module code it seems things are either different or incomplete and I'm left scratching my head a bit wondering.

So, I am wondering when will be a good time to start converting MX1 code? Should I wait for the release? As it is now I would have a lot of questions on converting MX1 code and I would like to pose them when the time is right.

Totally ready though to get into converting code and cant wait. :)


dawlane(Posted 2016) [#2]
I wouldn't port over any major projects yet. Things will be fluid for a while. And somethings may not be as obvious. What may have been valid in MX1 may not be in MX2. As with containers. http://www.monkey-x.com/Community/posts.php?topic=10588


Richard Betson(Posted 2016) [#3]
What may have been valid in MX1 may not be in MX2.

This is true and I can see certain issues making themselves present over time.

I am in the position of do I stall my framework development or just keep coding in MX1. I may have missed it but a time line laying out say when mojo will be complete and a true version 1 of MX2 will be ready would be helpful. If we are talking another, oh, six months I might try to complete my current project which would allow support for MX1 which I think is cool, but the more I add the more I have to convert down the road to MX2 and that will be a chore. There are also many questions I have about mojo (MX2) vs. mojo2 and how much of it will change code wise. For example will the way lighting and shadows are supported change? Will some of the functions and methods we use now with mojo2 be deprecated? It would be helpful to me to know if hammering out a bunch more code in MX1 is ultimately a good or bad thing as far as MX1-to-MX2 conversion goes.

Edit: I am aware that some functions have already changed such as KeyHiy() and MouseX() so I think there is much to consider here and perhaps consolidating the changes to a list (updated and maintained) would be helpful, something similar to the conversion guide that exists now.


dawlane(Posted 2016) [#4]
I am in the position of do I stall my framework development or just keep coding in MX1.
Well if your ultimate goal was to use the new language, then make a start. Any problems or bugs that turn up would help Mark get things more stabilised. But if you want to get things done quickly, then keep to what you know that works. If I remember I didn't see a stable version of Monkey(X) suitable for production lower than v29. You didn't see anything for Linux until 76c (I think it was) and bit of hacking was required for versions lower than that to get it to work on Linux.

Edit: The KeyHit etc are one example of what I mean by fluid. And try the spacechimps example in bananas. On my Linux system it fails to load the wave file. As far as I can tell it's finding and loading the asset into memory (haven't checked if this is being correctly copied), but having problems with Mix_LoadWAV.


Richard Betson(Posted 2016) [#5]
Well if your ultimate goal was to use the new language, then make a start. Any problems or bugs that turn up would help Mark get things more stabilised.

I'm all for this and a major conversion is a great way to find bugs and issues. But, as you suggested earlier ( "I wouldn't port over any major projects yet") I'm going to have to wait I guess until for example mojo and other modules are in a more complete state. I am still left though with lingering questions on what will be deprecated and what will not when it comes to commands, functions or methods used in current MX1 modules. This from a conversion standpoint is of utmost importance. In other words how much of the MX1 current command base is going to make it into MX2 and when will it all be there? Using my initial example of TransformCoords() is a good place to start. Is it gone or will it be added later. This is the kind of thing I am looking to get answers to as if it's gone I need to code a solution. It's is a question of state and architecture.

But if you want to get things done quickly, then keep to what you know.

For me it's more about supporting Marks new effort and making use of the new design and the support for third party resources MX2 is providing. For example my game project hinges on good UDP network support, something that includes serialization and other common network supported features. MX1 as far as I know just does not have this available (maybe I'm wrong and that would be welcome news). MX2 will (is) bring to the table certain options just not currently available in MX1 and for a large scale, network based, multiplayer game MX2 is the solution I need. Additionally fleshing out a gaming framework (as I am attempting) is a task not lightly taken and to have the best shot at a conversion from MX1 to MX2 I need to understand the conventions involved. This for example was why I was able to develop a good bulk of the code I am currently using in MX1 with BlitzMax. I understood MX1's command architecture and structure which allowed me to code a port friendly version in BlitzMax. If I continue developing in MX1 I want to use this same technique, coding a port friendly version. I'm again left with the same questions on command, functions and methods. What is in and what is out and what will be changed to something else.


dawlane(Posted 2016) [#6]
then keep to what you know
That should have been "then keep to what you know that works."
Using a iPad 2 with predictive text is a pain.


marksibly(Posted 2016) [#7]
Without knowing anything about your project it's impossible to say anything about if/when it'll be convertable to mx2.

TformCoords has gone - there are now vector/matrix math ops you can use, but you may not even need it as Mouse.Location now returns coords in 'view' (effectively canvas) coords.

There is currently no projection matrix in Canvas - projection matrix is implicitly 1:1 pixels. There will eventually be some kind of '3d matrix' in canvas for 3d-ish ops and/or projection tricks. You can setup a virtual resolution easily enough though - see viewlayout demo.

Again, without knowing more about your project it's just impossible to give you any sensible advice beyond 'take a look at the bananas'!


Richard Betson(Posted 2016) [#8]
Without knowing anything about your project it's impossible to say anything about if/when it'll be convertable to mx2.

I totally get that and my intent here is to invoke feedback to get a sense of what I am up against in converting code. From my point of view there is much I do not know about the changes that have occurred and there is of yet, no real consolidated list of these changes (that I'm aware of). I guess I'll just start asking about issues I encounter and wait for the documentation and other information to catch up which is not a problem. I'm just interested in getting a better understanding of what you've been up to (beyond the obvious) and how I need to adapt.

TformCoords has gone

So, right on then. I'll see how this effects my code. and thanks for explaining that.


marksibly(Posted 2016) [#9]
Well, you can look at the Canvas docs in a browser and point out what methods are missing that you need for a start.

I'm *guessing* you might be missing SetProjection2d, as this is the only thing TFormCoords really helps with? If so, what are you using it for etc.

I left this out for now because it just seemed to confuse people, ie: most people just ended up setting projection matrix to viewport size and don't I think anyone found it particularly useful. It may yet return if there's demand, but for now the "letterbox" layout system whould be fine for 99% of users as they don't have to worry about projection matrix or TformCoords at all.

You can also 'back project' coords into 'canvas local' space using something like:

Local coords:=-canvas.Matrix * New Vec2f( Mouse.X,Mouse.Y )

So if you've done a bunch of Translate/Scales etc, this will convert 'view' coords back to 'draw' coords.


Richard Betson(Posted 2016) [#10]
^OK, um, here is what I am doing with a few of the missing (deprecated) commands (methods I guess but I will call them commands here) that I currently use in MX1.

I am indeed using SetProjection2d() along with SetScreenSize() and SetViewport(). I was using these to setup a virtual resolution that would just stretch to fit a given display. So using a base resolution of 1280x720 I could adapt to most any display size and yet still have a screen size of 1280x720. I also used it for mobile and screen transformations for example when you turn a mobile device and go from landscape view to portrait view. In this case setting the screen size from 1280x720 to 720x1280. Another use is for desktop applications and realizable window where the device height and width are used to set the view port and the projection matrix. This of course is why I am using TransformCoords() as it is the way to get the transformed mouse coordinates. All of it to me is useful and desirable and here is some code that demonstrates how I use these commands to accomplish the behaviors mentioned.



So I would like to retain the above behavior in my port of my gaming framework (Alien Phoenix). I find it way useful to work with one screen size and be able to change that screen size to support mobile landscape and portrait views as well as the other behaviors mentioned.

Another change in mojo MX2 is that it appears Transform() is gone. I use Transform() to scale a matrix and then draw images and I use it often enough so that changing to another method might be an issue. Using Transform() was the only way I could scale images (Scale() just seemed not to work for me) for the GUI portion of my framework as I recall. So I would be interested in how to achieve the same behavior of Transform() and scaling a matrix in mojo for MX2. Scaling an image in mojo with MX2 is OK but it would have to work more like Transform() does and not like mojo2 (MX1) Scale() does.

I guess also I will mention that I need to set the view port within my GUI portion of my framework and also get the view port dimensions or rect. So I do use SetViewport() and Scissor() currently in mojo2/MX1 in more then a few places.

I hope this makes sense and I will have a look at some of the sample code you have for mojo in MX2. Hopefully I can see how I might be able to solve some of these conversion issues and better understand mojo for MX2. If you need it I can post some code demonstrating how I use Transform(). I'm sure laying out the alternatives here will be useful to others for sure. :)


marksibly(Posted 2016) [#11]
The viewlayout demo shows how to setup a virtual resolution. Basically, you just need to set window layout to "letterbox" and return the size you want to be in OnMeasure(), eg:

Class MyWindow Extends Window

   Method New()
      Layout="letterbox"
   End

   Method OnMeasure:Vec2i() Override
      Return New Vec2i( 1920,1080 )
   End

   Method OnRender( canvas:Canvas ) Override
      canvas.DrawText( "MouseX="+Mouse.X+", MouseY="+Mouse.Y,1920/2,1080/2,.5,.5 )
   End

End 


OnRender() will render to a 1920x1080 canvas and Mouse.X and Mouse.Y will return coords in the correct range.

> Another change in mojo MX2 is that it appears Transform() is gone.

You can just modify the canvas 'Matrix' property directly, eg:

Local myMatrix:=New AffineMat3f
myMatrix.i.x=2
myMatrix.j.y=2
canvas.Matrix*=matrix   'transform current matrix by myMatrix.


An 'AffineMat3f' is basically just the old [ix,iy,jx,jy,tx,ty] transform array, but with a bunch of useful methods and operators.

Ditto you can easily modulate the current color with:

canvas.Color*=Color.Grey 'halve the current color!

This is probably the biggest change you'll find in mx2 - things like matrices and colors etc that just got passed around in an 'ad hoc' way in bmx/mojo/mojo2 are now usually stored in structs like Color, Recti, AffineMat3f etc.

> (Scale() just seemed not to work for me)

Could be an 'order of operations' problem. If you are doing a sequence of translations, rotations etc, you frequently (but not always) want to do them in 'TRS' order (I remember that thanks to the TRS-80!) ie: translate-rotate-scale. Mess up the order, and you get weird results, ie: they're not commutative.


Richard Betson(Posted 2016) [#12]
Yo,

Cool, so I will have a go at trying to work up a MX2 demo illustrating the above and see how I do. :) Thanks! BTW the TRS-80 was the 'first' computer I encountered and got me started on the path. :D