Then I had a library linking problem because DMD is exclusively a 32bits compiler. I missed libsdl_image in /usr/lib32. I run a 64 bits machine like modern people do The funny part is that I had all the libsdl libraries except this 'image' one in /usr/lib32. So I downloaded a package for i386 from the big debian repository then I forced the install:

Code:

sudo dpkg -i --force-architecture libsdl-image1.2_1.2.6-3_i386.deb

The install is made in /usr/lib wich is a sym link to /usr/lib64. So you have to move the lib in the right folder.

Note that at this point you 64bit libSDL_image package is broken But easy to repair in 2 clicks with synaptic or another package manager.

I had the same problem with libvorbis. Except that I could not find a package So I removed everything linked to ogg / vorbis for the demo I tried. (a few comments out in resource/sound.d, system/system.d, and demo1/ main.d ship.d gameobj.d)

Then you may need to modify buildyage, if your architecture is not recognized correctly.

I had a strange problem with the shaders. At some point one light throwed some Graphics exception, after a if ( location = -1) in render.d I think (it was on another machine, don't have the code here). I commented out the exception and it worked fine. However it was hard to reproduce the problem afterwards by uncommenting. Weird.

Anyway I also got some real problem, ie some segfaults. All the segfaults were due to a code like this:

Code:

for (i; i < max; ++i)
{
char[] s = "texture0\0";
s[7] = i + '0';
}

I don't know how it works with Windows, but clearly such a string like "texture0\0" will be compiled as part of the program, not in the data stack or on the heap. So of course trying to modify through pointer access will fail on Linux. the char[] s is clearly non modifiable.

I solved it by the following:

Code:

char[] s = "texture";
char[] s2 = s ~ cast(char)(i + '0');

Or something like that. It is more D like This problem appears 4 or 5 times in the program.

@JoeCoder
I don't have easy svn access because of some proxy setting I will commit all of that of course when I have time.

On Windows, the contents of the program are loaded into memory and (I think) are safe to modify unless DEP is enabled. And I obviously forgot about DEP when I wrote that code, so this does need to be fixed.

The reason I didn't use concatenation was to prevent memory allocation, since this code is called very frequently. The best solution would be to allocate it once and then do the character substitution.

What video card was in the machine that thew the GraphicsException when it couldn't set the GLSL uniform variable?

I've had other odd problems with the shaders. I have a Radeon x600 laptop that can only accept shaders of up to about 96 instructions. Normally a 6 light shader will fall back to a 5 light shader if the card says it can't run it, and from 5 to 4 and so on. This card will reject shaders with 6+ lights, but for 4-5 lights it will accept the shader and render nothing. 1-3 lights render fine. I'm pretty sure it's an ATI driver bug. A new ATI card doesn't have the issue at all.

Except for that, you're in for a treat once you get everything running. The current demo looks better than any screenshots or videos I've posted so far.

By the way, this is excellent work! You're very good at understanding new code--better than me probably.

the machine is an Intel core 2 duo E6750 with GeForce8400 GS. At some point I had the demo but no lighting (black screen, but I see a changing FPS in the title bar + texture loading). It was only a problem for the light. It triggered there (opengl.d):

I tried both demo 1 and 2. I have some problems to manipulate the spaceship in demo 1. I mean that I don't really understand where I go with the mouse, it seems pretty sensitive. Otherwise it sounds great and fires correctly I was impressed by demo2. Maybe I missed something (if I click on the squares my mouse pointer disappears...) but I have only a rotating ship with a GUI window which I can move, however a nice and transparent GUI is definitely not something common in open-source engines Great.

BTW the FPS is 150 with the nvidia card.

Some Linux point here: in Linux all graphics go to the X server first, then to something called the MESA lib. If an openGL feature is supported by the GPU, the processing of the feature is sent to the GPU directly. This is called direct rendering. Most interesting, if a feature is not supported, the MESA lib emulates it in software. The MESA lib implements the complete OpenGL spec in software So JoeCoder I wonder if the probing for GL features is actually speaking truth in Linux. Because maybe (I say maybe) the MESA lib always answer yes to a feature probing, even if it can fall back on software rendering in the background.

Can you tell which version of OpenGL is required normally with the current code? My nvidia GPU supports OpenGL 2.1.2.

The minimum required OpenGL version for Yage is 1.1, and if you modify Probe to return false for the extension checks, it should render this way. I might be using some OpenGL 1.2 features without checking for them though. Oops.

Probe queries for the FrameBufferObject extension that was made official in OpenGL 3, but Yage doesn't use it yet. The next newest feature is Shaders, which is from OpenGL 2.0.

Quote:

I have some problems to manipulate the spaceship in demo 1

I agree--it is a little difficult. I spend more time on engine features than making demos. And I got so used to the controls that I didn't even notice any more.

Quote:

if I click on the squares my mouse pointer disappears

I think I broke that in a recent commit. I did another commit last night which hopefully fixed it.

I used Kubuntu 8.10 for 6 months about a year ago, but it crashed and I didn't have time to reinstall it. I've been using Windows ever since, which is why Yage's Linux support has suffered so much. I knew MESA could emulate OpenGL features, but I didn't realize that was the default and it would always list the extension strings as supported. Is there a better way to Probe on Linux?

I'm not sure why the uniform variable error caused everything to render black. The Gui and skybox don't use shaders at all and still should've rendered fine.

It would be nice to keep track of the openGL version. It feels professional On Linux I don't think we can do much about MESA, and it is not our job anyway as engine devs. I saw on the new Ubuntu a kind of control panel for the graphics It seems that one can already activate / desactivate the Direct Rendering, I haven't seen all the features but it sounds good.

Don't worry about the controls, I just wanted to know if it was an environment problem. I think the black screen was simply a normal screen without light, because the textures were loading normaly etc. Of course no light = everything is black.

PS: my book (3d terrain programming) speaks about geomipmap. I also checked the Infinity website that I hadn't visited for long. The last demo kicks ass. I know there was a cool dev blog, I will try to find it again.

Impossible to make the demo 2 work, and the demo 1 seems to crash randomly with a segfault at different places

On a 32-bits on the contrary it is stable. My advice for Linux users, install a 32 bits somehow (Live USB, chroot, second partition...) and wait for dmd 64. Also I can't get svn access from where I want to work. I can reach svn only from another machine very irregularly. I wrote a post in the "site" section of the forum to get svn through ssh, we'll see.

The segfault happens at the first direct call of an openGL function, but sometimes at another point in the code which I can't trace! I don't know, it has to do with the loading of the openGL library I think. Somehow the function points to a place in memory where openGL lib should be but is not. The bottom line is that the lack of dmd 64 makes everything more complicated. You should have no problem with a windows 64.

The stack trace you posted makes it look like it's failing in demo1.ship.Ship.update. The scene graph is rather multi-threaded and I wonder if I haven't synchronized something properly. I've been considering a rewrite but I don't have a definite direction yet.

Image2 is successor of Image class... but for the moment I use Image class to load a heightmap because Image2 does not propose this (I am testing a heightmap stuff).

I looked more at infinity. The dev uses a pretty complex texturing. Creating the texture pack already For the moment I do my own tests and I haven't looked at your interface too much, but if you can say more about the terrain system for Yage I open a new topic about it.

I just read Andre Alexandrescu's excellent chapter on D2 concurrency. It looks like it has everything I need to keep me from breaking things with threads.

I wold love to rewrite Yage's scene graph to use this, but I think it may be better to wait for D2 to mature and get more libraries before making the jump, maybe even Tango will be ported. I'm open to suggestions.