FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

make it work on Linux the 17/12/2010
Goto page 1, 2  Next
 
Post new topic   Reply to topic     Forum Index -> Yage
View previous topic :: View next topic  
Author Message
anarky



Joined: 03 Jul 2010
Posts: 35

PostPosted: Sat Jul 03, 2010 10:43 am    Post subject: make it work on Linux the 17/12/2010 Reply with quote

Hi,

I finally made this engine work on my Linux box (Xubuntu 8.04 something). I had a couple of problems which are good to know.

First go there: http://www.dsource.org/projects/tango/wiki/TopicInstallTangoDmd to download the bundle dmd+tango version, and add it in your PATH. Quite easy it works fine.

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 Laughing 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.

Code:
sudo mv /usr/lib/libSDL_image-1.2.so.0.1.5 /usr/lib32/libSDL_image-1.2.so.0.1.5


Maybe you will also need to create the symbolic link:
Quote:
/usr/lib32/libSDL_image-1.2.so.0 -> libSDL_image-1.2.so.0.1.5


Note that at this point you 64bit libSDL_image package is broken Very Happy 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 Crying or Very sad 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.
Code:
    version (linux)
-   {   version (X86)
+   {/+   version (X86)
          char[] platform = "linux32";
       version (X86_64)
          char[] platform = "linux64";
+         System.trace("{}",platform);
+   +/
+      char[] platform = "linux64";
+      System.trace("{}",platform);
    }



Good. So now let's correct the bugs Laughing First in trunk/yage/system/window.d line 258 change
Code:
if(fullscreen)
to
Code:
if (false)
cause fullscreen is not defined.

Also you can get an exception about a toLower function in yage/gui/style.d. Correct with those changes:
Code:

-         char[] property = trim(tokens[0]);
-         property = toLower(property, property);
+         char[] prop = trim(tokens[0]);
+         char[] property = toLower(prop);


Finaly in yage/resource/manager.d I put a hack (ie I don't know why it works) against
Quote:
The path '%s' could not be resolved.

Code:
-         if (FilePath(result).exists)
+         if (FilePath(path).exists)
+            return path;
+         else if (FilePath(result).exists)
             return result;


At this stage it should work. Wink , just run
Code:
./buildyage -debug &&../bin/yage3d

I wanted to do this post because it took me like 4 hours to find out all of that. But I am just back to D too Rolling Eyes

I will open some corresponding bug reports to hope to see those problems solved in the future.

peace
[Anarky]


Last edited by anarky on Fri Dec 17, 2010 10:22 am; edited 1 time in total
Back to top
View user's profile Send private message
JoeCoder



Joined: 29 Oct 2005
Posts: 294

PostPosted: Sat Jul 03, 2010 12:30 pm    Post subject: Reply with quote

It's been a long time since I had compiled Yage on Linux, so thanks for these fixes. I gave you svn write access if you want to commit these changes--just use your dsource username/password
Back to top
View user's profile Send private message
anarky



Joined: 03 Jul 2010
Posts: 35

PostPosted: Mon Jul 05, 2010 1:46 pm    Post subject: Reply with quote

Compiling on another machine today,

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 Wink This problem appears 4 or 5 times in the program.

@JoeCoder
I don't have easy svn access because of some proxy setting Mad I will commit all of that of course when I have time.
Back to top
View user's profile Send private message
JoeCoder



Joined: 29 Oct 2005
Posts: 294

PostPosted: Mon Jul 05, 2010 7:24 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
anarky



Joined: 03 Jul 2010
Posts: 35

PostPosted: Tue Jul 06, 2010 8:58 am    Post subject: Reply with quote

Hi,

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):

Code:
if (location == -1)
   throw new GraphicsException("Unable to set OpenGL shader uniform variable: %s", uniform.name);


On another machine with recent ATI card I had exactly no problem.

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 Twisted Evil 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 Very Happy 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 Cool 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.
Back to top
View user's profile Send private message
JoeCoder



Joined: 29 Oct 2005
Posts: 294

PostPosted: Tue Jul 06, 2010 9:22 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
anarky



Joined: 03 Jul 2010
Posts: 35

PostPosted: Thu Jul 08, 2010 3:04 am    Post subject: Reply with quote

Hi,

It would be nice to keep track of the openGL version. It feels professional Laughing 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 Surprised 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. Rolling Eyes

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.
Back to top
View user's profile Send private message
anarky



Joined: 03 Jul 2010
Posts: 35

PostPosted: Wed Jul 14, 2010 6:51 am    Post subject: Reply with quote

I kind of give up on the 64 architecture.

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

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.
Back to top
View user's profile Send private message
JoeCoder



Joined: 29 Oct 2005
Posts: 294

PostPosted: Fri Jul 16, 2010 2:36 pm    Post subject: Reply with quote

Were you able to get a stack trace for any of the crashes? I don't have any 64-bit machines to test right now, but it would be useful in the future.
Back to top
View user's profile Send private message
anarky



Joined: 03 Jul 2010
Posts: 35

PostPosted: Sat Jul 17, 2010 11:09 am    Post subject: Reply with quote

It looks like this:

Code:
 ./buildyage -debug &&../bin/yage3d
./buildyage is not supported.
Building Yage...
If you're curious, the options are:
   -ddoc    Generate documentation in the doc folder
   -debug   Include debugging symbols and enable stack tracing on Windows.
            Otherwise optimize, inline functions, and remove unittests/asserts.
   -lib     Create a yage lib file in the lib folder.
   -profile Compile in profiling code.
   -run     Run when finished.
   -silent  Don't print this message.
   -verbose Print all commands as they're being executed.
Example:  dmd -run buildyage.d -release -run
...
The build completed successfully in 2.11 seconds.
yage3d executable has been placed in ../bin
Using OpenAL Device 'ALSA Software on default'.
Yage has been initialized successfully.
GL_ARB_multitexture support enabled.
GL_ARB_texture_compression support enabled.
GL_ARB_shader_objects support enabled.
GL_ARB_vertex_buffer_object support enabled.
GL_EXT_framebuffer_object support enabled.
Starting update loop.
Texture '../res/sky/blue-nebula.jpg' loaded in 0.17342700 seconds.
Model ../res/sky/blue-nebula.dae loaded in 0.20115000 seconds.
Texture '../res/space/fighter.jpg' loaded in 0.01980700 seconds.
Model ../res/space/fighter.dae loaded in 0.03424700 seconds.
Texture '../res/space/star.png' loaded in 0.00948600 seconds.
Material '../res/space/star.dae#star-material' loaded in 0.00976400 seconds.
Texture '../res/space/star's-end.jpg' loaded in 0.05395600 seconds.
Texture '../res/space/star's-end-normal-specular.png' loaded in 0.06379300 seconds.
Model ../res/space/planet.dae loaded in 0.32343300 seconds.
Texture '../res/space/rocky2-normal.jpg' loaded in 0.06213300 seconds.
Texture '../res/space/rocky2.jpg' loaded in 0.05084700 seconds.
Texture '../res/space/rocky1.jpg' loaded in 0.04645300 seconds.
Model ../res/space/asteroid1.dae loaded in 0.04796800 seconds.
Texture '../res/gui/skin/clear2.png' loaded in 0.00014300 seconds.
Starting rendering loop.
Texture '../res/gui/skin/clear3.png' loaded in 0.00016400 seconds.
Segmentation fault encountered at:
[ 804c62a] 8048000+17962 demo1.ship.Ship.update                                                           @804c2b4+886 ../bin/yage3d:0
 Stacktrace:
[ 81062c3] 8048000+778947 tango.core.tools.StackTrace.defaultAddrBacktrace                                 @81062ac+23 ../bin/yage3d:0
[ 8106086] 8048000+778373 tango.core.tools.StackTrace.BasicTraceInfo.trace                                 @8106054+49 ../bin/yage3d:0
[ 8106510] 8048000+779535 tango.core.tools.StackTrace.basicTracer                                          @81064e0+47 ../bin/yage3d:0
[ 810672b] 8048000+780074 tango_stacktrace_fault_handler                                                   @81065f0+314 ../bin/yage3d:0
[f7efa410]f7efa000+1039 ???                                                                                 @0+0 :0
[ 8051256] 8048000+37461 yage.scene.node.Node.update                                                      @805111c+313 ../bin/yage3d:0
[ 8050701] 8048000+34560 yage.scene.scene.Scene.update                                                    @80506e4+28 ../bin/yage3d:0
[ 804ae75] 8048000+11892 demo1.main.DemoScene.update                                                      @804ae58+28 ../bin/yage3d:0
[ 80526c1] 8048000+42688 yage.core.repeater.Repeater.HelperThread.run                                     @80525e8+216 ../bin/yage3d:0
[ 8103ac5] 8048000+768708 tango.core.Thread.Thread.run                                                     @8103a90+52 ../bin/yage3d:0
[ 81030dc] 8048000+766171 thread_entryPoint                                                                @810308c+79 ../bin/yage3d:0
[f7ec450f]f7ebe000+25870 ???                                                                                 @0+0 /lib32/libpthread.so.0:0
[f7e1d0ee]f7d39000+934125 clone                                                                            @f7e1d090+93 /lib32/libc.so.6:0
Stacktrace signal handler abort().
Aborted


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.

Anyway...
Back to top
View user's profile Send private message
JoeCoder



Joined: 29 Oct 2005
Posts: 294

PostPosted: Sat Jul 17, 2010 1:14 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
anarky



Joined: 03 Jul 2010
Posts: 35

PostPosted: Mon Jul 19, 2010 3:05 am    Post subject: Reply with quote

yeap, it can be a thread problem.

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 Mad 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.
Back to top
View user's profile Send private message
JoeCoder



Joined: 29 Oct 2005
Posts: 294

PostPosted: Sat Jul 24, 2010 2:30 pm    Post subject: Reply with quote

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.[/url]
Back to top
View user's profile Send private message
JoeCoder



Joined: 29 Oct 2005
Posts: 294

PostPosted: Sat Jul 24, 2010 2:34 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
anarky



Joined: 03 Jul 2010
Posts: 35

PostPosted: Mon Jul 26, 2010 9:02 am    Post subject: Reply with quote

Thanks for the link, it was very interesting.

I suggest to wait minimum 1 year, mainly because of the documentation status of D2. And there is quite a lot to do with the engine itself... Wink

Besides that, when my Terrain assignement is over I will be please to help you on a full D2 rewrite Very Happy
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> Yage All times are GMT - 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group