Présentation + how to reset opengl context ?

[Bubuche87]

Hello everybody. I read the etiquette, I used the search function, with no luck.
You have a "TL;DR" on the last line of this post.

It's my first message on this forum, so a short presentation of myself seems adequate: I am a computer scientist ( a programmer ), I am french ( so I'll do/I did/ I am doing many grammars and syntaxes errors ), and I am currently developing on a fairly old computer running an Ubuntu 16 and not even having opengl 2.0.
It does have extensions, however, so I have shaders but with limitations etc. Oh, and I don't have an Internet connection at home.
I also have an Android much more recent.
And happy new year everybody.

That being said let's go to the topic at hand. I would played a bit with love and so far so good. But I would like to go one step further: 3D.
I already have some experience with opengl, so I only need to get started.

I plan to use ffi. Actually, I managed to do a glClearColor and a glClear ( never though I cannot guarantee that this one passed ) and change the background of the window. But nothing more. I tried a glBegin/glEnd with triangles of all winding and size I could think of, but got nothing on screen.

The same thing with a GLUT created window gave me the expected triangle.
I tried to reset what I could think of:

Code: Select all

glUseProgram( p );
glBindTexture( texture2d constant and 0 )
glLoadIdentity

Without success.
I tried to delve into the sources ( I managed to compile love 11.4 ) but it's not my way of coding and I admit I am not fond of it ( not a critic: it's just not how I organize my programs, it's a matter of taste ).

Could someone give me a list of the things I should disable/reset to obtain a genuine opengl context ?

