Topic: [PRINT_MODE:SHADER] (Read 85898 times)

arclance · « **Reply #15 on:** October 17, 2011, 10:52:18 am »

This does not work for me. This is what happens.

Quote

./df
textures::load(): data/art/Phoebus_16x16.png 256x256 16x16 16x16
textures::load(): data/art/Phoebus_16x16.png 256x256 16x16 16x16
Loading bindings from data/init/interface.txt
textures::load(): data/art/mouse.png 32x32
set_mode(): requesting vsync=0 and singlebuf=0.
set_mode(): SDL_GL_SWAP_CONTROL: 0
set_mode(): SDL_GL_ACCELERATED_VISUAL: 1
set_mode(): SDL_GL_DOUBLEBUFFER: 1
Segmentation fault

I am using Ubuntu 11.04 32bit with a Nvidia GeForce 8600M GT and the Nvidia drivers.
Other opengl applications work fine.

How exactly are you compiling this program?
I can try to get a working 64bit version if you can walk me through it.

Warmist · « **Reply #16 on:** October 17, 2011, 05:12:59 pm »

Quote from: lxnt on October 09, 2011, 07:24:19 pm

<...>
Windows builder and testing are needed.
<...>

Unless I misunderstood something i have bad news. Windows DF version is using different way to include graphics lib, it's built into df itself AFAIK. So only linux can have a nice separate lib.

Mike Mayday · « **Reply #17 on:** October 17, 2011, 06:12:07 pm »

oh goddamnit
I swear, if this thing eds up working, I'm switching over to linux.

Valience · « **Reply #18 on:** October 18, 2011, 02:46:02 pm »

I have windows and some pretty basic knowledge of programming. Very basic.

So, I've managed to set up Tortoisegit and snag the code from your repository, but I'm stuck there. I have MS Visual C++ 2008 installed, but there doesn't appear to be a valid solution/project file to load. I tried renaming .cproject into shader.* where * was any of the extensions the program would load, but to little avail. Am I simply overlooking something in there (like the .project and .cproject only being linux compatible) or am I less intelligent than I previously thought?

Even if the library may not load with the windows version currently, I'm interested in figuring this out for future endeavors.

lxnt · « **Reply #19 on:** October 18, 2011, 06:20:54 pm »

Quote from: arclance on October 17, 2011, 10:52:18 am

This does not work for me. This is what happens.
Quote
set_mode(): SDL_GL_DOUBLEBUFFER: 1
Segmentation fault

This is most likely a bug in code that gets shader code. Version I uploaded today has this part reworked, please try it. Zoom is still erratic, but F10 will get you out of trouble most of the time.

In case it segfaults again, please post a backtrace.

Quote from: arclance on October 17, 2011, 10:52:18 am

How exactly are you compiling this program?
I can try to get a working 64bit version if you can walk me through it.

I'm using Eclipse+CDT to build it. Project files and stuff are supplied, though only debug build is configured.

There is no sense to compile a 64bit version of it, because there's no 64bit version of game itself, or at least I never heard of it.

On posting backtraces in case someone isn't familiar with gdb.

Use this instead of ./df :

Code: (./dfgdb) [Select]

#!/bin/sh
DF_DIR=$(dirname "$0")
cd "${DF_DIR}"
export SDL_DISABLE_LOCK_KEYS=1 # Work around for bug in Debian/Ubuntu SDL patch.
#export SDL_VIDEO_CENTERED=1 # Centre the screen.  Messes up resizing.
gdb -ex r -ex bt --args ./libs/Dwarf_Fortress $* # Go, go, go! :)

When it segfaults under gdb, it'll spew the backtrace out. Post it.

lxnt · « **Reply #20 on:** October 18, 2011, 06:29:18 pm »

Quote from: Warmist on October 17, 2011, 05:12:59 pm

Unless I misunderstood something i have bad news. Windows DF version is using different way to include graphics lib, it's built into df itself AFAIK. So only linux can have a nice separate lib.

Um. A cursory look at the windows executable confirms this. Too bad.

Fortunately, trying out Ubuntu nowadays is a question of a thumb drive and some downloading.

I guess this answers part of your question, Valience.

For why Visual Studio could not find any project files - that's because there are only Eclipse ones.

In fact you can download Eclipse+CDT, mingw32, a truckload of libraries and after extensive hair-pulling sessions, it will even compile. I advise against that though.

lxnt · « **Reply #21 on:** October 18, 2011, 06:33:16 pm »

For reference, here's how launch and immediate quit look like on console:

