SDL and selecting a GL profile

[sicilicaParticipant]

So, using the sdl2 and gles20 modules, I open a window and create a GL context to attach to it. Querying glGetString(GL_VERSION) gives me this:

OpenGL ES 2.0 (ANGLE 2.1.0.4b4cdff894f4)

1	OpenGL ES 2.0 (ANGLE 2.1.0.4b4cdff894f4)

In M1, on the GLFW3 target, I get this:

4.5.0 NVIDIA 364.72

1	4.5.0 NVIDIA 364.72

And I actually get a lot of compile errors for Angle.

 

So, clearly I’m getting a compatibility profile, but either I’m less familiar with the SDL2 API than I thought I was or I can’t manage to tell it to use the core profile.

It’s very likely that this is because it’s using Angle (I haven’t tried on my Linux build yet), but with mx2cc, your only target options are “desktop” and “emscripten”, so it’s not like I have the option to actually use OpenGL (I kinda disagree with this, anyway; I’m not convinced that whatever performance boosts could be gained by running in a DirectX emulated environment is worth the stability loss of not actually running the OpenGL on hardware).

 

Anyone know what I can do? If possible, I really want to break out of the compatibility profile because all of my shaders use #version 330 features, and I’m not interested in targeting mobile.

EDIT: At this point I’m 90% certain I just need to be able to not compile with Angle. What would it take to do that?

[Mark SiblyKeymaster]

You probably need to use this *before* opening the window.

https://wiki.libsdl.org/SDL_GL_SetAttribute

Also, you may have to change this line in SDL2 include/SDL_config_windows.h

#define SDL_VIDEO_OPENGL     0

…change to ‘1’ then update sdl2 module. Might need some other tweaks too. There are also some additional SDL functions for selecting the preferred video driver you might need to look into.

> I kinda disagree with this, anyway; I’m not convinced that whatever performance boosts could be gained by running in a DirectX emulated environment is worth the stability loss of not actually running the OpenGL on hardware

The main issue here is compatibility – the sad fact is that a random PC has a much better chance of running HW accelerated D3D9/D3D11 decently (without a graphics driver update) than it does OpenGL. Even with a driver update, GL can still be a bit hit and miss…

The angle code is very stable (it’s used by most browsers) and very fast (faster than d3d9 bmx here) so IMO it’s the right choice for a ‘default’ driver..

[sicilicaParticipant]

Hmm, no dice. I tried disabling SDL_VIDEO_OPENGL_ES2 and SDL_VIDEO_OPENGL_EGL as well, but it didn’t seem to make a difference. Also, calling SDL_GL_SetAttribute() before creating a window crashes, presumably because there’s no GL context bound (you can’t create a context without a window unless I’m mistaken?).

I mean, you’re not wrong about compatibility and stuff – I’ve definitely seen people have problems with OpenGL working on their cards/drivers – but the whole thing is just a bunch of crap. Seriously hoping Vulkan manages to clean all of this up….

EDIT: I deleted my build folder between all these to make sure, too.

[Mark SiblyKeymaster]

> Also, calling SDL_GL_SetAttribute() before creating a window crashes,

You need to do this after SDL_Init, but before creating the SDL_Window.

If you’re trying to do this in mojo as opposed to raw SDL, you’ll probably have to hack the AppInstance class.

I’d recommend trying with raw SDL first to get things working, eg:

Monkey

#import "<libc>" #import "<sdl2>" #import "<gles20>" Namespace sdl2test Using libc.. Using sdl2.. Using gles20.. Class SdlWindow Field sdlWindow:SDL_Window Ptr Field sdlGLContext:SDL_GLContext Method New() SDL_Init( SDL_INIT_EVERYTHING ) SDL_GL_SetAttribute( SDL_GL_DEPTH_SIZE,1 ) sdlWindow=SDL_CreateWindow( "SDL2 Window",SDL_WINDOWPOS_CENTERED,SDL_WINDOWPOS_CENTERED,640,480,SDL_WINDOW_OPENGL ) sdlGLContext=SDL_GL_CreateContext( sdlWindow ) SDL_GL_MakeCurrent( sdlWindow,sdlGLContext ) Local i:Int SDL_GL_GetAttribute( SDL_GL_DEPTH_SIZE,Varptr i ) Print "SDL_GL_DEPTH_SIZE="+i End Method Run() Repeat Local event:SDL_Event While( SDL_PollEvent( Varptr event ) ) Select event.type Case SDL_WINDOWEVENT Local wevent:=Cast<SDL_WindowEvent Ptr>( Varptr event ) Select wevent->event Case SDL_WINDOWEVENT_CLOSE exit_( 0 ) End End Wend OnRender() SDL_GL_SwapWindow( sdlWindow ) Forever End Method OnRender() glClearColor( 1,1,0,1 ) glClear( GL_COLOR_BUFFER_BIT ) End End Function Main() Local window:=New SdlWindow window.Run() End

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83

