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 - sorlok_reaves

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 »
76
Programming Help / Re: [Solved] Adding a new function
« on: October 04, 2014, 06:26:28 PM »
I'm not so familiar with DirectX, so you're probably right. Anyway, if it's crashing on NULL then something is definitely wrong.

77
Programming Help / Re: [Solved] Adding a new function
« on: October 04, 2014, 06:12:15 PM »
Just think of it this way:

Code: [Select]
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.

78
Programming Help / Re: [Solved] Adding a new function
« on: October 04, 2014, 05:54:34 PM »
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.

79
Developing ENIGMA / Re: Massive GL3.3 changes.... again
« on: October 04, 2014, 05:41:45 PM »
Now I'm getting a compile error:
Code: [Select]
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]
#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.

80
Issues Help Desk / Re: Bad C++ generation
« on: October 04, 2014, 03:21:04 PM »
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]
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.


81
Developing ENIGMA / Re: Massive GL3.3 changes.... again
« on: October 04, 2014, 03:15:33 PM »
Running your latest changes allows it to compile, but it still crashes at:

Code: [Select]
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]
%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.

82
Developing ENIGMA / Re: Massive GL3.3 changes.... again
« on: October 04, 2014, 01:18:28 PM »
Sure, I'll have a look. Also, you are right that the first line should look like this:

Code: [Select]
fbc = glXChooseFBConfig(enigma::x11::disp, DefaultScreen(enigma::x11::disp), visual_attribs, &fbcount);

83
Developing ENIGMA / Re: Massive GL3.3 changes.... again
« on: October 04, 2014, 12:35:06 PM »
I've done a little digging. Turns out this line:

Code: [Select]
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.

84
Developing ENIGMA / Re: Massive GL3.3 changes.... again
« on: October 04, 2014, 11:03:02 AM »
First, some basic errors:

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

Code: [Select]
#include "libEGMstd.h"
...because you use toString().

Also, on this line:
Code: [Select]
*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]
*vi = glXGetVisualFromFBConfig( enigma::x11::disp, fbc[0] );
...you store a single pointer in a value type. I tried changing these lines to:

Code: [Select]
*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.)

85
Developing ENIGMA / Re: Massive GL3.3 changes.... again
« on: October 03, 2014, 11:54:12 PM »
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]
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=""


86
Developing ENIGMA / Re: Massive GL3.3 changes.... again
« on: October 03, 2014, 11:48:34 PM »
Lots of great fixes! One minor bug: you need to add the following in GL3shader.cpp:

Code: [Select]
#include <cstring>
...because memcpy is actually defined there (for some reason). Otherwise, Project Mario can't compile in Linux.

87
Programming Help / Re: [Solved] Adding a new function
« on: October 03, 2014, 11:39:26 PM »
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.

88
Issues Help Desk / Re: Bad C++ generation
« on: October 03, 2014, 11:34:01 PM »
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.

89
Programming Help / Re: [Solved] Adding a new function
« on: October 03, 2014, 11:23:57 PM »
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).

90
Issues Help Desk / Re: Bad C++ generation
« on: October 03, 2014, 09:34:24 PM »
On Windows:
C:/ProgramData/ENIGMA/Preprocessor_Environment_Editable

On Linux:
~/.enigma

On Mac:
./ENIGMA/

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 »