You may ask: "why using love, if you want 3d and don't plan to use love.graphics ?"
Answer: because I have it ( no internet connection = it's a hassle to get any program running on Ubuntu ), because it's handle the input and the sound for me ( still that I won't have to write ) and more importantly because it runs on Android.
Plus if I use ffi to import opengl functions, it means I'll be using luajit. Which is fine, but I also need string.unpack which doesn't exist in luajit. But love provides a replacement.
You may ask: " why don't compile for Android directly ?". For the same reason as before: no internet, so good luck to install the ndk, plus good luck to setup everything correctly on a 32bits machine.


Tl;dr: what should I call to reset the opengl context to it's original state ?

[zorg]

Hi, and welcome to the forums;

Löve already has an OpenGL context, and is perfectly capable of 3D rendering (with some effort) although it does have a minimum OpenGL version requirement.

It also already has LuaJIT by default, although you did mention something about compiling löve yourself... from what i understand you want to somehow use the FFI to have your own graphics backend with löve due to löve already being cross-platform and having other things like audio and such implemented.

Honestly, i'm not sure if i can help with this one.

I suggest you check out one or more of the 3D libraries others have wrote already to see how they do it:
https://github.com/groverburger/g3d
https://github.com/rozenmad/Menori

[yal2du]

I tried to delve into the sources ( I managed to compile love 11.4 ) ... Could someone give me a list of the things I should disable/reset to obtain a genuine opengl context ?

If you can compile love, should be able to add a function to export whatever context related variables you need, then call that function with ffi. (see window.ccp line 312). Or, since Love uses SDL, maybe call the following exports via ffi to get the window and context:

SDL_GL_GetCurrentWindow 0x0001c5a0 99 (0x63) SDL2.dll Exported Function
SDL_GL_GetCurrentContext 0x0001c590 98 (0x62) SDL2.dll Exported Function

Guessing that any such reading or manipulation of graphics state via ffi probably needs to be done from within love.draw()

Also, see https://wiki.libsdl.org/SDL_GL_GetProcAddress

"If the GL library is loaded at runtime with SDL_GL_LoadLibrary(), then all GL functions must be retrieved this way. Usually this is used to retrieve function pointers to OpenGL extensions.

There are some quirks to looking up OpenGL functions that require some extra care from the application. If you code carefully, you can handle these quirks without any platform-specific code..."

[yal2du]

I am currently developing on a fairly old computer running an Ubuntu 16 and not even having opengl 2.0.
It does have extensions, however, so I have shaders but with limitations etc. Oh, and I don't have an Internet connection at home.
I also have an Android much more recent.

Wait a second, I just reread your post and noticed that you are attempting to develop on a machine "not even having opengl 2.0".

https://www.khronos.org/opengl/wiki/His ... tion_Model

Many of the (immediate mode) calls you might be trying to invoke were deprecated in 2008 and removed from opengl in version 3.1 (2009). You might have an older opengl implementation on your system but i doubt love is using it at all. in other words, pretty sure sdl and hence love use opengl version > 3.0. You might be able to check with ffi by defining SDL_GL_GetProcAddress and invoking the equivalent of:

Code: Select all

--[[
   const GLenum GL_VENDOR_ENUM=0x1F00;
   const GLenum GL_RENDERER_ENUM=0x1F01;
   const GLenum GL_VERSION_ENUM=0x1F02;
   ]]
   
ffi.cdef[[
   typedef unsigned char GLubyte;
   typedef unsigned int GLenum;
   typedef const GLubyte* (*glGetStringPtr)(GLenum name);
   glGetStringPtr SDL_GL_GetProcAddress(const char *proc);
   ]]
   
local sdl2           = ffi.load("SDL2")
local glGetStringPtr = sdl2.SDL_GL_GetProcAddress("glGetString")
print(glGetStringPtr)
local glversion      = glGetStringPtr(0x1F02)
print('glversion ',glversion)
local version = ''
local vc      = 0
while glversion[vc] ~= 0 do
   version = version..string.char(glversion[vc])
   vc = vc+1
end
print(version,vc)

(lifted/adapted from Window.cpp @ line 154)

After doing so on a windows 10 box i get back the following string:

3.3.14761 Core Profile Context 21.10.3 30.0.13031.1001

[Bubuche87]

Ok I'll try the functions you mentioned when I'll be back home.
Yes, you read correctly, the GPU does not support OpenGL 2.0
By luck, I still have the possibility to define shaders ( not in LÖVE, which is perfectly understandable, it says my system does not support shaders ) but, for example, I don't have the possibility to define GL_RED as the pixel format when I create a texture, even though I should be able to, according to the documentation, if my system were supporting OpenGL 2.9.
https://docs.gl/gl2/glTexImage2D

But in any case, I did a glxinfo and I am quite sure (but we can all make mistakes) that it didn't support OpenGL 2.0.
It REALLY is an old computer. But it means that if I manage to have something working on this one, it should work everywhere. Which is good.

( Also, I don't have floats for the channels in my shaders. Everything is clamped to [0, 1] and is on one byte. I don't have texelFetch functions, nor any function to query the size of a texture. It's like an adventure everytime I need to implement something but I somehow find that hilarious XD.)

Thanks for the functions, I'll try that.


Annnnnd ... Well, this post is already too long, so let's make it longer.
I have to do tests, but if I understand things correctly, ffi can pull C functions out of binaries. Somehow, it means that a fairly short Lua script would allow the loading and the execution of any C program, as long as it is compiled with the right asm.
I mean, _even compiled without the NDK_.
In a nutshell it would mean that love can become a whole new way of developing on Android, with a much lighter ( like: nothing but a plain old gcc ) development kit.
With nothing magical in it: the guys that have been developing "love for Android" had had to pass through all of those steps to have their program running on Android. But now, maybe we can reuse their work ( it will be used as a nominee by the C program ).
It's more or less already what is going on when we launch a game in a .love file on android: "love for Android" act like a nominee for the actual game, so the game developer does not have to go through all the steps required to launch a program on android.
What I would like to do is extend that to C programs or arbitrary Lua programs ( even full 3D games that would only use a tiny bit of what love can offer ).
All of that relies on how ffi will be able to load stuff on android. I need to do test and I already have plenty of things to do.

Congratulations if you managed to read all of that