Just think of it this way:

Code Select Expand

D3DWhatever* something = 0xFF00FF;

Give this garbage pointer, how can you *possibly* know it's invalid? In C++, it just points to a memory location, and the runtime just assumes that you point to one that represents an object, or NULL.

Now, D3D *could* maintain a list of all known D3DWhatever pointers somewhere global, and check this every single time it's given a pointer. But that's costly, and it only helps very obscure cases like this one.

Valgrind might be able to detect this, if the memory being pointed to is uninitialized or something like that. But even then, it's kind of a gray area.

This is one very good reason why you should always initialized your pointers to NULL; it allows the runtime to detect when a pointer is definitely invalid.

Still in Sydney at the moment so don't have access to any code right now.

Having said that, the exact same DLL is working 100% in GM:S.

Even if I skip the init to force a null pointer for the device, in the quad crate call, GM:S returns 1 for failed call (as expected) but ENIGMA crashes instantly.

Yes, but that's probably because your pointer is initially in a garbage state anyway (because you never set it to anything).

Anyway, it's much better to wait until we get an actual test case; I don't think we'll be able to solve this until Robert and I actually have something concrete to work with.

Now I'm getting a compile error:

Code Select Expand

Bridges/xlib-OpenGL3/graphics_bridge.cpp:132:21: error: 'glxewInit' was not declared in this scope
    err = glxewInit();

What's really weird about this is that you include glxew.h. So I tracked down within that file:

Code Select Expand

#ifdef GLEW_MX
#define glxewInit() glxewContextInit(glxewGetContext())
#endif

GLEW_MX is an optional macro, and defining it makes a lot of other things more annoying (like glewGetContext()). Not entirely sure what the right response here is.

Sorlok, I'll be honest, I was more interested in overloading var for array so we can test array lengths and also to return arrays of pixel data from background functions, like background_getpixels is what I wanted to do. Studio added some of these functions which I'd also like to have. It is much easier for heightmaps and stuff, and the old way of drawing to the screen then draw_getpixel one at a time was soooooooo slow. But currently regular arrays don't even work in the parser, and to overload var we'd also have to overload std::array which I tried and failed at.

The major challenge with pushing more variable types onto variant is the semantics of other operators (like add, subtract) when differing types are involved.

The other major question is more a design issue: do we want to mirror GM:S's array syntax 100%, for example, or do it in some other way (maybe introduce a different variant type internally?) Consider the following:

Code Select Expand

var i = 10;
var p = /* some pointer */;
var s = "hi";
var a = /* some array */;
var u = i + p + s + a;

If GM supports this last line, you're just begging for hard-to-debug games.

Running your latest changes allows it to compile, but it still crashes at:

Code Select Expand

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


Running on master compiles and runs, and then the game is unplayable (just a single blue screen and the cursor, but it's not clear if I'm actually moving, since everything is blue).

Project Mario builds on master.

The shader example still crashes on master, but I figured out why. By default (because this is an EGM file!) the make directory is set to:

Code Select Expand

%PROGRAMDATA%/ENIGMA/

I really, really, really think we should not honor the user-specified make directory and just pick one (internally) for each platform. I've run into this same bug like 3 times.

Sure, I'll have a look. Also, you are right that the first line should look like this:

Code Select Expand

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

I've done a little digging. Turns out this line:

Code Select Expand

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

...will segfault unless glewInit() is called. However, glewInit() will fail if it is not in exactly the right place (causing later failures). The important thing here is that even if glewInit() fails, the glXChooseFBConfig() will at least not segfault.

I'll try to track down the "right" place to put the glewInit() call, but maybe Robert has a better idea? I'm not much of an OpenGL person.

First, some basic errors:

In Bridges/xlib-OpenGL3/graphics_bridge.cpp, you need:

Code Select Expand

#include "libEGMstd.h"

...because you use toString().

Also, on this line:

Code Select Expand

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

...you are storing a double-pointer in a single-pointer.

Similarly, here:

Code Select Expand

*vi = glXGetVisualFromFBConfig( enigma::x11::disp, fbc[0] );

...you store a single pointer in a value type. I tried changing these lines to:

Code Select Expand

*fbc = *glXChooseFBConfig(enigma::x11::disp, DefaultScreen(enigma::x11::disp), visual_attribs, &fbcount);
*vi = *glXGetVisualFromFBConfig( enigma::x11::disp, fbc[0] );

...but I got a segfault on the first line. I'll look into this more, but perhaps you changed how the *FBConfig() functions work? (GL1 doesn't use them, and Windows-GL3 does something different.)

Also, the Minecraft example looks like this on Linux (+Nvidia), with both OpenGL1 and OpenGL3:



Finally, the shader example will cause Lateral GM to segfault, shortly after:

Code Select Expand

Running make from `make'
Full command line: make Game WORKDIR="%PROGRAMDATA%/ENIGMA/" GMODE=Run GRAPHICS=OpenGL3 AUDIO=OpenAL COLLISION=Precise WIDGETS=None NETWORKING=None PLATFORM=xlib CXX=g++ CC=gcc COMPILEPATH="Linux/Linux" EXTENSIONS=" Universal_System/Extensions/Alarms Universal_System/Extensions/Timelines Universal_System/Extensions/Paths Universal_System/Extensions/MotionPlanning Universal_System/Extensions/DateTime Universal_System/Extensions/ParticleSystems Universal_System/Extensions/DataStructures" OUTPUTNAME="/tmp/egm7620500460771948401.tmp" eTCpath=""

Lots of great fixes! One minor bug: you need to add the following in GL3shader.cpp:

Code Select Expand

#include <cstring>

...because memcpy is actually defined there (for some reason). Otherwise, Project Mario can't compile in Linux.

My knowledge of DLLs is also limited. I guess we'll need lonewolf to post some sample project & branch.

I'll talk to Josh about this once there's a clear need for pointers in variants. Right now it seems like we'll definitely need to look at this for external library initialization, but maybe there's a better way to chain the calls and avoid variants entirely? After all, normal ENIGMA scripts shouldn't really be playing around with pointers.

There are two parsing errors I've yet to push patches for. Once of them involves variable scoping with single-line if. The other involves the decrement/increment operators. And there are plenty of other bugs that are unknown.

But like Robert said, it'll be easier to debug if you post the sample code.

Glad the pointer passing is working. Once you figure out the DLL issue, let me know  ---we really need to have a discussion about the "right" way to store pointers in variants (since my solution is a bit hacky).

On Windows:
C:/ProgramData/ENIGMA/Preprocessor_Environment_Editable

On Linux:
~/.enigma

On Mac:
./ENIGMA/

All the variant is doing is wrapping the pointer and then passing it back; I've confirmed that it works for simple new'd data. It would have to be something slightly more complicated, I think, to cause the invalid pointer to be saved.

Can you post a branch and test game, so that I can run it through GDB?