#import "<libc>" #import "<sdl2>" #import "<gles20>"   Namespace sdl2test   Using libc.. Using sdl2.. Using gles20..   Class SdlWindow   Field sdlWindow:SDL_Window Ptr Field sdlGLContext:SDL_GLContext Method New() SDL_Init( SDL_INIT_EVERYTHING ) SDL_GL_SetAttribute( SDL_GL_DEPTH_SIZE,1 ) sdlWindow=SDL_CreateWindow( "SDL2 Window",SDL_WINDOWPOS_CENTERED,SDL_WINDOWPOS_CENTERED,640,480,SDL_WINDOW_OPENGL ) sdlGLContext=SDL_GL_CreateContext( sdlWindow ) SDL_GL_MakeCurrent( sdlWindow,sdlGLContext ) Local i:Int SDL_GL_GetAttribute( SDL_GL_DEPTH_SIZE,Varptr i ) Print "SDL_GL_DEPTH_SIZE="+i End Method Run() Repeat Local event:SDL_Event While( SDL_PollEvent( Varptr event ) ) Select event.type Case SDL_WINDOWEVENT Local wevent:=Cast<SDL_WindowEvent Ptr>( Varptr event ) Select wevent->event Case SDL_WINDOWEVENT_CLOSE exit_( 0 ) End End   Wend OnRender() SDL_GL_SwapWindow( sdlWindow ) Forever End Method OnRender() glClearColor( 1,1,0,1 ) glClear( GL_COLOR_BUFFER_BIT ) End End     Function Main()   Local window:=New SdlWindow window.Run()   End

All this does is enable depth buffering, but it’s a start.

but the whole thing is just a bunch of crap.

Eloquently put, but it is what it is. MS won this round, hopefully Vulkan wins the next!

[taumelSpectator]

The OpenGL ES2 support brings up the whole Monkey-X dilemma again. Too many platforms with different needs based on outdated least common denominator tech.

The vast majority of Windows runs on DX11/10 hardware. OS X is based on OpenGL 4.x and Metal. iOS is utalising Metal too and a significant percentage of Android is OpenGL ES3.X ready. Depending on the stats you’re looking at, OpenGL ES2 is still a market but the time is working against you and you’re holding back the others.

Waiting for Vulkan to solve all these issues … i doubt it will work out this way easily soon. The vendors are having too different interests. In order to provide a good solution for m2 now and in a foreseeable future, i think there must be other options as well.

Now as m2 isn’t finished you could hold this back for some further time but then again other tools are working on it/doing it already. You don’t need every feature from the new APIs but some of them are damn sweet and can make a huge difference about what is your content and how it feels like. In my opinion Mark should go for this opportunity. Always keeping 3D in mind too.

[sicilicaParticipant]

@taumel – Other than mojo being based on a particular graphics library, nothing there is a problem for M2. There’s no reason you can’t use it with a different version of OpenGL, or Vulkan, etc – you would just need to wrap those C APIs and throw them in a module. Also, Vulkan is already in a really good position – basically 100% of cards you care about already support it, and I’ve played with the API and it all seems sensible. It’s not a question of whether it can “solve the issues” or whether vendors support it; the question is whether game developers will actually start using it. If it never gets bigger than something a few indie devs use, then support for it won’t last into the future. That said, for me personally, I’m not going to develop anything commercial with it until I’ve seen some others do so. I’m not the early adopter type.

@mark – Yeah, what you have there is almost exactly what I’m doing, except I’m not using libc for anything. I tested again, though, and it wasn’t the SetAttribute() call that crashes, it was the glGetString() call just afterwards:

Monkey

' sdl init... SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_CORE) ' make window and context here... Print String.FromCString(glGetString(GL_VERSION)) ' null pointer exception

1 2 3 4 5 6 7

' sdl init...   SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_CORE)   ' make window and context here...   Print String.FromCString(glGetString(GL_VERSION)) ' null pointer exception

