Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - kanonet

GLBasic - en / Re: GL ES
If you switch to GLES2, you would need to rewrite all graphic commands, this would include 3D and 2D. Additionally this would break compatibility with old platforms that do not support GLES2.
Or alternatively we could try to use something like Regal, that translates GLES1 calls 2 GLES2 calls. So not much porting would need to be done and than we could add new features, like shader support.

This is no new issue and has been debated before many times, but nothing happend (and probably never will).
GLBasic - en / Re: GL ES
Im late on the Party, but: on mobiles you have to choose whether you want to use GLES1, 2 or 3 on create of your "window", then you are tied to that version. GLBasic creates its surfaces with GLES1, simply because all drawing commands are written on old, depreciated GL. That means you cant use shaders at all.
You would need to close GLBasic's, window and create a new one, with GLES2 enabled. Even if it works, it will have huge side effects, like GLBasic drawing commands wont work at all, some others probably too... So no easy task, as long as the GLBasic core does not get rewritten (which would be a huge pile of work).
That's what I was talking about. How does it work on Pandora?
Yes, "_" does work in GLBasic too.
Do you mean the BUSY function? I dont know and my compiler says, he doesnt neither.
Spacefractal GLBasic update to GLES2 will not happen, because this is not backward compatible to GLES1.1, so the complete Engine would need to be rewritten in shaders. GLBasic uses old fixed function stuff on all platforms, rewriting it would probably the biggest project in history of GLBasic. I dont think Gernot has time for this and probably also not enough experience with modern OpenGL.
But maybe he could create a GLES2 context and then use his old graphic engine with the help of Regal or one if its forks.

Nabz when disabling lights, you could try the OpenGL wrapper and directly call glEnable/glDisable(GL_LIGHTING), this should be faster, than enabling/disabling each individual lights manually. In the end you need to simply test it, to tell if any approach works for you.
GLBasic is stuck on GLES 1.1 on mobiles, so no shaders for you.
Actually enabling and disabling light for every 2nd object can cost you quite some performance. I would instead sort all non light object draw them, draw lights and then draw all light objects.
IIRC strange behaviour could be fixed by simply inverting cullmode. At least this was a bug years ago, when I tested android for the last time. Dunno if it ever got fixed, so simply try it.
Actually its aso possible to MEM2SPRITE an array (not sure if only 1dim or also 4dim) and save it as image. At least if we are talking about integer arrays. If you save it as PNG, you get loseless compression.
GLBasic - en / Re: GLB vs C
Generally GLBasic allowes the usage of net sockets, so you can use this to allow commuication with other apps, no matter how they were written (as long as they use web sockets too).
GLBasic - en / Re: GLB vs C
I cant imagine a scripting language like python to be faster than natively compiled languages like C/C++. I think they just use it, because its easier for them and still fast enough. Generally I would advice you to simply write your code and benchmark it, thats the best way, if you want to know the performance.
Und wenn du Bumpmapping weg läßt, funktioniert einfaches 3D texturing? Und immer auf die Pfade achten, aber das hast du ja bei 2D schon...
In GLBasic program, did you use URLDECODE$ after DECRYPT$?
(Official) multithread support:
But use Graphic/sound/etc commands in main thread only, your secondary threads are for expensive logic only.