Code: [Select]

lxnt@bigbox:~/00DFGL/dfa_linux$ ./df
textures::load(): data/art/Phoebus_16x16.png 256x256 16x16 16x16
textures::load(): data/art/Phoebus_16x16.png 256x256 16x16 16x16
Loading bindings from data/init/interface.txt
textures::load(): data/art/mouse.png 32x32
set_mode(): requesting vsync=0 and singlebuf=0.
set_mode(): SDL_GL_SWAP_CONTROL: 1
set_mode(): SDL_GL_ACCELERATED_VISUAL: 1
set_mode(): SDL_GL_DOUBLEBUFFER: 1
set_mode(): SDL_FULLSCREEN: 0
Using embedded vertex shader code.
Using embedded fragment shader code.
GL_COMPILE_STATUS: true
GL_COMPILE_STATUS: true
GL_LINK_STATUS: true
GL_VALIDATE_STATUS: true
makeansitex(): 2.
handed off cats with 0 tiles. (0x0).
Resetting textures
texdumpst::init(): allocating 368x368 limit=529 (16x16 cells)
handed off cats with 513 tiles. (23x23).
accepted font texture (name=1): 368x368px oa
reshape(): got grid 0x0 window -1x-1 texture_ready=1 stretch=1 snap=1
reshape(): final grid 80x25 window 1280x400 viewport 1280x400 Psz 16x16
makegrid(): 80x25
set_viewport(): got 1280x400 out of 1280x400
Returning input:
    8: STANDARDSCROLL_UP
    8: CURSOR_UP
    8: A_MOVE_N
Returning input:
    Enter: SELECT
    Enter: CLOSE_MEGA_ANNOUNCEMENT
    Enter: WORLD_PARAM_ENTER_VALUE
    Enter: SETUPGAME_SAVE_PROFILE_GO
    Enter: D_BURROWS_DEFINE
    Enter: D_MILITARY_ALERTS_SET
lxnt@bigbox:~/00DFGL/dfa_linux$

arclance · « **Reply #22 on:** October 18, 2011, 08:30:21 pm »

Quote from: lxnt on October 18, 2011, 06:20:54 pm

I'm using Eclipse+CDT to build it. Project files and stuff are supplied, though only debug build is configured.

I got it to build in Ubuntu 11.04 32bit but I had to add the path /usr/lib/i386-linux-gnu/glib-2.0/include and remove /usr/lib/glib-2.0/include to get glibconfig.h due to the install location changing.
I get the same results as below for your current version with the version I built.

Quote from: lxnt on October 18, 2011, 06:20:54 pm

There is no sense to compile a 64bit version of it, because there's no 64bit version of game itself, or at least I never heard of it.

Your version is built against the 32bit version of libGLEW so it does not work in 64bit Ubuntu 11.04 (may work in 11.10 because it has more mutiarch support).
You get following error.

Quote

./df
./libs/Dwarf_Fortress: error while loading shared libraries: libGLEW.so.1.5: wrong ELF class: ELFCLASS64

Putting the 32bit libGLEW.so.1.5 in df_linux/libs is not enough because this happens.

Spoiler (click to show/hide)

I did get a 64bit version to build in Ubuntu 11.04 64bit but it needs more changes to get it to talk to Dwarf Fortress because it it is 32bit.
My 64bit machine is much more powerful so I play Dwarf_Fortress on it.
I would like to get this working in 64bit because of that.

New version does not work in Ubuntu 11.04 32bit with a Nvidia GeForce 8600 GTS and the Nvidia drivers. It does this now.

Spoiler (click to show/hide)

I will try the laptop I was using before tomorrow and let you know what happens.
Edit: Laptop (32bit) does the exact same thing as the 32bit desktop.
Edit2: Figured out how to use eclipse added results.

Mike Mayday · « **Reply #23 on:** October 19, 2011, 05:02:34 am »

Quote from: lxnt on October 18, 2011, 06:29:18 pm

Fortunately, trying out Ubuntu nowadays is a question of a thumb drive and some downloading.

Wouldn't running the game from a thumb drive OS be much slower?

kingofthescots · « **Reply #24 on:** October 19, 2011, 02:21:35 pm »

Actually, the thumb drive probably reads faster then your regular hard drive does. So if DF reads a lot of stuff from your HDD, then in theory performance would be improved. Plus you could play anywhere just by toting around your thumb drive. Would make slow days at work much more interesting....

lxnt · « **Reply #25 on:** October 19, 2011, 06:22:13 pm »

I was digging into what those GL errors could have meant. To no avail.