So, my bad on that. That proves that moving the SetAttribute() to before the window creation made it do more than noop, since before it had no impact on anything – but glGetString() should return a ubyte pointer and I tested and showed it giving me null, which is… weird. Any idea?

Oh, and if I skip testing GL_VERSION, then trying to compile a shader leaves GL_COMPILE_STATUS as 0 and glGetShaderInfoLogEx() returns an empty string, so I can only imagine the driver is failing to write anything to that byte array, too.

EDIT: WHOA, libc gives you bindings for malloc and free? And memset, too. Wow. I posted before about wanting to store fixed-size arrays inside a struct, and I concluded that if I really wanted to I’d either have to write the struct in C and import it or make a really complicated RawArray struct for it based on the Array in the core module. But this way I could just store a pointer and do malloc/free in a constructor/destructor (though I probably have to call them manually)! Sweet. And certainly pointers support array syntax, since M2’s “->” just seems to be an alias for “[0].”. Cool.

[taumelSpectator]

@sicilica
Theoretically you might wrap all such things on your own but practically, apart from a handful of users, the Blitz products don’t seem to be the right playground for such a strategy.

Until there will be proper OS X support, not just wrapping it on Metal by a third party, it’s hard to imagine Vulkan being a reasonable cross platform option. Until this happens, if you can afford it, it’s the best to support the APIs which run smooth on each platform.

[coconParticipant]

There is a very interesting project that “wraps” all of the graphics APIs under one roof.

https://github.com/gfx-rs/gfx

This might be a good inspiration of what the rendering backend of mojo would be.

[sicilicaParticipant]

@taumel
The problem with supporting the best APIs for each platform you want to run on is that it’s extremely costly, especially for a small studio – in practice, the way you handle memory and the way you interact with the graphics pipeline need to completely change based on the target, and that’s probably more true for consoles than for different desktop OSes. Worse, most of this code is so integral to the engine that it touches almost all of the game, making it hard to completely abstract out from gameplay code. Even a professional studio carefully chooses which platforms to support and has to devote a lot of resources to porting code, so you really only get releases on Windows and PS/Xbox, since each “version” of the game needs to be carefully maintained.

In any case, all of these API concerns have little to do with language – your language choice should have little impact on any of this so long as you have an available toolchain. I’m only considering C++ targets with existing libraries for the target system; this conversation is essentially just about the technical details of connecting those libraries to Monkey. Whether you want to use D3D, or OpenGL, or Vulkan – whether you want SDL, or anything else – the choice of which is the “best” choice has little to do with the fact that any of those options should be possible.

 

Anyway, Mark publishes a gles20 module, and I’d like to use the GLES C API without forcing the driver to compile GLSL scripts in compatibility mode, ideally also without hacking Mark’s code too overly much. Of course I could link in a different OpenGL lib for the C bindings, since it’s apparent that I’m not concerned with supporting mobile and such anyway, but it’d be nice to not have to worry about it. If anyone – in particular Mark, who should know how things are laid out better than the rest of us – can give me pointers on what part of the module is giving me grief (probably the Angle stuff, if I had to guess), it’d be appreciated.

 

Edit:

@cocon, that actually looks like a really interesting approach, which I guess is what the Rust community came up with? That could be really convenient for general use, but I doubt it has any longevity, since by adding that additional layer of abstraction between the application and the driver (at best you have to remap function calls, at worst you have to emulate some things) you will always lose performance. Vulkan is interesting precisely because it has momentum as a more universal way to work with GPUs and is MORE efficient than most of the currently used methods by being a better representation of the underlying hardware and drivers (same with DX12, except for the M$ label).

[taumelSpectator]

@sicilica
I’m aware of that you don’t get it for free. Questions are a) is it worth the effort and b) what are the others offering.

Looking at popular game engines these days, you can’t always choose your language freely, they can be tied to the engines, so, your toolchain is partly fixed. I also doubt that a majority of the Bitz community sees API concerns decoupled from the language. At the end of the day it’s often a pleasing mix you’re after, less isolated aspects.

[sicilicaParticipant]

@taumel

“Toolchain” here basically just means “a C compiler with bindings for your hardware.” In any case, yeah, I’m completely not talking about mojo and how it’s implemented here, so you’re probably right and that just makes me a black sheep.

[taumelSpectator]

Nah, i wanna be the black sheep. :O)

[Author]

Posts