Are we there yet?

…Not quite, but I think we’re in the final stretch now!

I now have a usable debugger up and running. It’s currently pretty simple but the basics are in, ie: you can run/pause/step/enter/leave mx2 code and see all the variables on the stack as they are updated. And wow, you forget how much easier a debugger can make life when you’re so used to going without!

The bad news is that I wont be ‘releasing’ this just yet. The debugger – all the GUI stuff in fact – is based on mojo2, and mojo2 is IMO not quite ready for release. I did consider releasing a ‘mojo2-old’ style module, but I have decided against that as it would also need to include an ‘old’ version of the app/window stuff and would just confuse things in the long run I think.

I have abandoned plans for a whole new 2d module, and have instead decided to soup up mojo2. The biggest change I am planning to make here is getting rid of the mojo2 ‘Renderer’ class, which is currently used for lighting/shadows (well, you can ‘sort of’ do these directly with canvas but it isn’t pretty). Instead, lights will be ‘added’ directly to drawlists, in the same way ShadowCasters are. The Renderer class was a pretty good idea, but it forced you to use/create a scenegraph design which IMO just didn’t ‘fit’ with the rest of Mojo2’s ‘immediate mode’ approach.

Most of the ‘grunt work’ stuff like images, fonts, drawing etc will remain the same (with several enhancements) so most of your mojo2 code will look the same/similar, unless you’re using Renderer of course. A backward compatibility Renderer class is a possibility here if there is enough demand.

As for the IDE, I have scaled back my ambitions here a bit. I was (and in the long run, still am) planning on building a ‘plugin’ based IDE, that would allow you to write plugins for stuff like map/scene editors, file conversion tools etc, but I think I got a bit ahead of myself here. This is something best done with a reasonably mature set of APIs, and mx2 just isn’t there yet, to put it mildly!

So the ‘new’ Ted2 is simpler than I originally intended, and in fact bears a stricking resemblance to Ted1. This is pretty much complete now, although it lacks ‘options’ dialogs (you will need to edit JSON files) and a few other bits and pieces. Also, although I wanted to do ‘native’ menus, I ended up doing custom ones instead – it was just faster/easier than getting native menus going on Windows/MacOS/Linux and of course will work everywhere.

I also get that not everyone will use Ted2, so I am also planning to do something like ‘mx2db’ that includes the debugger but is used the same way as mx2cc.

My current goal is to get a V1.0 of mx2 together so people can start actually using it. In addition to what’s already up on github, this will include:

* Ted2 (with usable debugger)
* Custom Gui module.
* Sexier Mojo2 module.
* Decent set of docs.
* Usable help system.
* mx2db for people using 3rd party IDEs.

Things that will not, alas, be in V1.0:

* Threads
* Reflection
* Module manager (soon!)
* Android/iOS support (soon!)
* Custom 3D Module

It’s been about a year now since I started mx2 and yes, like seemingly all software projects, it’s taken longer than originally planned. I have probably taken the ‘long way around’ with a few things, but I do think the end result is going to be pretty cool. I have used it a LOT myself over the last 6 months (something I probably didn’t do enough of with monkey1) and, while there is stil lots to do, I am really happy with the general direction it’s taking.

Bye!
Mark

Liked it? Take a second to support Monkey 2 on Patreon!

6 thoughts to “Are we there yet?”

  1. Sounds great thanks for the update.

    What does “Custom GUI” exactly mean?  Is it referring to non-native menus?  Will it eventually be all native GUI ?

    And similarly, what does “Custom 3D” mean?

  2. Sounds like a good starting position!

    Yes, as good as any!

    I’d prefer to cram more into V1.0, but you’ve got to stop somewhere and say ‘this is what it is’….otherwise you just end up tinkering with it forever.

    What does “Custom GUI” exactly mean?

    The custom gui module is a simple gui system implemented entirely in monkey2/mojo2.

    It also provides the rendering framework for mojo2, and handles stuff like ‘virtual resolution’ and user input.

    It does however support ‘native’ file requesters, and I’d eventually like it to support native menus too. With native menus/dialogs, I don’t think people really notice native GUIs anymore.

    Will it eventually be all native GUI ?

    I will not be doing a native GUI module myself, but a 3rd party might!

    And similarly, what does “Custom 3D” mean?

    A simple 3d module implemented in monkey2.

  3. Sounds good!

    Please preserve the mojo 2 vectordrawing commands ( DrawIndexedPrimitives etc. ) when porting mojo 2.

    They are crucial to my personal framework, and it would great to be able to hop aboard the monkey2 train.

    Rendering to bitmap in general is also incredibly useful, so I hope it’s possible to preserve that functionality.

    PS: This site scales to full screen on my phone, making the text very small. When I change windows size on the desktop version, it behaves ok, it’s just that on my phone it should retain a larger text size, and let the page wrap that, rather than showing fullpage.  http://lccbyg.dk/ < Example of better css behavior.

     

     

     

     

     

  4. Have we finalised the language grammar yet?  I’d like to know if I can start porting code/frameworks across without having to rewrite half of it later.

  5. Please preserve the mojo 2 vectordrawing commands ( DrawIndexedPrimitives etc. )

    Definitely!

    Have we finalised the language grammar yet?

    The actual language is now pretty stable (has been for a while really) and any changes made at this point will be very minor, but if you want to be *really* sure you should wait for V1.0

Leave a Reply