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.

Messages - theprotocol

Pages: [1] 2
GLBasic - en / Re: Quick request
« on: 2012-Jul-25 »
German and I live in Dubai.

My preference would be English.

Well, inheritance is OOP at its core and thus not supported. I guess you have tried it, but since you can include type variables inside another type you can do:

Code: (glbasic) [Select]
TYPE Monster

TYPE Hydra
    BaseStats AS Monster

TYPE Medusa
    BaseStats AS Monster

Then access the basic data of a monster with something like Medusa.BaseStats.HitPoints and so on.

Well said. I've been using this method and it's quite nice.

The only limitation is polymorphism. Having an array of mixed subtypes remains impossible. However, it's not such a huge deal if you just organize your objects properly.

GLBasic - en / Re: Time step
« on: 2012-Jun-17 »
I've experimented with this a lot last year. It's an extremely interesting consideration.

What I've found is that interpolation can make games feel smooth as butter, but you have to find the "sweet spot." When you interpolate the graphics, your collisions will become inaccurate to a certain extent (as your rendering method will often predict positions that end up slightly wrong compared to what really happens). You need to balance the logic execution rate against the rendering framerate, and decide how much inaccuracy you can tolerate. The question is - how loose can your rendering output be compared to game logic?

Another thing I've found is that on mobile platforms, doing floating point calculations in every frame, as required for interpolation, is quite expensive. I even played around with math libraries like Eigen and GLM that would use the iPhone's vector unit (ARM NEON), but the performance wasn't up to scratch (Eigen was slower than straight floating point computations in my iOS project). The upside is that interpolation adds smoothness to the motion, and you might want to take the framerate hit (if any - depends on how complex your scene is).

There's definitely potential to pull it off on mobile platforms though, so long as you don't have thousands of things to interpolate each frame.

GLBasic - en / Re: Something wired
« on: 2012-Jun-16 »
No, wrong guess, if i do not specify a type its always a float. But even if i declare it as float or integer directly i get the same result (you can try it yourself if you want).

I see. Interesting...

GLBasic - en / Re: Something wired
« on: 2012-Jun-15 »
My guess:

You're not strictly specifying the type of "value." Assigning it to a string later tells the compiler that "value" is a string instead of an integer. This would occur before runtime (it happens at compilation). So it's as if you wrote value$ vs. value%. The compiler is just guessing ahead of time what the variable is (your later code with s$=value changes its guess).

The performance could vary in that case between - assigning 1 to a string (probably internal parsing or casting here)- and assigning 1 to an integer (native).

Don't get me wrong, the API of GLBasic is awesome, but the only reason why it runs on the browser is my hard work and perfection :D

Of course! I'm just commenting that the GLBasic API is so nicely structured - not to discount the work that you've done.  =D

wrong. ES 2.0 is totally different. There's no fixed function pipeline anymore. You have to program everything using shaders. (no glRotate, no glMultMatrix, no glEnable(GL_TEXTURE2D) )
It might be worth to do this at one point, but currently I'm having a lot more urgent things to push forward.

The bolded part is exactly consistent with what I said. My point is GLBasic already has the shader codepath, and that part 99% the same in ES as it is in regular OpenGL (some changes within the shaders themselves though). I acknowledged many times already that you do indeed remove the entire fixed function pipeline. But the idea is there isn't really much "porting" to be done, pretty much copypaste the existing shader codepath and don't include fixed function stuff.

However, I'm not pressuring you or anything! I understand that you have priorities. But I'm saying there could be potential for a community driven effort to do this (I'm looking into it!) somehow.

the protocol again: OpenGL|ES <> OpenGL
This are to different libraries and you can not run OpenGl on mobile devices.

I know the difference between OpenGL and OpenGL ES. However, their implementations are VERY similar. The vast majority of commands are interchangeable. I sincerely doubt GLBasic on desktops using the programmable pipeline (2.0+) uses any code that doesn't exist in ES 2.0.

Most of the groundwork is done in the non-mobile codepath. To "port" it to OpenGL ES should be almost trivial. Almost the same commands and API (a few restrictions on shader variables come to mind).

In fact, the X_SETSHADER command can be run on mobiles - it just returns an error. If this error isn't some hardcoded thing that GLBasic has ("block all 2.0 commands if mobile") then it's coming from OpenGL ES, which is saying "Sorry, you're using 1.1, this command fails."

So, the first step is to switch to a 2.0 context in OpenGL ES. This is 1 line of code that needs to be changed. The rest shouldn't be too hard (fixed function commands wouldn't work anymore, but who cares - you want to program your pipeline anyway or else stick to 1.1).

