QBJS Question

[SMcNeill]

Can QBJS handle our OpenGl commands, like we'd use in SUB _GL?

[bplus]

Quick answer while waiting for @dbox is probably not, _MapTriangle can't be used yet either. JS has its own graphics library.

[dbox]

Can QBJS handle our OpenGl commands, like we'd use in SUB _GL?

That support is not there today.  As @bplus stated I do have on the roadmap to add support for _MapTriangle.  I'd love to see some @MasterGy 3D creations that can be played on the web!

As far as support for the _gl commands in future releases... the honest answer is I don't know yet.  WebGL is "OpenGL ES 2" not plain OpenGL. (The ES is for Embedded Systems.) It is essentially a subset of OpenGL.  So I'm not sure if there will be a 1-to-1 correlation for all of the low level _gl calls that QB64 supports.  This would be further out on the roadmap for QBJS unless someone else wants to jump in and contribute.

My focus at the moment is improving the error reporting in the compiler and implementing as many QB45 and QB64 standard keywords as is feasible.

[SMcNeill]

No worries.  I was just hoping to do some pumpkins with rotations and transformation models via blender and opengl. If QBJS doesn't support it yet, I could always save as a GIF (do you support animated GIF files?), or even write the assets as multiple bmp/png files and then PutImage rotate them.

I just had surgery this morning (they finally ganked my gallbladder out for me), and everything when much quicker and smoother than I'd ever would've expected.  I figured I'd be out for a week or more healing, but right now, I can't hardly tell where they did squat.  The holes they left behind were smaller than what I've caused myself shaving in the past!

Since I feel like I'll be recovered fairly quickly overall, and since this is a nice little contest to help explore QBJS capabilities and functionality, I thought I'd take a look at forming at least a roadmap on a banner in the language.  My current thought, watching the various animations, is to try and do a nice calendar style banner.   Some leaves falling to start... transitioning to a pumpkin around Halloween...  morphing into a Turkey after...  and then finally a countdown heading towards winter and Christmas.

I've just not used QBJS enough in the past to work out the easiest path forward yet for such a vision.  I may end up having to pester you guys with all sorts of silly little questions once I start working on it.  

[mnrvovrfc]

As far as support for the _gl commands in future releases... the honest answer is I don't know yet.  WebGL is "OpenGL ES 2" not plain OpenGL. (The ES is for Embedded Systems.) It is essentially a subset of OpenGL.  So I'm not sure if there will be a 1-to-1 correlation for all of the low level _gl calls that QB64 supports.  This would be further out on the roadmap for QBJS unless someone else wants to jump in and contribute.

QB64PE and QBJS definitely need to be on the same page on this. On Linux things are getting leery because more people are crying out for Wayland visual protocol which could affect compatibility with X-dot-org. This would be taken up by no more than a hundred programmers anyway, while the rest of us just want to take some old source code and be able to compile it, run it and enjoy it somehow.

I agree about MasterGy's work, and also commandvom's effort. There are many others showcased here or in Github. The problem is some dishonest companies and people could begin to notice things going into shape, then begin "stealing" work claiming it to be originally their own. This is easier shown in a web browser, rather than their having to pick up source code for an "obscure" compiler.

[dbox]

No worries.  I was just hoping to do some pumpkins with rotations and transformation models via blender and opengl. If QBJS doesn't support it yet, I could always save as a GIF (do you support animated GIF files?), or even write the assets as multiple bmp/png files and then PutImage rotate them.

I would suggest looking at the RotoZoom method:

[bplus]

Oh there is a Rotozoom with G2D, nice to know! Half the reason I needed _MapTriangle.