Got an error compiling:

Code Select Expand

In file included from Bridges/xlib-OpenGL3/../General/glxew.h:102:0,
                 from Bridges/xlib-OpenGL3/graphics_bridge.cpp:21:
Bridges/xlib-OpenGL3/graphics_bridge.cpp: In function 'void enigma::EnableDrawing()':
Bridges/xlib-OpenGL3/../General/../../Graphics_Systems/General/glew.h:18011:51: error: 'glewGetContext' was not declared in this scope
#define glewInit() glewContextInit(glewGetContext())
                                                   ^
Bridges/xlib-OpenGL3/graphics_bridge.cpp:128:18: note: in expansion of macro 'glewInit'
     GLenum err = glewInit();

Turns out that when you define GLEW_MX, you need to define your own glewGetContext() function (since there can be multiple contexts now).

Do you have any ideas on implementing array length sorlok? I was wanting to add some like sprite_getpixels and surface_getpixels or even d3d_model_vertices(var vertices[]) functions that return an array to avoid multiple bindings for each pixel. Without JDI supporting collections in EDL yet and me not wanting the functions to rely on the data structure extension, we are left with returning arrays. But they are unusable if the user can not get the array dimensions with the Studio function.

I can probably figure it out. I'd like to remove the "placement new" that Josh put in first, because it I find it confusing (and he said I could). At that point, it's just a matter of fiddling around with the lua_table struct. So, yep, I'll give it a shot.

I never knew arrays were broken they always worked for me. 

Another satisfied customer!

Arrays are not, I think, entirely fixed. The way they're copied and garbage collected seems a bit off to me (I'm also debugging array-based problems in Spelunky).

But, yes, basic array usage works just dandy.

I'll give it a try and get back to you (stuck in a meeting).

I'll give it a shot. I'm assuming the lua_table<lua_table<variant>> construct is used for 2-D arrays. Does that actually work right internally? (I have received mixed information on whether or not arrays "work" in ENIGMA.)

Yeah, I never really enjoy dealing with placement new.

In var4_lua.cpp:

Code Select Expand

void var::initialize() {
  new(&values) vararray;
}
void var::cleanup() {
  as_lua(values) . ~vararray();
}

Why do vars initialize with placement new in ENIGMA?

[Edit]

Ok, I tried GLEW_MX, and glXChooseFBConfig is still a null pointer. There is clearly something weird going on there.

Edit: Just for kicks, I tried updating the glew.c/glew.h packaged with ENIGMA. Still no dice.

glCreateShader() was also NULL. Enabling the COMPATIBILITY_PROFILE does not help.

I think this is almost certainly because I'm fiddling with raw pointers. I think the correct approach is to use glxew.h with GLEW_MX, or maybe that new approach you mentioned.

Anyway, I'm always free to help debug this; I'd like very much to see GLES integration.

If I force the pointer (using these changes), then the program runs past initialization and crashes immediately on:

Code Select Expand

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x0000000000483ad8 in enigma::Shader::Shader (this=0x919620, type=0)
    at Graphics_Systems/OpenGL3/GLSLshader.h:40
#2  0x000000000047cd3d in enigma_user::glsl_shader_create (type=0)
    at Graphics_Systems/OpenGL3/GL3shader.cpp:490
#3  0x00000000004990de in enigma::graphicssystem_initialize ()
    at Graphics_Systems/OpenGL3/OPENGL3Std.cpp:101
#4  0x000000000051d598 in enigma::initialize_everything ()
    at Universal_System/loading.cpp:59
#5  0x0000000000455f1c in main (argc=1, argv=0x7fffffffe0b8)
    at Platforms/xlib/XLIBmain.cpp:306

Does this look like we're making progress, or did I just cause all sorts of nondeterminism by casting function pointers around? After all, the point of Glew is to handle this kind of stuff automatically.

Yes, placing blocks an destroying them in Minecraft works on the branch. I think it's correct to say that the world generation broke.

The Shader example crashes at the same place as Minecraft (the glXChooseFBConfig() thing).

I'll try to integrate the sample code's context stuff and see if that helps.

Actually it's defined in line 303, where there is no GLEW_MX required. glxewInit calls glxewContextInit() which is in glew.c line 13227. So the whole thing seems weird to me.

Which file are we talking about? I'm referring to glxew.h, where glxewInit() is defined on line 1566, but only if GLEW_MX is defined. glXChooseFBConfig() will always be defined, but it might point to nothing if glxewInit() is never called.

Previously only glXChooseVisual was called. For proper GL3 context it seems we need glXChooseFBConfig as well. I'm honestly out of ideas. You can try using GLEW_MX, as glxewGetContext() shouldn't cause problems. GLEW homepage says that GLEW_MX is not actually included in default release. So you might need to make a custom glew build to enable that (http://glew.sourceforge.net/advanced.html). But it does look that we have everything we need already. It would be 100x easier for me to fix this if I had Linux. I guess I will have to either dual-boot or do a vm thing.

You might want to look at putting Ubuntu in a VM; I've tried enabling GLEW_MX, and got a bit stuck since it requires you to manually handle the render contexts yourself.

Try compiling this simple example: https://www.opengl.org/wiki/Tutorial:_OpenGL_3.0_Context_Creation_%28GLX%29 . It doesn't use glew, and uses old school pointer stuff. But if nothing else, then you can at least get the pointer for that function alone. And use glew for the rest.

The example works.

Also, we might look into glbinding, https://github.com/hpicgs/glbinding . It the newest and most recently worked on binding framework. It basically replaces glew and many others. It uses C++11 features and is quite interesting. But changing this will probably be a little painful, and we haven't decided if we go towards supporting C++11 compilers only, so I guess we should hold off of that for a while.

From my point of view, C++11 support would be great! I think the main concern is double-checking that MinGW on Windows has all the C++11 features we'll need. The other devs will probably have different opinions.

Actually, if this is just in the graphics Bridge, couldn't we selectively enable C++11 on Linux when GL3 is used?

[EDIT]

Unfortunately, it still crashes at the same line:

Code Select Expand

fbc = glXChooseFBConfig(enigma::x11::disp, DefaultScreen(enigma::x11::disp), visual_attribs, &fbcount);

Fun time; I just figured out that glXChooseFBConfig is NULL on my machine. Like, the function pointer returned by glxew is null. This shouldn't be happening (modern graphics card, etc.), but I'll dig into it a bit more.

EDIT: Ok, so it seems the function pointers are only set to non-null if glxewInit() is called. But that can only work if GLEW_MX is defined... which requires us to track the current render context.

My question is... did glXChooseFBConfig() work before, or was it added just to this commit?

I'm not so familiar with DirectX, so you're probably right. Anyway, if it's crashing on NULL then something is definitely wrong.