edit: Summary version in case you still don't understand my point: OpenGL and OpenGL ES are extremely similar. Maybe 90% similar. If we simply establish a 2.0 GL Context then if we're lucky, GLBasic's OpenGL code should be THE SAME as required for OpenGL ES 2.0. If not, then we need some very minor tweaks (and obviously disable all fixed function commands and use the programmable pipeline commands only).


Hahahaha, once again GLBasic surprises me. Best. Language. Ever.

I'm not sure you can put your levels in it though, since the packs are more for media assets. Either way, it's best to encode your level files into binary, rather than plain ini files.

Check out GLBasic's SETSHOEBOX command. There's a Shoebox utility bundled with GLBasic under the "Tools" menu as well.

This lets you put your data in a compressed "pack." GLBasic can read from it directly. This will work for any graphical and audio assets and interfaces with GLBasic's commands, like LoadBMP and Playmusic etc. I'm not sure how secure this is. I bet a determined user could figure out how to unpack the file.

Announcements / Re: HDD crash.
« on: 2012-Jun-14 »
Oh no. I'm not much of a forum-goer so I missed this. This sucks. :(

GLBasic uses OpenGL|ES 1.1 since some devices don't support 2.0.
So, there's no shader support for mobile devices.

Isn't it just a matter of creating a 2.0 GL context instead of 1.1 in the initialization? GLBasic already has this implemented for non-mobile platforms. Isn't it a trivial change to just optionally include this code path for mobile platforms? Like, some kind of initialization command to tell GLBasic to generate a 2.0 context when building mobile code.

Very impressive. Well done!

I must say though, a huge credit should go to Gernot for designing the GLBasic API in such a straightforward way. It's abstracted just the right amount, such that it's similar to native OpenGL conceptually, but much easier.

"Thinking out loud" post - will contain a lot of errors!

I've been looking into some makeshift way of overriding GLBasic's EAGLContext initialization when it generates mobile device code.

Thinking out loud, these are my initial assumptions:

- The existence of X_SETSHADER means that GLBasic is using the OpenGL 2.0 spec when available. Therefore, 2.0 functions are implemented somewhere in GLBasic. I'm assuming they are mostly interchangeable with OpenGL ES 2.0 calls.

- When GLBasic builds a mobile app (Android or iOS), the generated code creates a v1.1 GL Context. I'm looking for a way to switch this into a 2.0 context (Looking at this currently for iOS).

- Possible roadblock: even if we somehow manage to override the GLContext code that GLBasic generates with inline C/C++, does GLBasic arbitrarily block shader-related code from being built into mobile projects? It looks like the answer is probably no since shader functions return a "fail." I'm hoping this "false" response isn't hard coded by GLBasic, but rather comes from the OpenGL implementation (which returns false if you attempt shaders in a 1.1 context). If GLBasic is simply blocking 2.0 functions on mobile devices in a pre-determined way, then this is hopeless.

English version: Is the error "FAILED TO LOAD SHADER" coming from GLBasic, or OpenGL? I hope GLBasic leaves it to the OpenGL implementation (not hard coded in GLBasic generated mobile code).

Does anyone see any potential here?

edit: My approach here is iOS-centric. Android might be easier! It seems the Android API provides functions for switching the context version. For example:

Code: (glbasic) [Select]

Would be good if someone more knowledgeable on Android could chime in.

Aw, that's a bit disappointing. I assumed shader support for mobile platforms was in. Kinda puts a wrench in some of my ideas. ;(

Pages: [1] 2