Double trouble?

Paul59

Active Member
CX Code Contributor
Joined
Dec 13, 2018
Location
UK
@MikeHart In view of the hassle of fixing bugs and difficulty in further developing CX is there any point/advantage/requirement in continuing to offer both mojo and mojo2?

I have to say I know nothing about mojo; I've never used it (other than running the examples) and I don't seem to be lacking anything by using only mojo2. I realize people might have modules etc that rely on mojo and this backward compatibility might be the reason for keeping it. I've also seen arguments claiming mojo is faster than mojo2 and maybe mojo2's features aren't supported on all platforms? I don't know how things work under the hood but help says mojo provides basic App functionality so I'm guessing some merging of code would be required which could possibly be too much work in itself.

Just a thought...
 

MikeHart

Administrator
Staff member
Joined
Jun 19, 2017
Location
Germany
Yeah, that came to my mind too. Any reduction of the toolset will help speed up the development.
But I need to find out, WHY mojo2 is so much slower than mojo1.
 

Phil7

Active Member
3rd Party Tool Dev
Joined
Jun 26, 2017
I am still using mojo1, because it was the only way to run my apps(32bit) on really old windows machines that had not been updated for a long time.
I am not completely against ditching mojo1, but it is a lot of work to migrate because I am using ignitionX (mojo1 only) framework a lot and we should double check, if there are any issues on some devices / platforms. I have the feeling mojo1 beeing not as capable as mojo2 is still more mature and has been tested by a larger audience.
 

MikeHart

Administrator
Staff member
Joined
Jun 19, 2017
Location
Germany
Personally I find the API of mojo1 easier to grasp. Well it is not much of a difference but somehow feels easier.
I think we could add lights and shaders to it too, just I didn't find time to look into it.
 

Paul59

Active Member
CX Code Contributor
Joined
Dec 13, 2018
Location
UK
@Pierrou @Phil7 Well if mojo is more robust, works with older computers and 'legacy' frameworks without any issues, those people who use it can carry on with CX as it is today but future versions could just include mojo 2 (although I'm not sure exactly what 'future versions' of CX would have that it doesn't at the minute!)

@MikeHart I'm not sure that 'bouncy aliens' as it stands for mojo2 is written in the best/fastest way. I rewrote the original example but didn't consider whether it could be better/faster. I might have a look at it in the next day or two.
 

MikeHart

Administrator
Staff member
Joined
Jun 19, 2017
Location
Germany
I'm not sure that 'bouncy aliens' as it stands for mojo2 is written in the best/fastest way. I rewrote the original example but didn't consider whether it could be better/faster. I might have a look at it in the next day or two.
Create 30.000 sprites and you will see the difference right away. 50.000 in glfw.
 

Paul59

Active Member
CX Code Contributor
Joined
Dec 13, 2018
Location
UK
Create 30.000 sprites and you will see the difference right away. 50.000 in glfw.
Which versions of bouncy aliens are you comparing? The examples shipped with the current version of CX are quite different and can't be compared fairly.
 

PixelPaladin

Active Member
CX Code Contributor
3rd Party Module Dev
Joined
Aug 27, 2017
Location
Germany
@MikeHart: Well mojo1 might be faster when rendering a lot of sprites but mojo2 is way more powerful: with canvas objects you can render into textures and you can also use gl fragment shaders – with these two features alone you have unlimited possibilities compared to mojo1. And when it comes to performance: just try rendering a lot of bouncyaliens using random colors for each sprite on the html5 target – I bet mojo2 performs a lot better in this case ;)
 

SLotman

Member
Joined
Jul 3, 2017
Mojo1 is more compatible, plain and simple - specially on mobile. Some Android devices just plain hate shaders :p

I do miss "render to texture" under mojo1 - but that's it.
 
Top Bottom