Clay Smith wrote:
>> Awesome! Look very professional.
>> ~ Clay
> 
> Scintilla support would be great as well, because besides being my favorite editor, it would be the one component I would need to edit AI scripts in WarBots in-game, if I ever get around to that project. Were you thinking of using in-game Scintilla support for the Fragbots?

Thanks! I'm actually focusing on Deadlock and its in-game scripting, as well as tweaking shaders and perhaps other code (which might be recompiled and loaded dynamically) from within a game/editor. But in the longer run, when I finally get around to reanimating Fragbots, that would be an option as well.


-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode

Tom S wrote:

> Lutger wrote:
>> I'm getting a black window, unfortunatly. Anything I should look for to debug, setup my env differently, etc.? Thanks.
>> 
>> System: mandriva linux 2008.1 running compiz on Geforce 6600GT with nvidia's driver, compiled with dmd 1.030.
> 
> Are you getting the same black window with the demos from
> http://hybrid.team0xf.com/Demos.7z ?
> I'm not sure if anyone has tested Hybrid/Dog with compiz yet. If e.g.
> glxgears works for you, I could try comparing its (GL)X code with
> Hybrid's bit by bit, and perhaps something will stand out.
> Other than that... you might check if any of the Dog demos work
> (xf.dog.test / xf.dog.testThreads) and don't yield black windows.
> 

Hi, the demos give the same result. xf.dog.testThreads.d also a black window. With xf.dog.test.d I get this assertion: "tango.core.Exception.AssertException@xf.dog.ext.ARB_shader_objects(369): Assertion failure" (this is gl.GetString returning null on querying the extension strings)

glxgears works fine. I've ported this example program to D: http://www.opengl.org/wiki/index.php/Programming_OpenGL_in_Linux:_GLX_and_Xlib

This also works ok with derelict and the x11 bindings from gld and might be somewhat simpler than glxgears.

I get the same result btw. when compiz is not enabled, it could very well be something in my setup, perhaps it's linking to mesa or something like that. I still haven't figured out how all these opengl libs + glx work under linux, it's all quite messy imho.

Tom S wrote:

> Lutger wrote:
>> I'm getting a black window, unfortunatly. Anything I should look for to debug, setup my env differently, etc.? Thanks.
>> 
>> System: mandriva linux 2008.1 running compiz on Geforce 6600GT with nvidia's driver, compiled with dmd 1.030.
> 
> Are you getting the same black window with the demos from
> http://hybrid.team0xf.com/Demos.7z ?
> I'm not sure if anyone has tested Hybrid/Dog with compiz yet. If e.g.
> glxgears works for you, I could try comparing its (GL)X code with
> Hybrid's bit by bit, and perhaps something will stand out.
> Other than that... you might check if any of the Dog demos work
> (xf.dog.test / xf.dog.testThreads) and don't yield black windows.

I've got the same problems; though, I found by accident, that in the platform related libraries like glx.d and Xlib.d the function pointer aliases have D linkage:

alias void function(void *, char *, int, int, char * *) _BCD_func__849;

There is no extern(C): at the start of the files. It should of course read:

alias extern(C) void function(void *, char *, int, int, char * *)
_BCD_func__849;

I can't test it right here, since I've got no xf86vm (why is this needed at
all?)

Lukas Pinkowski a écrit :
> I've got the same problems; though, I found by accident, that in the
> platform related libraries like glx.d and Xlib.d the function pointer
> aliases have D linkage:
> 
> alias void function(void *, char *, int, int, char * *) _BCD_func__849;
> 
> There is no extern(C): at the start of the files. It should of course read:
> 
> alias extern(C) void function(void *, char *, int, int, char * *)
> _BCD_func__849;
> 
> I can't test it right here, since I've got no xf86vm (why is this needed at
> all?)

Indeed, it's a BCD bug: http://www.dsource.org/projects/bcd/ticket/4

Lutget wrote:
> Hi, the demos give the same result. xf.dog.testThreads.d also a black
> window. With xf.dog.test.d I get this assertion: "tango.core.Exception.AssertException@xf.dog.ext.ARB_shader_objects(369):
> Assertion failure" (this is gl.GetString returning null on querying the
> extension strings)

Thanks for checking it out!
A relatively sane reason for this behavior is that the GL context is not created, somehow. glGetString could theoretically return null if it's called within glBegin .. glEnd, but this is not the case.