They hint that your driver/card combo does not have enough vertex attribute array pointers available,
(GL_MAX_VERTEX_ATTRIBS value), but I would be very surprised if this is in fact so.

I counted what my shaders use of various GL resources and put some checking code in, which will at least print what there is and how much is actually needed.

Please try 20112011 version out, and post whatever it prints after set_mode() lines.

As for thumb drives - their speed varies wildly, but luckily DF does not read or write much while you play, so it should not slow down the game.

arclance · « **Reply #26 on:** October 19, 2011, 06:46:13 pm »

Quote from: lxnt on October 19, 2011, 06:22:13 pm

Please try 20112011 version out, and post whatever it prints after set_mode() lines.

Heres what I get on the 32bit computer.

Spoiler (click to show/hide)

And the 64bit computer with 32bit libGLEW.so.1.5 in df_linux/libs (Nvidia GT 240).

Spoiler (click to show/hide)

Here is what the Dwarf Fortress window looks like

Spoiler (click to show/hide)

lxnt · « **Reply #27 on:** October 19, 2011, 07:31:24 pm »

Ah. Now I see. GL errors are due to Nvidia GLSL compiler being better at optimization than Mesa one.

Ok. Try this: get shaders' source from git, put paths to them into init.txt:

Code: [Select]

[VERTEX_SHADER:somewhere/some.file] 
[FRAGMENT_SHADER:somewhere/another.file]

First, change this line in fragment.shader:

Code: [Select]

        //vec4 c_color = mix(crea_color*cf_color, cb_color, 1-crea_color.a);

to

Code: [Select]

        vec4 crea_color = mix(crea_color*cf_color, cb_color, 1-crea_color.a);

This will mess up creature colors, but should get rid of GL errors.

Tiles showing as single pixels may or may not be related to this issue.
If the above does not help, change the last line in the vertex shader from

Code: [Select]

    
gl_PointSize = pszar.z;

to

Code: [Select]

    
gl_PointSize = 16;

This will kill zoom, but at least would help diagnose the problem.

Edit: And many, many thanks for testing and feedback.

lxnt · « **Reply #28 on:** October 19, 2011, 07:45:17 pm »

Okay, scratch that. I pushed the fix that should help and also uploaded new binary.

arclance · « **Reply #29 on:** October 19, 2011, 08:32:26 pm »

Quote from: lxnt on October 19, 2011, 07:45:17 pm

Okay, scratch that. I pushed the fix that should help and also uploaded new binary.

It works (mostly) both on the 32bit computer and the 64bit computer with 32bit libGLEW.so.1.5 in df_linux/libs.
I can see what you mean by resizing not working correctly, seems very random right now.
Notice the green line in this screenshot that is left when maximizing the window. (no fullscreen Dwarf Fortress uses both of my monitors for some reason).

Spoiler (click to show/hide)

Also unit graphics do not appear to be working correctly.
Here are some screenshots comparing SHADER mode with VBO mode. SHADER is first VBO second.

Spoiler (click to show/hide)

And then there is this thing with the cursor (X) that sometimes happens when you move over units.

Spoiler (click to show/hide)

Notice the three yellow X's right next to each other the right two are dwarves, the Mayor who is in jail and the liason who is trying to meet with him.

I tried building the new verison myself to see if that made any difference but I get this when I run Dwarf Fortress.

Code: [Select]

./df
./libs/Dwarf_Fortress: symbol lookup error: /df_linux/libs/libgraphics.so: undefined symbol: _binary____vertex_shader_end

News:

Author Topic: [PRINT_MODE:SHADER] (Read 85898 times)

arclance

Re: [PRINT_MODE:SHADER]

Warmist

Re: [PRINT_MODE:SHADER]

Mike Mayday

Re: [PRINT_MODE:SHADER]

Valience

Re: [PRINT_MODE:SHADER]

lxnt

Re: [PRINT_MODE:SHADER]

lxnt

Re: [PRINT_MODE:SHADER]

lxnt

Re: [PRINT_MODE:SHADER]

arclance

Re: [PRINT_MODE:SHADER]

Mike Mayday

Re: [PRINT_MODE:SHADER]

kingofthescots

Re: [PRINT_MODE:SHADER]

lxnt

Re: [PRINT_MODE:SHADER]

arclance

Re: [PRINT_MODE:SHADER]

lxnt

Re: [PRINT_MODE:SHADER]

lxnt

Re: [PRINT_MODE:SHADER]

arclance

Re: [PRINT_MODE:SHADER]