> glxgears works fine. I've ported this example program to D:
> http://www.opengl.org/wiki/index.php/Programming_OpenGL_in_Linux:_GLX_and_Xlib

Thanks! I'll look at it.


> I get the same result btw. when compiz is not enabled, it could very well be
> something in my setup, perhaps it's linking to mesa or something like that.
> I still haven't figured out how all these opengl libs + glx work under
> linux, it's all quite messy imho. 

Well, it should work well with Mesa. At least it works for me, in the Debian Etch I've got set up in VMWare Player.




Lukas Pinkowski wrote:
> I've got the same problems; though, I found by accident, that in the
> platform related libraries like glx.d and Xlib.d the function pointer
> aliases have D linkage:
> 
> alias void function(void *, char *, int, int, char * *) _BCD_func__849;
> 
> There is no extern(C): at the start of the files. It should of course read:
> 
> alias extern(C) void function(void *, char *, int, int, char * *)
> _BCD_func__849;

:o Hrm, this doesn't look too good, I'll pass the info to Ralith / Benjamin who's created the GLX backend. Such an error should cause it to crash on his GDC under FreeBSD and my VM'd debian... Weird.

Thanks a lot for testing and finding it out :)


> I can't test it right here, since I've got no xf86vm (why is this needed at
> all?)

It appears that it's used for changing display modes for fullscreen support, tho I'm sure Ralith would be able to give you more info :}


-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode

e-t172 wrote:
> Indeed, it's a BCD bug: http://www.dsource.org/projects/bcd/ticket/4

"Opened 1 year ago" ? Ouch... Looks like it will require manual fixing. Thanks for bringing this up!


-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode

The missing 'extern(C)' has been added to the generated bindings, xf86vm has been replaced by randr. The Demos.7z package has been updated as well. So far, it's been tested on Ralith's FreeBSD and my Debian Etch in a VM.


-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode

Tom S wrote:

> The missing 'extern(C)' has been added to the generated bindings, xf86vm has been replaced by randr. The Demos.7z package has been updated as well. So far, it's been tested on Ralith's FreeBSD and my Debian Etch in a VM.

Hi,

it works under Ubuntu Gutsy (which my university is using), but it doesn't
work under openSUSE 10.3:

This is the output:

...
...
Registering widget: FramedTopLevelWindow
Registering widget: GLViewport
Creating widget: FramedTopLevelWindow
object.Exception: Unable to create double-buffered visual
X Error: BadWindow (invalid Window parameter)


My Graphics Card:

OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce 7600 GS/PCI/SSE2/3DNOW!
OpenGL version string: 2.1.2 NVIDIA 169.12


The test-program 'runs' when I make the following change to GLX.d (though I
get only a black window):

int[] attrListDbl = [
                        GLX_RGBA,
                        GLX_DOUBLEBUFFER,
                        GLX_RED_SIZE, 1,
                        GLX_GREEN_SIZE, 1,
                        GLX_BLUE_SIZE, 1,
                        GLX_DEPTH_SIZE, _depthBits,
                        None];

I also tried RED_SIZE 5, GREEN_SIZE 6, BLUE_SIZE 5, which results in a black
window, too.
Although, the program seems to react to clicks, just nothing is rendered
(tried a different color for glClear).


Btw. the test.d in the Dog-package crashes with:

tango.core.Exception.AssertException@xf.dog.ext.ARB_shader_objects(369):
Assertion failure

And testThreads shows black windows only.

Cheers

Lukas Pinkowski wrote:
> (...)

Thanks a lot for the comprehensive report :)
I'll look into this stuff as soon as I get some univ stuff sorted out, perhaps I'll even get a real Linux setup :P The GLX backend dude will surely get this info as well :> I'm sure that with a bit of hacking it will be able to run (almost) everywhere.


-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode

Tom S wrote:

> Lukas Pinkowski wrote:
>> (...)
> 
> Thanks a lot for the comprehensive report :)
> I'll look into this stuff as soon as I get some univ stuff sorted out,
> perhaps I'll even get a real Linux setup :P The GLX backend dude will
> surely get this info as well :> I'm sure that with a bit of hacking it
> will be able to run (almost) everywhere.

I've just found out that the problem lies with reshaping the window. After
clearing with yellow (glclear(1,1,0,1)) the window indeed was yellow. But
after this, the contents of the window were not changed.
Even worse, when the window was resized, it became a black window.

Hope this helps with finding the problem!

Cheers