Bay 12 Games Forum

Dwarf Fortress => DF Modding => Topic started by: lxnt on October 09, 2011, 07:24:19 pm

Title: [PRINT_MODE:SHADER]
Post by: lxnt on October 09, 2011, 07:24:19 pm

[ README (https://github.com/lxnt/rendumper#this-is-df-modular-backend) | Download (http://sourceforge.net/projects/tolisnitem/files/) | Source code (https://github.com/lxnt/rendumper)  ]
 

---

26 June 2013.

About half a year ago this project morphed from simply patching up graphics code to an all-out attempt to bring graphics, and all other supporting code up to date.

As of today, it reached feature-parity with the old code, some amount of bugs present nonwithstanding.

For more information please see the README link above, and read the tail of this topic.

Spoiler: Older message text (click to show/hide)

11 November 2011.
The so-called "stable" version has been uploaded. It fixes a couple of bugs that might have caused intermittent crashes. It also is compiled with optimization and w/o debug (thus the size).

This is a direct replacement of any other renderer - it draws stuff identically or as close to as is sensible. It is also faster, easily beating 500 graphic FPS on pause (on my r4850), and not biting off much time out of game engine when in action - but make sure you cap G_FPS at something low and enable SINGLE_BUFFER.

23 October 2011.

Creatures are drawn exactly as in other GL renderers. For now.

22 October 2011.

Zoom works at last. On to getting creatures drawn the right way.

17 October 2011.

Added some docs in form of an README file (https://github.com/lxnt/-PRINT_MODE-SHADER-/blob/89e5ad85524a9be95e9158587fd05ae100d8e743/README.glsl).

Windows builder and testing are needed.

16 October 2011.

Source code is now hosted at github: here (https://github.com/lxnt/-PRINT_MODE-SHADER-)

Another interim release.
Highlights:
 support for non-square graphics and for stretch when zooming.
 shader source code embedded into the library to simplify deployment
 new configuration tokens:

Code: [Select]

[DUMP_SCREEN:0]
[TEXTURE_PARAM:NEAREST]
[VERTEX_SHADER:data/vertex.shader]

[FRAGMENT_SHADER:data/fragment.shader]

DUMP_SCREEN controls screen dumping for consumption by the testbed. 0 - disabled, >0 - dump screen every this frame.
TEXTURE_PARAM - now honored by the renderer
VERTEX_SHADER/FRAGMENT_SHADER - override embedded shaders with ones loaded from given files.

Python testbed non-functional at the moment, as the screen dump format changed.

http://dffd.wimbli.com/file.php?id=5044 (http://dffd.wimbli.com/file.php?id=5044)



To introduce myself to glsl and also get rid of graphics-related slowdowns, I implemented PRINT_MODE:SHADER. Almost.

The goal is to offload entire render to the GPU. As such, my code does absolutely nothing with screen[] and screentexpos[] arrays apart from uploading them as vertex buffer objects.  Everything gets done on the videocard.

This is very much a work in progress, so bugs are there and features are not. Resize window at your own risk.
 Requirements are: GLSL 1.20, which implies OpenGL2.0+.

Code works for me at ubuntu maverick 32bit + radeon 4850
OpenGL renderer string: Mesa DRI R600 (RV770 9440) 20090101 x86/MMX+/3DNow!+/SSE2 TCL DRI2
Should work on any 2xxx/3xxx/4xxx radeon with open-source drivers. No idea re windows or nvidia.

Limitations: 16x16 graphics only,  resize messes things up, creatures are not drawn correctly. Phoebus graphic/tile set is recommended.

Archive contents: eclipse project. Debug/libprint_shader.so - replace your libs/graphics.so to try it out.
vertex.shader and fragment.shader go into data/ directory.

t3.py - python testbed. works on screen and texture dumps (dump code disabled right now).
An example dump is included, launch like: python t3.py screendump 10

Title: Re: [PRINT_MODE:SHADER]
Post by: NobodyPro on October 09, 2011, 09:54:17 pm

Forgive me if I'm a little very suspicious what with your one post and gibberish username. In layman's terms, what is this and how have you done it?

Title: Re: [PRINT_MODE:SHADER]
Post by: magistrate101 on October 09, 2011, 10:17:39 pm

Quote from: NobodyPro on October 09, 2011, 09:54:17 pm

Forgive me if I'm a little very suspicious what with your one post and gibberish username. In layman's terms, what is this and how have you done it?

To answer the first half of your laymen's terms question, it is a program/script that uses a different renderer than regular df, and thus offloads graphics-related computations entirely onto the GPU (From what I can get out of it, anyways)
I have no idea HOW, as I am not a coder.
edit:

Spoiler: A comment he left in the code (click to show/hide)

Code: [Select]

"""
    okay. we in fact twist vertex coordinates to correspond to backwards ordering of the
    screen, screentexpos and friends. uploaded on resize.
    then we just upload screen, screentexpos and friends as attr arrays. Phew.

    upload font as texture. texcoords from screen[] values computed as below.
    upload ascii color conversion table as texture.
    upload all graphics as one texture.

    upload mapping from screentexpos[] values to texcoords as vec4 texture:
     gvec = (offsettop, offsetleft, offsetbottom, offsetright), normalized,
     something like
     

    somehow upload all graphics as textures, and keep'em somewhat organized.
    most practical way is to assemble them into xlarge POT textures. and bind them all.
    GL_RGBA32F or non-normalized GL_RGBA16U or two GL_RGBA8U textures, one with top/left,
    other with right/bottom


"""

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on October 10, 2011, 08:49:19 pm

More development ensued.

Zoom/resize fixed to more-or-less playable state.
I made an attempt to save screen[] contents from being overwritten with creatures, so that in graphics mode they can be drawn on top of floors, grass, etc. Not guaranteed to work in all cases. It would be much better if the core game did not overwrite screen[] array with characters for creatures if in graphics mode and there's something to put into screen_texpos[].
Putting 'action animation' code into yet another layer would be even better.

As for what this thread is about: yes, it's about making graphics snappy, especially when zoomed out.

As for how I did it - I used OpenGL point sprites instead of two triangles per tile, and I moved whatever graphic-related calculations were done on CPU to the GPU. These were - calculating offsets (in the single texture image) for each tile and uploading each tile individually (with about 3700 tiles that was slow) - on each resize. This particularly slowed down loading a saved game.

Calculating and uploading colors and texture coordinates for each tile, or, alternatively, finding out which tiles changed. Uploading triangle data - 6x number of tiles. Both done to draw each frame. Either way, when zoomed out to 256x256 tile screen this was way too slow too.

Result: zoom in/out feels much better. Also you can see barrels behind dwarves that drink from them.


Question for developers: what is textures::clone_texture() for?

Title: Re: [PRINT_MODE:SHADER]
Post by: magistrate101 on October 10, 2011, 10:44:30 pm

Code: [Select]

Traceback (most recent call last):
  File "C:\df_opengl\t3.py", line 422, in <module>
    loader = FrameLoader(sys.argv[1])
IndexError: list index out of rangewhat?

edit: using windows8 (df works fine on it, and so does python), using python 2.6.6.
edit2: I don't get a single hit offa google for your question on "textures::clone_texture()"  ???

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on October 11, 2011, 06:38:38 am

The error you encountered means that it expected an argument (three actually) but did not get one.

usage: ./t3.py <screendump-filename> <desired-fps> <start_frame>

It also expects texdump0002.png and shaders in the current directory.
A screendump and texdump are supplied, erm, were supplied in previous version (forgot it this time), so get it and try running it like :

./t3.py screendump 10 0

screendump was generated by dumping every 4th or 5th frame, so playback is jerky.

Controls: mouse wheel - zoom, left mouse button and space - pause/unpause, right mouse button drag - panning, esc - quit


textures::clone_texture() is an internal df function that gets called from core game, so the question was directed more at people familiar with code we don't get to see, i.e. Toady.

Title: Re: [PRINT_MODE:SHADER]
Post by: magistrate101 on October 11, 2011, 04:37:45 pm

Quote from: lxnt on October 11, 2011, 06:38:38 am

The error you encountered means that it expected an argument (three actually) but did not get one.

usage: ./t3.py <screendump-filename> <desired-fps> <start_frame>

It also expects texdump0002.png and shaders in the current directory.
A screendump and texdump are supplied, erm, were supplied in previous version (forgot it this time), so get it and try running it like :

./t3.py screendump 10 0

screendump was generated by dumping every 4th or 5th frame, so playback is jerky.

Controls: mouse wheel - zoom, left mouse button and space - pause/unpause, right mouse button drag - panning, esc - quit


textures::clone_texture() is an internal df function that gets called from core game, so the question was directed more at people familiar with code we don't get to see, i.e. Toady.

Thanks, and the information is nice to know, I suppose :P

edit: zooming crashes it, and all I see is grey with white and black dots :\

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on October 12, 2011, 06:46:29 am

Testbed's code somewhat lagged behind c++ code, so crashes are not that surprising.

I'll be releasing a version later this week that would have all functionality standard print_mode has, both in c++ and python code. Then will be time for thorough testing.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on October 16, 2011, 09:21:50 am

bump. see top post.

Title: Re: [PRINT_MODE:SHADER]
Post by: Mike Mayday on October 16, 2011, 02:32:27 pm

This is quite interesting.
Would you be able to make it so that zooming only affects the world view and not the menus?

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on October 16, 2011, 05:39:05 pm

Quote from: Mike Mayday on October 16, 2011, 02:32:27 pm

Would you be able to make it so that zooming only affects the world view and not the menus?

I'm not sure if it's impossible. Seems like the entire interface is drawn through the code in g_src/interface.cpp,
and if it's in fact so, this is what I'll be doing after I fix zoom/resize.

Title: Re: [PRINT_MODE:SHADER]
Post by: Mike Mayday on October 16, 2011, 05:41:33 pm

Oh my godddd the implications of this... (http://mayday.w.staszic.waw.pl/gobticons3/beautiful.gif)

EDIT: just to be sure: my dream is for the interface to be displayed at 16x16 px (can be downscaled 32x32px, I don't mind) while the world view would be displayed at 32x32px (and using 32x32px icons, not upscaled 16x16 ones).

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on October 17, 2011, 07:53:51 am

Quote from: Mike Mayday on October 16, 2011, 05:41:33 pm

EDIT: just to be sure: my dream is for the interface to be displayed at 16x16 px (can be downscaled 32x32px, I don't mind) while the world view would be displayed at 32x32px (and using 32x32px icons, not upscaled 16x16 ones).

I have separating map and interface zoom and fonts in plans - see the readme file for what exactly I do plan.

However, I'm no artist, someone would have to actually draw tile/graphics sets in resolutions you want.

Title: Re: [PRINT_MODE:SHADER]
Post by: kingofthescots on October 17, 2011, 09:13:56 am

I hope someone compiles this for windows soon. This looks like quite an interesting development, and I'd like to see it in action.

Title: Re: [PRINT_MODE:SHADER]
Post by: Mike Mayday on October 17, 2011, 10:33:22 am

Quote from: lxnt on October 17, 2011, 07:53:51 am

Quote from: Mike Mayday on October 16, 2011, 05:41:33 pm

EDIT: just to be sure: my dream is for the interface to be displayed at 16x16 px (can be downscaled 32x32px, I don't mind) while the world view would be displayed at 32x32px (and using 32x32px icons, not upscaled 16x16 ones).

I have separating map and interface zoom and fonts in plans - see the readme file for what exactly I do plan.
However, I'm no artist, someone would have to actually draw tile/graphics sets in resolutions you want.

That would be yours truly.

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance 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.

Title: Re: [PRINT_MODE:SHADER]
Post by: Warmist 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.

Title: Re: [PRINT_MODE:SHADER]
Post by: Mike Mayday on October 17, 2011, 06:12:07 pm

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

Title: Re: [PRINT_MODE:SHADER]
Post by: Valience 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.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt 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 (http://www.eclipse.org/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.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt 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.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt 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$


Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on October 18, 2011, 08:30:21 pm

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

I'm using Eclipse+CDT (http://www.eclipse.org/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)

./df
textures::load(): data/art/Phoebus_20x20.png 320x320 16x16 20x20
textures::load(): data/art/Phoebus_20x20.png 320x320 16x16 20x20
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
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
GL_INVALID_VALUE at ../renderer_glsl.hpp:358
GL_INVALID_VALUE at ../renderer_glsl.hpp:360
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=0 snap=0
reshape(): final grid 80x25 window 1600x500 viewport 1600x500 Psz 20x20
makegrid(): 80x25
set_viewport(): got 1600x500 out of 1600x500
GL_INVALID_VALUE at ../renderer_glsl.hpp:442
GL_INVALID_VALUE at ../renderer_glsl.hpp:447
GL_INVALID_VALUE at ../renderer_glsl.hpp:442
GL_INVALID_VALUE at ../renderer_glsl.hpp:447
GL_INVALID_VALUE at ../renderer_glsl.hpp:442
GL_INVALID_VALUE at ../renderer_glsl.hpp:447
GL_INVALID_VALUE at ../renderer_glsl.hpp:442
GL_INVALID_VALUE at ../renderer_glsl.hpp:447
GL_INVALID_VALUE at ../renderer_glsl.hpp:442
GL_INVALID_VALUE at ../renderer_glsl.hpp:447
GL_INVALID_VALUE at ../renderer_glsl.hpp:442
GL_INVALID_VALUE at ../renderer_glsl.hpp:447
GL_INVALID_VALUE at ../renderer_glsl.hpp:442
GL_INVALID_VALUE at ../renderer_glsl.hpp:447
GL_INVALID_VALUE at ../renderer_glsl.hpp:442
GL_INVALID_VALUE at ../renderer_glsl.hpp:447
GL_INVALID_VALUE at ../renderer_glsl.hpp:442
GL_INVALID_VALUE at ../renderer_glsl.hpp:447
GL_INVALID_VALUE at ../renderer_glsl.hpp:442
GL_INVALID_VALUE at ../renderer_glsl.hpp:447
GL_INVALID_VALUE at ../renderer_glsl.hpp:442
GL_INVALID_VALUE at ../renderer_glsl.hpp:447
GL_INVALID_VALUE at ../renderer_glsl.hpp:442
GL_INVALID_VALUE at ../renderer_glsl.hpp:447
GL_INVALID_VALUE at ../renderer_glsl.hpp:442
GL_INVALID_VALUE at ../renderer_glsl.hpp:447
GL_INVALID_VALUE at ../renderer_glsl.hpp:442
GL_INVALID_VALUE at ../renderer_glsl.hpp:447
GL_INVALID_VALUE at ../renderer_glsl.hpp:442
GL_INVALID_VALUE at ../renderer_glsl.hpp:447
GL_INVALID_VALUE at ../renderer_glsl.hpp:442
GL_INVALID_VALUE at ../renderer_glsl.hpp:447
GL_INVALID_VALUE at ../renderer_glsl.hpp:442
GL_INVALID_VALUE at ../renderer_glsl.hpp:447
GL_INVALID_VALUE at ../renderer_glsl.hpp:442
GL_INVALID_VALUE at ../renderer_glsl.hpp:447
GL_INVALID_VALUE at ../renderer_glsl.hpp:442
GL_INVALID_VALUE at ../renderer_glsl.hpp:447
GL_INVALID_VALUE at ../renderer_glsl.hpp:442
GL_INVALID_VALUE at ../renderer_glsl.hpp:447
GL_INVALID_VALUE at ../renderer_glsl.hpp:442
GL_INVALID_VALUE at ../renderer_glsl.hpp:447
GL_INVALID_VALUE at ../renderer_glsl.hpp:442
GL_INVALID_VALUE at ../renderer_glsl.hpp:447
GL_INVALID_VALUE at ../renderer_glsl.hpp:442
GL_INVALID_VALUE at ../renderer_glsl.hpp:447
GL_INVALID_VALUE at ../renderer_glsl.hpp:442
GL_INVALID_VALUE at ../renderer_glsl.hpp:447
GL_INVALID_VALUE at ../renderer_glsl.hpp:442
GL_INVALID_VALUE at ../renderer_glsl.hpp:447
GL_INVALID_VALUE at ../renderer_glsl.hpp:442
GL_INVALID_VALUE at ../renderer_glsl.hpp:447
---continues until killed---

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)

./df
textures::load(): data/art/Phoebus_20x20.png 320x320 16x16 20x20
textures::load(): data/art/Phoebus_20x20.png 320x320 16x16 20x20
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
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
GL_INVALID_VALUE at ../renderer_glsl.hpp:358
GL_INVALID_VALUE at ../renderer_glsl.hpp:360
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=0 snap=0
reshape(): final grid 80x25 window 1600x500 viewport 1600x500 Psz 20x20
makegrid(): 80x25
set_viewport(): got 1600x500 out of 1600x500
GL_INVALID_VALUE at ../renderer_glsl.hpp:442
GL_INVALID_VALUE at ../renderer_glsl.hpp:447
GL_INVALID_VALUE at ../renderer_glsl.hpp:442
GL_INVALID_VALUE at ../renderer_glsl.hpp:447
GL_INVALID_VALUE at ../renderer_glsl.hpp:442
GL_INVALID_VALUE at ../renderer_glsl.hpp:447
GL_INVALID_VALUE at ../renderer_glsl.hpp:442
GL_INVALID_VALUE at ../renderer_glsl.hpp:447
GL_INVALID_VALUE at ../renderer_glsl.hpp:442
GL_INVALID_VALUE at ../renderer_glsl.hpp:447
GL_INVALID_VALUE at ../renderer_glsl.hpp:442
GL_INVALID_VALUE at ../renderer_glsl.hpp:447
GL_INVALID_VALUE at ../renderer_glsl.hpp:442
GL_INVALID_VALUE at ../renderer_glsl.hpp:447
GL_INVALID_VALUE at ../renderer_glsl.hpp:442
GL_INVALID_VALUE at ../renderer_glsl.hpp:447
GL_INVALID_VALUE at ../renderer_glsl.hpp:442
GL_INVALID_VALUE at ../renderer_glsl.hpp:447
GL_INVALID_VALUE at ../renderer_glsl.hpp:442
GL_INVALID_VALUE at ../renderer_glsl.hpp:447
GL_INVALID_VALUE at ../renderer_glsl.hpp:442
GL_INVALID_VALUE at ../renderer_glsl.hpp:447
GL_INVALID_VALUE at ../renderer_glsl.hpp:442
GL_INVALID_VALUE at ../renderer_glsl.hpp:447
GL_INVALID_VALUE at ../renderer_glsl.hpp:442
GL_INVALID_VALUE at ../renderer_glsl.hpp:447
GL_INVALID_VALUE at ../renderer_glsl.hpp:442
GL_INVALID_VALUE at ../renderer_glsl.hpp:447
GL_INVALID_VALUE at ../renderer_glsl.hpp:442
GL_INVALID_VALUE at ../renderer_glsl.hpp:447
GL_INVALID_VALUE at ../renderer_glsl.hpp:442
GL_INVALID_VALUE at ../renderer_glsl.hpp:447
---continues until killed---

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.

Title: Re: [PRINT_MODE:SHADER]
Post by: Mike Mayday 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?

Title: Re: [PRINT_MODE:SHADER]
Post by: kingofthescots 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....

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt 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.

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance 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)

GL_MAX_VERTEX_ATTRIBS=16, needed=7
GL_MAX_VERTEX_UNIFORM_COMPONENTS=4096, needed=7
GL_MAX_FRAGMENT_UNIFORM_COMPONENTS=2048, needed=6
GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS=32, needed=1
GL_MAX_TEXTURE_IMAGE_UNITS=32, needed=1
GL_MAX_VARYING_FLOATS=60, needed=20
GL_MAX_TEXTURE_COORDS=8, needed=7
GL_POINT_SIZE_MIN=0, needed=4
** GL_POINT_SIZE_MAX=63, needed=96
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
GL_INVALID_VALUE at ../renderer_glsl.hpp:459
GL_INVALID_VALUE at ../renderer_glsl.hpp:461
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=0 snap=0
reshape(): final grid 80x25 window 1600x500 viewport 1600x500 Psz 20x20
gps_allocate(80, 25)
set_viewport(): got 1600x500 out of 1600x500
GL_INVALID_VALUE at ../renderer_glsl.hpp:560
GL_INVALID_VALUE at ../renderer_glsl.hpp:562

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

Spoiler (click to show/hide)

GL_MAX_VERTEX_ATTRIBS=16, needed=7
GL_MAX_VERTEX_UNIFORM_COMPONENTS=4096, needed=7
GL_MAX_FRAGMENT_UNIFORM_COMPONENTS=2048, needed=6
GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS=32, needed=1
GL_MAX_TEXTURE_IMAGE_UNITS=32, needed=1
GL_MAX_VARYING_FLOATS=60, needed=20
GL_MAX_TEXTURE_COORDS=8, needed=7
GL_POINT_SIZE_MIN=0, needed=4
** GL_POINT_SIZE_MAX=63, needed=96
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
GL_INVALID_VALUE at ../renderer_glsl.hpp:459
GL_INVALID_VALUE at ../renderer_glsl.hpp:461
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=0 snap=0
reshape(): final grid 80x25 window 1600x500 viewport 1600x500 Psz 20x20
gps_allocate(80, 25)
set_viewport(): got 1600x500 out of 1600x500
GL_INVALID_VALUE at ../renderer_glsl.hpp:560
GL_INVALID_VALUE at ../renderer_glsl.hpp:562

Here is what the Dwarf Fortress window looks like

Spoiler (click to show/hide)

(http://img.ie/36c4b.png)

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt 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.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on October 19, 2011, 07:45:17 pm

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

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance 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)

(http://img.ie/87363.png)

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)

(http://img.ie/294c2.png)
(http://img.ie/8cb16.png)

Spoiler (click to show/hide)

(http://img.ie/b2a9b.png)
(http://img.ie/7ac87.png)

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

Spoiler (click to show/hide)

(http://img.ie/016a5.png)

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


Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on October 20, 2011, 05:29:08 am

Quote from: arclance on October 19, 2011, 08:32:26 pm

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

The green line is a part of background, which is intentionally drawn green to see how much of the window is used.

Twin screen maximization is due to differences between nvidia and open-source drivers, I'll read up how people cope with this.

Quote from: arclance on October 19, 2011, 08:32:26 pm

Also unit graphics do not appear to be working correctly.

This is expected due to the kludge I put yesterday into the fragment shader. Temporary.

Quote from: arclance on October 19, 2011, 08:32:26 pm

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

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.

This must be new underlay code not behaving correctly. Also expected, since I spent yesterday rewriting stuff to get it to draw something at all on your system.

Quote from: arclance on October 19, 2011, 08:32:26 pm

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


Hm. Might be because objcopy lacks some architecture parameter. Check out build settings - artifacts  - pre-build step, I think it's there.

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on October 20, 2011, 11:37:27 am

Quote from: lxnt on October 20, 2011, 05:29:08 am

Quote from: arclance on October 19, 2011, 08:32:26 pm

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


Hm. Might be because objcopy lacks some architecture parameter. Check out build settings - artifacts  - pre-build step, I think it's there.

Right now this is what it looks like.

Code: [Select]

objcopy -I binary -B i386 -O elf32-i386  ../vertex.shader vs.o ; objcopy -I binary -B i386 -O elf32-i386  ../fragment.shader fs.o
It is the same as when I built the old version and that ran with the glsl errors and did not have this error.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on October 21, 2011, 07:47:33 pm

Quote from: arclance on October 20, 2011, 11:37:27 am

Right now this is what it looks like.

Code: [Select]

objcopy -I binary -B i386 -O elf32-i386  ../vertex.shader vs.o ; objcopy -I binary -B i386 -O elf32-i386  ../fragment.shader fs.o
It is the same as when I built the old version and that ran with the glsl errors and did not have this error.

This stuff is flaky at best  :(

I upgraded my system to Natty 64bit, and made it compile and run my code.

See https://github.com/lxnt/-PRINT_MODE-SHADER-/blob/master/README.glsl (https://github.com/lxnt/-PRINT_MODE-SHADER-/blob/master/README.glsl)

Problems with those symbols may be related to order in which vs.o and fs.o end up on linker command line. Or they might depend on phase of the moon. I put some macros in code to make tweaking this easier. About all I could do. It works for me at least.

Sadly, no functional enhancements yet.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on October 22, 2011, 12:03:48 pm

Next milestone reached : zoom now works acceptably. Please test it.

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on October 22, 2011, 09:07:33 pm

Quote from: lxnt on October 22, 2011, 12:03:48 pm

Next milestone reached : zoom now works acceptably. Please test it.

Yes the zoom works much better now.

As far as building in Ubuntu 11.04 64bit I ran into a problem in this part of your instructions.

Quote from: README.glsl

dpkg-deb -x libglib2.0-0_2.28.6-0ubuntu1_i386.deb glib32

and put the glibconfig.h from glib32 somewhere. Then point Eclipse
(project->properties->C/C++Build->Settings->GCC C++ Compiler->Includes)
there.

Here is the full console output of the build.  Maybe that will help.

There is no file glibconfig.h found in libglib2.0-0_2.28.6-0ubuntu1_i386.deb are you sure this is where you got it from?
Are you sure this file is not generated for your system when the package is installed (not uncommon for a config file)?

No improvement in building in Ubuntu 11.04 32bit.
I still get this error when I use the result.

Code: [Select]

./df
./libs/Dwarf_Fortress: symbol lookup error: ~/Dwarf_Fortress/Test_Fortress/gputest/df_linux/libs/libgraphics.so: undefined symbol: _binary____vertex_shader_end
Here is the full console output from the build in eclipse.  Maybe that will help you identify the problem.
http://pastebin.com/4c4LKm07

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on October 23, 2011, 05:01:37 am

Quote from: arclance on October 22, 2011, 09:07:33 pm

As far as building in Ubuntu 11.04 64bit I ran into a problem in this part of your instructions.

Quote from: README.glsl

dpkg-deb -x libglib2.0-0_2.28.6-0ubuntu1_i386.deb glib32

and put the glibconfig.h from glib32 somewhere. Then point Eclipse
(project->properties->C/C++Build->Settings->GCC C++ Compiler->Includes)
there.

There is no file glibconfig.h found in libglib2.0-0_2.28.6-0ubuntu1_i386.deb are you sure this is where you got it from?

I put the wrong package name there. The one that contains glibconfig.h is libglib2.0-dev_2.28.6-0ubuntu1_i386.deb.

Quote from: arclance on October 22, 2011, 09:07:33 pm

No improvement in building in Ubuntu 11.04 32bit.
I still get this error when I use the result.

Code: [Select]

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


I'm getting rid of objcopy right now.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on October 23, 2011, 10:29:41 am

New version uploaded.

Objcopy is no more. Hopefully this will avoid problems with _binary_crap missing.

I turned off the tile-under-creature tracking for the moment, so it should draw map exactly as PRINT_MODE:STANDARD does, only faster.

I implemented embedded shader-sets. There are two now, 'standard' and 'cbr_is_bold'. The difference is in the interpretation of screentexpos_cbr  array.

The standard one behaves as all other renderers (maybe except for the TEXT one) do: it interprets values from this array as background colors for the creature.
(see renderer::screen_to_texid(), enabler.cpp:45)

The other one behaves as the previous attempt on shader renderer does: it takes cbr for a bold/bright bit for the foreground color from the screentexpos_cf array.
(see data/shader.vs:42 and data/shader.vs:48)

I don't know enough of DF graphics and coloring to make a decision on which is the right way. From what I've seen in creature draw data dumps (see README for an option that turns this on),  cbr is always either 0 or 1, so I tend to think that it's a bug in standard renderers. Opinions?

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on October 23, 2011, 12:10:54 pm

Quote from: lxnt on October 23, 2011, 10:29:41 am

New version uploaded.

Objcopy is no more. Hopefully this will avoid problems with _binary_crap missing.

I turned off the tile-under-creature tracking for the moment, so it should draw map exactly as PRINT_MODE:STANDARD does, only faster.

It now builds correctly in Ubuntu 64bit it seems much smoother than the built in renderers.  Here is a screenshot using 20x20 pixel tiles.

Spoiler (click to show/hide)

(http://img.ie/b14bc.png)

You need to update the 32bit build configuration to match the 64bit.  I had to change the prebuild steps to match the 64bit ones.
The unit graphics do not respect their correct tile size if they are not 16x16 pixels when built in this way in 32bit Ubuntu 11.04.
It is using the 16x16 square starting from the top left corner and not the whole 20x20 tile for creature graphics and then resizing that to 20x20 pixels in this screenshot.
Never mind I somehow got 24x24 creature graphics in by mistake when I replaced the 16x16 I was testing with before.  I updated the screen shot with the correct graphics installed.

Spoiler (click to show/hide)

(http://img.ie/57756.png)

Quote from: lxnt on October 23, 2011, 10:29:41 am

I implemented embedded shader-sets. There are two now, 'standard' and 'cbr_is_bold'. The difference is in the interpretation of screentexpos_cbr  array.

The standard one behaves as all other renderers (maybe except for the TEXT one) do: it interprets values from this array as background colors for the creature.
(see renderer::screen_to_texid(), enabler.cpp:45)

The other one behaves as the previous attempt on shader renderer does: it takes cbr for a bold/bright bit for the foreground color from the screentexpos_cf array.
(see data/shader.vs:42 and data/shader.vs:48)

I don't know enough of DF graphics and coloring to make a decision on which is the right way. From what I've seen in creature draw data dumps (see README for an option that turns this on),  cbr is always either 0 or 1, so I tend to think that it's a bug in standard renderers. Opinions?

I tried both shaders and they both work.  Here is a screenshot using cbr_is_bold.

Spoiler (click to show/hide)

(http://img.ie/986c6.png)

This page on the wiki about colors (http://df.magmawiki.com/index.php/Color) says

Quote

Colors are primarily defined using the [COLOR:x:y:z] or [DISPLAY_COLOR:x:y:z] tokens. The three arguments are:

    Foreground color [0-7]
    Background color [0-7]
    Brightness of the foreground color [0 or 1]

The brightness of the background color is always 0.

I do not know what the source for this is though.  I would read the whole page it goes into more detail than that.
cbr_is_bold sounds like the right way to me.
It is compatible with the way standard works as far as the raws are concerned but allows for more options if they are needed or desired. 
I haven't seen anything that uses something other than a cbr of 0 or 1 in the raws when I was modding so that may be why only you only see those numbers when you dump the creature data.

I did a little testing on the effect of changing cbr values in a mod I am working on.
I changed the cbr values of the left half of one of my custom workshops.
Here is the unchanged values with all colors being in the form x:y:0 [SHADER_SET:cbr_is_bold].

Spoiler (click to show/hide)

(http://img.ie/15b50.png)

Here is the same workshop with the colors in the left half of the workshop being in the form x:y:1 using [SHADER_SET:standard].

Spoiler (click to show/hide)

(http://img.ie/6414b.png)

Here is the same workshop with the colors in the left half of the workshop being in the form x:y:1 using [SHADER_SET:cbr_is_bold].

Spoiler (click to show/hide)

(http://img.ie/6026b.png)

Higher cbr values than 1 produced the same result as 1.
The only difference I see is that your cbr_is_bold shader seems to produce a sharper image than standard does.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on October 23, 2011, 05:34:56 pm

Many thanks for testing. 32bit build target updated and pushed to the github.

Support for variable-size tile graphics on the same map requires quite a lot of modifications, which will take some time.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on October 27, 2011, 05:50:34 pm

This variable tile size business is taking too long. I'm sure I'll make it work, but it may take another week.

In the meanwhile, make sure your font (tileset) and all you graphics sets are of same tile size. Current version just takes whatever size the font is, and then crops anything larger, and leaves transparent margins on whatever tiles are smaller.

Title: Re: [PRINT_MODE:SHADER]
Post by: Mike Mayday on October 27, 2011, 06:07:22 pm

Did I read that right that you were working on displaying the floor under the creature?
And if yes, are you planning to return to that?

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on October 27, 2011, 06:19:36 pm

Yep, once I sort out variable-size tiles/graphics, I'll return to perfecting track-tiles-under-creatures algorithm. If all else fails, I'll just move on to integrating dfhack-like functionality and fetch correct floor data this way.

Since creature background color is used to pass some information, and for this purpose, at least Phoebus graphics set has minumum alpha of at least 59%,
I think of using this color for some blinking/fading effect, freeing up space around the graphic itself to be transparent. Another problem is that tileset itself has translucent tiles - for blending with floor background color - , so I can't take a generic approach like clamping alpha to 0 if it's less than some threshold.

I think that for testing purposes some large-size tileset would be nice, combined with some simplistic graphics set, the only requirement of which is that creature graphics have lots of transparent space.

Also I'd like to track how the game replaces creatures with down-arrows, question marks and rotating backslashes to also convert this to something else.

Title: Re: [PRINT_MODE:SHADER]
Post by: Mike Mayday on October 27, 2011, 06:56:21 pm

Well, a large tileset could be just a matter of resizing a small tileset, right?

As for backgrounds... I'm not really sure I understand what the trouble is here, but here's some facts just in case:
If memory serves me right, on the map display, the background colour is only used to represent:
(for creatures)
Lying down on the ground (brown) - could be replaced with rotating the tile by 90degrees (though in that case it will be important to keep all creatures facing one direction so that they will all be rotated to be lying on their backs)
Flashing Blue background + grayscale tile (legendary) - with larger tiles- just making the dude flash to gray or maybe gold would be enough
Blue background + colours shifted to blue (underwater) -  same as above, this will work very well with the actual tile rendered.

(for items): basically the colour depicts a puddle the item is lying in. Also irrelevant if the actual tile is depicted.
(and for walls): the fact that it's a wall :P  (this is circumvented in a "graphic" tileset, while not a problem in an ASCII tileset).


As for the fun with transparency and blending... I, for one, am abandoning it, because so much new stuff is added that is using already used tiles, that making appropriate symbols is getting impossible. So the tileset I'm using now is http://mayday.w.staszic.waw.pl/~mayday/upload/4%20lxnt/mayday2.png
Only the wall tiles have been heavily edited to depict something more... blockish.

Anyway, there's a 21x21px set I've uploaded some time ago (this the maximum tileset size my display supports)- plenty of space in the creature graphics, as many of them are just reused 16px icons :)
http://mayday.w.staszic.waw.pl/~mayday/upload/21pxDFG.zip
the tileset in this one uses the "graphic" approach http://mayday.w.staszic.waw.pl/~mayday/upload/4%20lxnt/mayday21.png

Or maybe you mean that the problem is the semi-transparent backrounds in many tiles? If so, I can remove them for testing.

Regarding mood icons- would you be able to display some graphics partially outside of the tile? Like a comic thought baloon centered in one of the upper corners of the actual creature tile?

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on October 28, 2011, 06:44:27 pm

Quote from: lxnt on October 27, 2011, 06:19:36 pm

I think that for testing purposes some large-size tileset would be nice, combined with some simplistic graphics set, the only requirement of which is that creature graphics have lots of transparent space.

Quote from: Mike Mayday on October 27, 2011, 06:56:21 pm

Well, a large tileset could be just a matter of resizing a small tileset, right?

If you want to test different tileset sizes you can use my Tileset Resizer (http://www.bay12forums.com/smf/index.php?topic=87196.0) Octave functions to resize tilesets. 
If you need a way to quickly remove transparency from tilesets for testing you can remove them using GIMP by deleting the alpha channel in the colors tab and saving the file.
I also have a function to make a single color transparent (you can make a non transparent tileset transparent this way) and a function for batch processing of multiple tilesets.
This post (http://www.bay12forums.com/smf/index.php?topic=87196.msg2592247#msg2592247) shows the reason I made the transparency converter function (purple outline) if you are interested in a look at some of the results from an earlier version of the function. 
If you have an interest in those I can try and get the next version of Tileset Resizer out this weekend.
I can run up to a 45x45 tileset due to Nvidia twinview causing Dwarf Fortress to fullscreen over both of my monitors if you want to see what happens with a really big tileset.

Title: Re: [PRINT_MODE:SHADER]
Post by: Mike Mayday on October 29, 2011, 04:16:09 am

Or here's the 21px tileset with no background http://mayday.w.staszic.waw.pl/~mayday/upload/mayday21_noalpha.png
Sadly it's for the modified raws from this version: http://mayday.w.staszic.waw.pl/~mayday/upload/21pxDFG.zip

If you need anything specific drawn, please let me know.

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on October 29, 2011, 03:16:58 pm

I have found a strange bug you should know about.
PRINT_MODE:SHADER works for a few days (more than 2 less than 5) but then SHADER mode starts crashing with a Segmentation Fault.  Other modes (VBO, etc.) keep working.
Here is a backtrace of the crash.

Spoiler (click to show/hide)

./dfbacktrace
GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /media/Linux_Data/Dwarf_Fortress/Test_Fortress/printmodeshader/df_linux/libs/Dwarf_Fortress...(no debugging symbols found)...done.
Starting program: /media/Linux_Data/Dwarf_Fortress/Test_Fortress/printmodeshader/df_linux/libs/Dwarf_Fortress
[Thread debugging using libthread_db enabled]
[New Thread 0xf4ce3b70 (LWP 14561)]
[New Thread 0xf44e2b70 (LWP 14562)]
textures::load(): data/art/Phoebus_20x20.png 320x320 16x16 20x20
textures::load(): data/art/Phoebus_20x20.png 320x320 16x16 20x20
Loading bindings from data/init/interface.txt
textures::load(): data/art/mouse.png 32x32

Program received signal SIGSEGV, Segmentation fault.
0xf7b47b02 in renderer_glsl::set_mode (this=0x995db38, w=1600, h=500,
    fullscreen=false) at ../renderer_glsl.hpp:201
201   ../renderer_glsl.hpp: No such file or directory.
   in ../renderer_glsl.hpp
#0  0xf7b47b02 in renderer_glsl::set_mode (this=0x995db38, w=1600, h=500,
    fullscreen=false) at ../renderer_glsl.hpp:201
#1  0xf7b4db9b in renderer_glsl::renderer_glsl (this=0x995db38)
    at ../renderer_glsl.hpp:969
#2  0xf7b41a23 in enablerst::loop (this=0x8c3e600, cmdline=...)

This can be worked around by starting with a fresh vanilla Dwarf Fortress install and installing everything again.
Here is the startup output from a fresh install for comparison.

Spoiler (click to show/hide)

./dfbacktrace
GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /media/Linux_Data/Dwarf_Fortress/Test_Fortress/printmodeshader/test/df_linux/libs/Dwarf_Fortress...(no debugging symbols found)...done.
Starting program: /media/Linux_Data/Dwarf_Fortress/Test_Fortress/printmodeshader/test/df_linux/libs/Dwarf_Fortress
[Thread debugging using libthread_db enabled]
[New Thread 0xf4ce3b70 (LWP 470)]
[New Thread 0xf44e2b70 (LWP 471)]
textures::load(): data/art/Phoebus_20x20.png 320x320 16x16 20x20
textures::load(): data/art/Phoebus_20x20.png 320x320 16x16 20x20
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
set_mode(): SDL_FULLSCREEN: 0
GL_MAX_VERTEX_ATTRIBS=16, needed=7
GL_MAX_VERTEX_UNIFORM_COMPONENTS=4096, needed=7
GL_MAX_FRAGMENT_UNIFORM_COMPONENTS=2048, needed=6
GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS=32, needed=1
GL_MAX_TEXTURE_IMAGE_UNITS=32, needed=1
GL_MAX_VARYING_FLOATS=60, needed=20
GL_MAX_TEXTURE_COORDS=8, needed=5
GL_POINT_SIZE_MIN=0, needed=4
GL_POINT_SIZE_MAX=63, needed=63
Embedded shader set 'cbr_is_bold' x
Embedded shader set 'standard'
Using embedded vertex shader code from 'cbr_is_bold'.
Using embedded fragment shader code from 'cbr_is_bold'.
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 460x460 limit=529 (20x20 cells)
handed off cats with 513 tiles. (23x23).
accepted font texture (name=1): 460x460px oa
reshape(): got grid 0x0 window -1x-1 texture_ready=1 stretch=0 snap=0
reshape(): final grid 80x25 window 1600x500 viewport 1600x500 Psz 20x20
gps_allocate(80, 25)
set_viewport(): got 1600x500 out of 1600x500

This install will work for a few days and then it also stops working.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on October 29, 2011, 06:32:27 pm

Thank you very much for the insights into df coloring and tileset. Unfortunately it's too early to think about all this (though I think offset icons on top of creatures won't much of problem).

I made variable-tile-sizes work, but only on gallium software renderer. Thus I uploaded my current testbed script with all necessary data here: http://dffd.wimbli.com/file.php?id=5122

Please try to run it (runme.sh script), preferably on non-ATI cards, and on more-or-less recent Mesa versions for Intel ones,  and report results here.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on October 29, 2011, 07:53:05 pm

Quote from: arclance on October 29, 2011, 03:16:58 pm

I have found a strange bug you should know about.
PRINT_MODE:SHADER works for a few days (more than 2 less than 5) but then SHADER mode starts crashing with a Segmentation Fault.  Other modes (VBO, etc.) keep working.
Here is a backtrace of the crash.

This is very strange. How can it know it's been installed for a given amount of time? I never wrote any code that would check that.

However, today after extensive shader debugging I lost all understanding how this previous version could work at all. :)

 

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on October 29, 2011, 09:05:44 pm

Found and fixed a bug in vertex shader which was causing fun (and all shader fun is hidden). Please download new version of http://dffd.wimbli.com/file.php?id=5122 .

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on October 31, 2011, 09:52:43 am

Resorted to filing a bug:

https://bugs.freedesktop.org/show_bug.cgi?id=42435

Will continue to develop code using llvmpipe (software) driver for the time being.

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on October 31, 2011, 04:02:53 pm

Quote from: lxnt on October 29, 2011, 09:05:44 pm

Found and fixed a bug in vertex shader which was causing fun (and all shader fun is hidden). Please download new version of http://dffd.wimbli.com/file.php?id=5122 .

Assuming I put every thing in the correct place as there were no installation instructions other than the python dependencies it does not work.
This is how it crashes.

Code: [Select]

./runme.sh
texture 0 data loaded
FrameLoader(): 18 frames indexed

vendor: NVIDIA Corporation
renderer: GeForce GT 240/PCI/SSE2
version: 3.3.0 NVIDIA 270.41.06
GLSL version: 3.30 NVIDIA via Cg compiler
GL_MAX_VERTEX_ATTRIBS: 16 needed:7
GL_MAX_VERTEX_UNIFORM_COMPONENTS: 4096 needed:7
GL_MAX_FRAGMENT_UNIFORM_COMPONENTS: 2048 needed:6
GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS: 32 needed:1
GL_MAX_TEXTURE_IMAGE_UNITS: 32 needed:1
GL_MAX_VARYING_FLOATS: 60 needed:20
GL_MAX_TEXTURE_COORDS: 8 needed:5
GL_POINT_SIZE_MIN: 0 needed:-4
GL_POINT_SIZE_MAX: 63 needed:63
GL_MAX_RECTANGLE_TEXTURE_SIZE: 8192 needed:2048
GL_ARB_texture_rectangle: supported
Compiling shaders:
 4varying.vs
 4varying.fs
Traceback (most recent call last):
  File "testbed.py", line 623, in <module>
    r = rednener(stuff, pa.vertex_shader, pa.fragment_shader)
  File "testbed.py", line 181, in __init__
    self.shader_setup()
  File "testbed.py", line 239, in shader_setup
    compileShader(file(self.vs).read(), GL_VERTEX_SHADER),
  File "/usr/lib/pymodules/python2.7/OpenGL/GL/shaders.py", line 162, in compileShader
    shaderType,
RuntimeError: ('Shader compile failure (0): 0(22) : error C7532: global type sampler2DRect requires "#version 140" or later\n0(22) : error C0000: ... or #extension GL_ARB_texture_rectangle : enable\n0(62) : error C7531: global function texture2DRect requires "#extension GL_ARB_texture_rectangle : enable" before use\n', ['#line 1 0\n#version 120\n#ifndef GL_ARB_texture_rectangle\n#extension GL_ARB_texture_rectangle : require\n#endif\n#pragma optimize(off)\n#pragma debug(on)\n\n/*\n    row-major order.\n    idx, rows, columns\n\n    column = fract(idx/columns)*columns (aka mod(idx, rows))\n    row = floor(idx/columns)\n\n    nc_t = column/columns = fract(idx/columns)\n    nc_s = row/rows = floor(idx/columns)/rows\n*/\n\nconst float ANSI_CC = 16.0; // ansi color count \n\nuniform sampler2DRect txco;\nuniform vec4 txsz;              // { w_tiles, h_tiles, tile_w, tile_h }\nuniform vec2 viewpoint;\t\t\t\nuniform vec3 pszar; \t\t\t// { parx, pary, psz }\n// Total 7 float values, 1 sampler\n\nattribute vec4 screen;          // { ch, fg, bg, bold } \nattribute float texpos;         //  tile_tex_idx \nattribute float addcolor;\nattribute float grayscale;\nattribute float cf;\nattribute float cbr;\nattribute vec2 position;        // almost forgot teh grid\n// Total 7 attributes  = 13 float values \n\nvarying vec4 ansicolors;        // tile: computed foreground and background color indexes for tile and creature\nvarying vec4 tile;         \t// creature: offset into font texture and tile size\nvarying vec4 creature;          // tile: offset into font texture and tile size\n\n// Total 6 texcoords  = 24 varying floats\n\nvec2 ansiconvert(vec3 c) { // { fg, bg, bold }, returns {fg_idx, bg_idx}\n    vec2 rv;\n    float bold_factor = 0.0;\n    if (c.z > 0.1)\n        bold_factor = 8.0;\n\n    rv.x = mod(c.x + bold_factor, ANSI_CC);\n    rv.y = mod(c.y, ANSI_CC);\n    return rv;\n}\n\nvec4 idx2texco(float idx) {\n    vec4 tile_size;\n    vec2 tile_coords;\n    vec4 rv;\n    \n    rv.x = txsz.x*fract( idx / txsz.x ) * txsz.z;  // pixel coords \n    rv.y = txsz.w*floor( idx / txsz.x ); // txsz.y;  // into font texture - "offset"\n\n    tile_size = texture2DRect(txco, rv.xy);\n    rv.zw = tile_size.xy * 256.0; // pixel size of the tile = "tilesize"\n    \n    return rv;\n}\n\nvoid main() { // precomputes whatever there can be precomputed\n    \n    ansicolors.xy = ansiconvert(screen.yzw);\n    tile = idx2texco(screen.x);\n    \n    vec2 defaultcolors = vec2(0.0, 15.0);\n    if (texpos > 0.1) {\n\tcreature = idx2texco(texpos);\n\tif  (grayscale > 0.1) {  \n\t    ansicolors.zw = ansiconvert(vec3(cf, screen.z, cbr));\n\t} else if (addcolor > 0.1) {\n\t    ansicolors.zw = ansicolors.xy;\n\t} else {\n\t    ansicolors.zw = defaultcolors;\n\t}\n    } else {\n\tcreature = vec4(0.0); // size of 0 = no creature.\n\tansicolors.zw = defaultcolors;\n    }\n    \n    vec2 posn = pszar.xy*position*pszar.z - viewpoint;\n     \n    gl_Position = gl_ModelViewProjectionMatrix*vec4(posn.x, posn.y, 0.0, 1.0);\n    gl_PointSize = pszar.z;    \n}\n'], GL_VERTEX_SHADER)

The old version is still working as of now. 
It just feels like it randomly decides to not work after a few days (not while playing, at startup) and you have to start from scratch with a new df_linux folder.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on November 01, 2011, 04:47:46 am

Nvidia driver is  being picky and wants #extension GL_ARB_texture_rectangle : enable line somewhere after #version line in the shader source code.

You can also try the testcase from the bug I submitted to the FDO (link in above post), it's somewhat more documented.

In other news I found a workaround for my problems - moving most of processing to the fragment shader, so the point is hopefully moot.
This would waste GPU resources, but hey, it would work at last. So expect new libgraphics.so shortly.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on November 05, 2011, 08:33:32 pm

Okay, I got rid of graphic tile size limitation, the only remaining is the aspect ratio one. New lib uploaded. It also should work on i965 (Intel Sandy Bridge chipset) machines.

As for aspect ratio limit : currently my code assumes all tiles are of same aspect ratio as the one in the font, and will shamelessly stretch anything else. It also assumes that both font/graphics pixels and on-screen ones are square.

Here's the question: If one uses, say, 8x14 font with half 32x32 graphics, other half being, say, 12x24 :  what should the code do?
Or the other way around: 32x24 font, 16x16 and 8x12 graphics. and some 48x54 ones just for fun.

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on November 05, 2011, 09:15:56 pm

Quote from: lxnt on November 05, 2011, 08:33:32 pm

Okay, I got rid of graphic tile size limitation, the only remaining is the aspect ratio one. New lib uploaded.

Does not work with the Nvidia drivers (and probably any drivers other than the one you are using that does not update libstdc++) if you follow the instructions in your readme.

Spoiler (click to show/hide)

./dfbacktrace
GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /media/Linux_Data/Dwarf_Fortress/Test_Fortress/printmodeshader/current/df_linux/libs/Dwarf_Fortress...(no debugging symbols found)...done.
Starting program: /media/Linux_Data/Dwarf_Fortress/Test_Fortress/printmodeshader/current/df_linux/libs/Dwarf_Fortress
/media/Linux_Data/Dwarf_Fortress/Test_Fortress/printmodeshader/current/df_linux/libs/Dwarf_Fortress: /usr/lib32/libstdc++.so.6: version `CXXABI_1.3.5' not found (required by /media/Linux_Data/Dwarf_Fortress/Test_Fortress/printmodeshader/current/df_linux/libs/libgraphics.so)
/media/Linux_Data/Dwarf_Fortress/Test_Fortress/printmodeshader/current/df_linux/libs/Dwarf_Fortress: /usr/lib32/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by /media/Linux_Data/Dwarf_Fortress/Test_Fortress/printmodeshader/current/df_linux/libs/libgraphics.so)

Program exited with code 01.
No stack.

You need to update libstdc++ (and possibly some other things) using this repository https://launchpad.net/~ubuntu-toolchain-r/+archive/test for it to work.

Also tiles are not rendered in the correct size and the screen is not filled when first loading a save file. 

Spoiler (click to show/hide)

(http://img.ie/a3a77.png)

This can be worked around by playing with the zoom until it looks right (or using an old screenshot to be sure its right).

Spoiler (click to show/hide)

(http://img.ie/6516a.png)

Quote from: lxnt on November 05, 2011, 08:33:32 pm

It also should work on i965 (Intel Sandy Bridge chipset) machines.

Do you mean that it will work with the built in graphics in the sandy bridge chipset?

Title: Re: [PRINT_MODE:SHADER]
Post by: Mike Mayday on November 06, 2011, 06:09:23 am

Quote from: lxnt on November 05, 2011, 08:33:32 pm

Here's the question: If one uses, say, 8x14 font with half 32x32 graphics, other half being, say, 12x24 :  what should the code do?
Or the other way around: 32x24 font, 16x16 and 8x12 graphics. and some 48x54 ones just for fun.

The biggest problem with all this is that game icons are, by necessity, pixelart. This means that any resizing other than upscaling them by increments of 2 is a murder on the piece of work that they are- seriously decreasing not only their looks but most of all their readability.
Sometimes decreasing them by 2x will work for a general overview and that's it. However, text and clear symbols can usually be downscaled with less of an impact, though it will also never look as good as the original.
Not to mention, the second situation is bloody unlikely- since the interface NEEDS to have 80 tiles horizontally, that would require a resolution of 2560...
An additional general rule: the aspect ratio of EVERY tile (tileset and graphics) must ALWAYS be mantained.

Due to those problems, I believe separating the worldview zoom from the menus is the only way to go. Any playing around with stretching and zooming is useless as long as most users can use 16px tiles at best (if I'm not mistaken, the most popular horizontal resolution is still 1280).
Once/IF that's taken care of, an optimum for me would be:

-situation 1 is: keep the menus with the original fontsize and for the worldview choose the largest of tiles (32x32), stretch the base tileset by a maximum fitting increment of 2x (in this case= once, because that will yield 16x24) and CENTER them, and keep the second set of graphic as is and also center them.

-situation 2: check your maximum resolution and keep decreasing the base tilest by increments of 2 until it fits- so in my case= just once, which results in 16x12 tiles. If your horizontal resolution is 1920 you can leave it be.
Now we've got a problem with the graphics: the basic view would indeed use the largest- 48x54 tiles, and stretch/center the others to 48x48 and 36x48 respectively.
But now that we're using tiles that big, one should be able to keep zooming out (STILL by increments of 2) until they reach the smallest tilesize of the set.
So the next zoomout will yield: 24x27, 16x16 and 8x12. Now we've come to a dumb situation because the tileset author decided to use a weird tile size- we can't divide 27 by two. I guess it's up to you to decide how to downscale it, let's say this results in 12x14, 8x8 and 8x12. Now we need to zoomout once again to make it fit the smallest original tiles (8x12) but the second one is good enough already. So the result of the last zoomout will be 6x12, 8x8 and 8x12.

I'm pretty sure that was not at all clear, in which case let me know. I'm also pretty sure all this is very hard to do and you'll want to look for another method, in which case also let me know and I'll try to think of more general rules without worrying about even scaling and readability so much.

EDIT: another thing! when stretching tiles by increments of 2, it's optimal to use the nearest neighbour method- tiles are designed to look best with it. All other stretches/squeezes should use some hq/SaI/etc. algorithm (don't remember which one you're using right now).

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on November 06, 2011, 09:32:48 am

Quote from: arclance on November 05, 2011, 09:15:56 pm

Does not work with the Nvidia drivers (and probably any drivers other than the one you are using that does not update libstdc++) if you follow the instructions in your readme.

Yup, my fault. Used a gcc too fresh. Will recompile with oldest gcc possible.

Quote from: arclance on November 05, 2011, 09:15:56 pm

Also tiles are not rendered in the correct size and the screen is not filled when first loading a save file. 

That one is strange. Can you please post output from the console?

Quote from: arclance on November 05, 2011, 09:15:56 pm

This can be worked around by playing with the zoom until it looks right (or using an old screenshot to be sure its right).

Try the reset-zoom hotkey,  F10, it should reset zoom so that tiles are drawn pixel-for-pixel.

Quote from: lxnt on November 05, 2011, 08:33:32 pm

Do you mean that it will work with the built in graphics in the sandy bridge chipset?

Yup. Works for me at:

Code: [Select]

OpenGL renderer: Mesa DRI Intel(R) Sandybridge Desktop x86/MMX/SSE2
OpenGL version: 2.1 Mesa 7.12-devel
lspci:
       Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)

dmidecode:
Base Board Information
        Manufacturer: Intel Corporation
        Product Name: DH67BL
        Version: AAG10189-204

With xorg-edgers drivers, as you see, but still.

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on November 06, 2011, 10:06:33 am

Quote from: lxnt on November 06, 2011, 09:32:48 am

Quote from: arclance on November 05, 2011, 09:15:56 pm

Also tiles are not rendered in the correct size and the screen is not filled when first loading a save file. 

That one is strange. Can you please post output from the console?

Here you go.

Code: [Select]

./df
textures::load(): data/art/Phoebus_20x20.png 320x320 16x16 20x20
textures::load(): data/art/Phoebus_20x20.png 320x320 16x16 20x20
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
set_mode(): SDL_FULLSCREEN: 0
GLEW: 1.5.2
OpenGL vendor: NVIDIA Corporation
OpenGL renderer: GeForce GT 240/PCI/SSE2
OpenGL version: 3.3.0 NVIDIA 270.41.06
OpenGL GLSL version: 3.30 NVIDIA via Cg compiler
GL_MAX_VERTEX_ATTRIBS=16, needed=7
GL_MAX_VERTEX_UNIFORM_COMPONENTS=4096, needed=7
GL_MAX_FRAGMENT_UNIFORM_COMPONENTS=2048, needed=6
GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS=32, needed=1
GL_MAX_TEXTURE_IMAGE_UNITS=32, needed=2
GL_MAX_VARYING_FLOATS=60, needed=12
GL_MAX_TEXTURE_COORDS=8, needed=3
GL_POINT_SIZE_MIN=0, needed=4
** GL_POINT_SIZE_MAX=63, needed=64
makeansitex(): 2.
Embedded shader set 'rect'
Embedded shader set 'cbr_is_bold' x
Using embedded vertex shader code from 'cbr_is_bold'.
Using embedded fragment shader code from 'cbr_is_bold'.
GL_COMPILE_STATUS: true
GL_COMPILE_STATUS: true
GL_LINK_STATUS: true
GL_VALIDATE_STATUS: true
makeansitex(): 2.
gps_allocate(80, 25)
Resetting textures
texdumpst::init(): allocating 2048x288 (max 64x9 32x32 cells)
accepted font texture (name=1): 2048x288px oa
accepted txco texture (name=3): 64x9px oa
reshape(): got grid 0x0 window -1x-1 texture_ready=1 stretch=0 snap=0
reshape(): final grid 80x25 window 1600x500 viewport 1600x500 Psz 20x20
set_viewport(): got 1600x500 out of 1600x500
reshape(): got grid 96x51 window 1920x1025 texture_ready=1 stretch=0 snap=0
reshape(): final grid 96x51 window 1920x1025 viewport 1920x1020 Psz 20x20
gps_allocate(96, 51)
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
set_mode(): SDL_FULLSCREEN: 0
set_viewport(): got 1920x1020 out of 1920x1025
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/dorfs.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/humans.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/goblins.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/elfs.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/koboldz.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/creature_birds.png 100x120 5x6 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/creature_domestic.png 440x120 22x6 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/creature_large_mountain.png 100x120 5x6 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/animals.png 240x600 12x30 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/water.png 80x140 4x7 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/gibbon.png 80x180 4x9 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/beasts.png 120x80 6x4 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/mans.png 240x340 12x17 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/newbeasts.png 120x160 6x8 20x20
Resetting textures
texdumpst::init(): allocating 2048x2656 (max 64x83 32x32 cells)
accepted font texture (name=1): 2048x2656px oa
accepted txco texture (name=3): 64x83px oa
reshape(): got grid 0x0 window -1x-1 texture_ready=1 stretch=0 snap=0
reshape(): final grid 80x25 window 1920x1025 viewport 1920x600 Psz 24x24
gps_allocate(80, 25)
set_viewport(): got 1920x600 out of 1920x102


Quote from: lxnt on November 06, 2011, 09:32:48 am

Quote from: arclance on November 05, 2011, 09:15:56 pm

This can be worked around by playing with the zoom until it looks right (or using an old screenshot to be sure its right).

Try the reset-zoom hotkey,  F10, it should reset zoom so that tiles are drawn pixel-for-pixel.

Does not fix it. It looks like this after pressing F10.

Spoiler (click to show/hide)

(http://img.ie/21739.png)

Code: [Select]

/df
textures::load(): data/art/Phoebus_20x20.png 320x320 16x16 20x20
textures::load(): data/art/Phoebus_20x20.png 320x320 16x16 20x20
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
set_mode(): SDL_FULLSCREEN: 0
GLEW: 1.5.2
OpenGL vendor: NVIDIA Corporation
OpenGL renderer: GeForce GT 240/PCI/SSE2
OpenGL version: 3.3.0 NVIDIA 270.41.06
OpenGL GLSL version: 3.30 NVIDIA via Cg compiler
GL_MAX_VERTEX_ATTRIBS=16, needed=7
GL_MAX_VERTEX_UNIFORM_COMPONENTS=4096, needed=7
GL_MAX_FRAGMENT_UNIFORM_COMPONENTS=2048, needed=6
GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS=32, needed=1
GL_MAX_TEXTURE_IMAGE_UNITS=32, needed=2
GL_MAX_VARYING_FLOATS=60, needed=12
GL_MAX_TEXTURE_COORDS=8, needed=3
GL_POINT_SIZE_MIN=0, needed=4
** GL_POINT_SIZE_MAX=63, needed=64
makeansitex(): 2.
Embedded shader set 'rect'
Embedded shader set 'cbr_is_bold' x
Using embedded vertex shader code from 'cbr_is_bold'.
Using embedded fragment shader code from 'cbr_is_bold'.
GL_COMPILE_STATUS: true
GL_COMPILE_STATUS: true
GL_LINK_STATUS: true
GL_VALIDATE_STATUS: true
makeansitex(): 2.
gps_allocate(80, 25)
Resetting textures
texdumpst::init(): allocating 2048x288 (max 64x9 32x32 cells)
accepted font texture (name=1): 2048x288px oa
accepted txco texture (name=3): 64x9px oa
reshape(): got grid 0x0 window -1x-1 texture_ready=1 stretch=0 snap=0
reshape(): final grid 80x25 window 1600x500 viewport 1600x500 Psz 20x20
set_viewport(): got 1600x500 out of 1600x500
reshape(): got grid 96x51 window 1920x1025 texture_ready=1 stretch=0 snap=0
reshape(): final grid 96x51 window 1920x1025 viewport 1920x1020 Psz 20x20
gps_allocate(96, 51)
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
set_mode(): SDL_FULLSCREEN: 0
set_viewport(): got 1920x1020 out of 1920x1025
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/dorfs.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/humans.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/goblins.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/elfs.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/koboldz.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/creature_birds.png 100x120 5x6 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/creature_domestic.png 440x120 22x6 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/creature_large_mountain.png 100x120 5x6 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/animals.png 240x600 12x30 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/water.png 80x140 4x7 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/gibbon.png 80x180 4x9 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/beasts.png 120x80 6x4 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/mans.png 240x340 12x17 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/newbeasts.png 120x160 6x8 20x20
Resetting textures
texdumpst::init(): allocating 2048x2656 (max 64x83 32x32 cells)
accepted font texture (name=1): 2048x2656px oa
accepted txco texture (name=3): 64x83px oa
reshape(): got grid 0x0 window -1x-1 texture_ready=1 stretch=0 snap=0
reshape(): final grid 80x25 window 1920x1025 viewport 1920x600 Psz 24x24
gps_allocate(80, 25)
set_viewport(): got 1920x600 out of 1920x1025
reshape(): got grid 60x32 window -1x-1 texture_ready=1 stretch=0 snap=0
reshape(): final grid 80x32 window 1920x1025 viewport 1920x768 Psz 24x24
gps_allocate(80, 32)
set_viewport(): got 1920x768 out of 1920x1025
Here is the result of playing with the zoom until it is correct.

Spoiler (click to show/hide)

(http://img.ie/11902.png)

Code: [Select]

andrew@The-Hammer:/media/Linux_Data/Dwarf_Fortress/Test_Fortress/printmodeshader/current/df_linux$ ./df
textures::load(): data/art/Phoebus_20x20.png 320x320 16x16 20x20
textures::load(): data/art/Phoebus_20x20.png 320x320 16x16 20x20
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
set_mode(): SDL_FULLSCREEN: 0
GLEW: 1.5.2
OpenGL vendor: NVIDIA Corporation
OpenGL renderer: GeForce GT 240/PCI/SSE2
OpenGL version: 3.3.0 NVIDIA 270.41.06
OpenGL GLSL version: 3.30 NVIDIA via Cg compiler
GL_MAX_VERTEX_ATTRIBS=16, needed=7
GL_MAX_VERTEX_UNIFORM_COMPONENTS=4096, needed=7
GL_MAX_FRAGMENT_UNIFORM_COMPONENTS=2048, needed=6
GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS=32, needed=1
GL_MAX_TEXTURE_IMAGE_UNITS=32, needed=2
GL_MAX_VARYING_FLOATS=60, needed=12
GL_MAX_TEXTURE_COORDS=8, needed=3
GL_POINT_SIZE_MIN=0, needed=4
** GL_POINT_SIZE_MAX=63, needed=64
makeansitex(): 2.
Embedded shader set 'rect'
Embedded shader set 'cbr_is_bold' x
Using embedded vertex shader code from 'cbr_is_bold'.
Using embedded fragment shader code from 'cbr_is_bold'.
GL_COMPILE_STATUS: true
GL_COMPILE_STATUS: true
GL_LINK_STATUS: true
GL_VALIDATE_STATUS: true
makeansitex(): 2.
gps_allocate(80, 25)
Resetting textures
texdumpst::init(): allocating 2048x288 (max 64x9 32x32 cells)
accepted font texture (name=1): 2048x288px oa
accepted txco texture (name=3): 64x9px oa
reshape(): got grid 0x0 window -1x-1 texture_ready=1 stretch=0 snap=0
reshape(): final grid 80x25 window 1600x500 viewport 1600x500 Psz 20x20
set_viewport(): got 1600x500 out of 1600x500
reshape(): got grid 96x51 window 1920x1025 texture_ready=1 stretch=0 snap=0
reshape(): final grid 96x51 window 1920x1025 viewport 1920x1020 Psz 20x20
gps_allocate(96, 51)
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
set_mode(): SDL_FULLSCREEN: 0
set_viewport(): got 1920x1020 out of 1920x1025
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/dorfs.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/humans.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/goblins.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/elfs.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/koboldz.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/creature_birds.png 100x120 5x6 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/creature_domestic.png 440x120 22x6 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/creature_large_mountain.png 100x120 5x6 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/animals.png 240x600 12x30 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/water.png 80x140 4x7 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/gibbon.png 80x180 4x9 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/beasts.png 120x80 6x4 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/mans.png 240x340 12x17 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/newbeasts.png 120x160 6x8 20x20
Resetting textures
texdumpst::init(): allocating 2048x2656 (max 64x83 32x32 cells)
accepted font texture (name=1): 2048x2656px oa
accepted txco texture (name=3): 64x83px oa
reshape(): got grid 0x0 window -1x-1 texture_ready=1 stretch=0 snap=0
reshape(): final grid 80x25 window 1920x1025 viewport 1920x600 Psz 24x24
gps_allocate(80, 25)
set_viewport(): got 1920x600 out of 1920x1025
reshape(): got grid 60x32 window -1x-1 texture_ready=1 stretch=0 snap=0
reshape(): final grid 80x32 window 1920x1025 viewport 1920x768 Psz 24x24
gps_allocate(80, 32)
set_viewport(): got 1920x768 out of 1920x1025
reshape(): got grid 83x44 window -1x-1 texture_ready=1 stretch=0 snap=0
reshape(): final grid 83x44 window 1920x1025 viewport 1909x1012 Psz 23x23
gps_allocate(83, 44)
set_viewport(): got 1909x1012 out of 1920x1025
reshape(): got grid 87x46 window -1x-1 texture_ready=1 stretch=0 snap=0
reshape(): final grid 87x46 window 1920x1025 viewport 1914x1012 Psz 22x22
gps_allocate(87, 46)
set_viewport(): got 1914x1012 out of 1920x1025
reshape(): got grid 83x44 window -1x-1 texture_ready=1 stretch=0 snap=0
reshape(): final grid 83x44 window 1920x1025 viewport 1909x1012 Psz 23x23
gps_allocate(83, 44)
set_viewport(): got 1909x1012 out of 1920x1025
reshape(): got grid 80x42 window -1x-1 texture_ready=1 stretch=0 snap=0
reshape(): final grid 80x42 window 1920x1025 viewport 1920x1008 Psz 24x24
gps_allocate(80, 42)
set_viewport(): got 1920x1008 out of 1920x1025
reshape(): got grid 76x41 window -1x-1 texture_ready=1 stretch=0 snap=0
reshape(): final grid 80x41 window 1920x1025 viewport 1920x984 Psz 24x24
gps_allocate(80, 41)
set_viewport(): got 1920x984 out of 1920x1025
reshape(): got grid 83x44 window -1x-1 texture_ready=1 stretch=0 snap=0
reshape(): final grid 83x44 window 1920x1025 viewport 1909x1012 Psz 23x23
gps_allocate(83, 44)
set_viewport(): got 1909x1012 out of 1920x1025
reshape(): got grid 87x46 window -1x-1 texture_ready=1 stretch=0 snap=0
reshape(): final grid 87x46 window 1920x1025 viewport 1914x1012 Psz 22x22
gps_allocate(87, 46)
set_viewport(): got 1914x1012 out of 1920x1025
reshape(): got grid 91x48 window -1x-1 texture_ready=1 stretch=0 snap=0
reshape(): final grid 91x48 window 1920x1025 viewport 1911x1008 Psz 21x21
gps_allocate(91, 48)
set_viewport(): got 1911x1008 out of 1920x1025
reshape(): got grid 96x51 window -1x-1 texture_ready=1 stretch=0 snap=0
reshape(): final grid 96x51 window 1920x1025 viewport 1920x1020 Psz 20x20
gps_allocate(96, 51)
set_viewport(): got 1920x1020 out of 1920x1025
reshape(): got grid 101x53 window -1x-1 texture_ready=1 stretch=0 snap=0
reshape(): final grid 101x53 window 1920x1025 viewport 1919x1007 Psz 19x19
gps_allocate(101, 53)
set_viewport(): got 1919x1007 out of 1920x1025
reshape(): got grid 106x56 window -1x-1 texture_ready=1 stretch=0 snap=0
reshape(): final grid 106x56 window 1920x1025 viewport 1908x1008 Psz 18x18
gps_allocate(106, 56)
set_viewport(): got 1908x1008 out of 1920x1025
reshape(): got grid 112x60 window -1x-1 texture_ready=1 stretch=0 snap=0
reshape(): final grid 112x60 window 1920x1025 viewport 1904x1020 Psz 17x17
gps_allocate(112, 60)
set_viewport(): got 1904x1020 out of 1920x1025
reshape(): got grid 120x64 window -1x-1 texture_ready=1 stretch=0 snap=0
reshape(): final grid 120x64 window 1920x1025 viewport 1920x1024 Psz 16x16
gps_allocate(120, 64)
set_viewport(): got 1920x1024 out of 1920x1025
reshape(): got grid 112x60 window -1x-1 texture_ready=1 stretch=0 snap=0
reshape(): final grid 112x60 window 1920x1025 viewport 1904x1020 Psz 17x17
gps_allocate(112, 60)
set_viewport(): got 1904x1020 out of 1920x1025
reshape(): got grid 106x56 window -1x-1 texture_ready=1 stretch=0 snap=0
reshape(): final grid 106x56 window 1920x1025 viewport 1908x1008 Psz 18x18
gps_allocate(106, 56)
set_viewport(): got 1908x1008 out of 1920x1025
reshape(): got grid 112x60 window -1x-1 texture_ready=1 stretch=0 snap=0
reshape(): final grid 112x60 window 1920x1025 viewport 1904x1020 Psz 17x17
gps_allocate(112, 60)
set_viewport(): got 1904x1020 out of 1920x1025
reshape(): got grid 106x56 window -1x-1 texture_ready=1 stretch=0 snap=0
reshape(): final grid 106x56 window 1920x1025 viewport 1908x1008 Psz 18x18
gps_allocate(106, 56)
set_viewport(): got 1908x1008 out of 1920x1025
reshape(): got grid 101x53 window -1x-1 texture_ready=1 stretch=0 snap=0
reshape(): final grid 101x53 window 1920x1025 viewport 1919x1007 Psz 19x19
gps_allocate(101, 53)
set_viewport(): got 1919x1007 out of 1920x1025
reshape(): got grid 96x51 window -1x-1 texture_ready=1 stretch=0 snap=0
reshape(): final grid 96x51 window 1920x1025 viewport 1920x1020 Psz 20x20
gps_allocate(96, 51)
set_viewport(): got 1920x1020 out of 1920x1025
reshape(): got grid 91x48 window -1x-1 texture_ready=1 stretch=0 snap=0
reshape(): final grid 91x48 window 1920x1025 viewport 1911x1008 Psz 21x21
gps_allocate(91, 48)
set_viewport(): got 1911x1008 out of 1920x1025
reshape(): got grid 96x51 window -1x-1 texture_ready=1 stretch=0 snap=0
reshape(): final grid 96x51 window 1920x1025 viewport 1920x1020 Psz 20x20
gps_allocate(96, 51)
set_viewport(): got 1920x1020 out of 1920x1025
reshape(): got grid 91x48 window -1x-1 texture_ready=1 stretch=0 snap=0
reshape(): final grid 91x48 window 1920x1025 viewport 1911x1008 Psz 21x21
gps_allocate(91, 48)
set_viewport(): got 1911x1008 out of 1920x1025
reshape(): got grid 96x51 window -1x-1 texture_ready=1 stretch=0 snap=0
reshape(): final grid 96x51 window 1920x1025 viewport 1920x1020 Psz 20x20
gps_allocate(96, 51)
set_viewport(): got 1920x1020 out of 1920x1025
reshape(): got grid 101x53 window -1x-1 texture_ready=1 stretch=0 snap=0
reshape(): final grid 101x53 window 1920x1025 viewport 1919x1007 Psz 19x19
gps_allocate(101, 53)
set_viewport(): got 1919x1007 out of 1920x1025
reshape(): got grid 96x51 window -1x-1 texture_ready=1 stretch=0 snap=0
reshape(): final grid 96x51 window 1920x1025 viewport 1920x1020 Psz 20x20
gps_allocate(96, 51)
set_viewport(): got 1920x1020 out of 1920x1025


Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on November 06, 2011, 10:09:15 am

Quote from: Mike Mayday on November 06, 2011, 06:09:23 am

The biggest problem with all this is that game icons are, by necessity, pixelart. This means that any resizing other than upscaling them by increments of 2 is a murder on the piece of work that they are- seriously decreasing not only their looks but most of all their readability.

Okay. Since I think that the policy on supported tile resolution/aspect ratios and such should be simple, let's limit it to this:

• Game is intended to be played without scaling/stretching or otherwise mutilating the graphics.
• Zoom is intended to be used to get a rough overview of the map, not a pretty one.
• Aspect ratio is defined by the font, that is, the floor tileset.
• If some graphics are of different aspect ratio, then they are uniformly scaled to fit inside the floor tile, centered. Resulting ugliness is the user's fault.

Since forcing interface text to the same size as the game tiles is not convenient on modern monitors, it is a project goal to make the interface drawn separately from the world view, preferably with vector fonts.

Zoom and scaling in my code is implemented by adjusting point sprite size in 1-pixel increments. Thus it is trivial to force scaling to exact integer multiple of pixels in the graphic.
Filtering is either GL_NEAREST or GL_LINEAR. While it's possible to implement some insanely complex scaler in the fragment shader, I don't think it's worth it due to the policy point 1.


How does this sound?

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on November 06, 2011, 11:49:20 am

Quote from: arclance on November 06, 2011, 10:06:33 am

Quote from: lxnt on November 06, 2011, 09:32:48 am

Quote from: arclance on November 05, 2011, 09:15:56 pm

Also tiles are not rendered in the correct size and the screen is not filled when first loading a save file. 

That one is strange. Can you please post output from the console?

Here you go.

Thank you. New version is up. Does work with standard libstdc++ too.

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on November 06, 2011, 12:19:14 pm

Quote from: lxnt on November 06, 2011, 11:49:20 am

Thank you. New version is up. Does work with standard libstdc++ too.

Tile size is wrong at startup but F10 works now.
At startup

Spoiler (click to show/hide)

(http://img.ie/9bc6a.png)

After hiting F10.

Spoiler (click to show/hide)

(http://img.ie/3c900.png)

Code: [Select]

./df
textures::load(): data/art/Phoebus_20x20.png 320x320 16x16 20x20
textures::load(): data/art/Phoebus_20x20.png 320x320 16x16 20x20
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
set_mode(): SDL_FULLSCREEN: 0
GLEW: 1.5.2
OpenGL vendor: NVIDIA Corporation
OpenGL renderer: GeForce GT 240/PCI/SSE2
OpenGL version: 3.3.0 NVIDIA 270.41.06
OpenGL GLSL version: 3.30 NVIDIA via Cg compiler
GL_MAX_VERTEX_ATTRIBS=16, needed=7
GL_MAX_VERTEX_UNIFORM_COMPONENTS=4096, needed=7
GL_MAX_FRAGMENT_UNIFORM_COMPONENTS=2048, needed=6
GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS=32, needed=1
GL_MAX_TEXTURE_IMAGE_UNITS=32, needed=2
GL_MAX_VARYING_FLOATS=60, needed=12
GL_MAX_TEXTURE_COORDS=8, needed=3
GL_POINT_SIZE_MIN=0, needed=4
** GL_POINT_SIZE_MAX=63, needed=64
makeansitex(): 2.
Embedded shader set 'rect'
Embedded shader set 'cbr_is_bold' x
Using embedded vertex shader code from 'cbr_is_bold'.
Using embedded fragment shader code from 'cbr_is_bold'.
GL_COMPILE_STATUS: true
GL_COMPILE_STATUS: true
GL_LINK_STATUS: true
GL_VALIDATE_STATUS: true
makeansitex(): 2.
gps_allocate(80, 25)
Resetting textures
texdumpst::init(): allocating 2048x288 (max 64x9 32x32 cells)
accepted font texture (name=1): 2048x288px oa
accepted txco texture (name=3): 64x9px oa
reshape(): got grid 0x0 window -1x-1 tile 20x20 texture_ready=1 stretch=0 snap=0
reshape(): final grid 80x25 window 1920x1000 viewport 1840x575 Psz 23x23
set_viewport(): got 1840x575 out of 1920x1000
Frame drawn in 2 msec
reshape(): got grid 96x50 window -1x-1 tile 20x20 texture_ready=1 stretch=0 snap=0
reshape(): final grid 96x50 window 1920x1000 viewport 1920x1000 Psz 20x20
gps_allocate(96, 50)
set_viewport(): got 1920x1000 out of 1920x1000
Frame drawn in 0 msec


Title: Re: [PRINT_MODE:SHADER]
Post by: Rose on November 06, 2011, 12:29:31 pm

I was pointed to this. I'll be keeping an eye on it.

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on November 06, 2011, 03:12:10 pm

Quote from: lxnt on November 06, 2011, 10:09:15 am

Since forcing interface text to the same size as the game tiles is not convenient on modern monitors, it is a project goal to make the interface drawn separately from the world view, preferably with vector fonts.

I would suggest you add a [MENU_TILESET:] to the init file where the tileset/font/vector font used for drawing the interface can be specified.
By making the world and the interface have separate tilesets you can keep punctuation and special symbols in the interface while replacing them in the world view so they both look good.
This would also allow the menu and world to have different native tilesizes so they do not need to be resized just to draw the menu or world.

I would be careful with anything involving drawing vectors as it has the possibility to make the menus draw very slowly due to the number of calculations required to draw a large number of changing vector objects (scrolling menus made up of vector fonts as an example (ex. Trade Menu)) can quickly bring even a powerful computer to its knees (much like Dwarf Fortress).

Title: Re: [PRINT_MODE:SHADER]
Post by: Mike Mayday on November 06, 2011, 05:10:03 pm

Quote from: lxnt on November 06, 2011, 10:09:15 am

Okay. Since I think that the policy on supported tile resolution/aspect ratios and such should be simple, let's limit it to this:

• Game is intended to be played without scaling/stretching or otherwise mutilating the graphics.
• Zoom is intended to be used to get a rough overview of the map, not a pretty one.
• Aspect ratio is defined by the font, that is, the floor tileset.
• If some graphics are of different aspect ratio, then they are uniformly scaled to fit inside the floor tile, centered. Resulting ugliness is the user's fault.

Since forcing interface text to the same size as the game tiles is not convenient on modern monitors, it is a project goal to make the interface drawn separately from the world view, preferably with vector fonts.

Zoom and scaling in my code is implemented by adjusting point sprite size in 1-pixel increments. Thus it is trivial to force scaling to exact integer multiple of pixels in the graphic.
Filtering is either GL_NEAREST or GL_LINEAR. While it's possible to implement some insanely complex scaler in the fragment shader, I don't think it's worth it due to the policy point 1.

How does this sound?

A smart tileset creator will be able to do wonders with this. Linear is, frankly, good enough. Vectors for the menus/interface- not necessary at all. Supporting 32x32 world view and 12x12 (or smaller) interface would be enough to make all graphics creators flip a positive bitch. And a separate tileset for the menus? That would be the limits of my imagination in terms of what a third party might do.

EDIT: Since I've been waiting for pretty much years for this, I just wanted to make sure: is this what you're hoping to achieve?
http://mayday.w.staszic.waw.pl/~mayday/upload/yesplease.jpg

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on November 07, 2011, 05:37:51 pm

Quote from: arclance on November 06, 2011, 12:19:14 pm

Tile size is wrong at startup but F10 works now.

Thank you. New version is up. It also tries to set 1:1 zoom if resizing upwards from a size that did not allow 1:1 zoom while keeping 80x25 grid (i.e. too small a window).

I switched to gcc-4.5 on my home machine, please test if this version works with stock libstdc++ on Natty.

Quote from: arclance on November 06, 2011, 03:12:10 pm

I would suggest you add a [MENU_TILESET:] to the init file where the tileset/font/vector font used for drawing the interface can be specified.

That's what I planned to do.

Quote from: arclance on November 06, 2011, 03:12:10 pm

I would be careful with anything involving drawing vectors as it has the possibility to make the menus draw very slowly.

It'll be optional in any case. We'll see what the performance is.

Quote from: Mike Mayday on November 06, 2011, 05:10:03 pm

EDIT: Since I've been waiting for pretty much years for this, I just wanted to make sure: is this what you're hoping to achieve?
http://mayday.w.staszic.waw.pl/~mayday/upload/yesplease.jpg

This too. Also the other way around to keep menus readable while zoomed out.

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on November 07, 2011, 05:59:03 pm

Quote from: lxnt on November 07, 2011, 05:37:51 pm

Quote from: arclance on November 06, 2011, 12:19:14 pm

Tile size is wrong at startup but F10 works now.

Thank you. New version is up. It also tries to set 1:1 zoom if resizing upwards from a size that did not allow 1:1 zoom while keeping 80x25 grid (i.e. too small a window).

I switched to gcc-4.5 on my home machine, please test if this version works with stock libstdc++ on Natty.

Tile size is correct at startup now.
Works on my 32bit 11.04 (natty) computer which has the stock libstdc++.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on November 10, 2011, 05:20:48 pm

Quote from: arclance on November 07, 2011, 05:59:03 pm

Tile size is correct at startup now.
Works on my 32bit 11.04 (natty) computer which has the stock libstdc++.

Thank you.

The so-called "stable" version has been uploaded. It fixes a couple of bugs that might have caused intermittent crashes you had experienced. It also is compiled with optimization and w/o debug (thus the size).

This is a direct replacement of any other renderer - it draws stuff identically or as close to as is sensible. It is also faster, easily beating 500 graphic FPS on pause (on my r4850), and not biting off much time out of game engine when in action - but make sure you cap G_FPS at something low and enable SINGLE_BUFFER.

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on November 10, 2011, 08:02:00 pm

Quote from: lxnt on November 10, 2011, 05:20:48 pm

This is a direct replacement of any other renderer - it draws stuff identically or as close to as is sensible. It is also faster, easily beating 500 graphic FPS on pause (on my r4850), and not biting off much time out of game engine when in action - but make sure you cap G_FPS at something low and enable SINGLE_BUFFER.

[SINGLE_BUFFER:YES] in [PRINT_MODE:SHADER] is unusable for me as the game looks like this

Spoiler (click to show/hide)

(http://img.ie/2125a.jpg)

The dark triangle jumps up and down the screen and blinks on and off rapidly while changing size.
This also happens when using [PRINT_MODE:VBO] but not in other modes.

I see no FPS improvement between [SINGLE_BUFFER:YES] and [SINGLE_BUFFER:NO].  FPS appears identical between these two settings in a 21 year old fort.
I am actually seeing the opposite of you when I test with a three season old fort.
With [SINGLE_BUFFER:YES] I get ~255 FPS in this fort.

Spoiler (click to show/hide)

(http://img.ie/b364a.png)

With [SINGLE_BUFFER:NO] I get ~270 FPS in this fort.

Spoiler (click to show/hide)

(http://img.ie/bc8c1.png)

I do see a 1 to 2 FPS improvement (35-36 FPS stock to ~37 FPS (much more stable) using shader) over the stock print modes in a 21 year old fort.
Setting [G_FPS_CAP:30] (from 50) got me an improvement of only 1 to 2 FPS. 
I got the same FPS when it was set at 25 (which I don't like to play at).
Moving from Debug build got me about 3 FPS.

FPS at pause is not representative of the FPS you will get in game.
Using your settings I get a FPS of ~190,000 when paused and 37 when unpaused.

Spoiler (click to show/hide)

(http://img.ie/25a54.png)

Spoiler (click to show/hide)

(http://img.ie/6b406.png)

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on November 11, 2011, 01:18:38 pm

Quote from: arclance on November 10, 2011, 08:02:00 pm

[SINGLE_BUFFER:YES] in [PRINT_MODE:SHADER] is unusable for me as the game looks like this

...

The dark triangle jumps up and down the screen and blinks on and off rapidly while changing size.
This also happens when using [PRINT_MODE:VBO] but not in other modes.

Sounds like "threaded optimization" (http://www.google.com/search?q=nvidia+vbo+threaded+optimization) bug. I don't have any sufficiently modern Nvidia hardware to test this though.

Quote from: arclance on November 10, 2011, 08:02:00 pm

I see no FPS improvement between [SINGLE_BUFFER:YES] and [SINGLE_BUFFER:NO].  FPS appears identical between these two settings in a 21 year old fort.
I am actually seeing the opposite of you when I test with a three season old fort.

Okay. Look at the console output, the code prints time spent drawing a frame every 5 seconds. If it's about 16-17 ms, your GL driver forces vertical refresh sync at 60Hz.

The whole point of this is to leave G_FPS capped by the game, not by the GL drivers. This way frame is drawn as fast as possible, and the rest of time is spent elsewhere,
not in drivers waiting for the vertical refresh.

If it's about 1-2 ms, then renderer does not waste time. This is visible in game when you pause and graphics FPS starts to climb to about the same value as game engine FPS.
The reason I quoted 500 FPS is that I capped game engine FPS to 500 and on every pause graphics FPS would climb to 500 in several seconds (this gradual rise has something to do with
how graphics FPS is calculated).

That said, I'm reading the code that communicates between rendering and game engine threads. There might be some deficiences whose removal can benefit game engine FPS.




 

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on November 11, 2011, 05:08:49 pm

Quote from: lxnt on November 11, 2011, 01:18:38 pm

Okay. Look at the console output, the code prints time spent drawing a frame every 5 seconds. If it's about 16-17 ms, your GL driver forces vertical refresh sync at 60Hz.

The whole point of this is to leave G_FPS capped by the game, not by the GL drivers. This way frame is drawn as fast as possible, and the rest of time is spent elsewhere,
not in drivers waiting for the vertical refresh.

If it's about 1-2 ms, then renderer does not waste time. This is visible in game when you pause and graphics FPS starts to climb to about the same value as game engine FPS.

It is 0-1 ms no matter what settings I use.  My graphical FPS never climbs above its cap when paused.  Game engine FPS climbs rapidly either to its cap or to a very large value when paused. 

[SINGLE_BUFFER:NO]

Code: [Select]

./df
textures::load(): data/art/Phoebus_20x20.png 320x320 16x16 20x20
textures::load(): data/art/Phoebus_20x20.png 320x320 16x16 20x20
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
set_mode(): SDL_FULLSCREEN: 0
GLEW: 1.5.2
OpenGL vendor: NVIDIA Corporation
OpenGL renderer: GeForce GT 240/PCI/SSE2
OpenGL version: 3.3.0 NVIDIA 270.41.06
OpenGL GLSL version: 3.30 NVIDIA via Cg compiler
GL_MAX_VERTEX_ATTRIBS=16, needed=7
GL_MAX_VERTEX_UNIFORM_COMPONENTS=4096, needed=9
GL_MAX_FRAGMENT_UNIFORM_COMPONENTS=2048, needed=11
GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS=32, needed=0
GL_MAX_TEXTURE_IMAGE_UNITS=32, needed=3
GL_MAX_VARYING_FLOATS=60, needed=8
GL_MAX_TEXTURE_COORDS=8, needed=2
GL_POINT_SIZE_MIN=0, needed=4
GL_POINT_SIZE_MAX=63, needed=48
makeansitex(): 2.
Embedded shader set 'rect'
Embedded shader set 'cbr_is_bold' x
Using embedded vertex shader code from 'cbr_is_bold'.
Using embedded fragment shader code from 'cbr_is_bold'.
GL_COMPILE_STATUS: true
GL_COMPILE_STATUS: true
GL_LINK_STATUS: true
GL_VALIDATE_STATUS: true
makeansitex(): 2.
gps_allocate(80, 25)
Resetting textures
texdumpst::init(): allocating 2048x288 (max 64x9 32x32 cells)
accepted font texture (name=1): 2048x288px oa
accepted txco texture (name=3): 64x9px oa
reshape(): got grid 0x0 window -1x-1 tile 20x20 texture_ready=1 stretch=0 snap=0
reshape(): final grid 96x50 window 1920x1000 viewport 1920x1000 Psz 20x20
gps_allocate(96, 50)
set_viewport(): got 1920x1000 out of 1920x1000
Frame drawn in 2 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/dorfs.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/humans.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/goblins.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/elfs.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/koboldz.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/creature_birds.png 100x120 5x6 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/creature_domestic.png 440x120 22x6 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/creature_large_mountain.png 100x120 5x6 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/animals.png 240x600 12x30 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/water.png 80x140 4x7 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/gibbon.png 80x180 4x9 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/beasts.png 120x80 6x4 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/mans.png 240x340 12x17 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/newbeasts.png 120x160 6x8 20x20
Resetting textures
texdumpst::init(): allocating 2048x2656 (max 64x83 32x32 cells)
accepted font texture (name=1): 2048x2656px oa
accepted txco texture (name=3): 64x83px oa
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
reshape(): got grid 96x51 window 1920x1025 tile 20x20 texture_ready=1 stretch=0 snap=0
reshape(): final grid 96x51 window 1920x1025 viewport 1920x1020 Psz 20x20
gps_allocate(96, 51)
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
set_mode(): SDL_FULLSCREEN: 0
set_viewport(): got 1920x1020 out of 1920x1025
Frame drawn in 0 msec
[SINGLE_BUFFER:YES]

Code: [Select]

./df
textures::load(): data/art/Phoebus_20x20.png 320x320 16x16 20x20
textures::load(): data/art/Phoebus_20x20.png 320x320 16x16 20x20
Loading bindings from data/init/interface.txt
textures::load(): data/art/mouse.png 32x32
set_mode(): requesting vsync=0 and singlebuf=1.
set_mode(): SDL_GL_SWAP_CONTROL: 0
set_mode(): SDL_GL_ACCELERATED_VISUAL: 1
set_mode(): SDL_GL_DOUBLEBUFFER: 0
set_mode(): SDL_FULLSCREEN: 0
GLEW: 1.5.2
OpenGL vendor: NVIDIA Corporation
OpenGL renderer: GeForce GT 240/PCI/SSE2
OpenGL version: 3.3.0 NVIDIA 270.41.06
OpenGL GLSL version: 3.30 NVIDIA via Cg compiler
GL_MAX_VERTEX_ATTRIBS=16, needed=7
GL_MAX_VERTEX_UNIFORM_COMPONENTS=4096, needed=9
GL_MAX_FRAGMENT_UNIFORM_COMPONENTS=2048, needed=11
GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS=32, needed=0
GL_MAX_TEXTURE_IMAGE_UNITS=32, needed=3
GL_MAX_VARYING_FLOATS=60, needed=8
GL_MAX_TEXTURE_COORDS=8, needed=2
GL_POINT_SIZE_MIN=0, needed=4
GL_POINT_SIZE_MAX=63, needed=48
makeansitex(): 2.
Embedded shader set 'rect'
Embedded shader set 'cbr_is_bold' x
Using embedded vertex shader code from 'cbr_is_bold'.
Using embedded fragment shader code from 'cbr_is_bold'.
GL_COMPILE_STATUS: true
GL_COMPILE_STATUS: true
GL_LINK_STATUS: true
GL_VALIDATE_STATUS: true
makeansitex(): 2.
gps_allocate(80, 25)
Resetting textures
texdumpst::init(): allocating 2048x288 (max 64x9 32x32 cells)
accepted font texture (name=1): 2048x288px oa
accepted txco texture (name=3): 64x9px oa
reshape(): got grid 0x0 window -1x-1 tile 20x20 texture_ready=1 stretch=0 snap=0
reshape(): final grid 96x50 window 1920x1000 viewport 1920x1000 Psz 20x20
gps_allocate(96, 50)
set_viewport(): got 1920x1000 out of 1920x1000
Frame drawn in 2 msec
reshape(): got grid 96x51 window 1920x1025 tile 20x20 texture_ready=1 stretch=0 snap=0
reshape(): final grid 96x51 window 1920x1025 viewport 1920x1020 Psz 20x20
gps_allocate(96, 51)
set_mode(): requesting vsync=0 and singlebuf=1.
set_mode(): SDL_GL_SWAP_CONTROL: 0
set_mode(): SDL_GL_ACCELERATED_VISUAL: 1
set_mode(): SDL_GL_DOUBLEBUFFER: 0
set_mode(): SDL_FULLSCREEN: 0
set_viewport(): got 1920x1020 out of 1920x1025
Frame drawn in 0 msec
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/dorfs.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/humans.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/goblins.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/elfs.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/koboldz.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/creature_birds.png 100x120 5x6 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/creature_domestic.png 440x120 22x6 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/creature_large_mountain.png 100x120 5x6 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/animals.png 240x600 12x30 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/water.png 80x140 4x7 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/gibbon.png 80x180 4x9 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/beasts.png 120x80 6x4 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/mans.png 240x340 12x17 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/newbeasts.png 120x160 6x8 20x20
Resetting textures
texdumpst::init(): allocating 2048x2656 (max 64x83 32x32 cells)
accepted font texture (name=1): 2048x2656px oa
accepted txco texture (name=3): 64x83px oa
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 1 msec
Frame drawn in 0 msec


Quote from: lxnt on November 11, 2011, 01:18:38 pm

The reason I quoted 500 FPS is that I capped game engine FPS to 500 and on every pause graphics FPS would climb to 500 in several seconds (this gradual rise has something to do with
how graphics FPS is calculated).

That said, I'm reading the code that communicates between rendering and game engine threads. There might be some deficiences whose removal can benefit game engine FPS.

You should tell us if you have capped your FPS.  My FPS always hits a cap like that no matter what print mode I am using when paused.
Your previous statement makes it sound like your max FPS uncapped is 500 when paused.
You should also state the max FPS you get when not using shader as a reference point since we don't have your computer.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on November 14, 2011, 04:43:26 pm

Well ok. My fault. Should have been more precise.

Anyway, you can measure, benchmark and profile the code as you see fit. It should be taken for granted that on high-spec machines performance gain would be minimal, because in any case time spent on rendering depends only on grid_size, while game FPS depend more on map size and population.

In other news, it seems like I would have to integrate dfhack into the renderer to implement features I promised. This will take some time.

Title: Re: [PRINT_MODE:SHADER]
Post by: Rose on November 14, 2011, 11:00:28 pm

lxnt, I just felt I should mention, it's actually not possible to make Stonesense to work in SDL, due to SDL limitations.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on November 15, 2011, 10:44:25 am

Quote from: Japa on November 14, 2011, 11:00:28 pm

lxnt, I just felt I should mention, it's actually not possible to make Stonesense to work in SDL, due to SDL limitations.

I know. It'd be more of a rewrite than porting effort. Since rendering is going to be rewritten anyway, and current goal of divorcing interface from map rendering implies stonesense-like fetches of additional data from the game (thus dfhack integration), there isn't much left to port. If one insists on having multiple windows, SDL 1.3 can be brought in.

Title: Re: [PRINT_MODE:SHADER]
Post by: Rose on November 15, 2011, 01:31:58 pm

well, any help you need, I generally hang out on #dfhack on freenode.

Title: Re: [PRINT_MODE:SHADER]
Post by: Mike Mayday on November 15, 2011, 03:52:50 pm

Listen guys I really would like to help with testing the project but I'd need help setting up a proper environment (usb ubuntu plus learning how to compile). If you think it's worth your trouble- shoot!

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on November 15, 2011, 04:25:06 pm

Quote from: Mike Mayday on November 15, 2011, 03:52:50 pm

Listen guys I really would like to help with testing the project but I'd need help setting up a proper environment (usb ubuntu plus learning how to compile). If you think it's worth your trouble- shoot!

Instructions on how to make a Ubuntu usb boot drive can be found here. (http://www.ubuntu.com/download/ubuntu/download)
If you have an Nvidia graphics card you should install the Nvidia proprietary drivers, they work much better that the open source drivers with Nvidia cards.
A guide on setting up linux to run dwarf fortress can be found here. (http://df.magmawiki.com/index.php/Installation#Linux)
The readme lists these dependencies you install them with synaptic package manager.

Code: [Select]

GTK+ 2+
SDL 1.2+
SDL_image
libgl
libglu
There is one more needed in Ubuntu but I don't remember what it is. 
Run Dwarf Fortress in the terminal and the error message should tell you what it is.

You don't need to learn how to compile just to test [PRINT_MODE:SHADER], the version on dffd (http://dffd.wimbli.com/file.php?id=5044) works on Ubuntu.
Just follow the setup directions in the readme and it should work fine.

If you want to actually play the game in linux dfhack in already compiled for linux.
Dwarf Therpist is not you will need to compile it yourself. 
If you do that I recommend you use this version (https://code.google.com/r/shishimar-dwarftherapist/) which has an animal tab and can read physical attributes from Dwarfs.
Instructions for compiling Dwarf Therapist are found here (https://code.google.com/p/dwarftherapist/wiki/BuildingDwarfTherapist) replacing

Code: [Select]

hg clone https://dwarftherapist.googlecode.com/hg/ dwarftherapistwith

Code: [Select]

hg clone https://code.google.com/r/shishimar-dwarftherapist/ dwarftherapistto use the version I recommended.

If you have any problems just ask.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on December 07, 2011, 02:07:35 pm

I'm sorry, guys, we've got some stuff going on in Moscow for the last couple of weeks, so no time for this alas.
Hope it'll get somewhat clearer after 10th.

Title: Re: [PRINT_MODE:SHADER]
Post by: Mike Mayday on December 07, 2011, 02:31:03 pm

Oh shit

is the Russian regime opposing development of this patch??

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on December 08, 2011, 12:52:50 pm

Quote from: Mike Mayday on December 07, 2011, 02:31:03 pm

is the Russian regime opposing development of this patch??

Its convulsions hinder my concentration.

Title: Re: [PRINT_MODE:SHADER]
Post by: CheatingChicken on December 27, 2011, 04:05:21 pm

Hello, fellow Dwarflings.

As i tried to use this shader, i ran into some problems. I am pretty new to linux, in fact i only just set up a debian system as i read that this shader is available for linux only. So after i finally taught myself how to install all the necessary libraries and got the basic Dwarf Fortress application to run, i tried setting the [PRINT_MODE] to SHADER. Sadly, all i got was

Spoiler: this (click to show/hide)

(http://666kb.com/i/bzvq9fu085lw0ii3l.png)

After fiddling with the settings in the init.txt, all i managed to do was to turn the screen blue, which despite being pretty didn't help me an awful lot.

Does anyone know, what could be responsible for this?

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on December 27, 2011, 04:43:07 pm

Quote from: CheatingChicken on December 27, 2011, 04:05:21 pm

Hello, fellow Dwarflings.

As i tried to use this shader, i ran into some problems. I am pretty new to linux, in fact i only just set up a debian system as i read that this shader is available for linux only. So after i finally taught myself how to install all the necessary libraries and got the basic Dwarf Fortress application to run, i tried setting the [PRINT_MODE] to SHADER. Sadly, all i got was

Spoiler: this (click to show/hide)

(http://666kb.com/i/bzvq9fu085lw0ii3l.png)

After fiddling with the settings in the init.txt, all i managed to do was to turn the screen blue, which despite being pretty didn't help me an awful lot.

Does anyone know, what could be responsible for this?

Are you sure you are using the latest version (the one in the first post)?  Older versions can cause problems like this with certain graphics cards (Nvidia for sure).
This looks similar to what happened when I tested the first version that did not crash with my graphics card (the green color is configured in init.txt now and its default color is black).

Quote from: arclance on October 19, 2011, 06:46:13 pm

Spoiler (click to show/hide)

(http://img.ie/36c4b.png)

Each tile was being rendered as a single pixel, it was caused by the way the Nvidia drivers optimize GLSL code.

If you have an Nvidia graphics card make sure you install the proprietary Nvidia drivers, the open source one does not work as well.
Tell us what graphics card you are using (not all graphics cards will work) and post the terminal output you get when running Dwarf Fortress so we can help you with the problem.

Title: Re: [PRINT_MODE:SHADER]
Post by: CheatingChicken on December 27, 2011, 05:23:52 pm

The Terminal's output on the default settings is just "Frame drawn in x miliseconds" every ~300ms

after enabling the dumping, it looks like this:

Spoiler (click to show/hide)

Frame drawn in 334 msec
dump_screen(): frame 30728: 1264 bytes (compressed 32000->1156 + 108)
dump_screen(): frame 30732: 1264 bytes (compressed 32000->1156 + 108)
dump_screen(): frame 30736: 1266 bytes (compressed 32000->1158 + 108)
dump_screen(): frame 30740: 1264 bytes (compressed 32000->1156 + 108)
dump_screen(): frame 30744: 1264 bytes (compressed 32000->1156 + 108)
dump_screen(): frame 30748: 1264 bytes (compressed 32000->1156 + 108)
dump_screen(): frame 30752: 1264 bytes (compressed 32000->1156 + 108)
dump_screen(): frame 30756: 1264 bytes (compressed 32000->1156 + 108)
dump_screen(): frame 30760: 1264 bytes (compressed 32000->1156 + 108)
dump_screen(): frame 30764: 1264 bytes (compressed 32000->1156 + 108)
Frame drawn in 73 msec
dump_screen(): frame 30768: 1264 bytes (compressed 32000->1156 + 108)
dump_screen(): frame 30772: 1264 bytes (compressed 32000->1156 + 108)
dump_screen(): frame 30776: 1264 bytes (compressed 32000->1156 + 108)
dump_screen(): frame 30780: 1264 bytes (compressed 32000->1156 + 108)
dump_screen(): frame 30784: 1264 bytes (compressed 32000->1156 + 108)
dump_screen(): frame 30788: 1264 bytes (compressed 32000->1156 + 108)
dump_screen(): frame 30792: 1264 bytes (compressed 32000->1156 + 108)
dump_screen(): frame 30796: 1264 bytes (compressed 32000->1156 + 108)
dump_screen(): frame 30800: 1264 bytes (compressed 32000->1156 + 108)
dump_screen(): frame 30804: 1264 bytes (compressed 32000->1156 + 108)

I am using the version i got from the front page about 3 days ago.

The green screen is exactly what my blue one looked like. I could even see the cyan pixels where the fps counter was.

If this can be about Nvidia drivers i will look into that, as im pretty sure this machine uses some Nvidia card (I'm visiting my parents for christmas, so i dont have access to my own pc).

Thanks for the help, i will let you know if it helped.

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on December 27, 2011, 05:50:45 pm

Quote from: CheatingChicken on December 27, 2011, 05:23:52 pm

The Terminal's output on the default settings is just "Frame drawn in x miliseconds" every ~300ms

after enabling the dumping, it looks like this:

Spoiler (click to show/hide)

Frame drawn in 334 msec
dump_screen(): frame 30728: 1264 bytes (compressed 32000->1156 + 108)
dump_screen(): frame 30732: 1264 bytes (compressed 32000->1156 + 108)
dump_screen(): frame 30736: 1266 bytes (compressed 32000->1158 + 108)
dump_screen(): frame 30740: 1264 bytes (compressed 32000->1156 + 108)
dump_screen(): frame 30744: 1264 bytes (compressed 32000->1156 + 108)
dump_screen(): frame 30748: 1264 bytes (compressed 32000->1156 + 108)
dump_screen(): frame 30752: 1264 bytes (compressed 32000->1156 + 108)
dump_screen(): frame 30756: 1264 bytes (compressed 32000->1156 + 108)
dump_screen(): frame 30760: 1264 bytes (compressed 32000->1156 + 108)
dump_screen(): frame 30764: 1264 bytes (compressed 32000->1156 + 108)
Frame drawn in 73 msec
dump_screen(): frame 30768: 1264 bytes (compressed 32000->1156 + 108)
dump_screen(): frame 30772: 1264 bytes (compressed 32000->1156 + 108)
dump_screen(): frame 30776: 1264 bytes (compressed 32000->1156 + 108)
dump_screen(): frame 30780: 1264 bytes (compressed 32000->1156 + 108)
dump_screen(): frame 30784: 1264 bytes (compressed 32000->1156 + 108)
dump_screen(): frame 30788: 1264 bytes (compressed 32000->1156 + 108)
dump_screen(): frame 30792: 1264 bytes (compressed 32000->1156 + 108)
dump_screen(): frame 30796: 1264 bytes (compressed 32000->1156 + 108)
dump_screen(): frame 30800: 1264 bytes (compressed 32000->1156 + 108)
dump_screen(): frame 30804: 1264 bytes (compressed 32000->1156 + 108)

I am using the version i got from the front page about 3 days ago.

The green screen is exactly what my blue one looked like. I could even see the cyan pixels where the fps counter was.

If this can be about Nvidia drivers i will look into that, as im pretty sure this machine uses some Nvidia card (I'm visiting my parents for christmas, so i dont have access to my own pc).

Thanks for the help, i will let you know if it helped.

Yes use the drivers from Nvidia, the open source drivers for Nvidia cards are not as good as the ones for other cards because the Nvidia drivers work well.
Print Mode shader has been tested to work with the Nvidia proprietary drivers (by me) but not the open source ones because they are not recommended for use beyond installing the OS.
Your frame draw times of ~300 ms look very high (I get 0-2 ms and lxnt reports that 16-17 ms is expected if your driver forces vsync) your graphics card or drivers may not be good enough.

In a Debian based OS you can use "sudo lshw" in a terminal to get information about all your system components or "sudo lshw -c display" just to give information about your graphics card.  This will tell you what your graphics cards model is and what driver you are using. 

Please post your full terminal output there is more information that can help tell if your graphics card will work.
If you are using dfhack don't start Dwarf Fortress with ./dfhack while trying to fix this problem, you will lose some terminal information from Print Mode Shader if you do.
It should look like this.

Quote from: arclance on November 11, 2011, 05:08:49 pm

Code: [Select]

./df
textures::load(): data/art/Phoebus_20x20.png 320x320 16x16 20x20
textures::load(): data/art/Phoebus_20x20.png 320x320 16x16 20x20
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
set_mode(): SDL_FULLSCREEN: 0
GLEW: 1.5.2
OpenGL vendor: NVIDIA Corporation
OpenGL renderer: GeForce GT 240/PCI/SSE2
OpenGL version: 3.3.0 NVIDIA 270.41.06
OpenGL GLSL version: 3.30 NVIDIA via Cg compiler
GL_MAX_VERTEX_ATTRIBS=16, needed=7
GL_MAX_VERTEX_UNIFORM_COMPONENTS=4096, needed=9
GL_MAX_FRAGMENT_UNIFORM_COMPONENTS=2048, needed=11
GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS=32, needed=0
GL_MAX_TEXTURE_IMAGE_UNITS=32, needed=3
GL_MAX_VARYING_FLOATS=60, needed=8
GL_MAX_TEXTURE_COORDS=8, needed=2
GL_POINT_SIZE_MIN=0, needed=4
GL_POINT_SIZE_MAX=63, needed=48
makeansitex(): 2.
Embedded shader set 'rect'
Embedded shader set 'cbr_is_bold' x
Using embedded vertex shader code from 'cbr_is_bold'.
Using embedded fragment shader code from 'cbr_is_bold'.
GL_COMPILE_STATUS: true
GL_COMPILE_STATUS: true
GL_LINK_STATUS: true
GL_VALIDATE_STATUS: true
makeansitex(): 2.
gps_allocate(80, 25)
Resetting textures
texdumpst::init(): allocating 2048x288 (max 64x9 32x32 cells)
accepted font texture (name=1): 2048x288px oa
accepted txco texture (name=3): 64x9px oa
reshape(): got grid 0x0 window -1x-1 tile 20x20 texture_ready=1 stretch=0 snap=0
reshape(): final grid 96x50 window 1920x1000 viewport 1920x1000 Psz 20x20
gps_allocate(96, 50)
set_viewport(): got 1920x1000 out of 1920x1000
Frame drawn in 2 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/dorfs.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/humans.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/goblins.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/elfs.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/koboldz.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/creature_birds.png 100x120 5x6 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/creature_domestic.png 440x120 22x6 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/creature_large_mountain.png 100x120 5x6 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/animals.png 240x600 12x30 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/water.png 80x140 4x7 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/gibbon.png 80x180 4x9 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/beasts.png 120x80 6x4 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/mans.png 240x340 12x17 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/newbeasts.png 120x160 6x8 20x20
Resetting textures
texdumpst::init(): allocating 2048x2656 (max 64x83 32x32 cells)
accepted font texture (name=1): 2048x2656px oa
accepted txco texture (name=3): 64x83px oa
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
reshape(): got grid 96x51 window 1920x1025 tile 20x20 texture_ready=1 stretch=0 snap=0
reshape(): final grid 96x51 window 1920x1025 viewport 1920x1020 Psz 20x20
gps_allocate(96, 51)
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
set_mode(): SDL_FULLSCREEN: 0
set_viewport(): got 1920x1020 out of 1920x1025
Frame drawn in 0 msec


Title: Re: [PRINT_MODE:SHADER]
Post by: CheatingChicken on December 28, 2011, 03:42:36 pm

I think i just made everything become worse. I tried installing the nvidia drivers, but lost internet connection half way through the installation. Additionally i've had to switch to a pc using an intel graphics chip.

Now all i can get is this:

Code: [Select]

./df
textures::load(): data/art/Chickentiles_Smoothed.png 192x192 16x16 12x12
textures::load(): data/art/Chickentiles_Smoothed.png 192x192 16x16 12x12
Loading bindings from data/init/interface.txt
textures::load(): data/art/mouse.png 32x32
set_mode(): requesting vsync=0 and singlebuf=0.
SDL_SetVideoMode: Couldn't find matching GLX visual
SDL initialization failure: Couldn't find matching GLX visual

Any help?

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on December 28, 2011, 04:00:35 pm

Quote from: CheatingChicken on December 28, 2011, 03:42:36 pm

I think i just made everything become worse. I tried installing the nvidia drivers, but lost internet connection half way through the installation. Additionally i've had to switch to a pc using an intel graphics chip.

Now all i can get is this:

Code: [Select]

./df
textures::load(): data/art/Chickentiles_Smoothed.png 192x192 16x16 12x12
textures::load(): data/art/Chickentiles_Smoothed.png 192x192 16x16 12x12
Loading bindings from data/init/interface.txt
textures::load(): data/art/mouse.png 32x32
set_mode(): requesting vsync=0 and singlebuf=0.
SDL_SetVideoMode: Couldn't find matching GLX visual
SDL initialization failure: Couldn't find matching GLX visual

Any help?

Almost all Intel graphics chips except the ones in the new sandbridge cpu's do not have the required OpenGL and GLSL features or shader specs to be used with PRINT_MODE:SHADER.  This is why in Windows most games will crash at startup if you have an Intel graphics chip.
Your terminal output indicates that you may not have installed all the dependencies for Dwarf Fortress or that your graphics card/driver can not take advantage of those dependencies.

Please take a look at this post I made about setting up linux to play Dwarf Fortress to see if you missed anything (http://www.bay12forums.com/smf/index.php?topic=94528.msg2763192#msg2763192)
Also please extract dwarf fortress again in a different location and run it without installing print mode shader and post its terminal output to make sure this is not a problem with Dwarf Fortress itself. 
There is one dependency I had to install in Ubuntu 11.04 that is not listed in the readme and I don't remember what it is, this will check for that and tell us what it is if you don't have it.
Post the results of "sudo lshw -c display" so we can see what graphics card you have.  I can look up the stats on the card and tell you if it will never work.

Title: Re: [PRINT_MODE:SHADER]
Post by: CheatingChicken on December 28, 2011, 04:15:24 pm

The Problem is, i had the same error when trying to run it on the nvidia machine (where i just couldn't finish the driver installation, as i lost any connection to the internet). Also i get this error on any PRINT_MODE except for 2D and TEXT, which seem to be running just fine.

I will have a look at your post, ill tell you if it changes anything

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on January 12, 2012, 12:17:32 pm

Quote from: CheatingChicken on December 28, 2011, 03:42:36 pm

Now all i can get is this:

Code: [Select]

SDL initialization failure: Couldn't find matching GLX visual


This basically means that you don't have any GL drivers available at all.

In fact I would not recommend using Debian, because it lags so much in software versions compared to pretty much any other distro.

Go for the latest Ubuntu release, and even then you might have to install xorg-edgers (https://launchpad.net/~xorg-edgers/+archive/ppa) stuff if you've got ATI/AMD or Intel hardware.

 

Title: Re: [PRINT_MODE:SHADER]
Post by: CheatingChicken on January 13, 2012, 02:58:03 am

I guess ill try this. Hope i dont mess it up again ^^

I pretty much broke my debian anyway. Cant remove the drivers, it says theyre not installed, but also i cant install them because it tells me theyre already there...

Title: Re: [PRINT_MODE:SHADER]
Post by: Iceco on January 13, 2012, 02:59:20 pm

I'm still trying to wrap my head around this, so forgive me if I miss the ball here.

Random remarks:

• If I understand it right, the main incentive for this utility was increasing FPS by offloading the graphics to the GPU (but with neat consequences like the SHADER mode)?
• Can it draw multiple tiles (from the tileset) + characters (from the characters set), or just 1 tile and 1 character.

I think it would be interesting to be able to draw multiple tiles on top of each other (f.e. the floor tile + the rope lying on top of it). I think it would probably need specially designed tilesets, but you already have Mayday's interest.

• And I don't know how you determine what tiles to draw, but if you look directly at the items that that need drawing (and not which one of the 256 icons represents it), this could potentially allow for extended graphics sets of more than 256 icons.
• And if you ever allow for different-size icons, it could be neat for the supposedly 3-tile wide wagons and forgotten beasts that currently look rather underwhelming.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on January 19, 2012, 01:21:03 pm

Quote from: Iceco on January 13, 2012, 02:59:20 pm

If I understand it right, the main incentive for this utility was increasing FPS by offloading the graphics to the GPU (but with neat consequences like the SHADER mode)?

This was the original motivation, and in fact the speedup provided is noticeable, although not quite significant on latest hardware.

Quote from: Iceco on January 13, 2012, 02:59:20 pm

Can it draw multiple tiles (from the tileset) + characters (from the characters set), or just 1 tile and 1 character.
I think it would be interesting to be able to draw multiple tiles on top of each other (f.e. the floor tile + the rope lying on top of it). I think it would probably need specially designed tilesets, but you already have Mayday's interest.

This was originally a side-feature. However, it turned out to be impossible to implement without hijacking all of map drawing from the game engine. So it currently does not do that, while I wait for when either I overcome my (busy|lazi)ness, or there's next DF release (that would most certainly require rework of the entire renderer anyway)

Quote from: Iceco on January 13, 2012, 02:59:20 pm

And if you ever allow for different-size icons, it could be neat for the supposedly 3-tile wide wagons and forgotten beasts that currently look rather underwhelming.

I think it's up to the game engine to support multiple-tile creatures first before they can be drawn.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on February 08, 2012, 05:18:37 pm

I'm back.

First, I pushed mouse fix and a crash fix. It crashed on second texture reset, so never while playing, thus not quite important; I noticed it only accidentally.
No binary upload yet.

Second,

Code: [Select]

>>> import memxml as mx
>>> mx.init()

...

>>> mx=reload(mx)
>>> mx.init()
>>> for crea in mx.crea_vector:
...   if crea.contents.name.has_name:
...     print crea.contents.name.first_name
...
iden
dastot
zulban
ilral
edem
id
tulon
>>>

This is embedded Python interpreter, using dfhack's Memory.xml parser (written in Python of course) and some ctypes magic to read meaningful stuff from the game.
As you can see, using Python's module reload feature it is not needed to ever restart the game while debugging and writing code, unless one manages to crash it.

It will be used in getting to know game internals and prototyping the map draw code.

The branch will be pushed to the github as soon as I clean it up somewhat.

Title: Re: [PRINT_MODE:SHADER]
Post by: Mike Mayday on February 09, 2012, 09:25:59 am

*crowds cheering*

*girls fainting*

*mayday wipes a single tear of joy from his right eye*

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on February 12, 2012, 11:36:33 am

This turns out to become a full-graphics implementation. Sorry about that.

Rendering:

The rendering engine is a primitive blitter implementation in GLSL.
It has one defined operation: given two tile textures, starting alpha and
ending alpha, it blits first texture with its alpha, then second texture
with its alpha.

Inputs to the blitter comprise:

• a texture album containing all needed textures of uniform size
• blitter "program", a 3D texture, width and height correspond to the tile type, while depth corresponds to the current frame number
• screen data represented as several layers of tile types.
• current frame number

Screen data consists, provisionally, of the following layers, each to be blitted on top of previous.

• rock: floors, walls, ramps; both natural and constructed
• rock: veins and gem clusters
• grass, moss, farms, vegetation
• other constructions: doors, tables, workshop components, traps, etc
• items: which to draw, one per tile
• contaminants
• creatures
• magma/water levels
• mist, dust, smoke, miasma
• designations and zones: piles, zones, burrows, mining/construction/wet|warm stone indicators

Graphic data is defined in the following format, which is intentionally raws-like.
Example definition

Code: [Select]


[TILE_PAGE:pagename]
    [FILE:page/name.png]
    [TILE_DIM:16:16]
    [PAGE_DIM:16:16]
    [DEF:cactus:10,6]
    [DEF:cheap_ore:132]
    [DEF:cheap_gem:168]
    [DEF:best_ore:9,12]
    [DEF:cage:1,3]

[MAT:DEFAULT]
    [WALL:SOLID]
[CEL:pagename:8,3]
    [WALL:ROUGH]
[CEL:pagename:8,3]
    [WALL:ROUGH:NS]
[CEL:pagename:11,13]

[MAT:GOLD]
    [VEIN]
[BLIT:best_ore]
[BLEND:FFD700]
[KEY:24]
[BLIT:best_ore]
[BLEND:AF8700]
[KEY:48]
    [CAGE]
[BLIT:cage]
[BLEND:FFD700FF]
[KEY:24]
[BLIT:cage]
[GLOW:FFD70080]
[KEY:48]

[MAT:SILTY_CLAY]
    [DEFAULT]
[BLEND:FBEC5D]


The above code defines first a texture set, quite like the existing creature graphics do.

One distinction is definition of aliases with DEF tag, and tile addressing by both tile number and tile coordinates.

MAT:DEFAULT definition provides a default mapping between various tiles and the texture set.
WALL:SOLID defines not-yet-mined tile, while WALL:ROUGH defines a wall not smoothed, in a end-tile position.
WALL:ROUGH:NS defines a 'vertical' wall, that is, one that goes from north to south. NSEW in place of it will define a wall cross.

MAT:GOLD defines a vein, and a cage. Vein is the symbol drawn on top of base rock tile. Cage is an item.
As defined, both will glow - alternate between bright and dim gold color with the period of 2 seconds.
Here, operations to draw a tile are interspersed with KEY tag which can be read as 'key frame at frame number such and such'.
Animation is fixed to 12  FPS. Total length of an animation is to be limited by 128 frames which is about 10 seconds.

MAT:SILTY_CLAY definition just says - take corresponding tile from MAT:DEFAULT def and apply color with the BLEND operation.
This is roughly the same thing the game does already.

In fact, BLEND is just a BLIT of solid-color texture, thus they are the same to the blitter. GLOW is the same as BLEND, but transitions to and from a GLOW cel are smoothed by linearly changing alpha from previous BLEND value to the GLOW value, and then to the next BLEND value. When loading graphics, those definitions are compiled into blitter input code for all 128 frames.

BLEND is first applied to the BLIT source, then the resulting image is blended on top of previous layer respecting resulting per-pixel alpha.

There will be distinct tile indices - that is, tags undeneath the MAT tag - for all items/item classes present in the game, with variants for rotating and stopped axles, windmills and such, busy vs idle workshops, passabe/forbidden doors, siege engines and whatever we'll come up with.

One caveat is that this would be quite videoram-hungry. However, with budget video cards having upwards of 512MB on board and more than enough gpu power nowadays, this won't be a problem. For those that don't fancy fancy graphics, classic renderers, including ncurses, will stay available.

Discuss.

Title: Re: [PRINT_MODE:SHADER]
Post by: Mike Mayday on February 12, 2012, 02:26:43 pm

I can't. I'm speechless. And terrified.

Title: Re: [PRINT_MODE:SHADER]
Post by: Ironhand on February 12, 2012, 04:29:42 pm

Holy crap.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on February 12, 2012, 06:47:39 pm

Now can someone please explain what do those double wall directions in fact mean:

dfhack/library/TileTypes.cpp:

Code: [Select]

       { "smooth stone wall RD2", WALL, STONE, VAR_1, TILE_SMOOTH, "--SS--E-" },
        { "smooth stone wall R2D", WALL, STONE, VAR_1, TILE_SMOOTH, "--S---EE" },
        { "smooth stone wall R2U", WALL, STONE, VAR_1, TILE_SMOOTH, "N-----EE" },
        { "smooth stone wall RU2", WALL, STONE, VAR_1, TILE_SMOOTH, "NN----E-" },
        { "smooth stone wall L2U", WALL, STONE, VAR_1, TILE_SMOOTH, "N---WW--" },
        { "smooth stone wall LU2", WALL, STONE, VAR_1, TILE_SMOOTH, "NN--W---" },
        { "smooth stone wall L2D", WALL, STONE, VAR_1, TILE_SMOOTH, "--S-WW--" },
        { "smooth stone wall LD2", WALL, STONE, VAR_1, TILE_SMOOTH, "--SSW---" },
        { "smooth stone wall LRUD", WALL, STONE, VAR_1, TILE_SMOOTH, "N-S-W-E-" },
        { "smooth stone wall RUD", WALL, STONE, VAR_1, TILE_SMOOTH, "N-S---E-" },
        { "smooth stone wall LRD", WALL, STONE, VAR_1, TILE_SMOOTH, "--S-W-E-" },
        { "smooth stone wall LRU", WALL, STONE, VAR_1, TILE_SMOOTH, "N---W-E-" },
        { "smooth stone wall LUD", WALL, STONE, VAR_1, TILE_SMOOTH, "N-S-W---" },
        { "smooth stone wall RD", WALL, STONE, VAR_1, TILE_SMOOTH, "--S---E-" },
        { "smooth stone wall RU", WALL, STONE, VAR_1, TILE_SMOOTH, "N-----E-" },
        { "smooth stone wall LU", WALL, STONE, VAR_1, TILE_SMOOTH, "N---W---" },
        { "smooth stone wall LD", WALL, STONE, VAR_1, TILE_SMOOTH, "--S-W---" },
        { "smooth stone wall UD", WALL, STONE, VAR_1, TILE_SMOOTH, "N-S-----" },
        { "smooth stone wall LR", WALL, STONE, VAR_1, TILE_SMOOTH, "----W-E-" },

?

Title: Re: [PRINT_MODE:SHADER]
Post by: Rose on February 12, 2012, 10:45:20 pm

each wall tile can be connected two any out of four directions.

{ "smooth stone wall LRUD", WALL, STONE, VAR_1, TILE_SMOOTH, "N-S-W-E-" }, for example, is a + shaped wall.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on February 13, 2012, 04:35:39 am

Quote from: Japa on February 12, 2012, 10:45:20 pm

each wall tile can be connected two any out of four directions.

{ "smooth stone wall LRUD", WALL, STONE, VAR_1, TILE_SMOOTH, "N-S-W-E-" }, for example, is a + shaped wall.

This I understood. But what does mean double-N in

Code: [Select]

        { "smooth stone wall RU2", WALL, STONE, VAR_1, TILE_SMOOTH, "NN----E-" },


Title: Re: [PRINT_MODE:SHADER]
Post by: Knight Otu on February 13, 2012, 05:39:15 am

Walls are sometimes represented as ╖╕╜╛╙╘╒╓ at their end. Presumably the NN distinguishes the two-line end and the single-line end in some fashion. Given the other wall types, the doubled direction probably is the single-line end. Maybe Baughn knows more, though.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on February 14, 2012, 11:44:01 am

Thanks Otu.

Now in the meanwhile we've got a new release. I have backported truetype changes to work with 31.25. Unfortunately, there can't be a single binary for both just and only because some keybinding ids were inserted/deleted to/from a middle of an enum.

In any case, enjoy:
3401 (http://dffd.wimbli.com/file.php?id=5488)
3125 (http://dffd.wimbli.com/file.php?id=5044)


If it complains about CXX ABI or something like that, rename included libstdc++.so.6.oneiric to libstdc++.so.6 (in libs/ directory)

Title: Re: [PRINT_MODE:SHADER]
Post by: SalmonGod on February 14, 2012, 12:34:37 pm

I just stumbled on this and am perplexed.  I get on a very basic level what this is supposed to do... I think... does it really provide much of a performance boost?... enough to think about setting up a linux install?

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on February 14, 2012, 01:51:34 pm

Quote from: SalmonGod on February 14, 2012, 12:34:37 pm

does it really provide much of a performance boost?

It is noticeable, on maximum zoom-out and when loading game - PRINT_MODE:STANDARD is quite slow when uploading textures. However, it does not significantly raise your FPS (as opposed to GPFS and overall interface smoothness). 

It would be interesting to compare STANDARD and SHADER on low-power machines, like mid-tier laptops. Unfortunately I don't have one.


 

Title: Re: [PRINT_MODE:SHADER]
Post by: Mike Mayday on February 14, 2012, 03:40:36 pm

Wow! So... all the mentioned features are already implemented??

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on February 14, 2012, 05:12:33 pm

Quote from: Mike Mayday on February 14, 2012, 03:40:36 pm

Wow! So... all the mentioned features are already implemented??

I'm not that omnipotent yet.

Title: Re: [PRINT_MODE:SHADER]
Post by: Greendogo on February 14, 2012, 06:09:04 pm

What's this talk of tile aliases?

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on February 14, 2012, 06:45:24 pm

Quote from: Greendogo on February 14, 2012, 06:09:04 pm

What's this talk of tile aliases?

What I posted above is a preliminary format for full-graphic tilesets, which is to be discussed and improved while I write renderer backend.

Title: Re: [PRINT_MODE:SHADER]
Post by: dennislp3 on February 14, 2012, 07:03:49 pm

Posting to watch this! yes...look how productive I am by adding my constructive self to your list of stalkers!

Title: Re: [PRINT_MODE:SHADER]
Post by: peterix on February 15, 2012, 12:25:33 pm

Hello!

You asked me something on IRC while I was asleep and I couldn't reply. So, here:

Quote

[00:00:00] - {Day changed to Wed Feb 15 00:00:00 2012}
[00:30:27] <lxnt> peterix, _Q: I'm working on separating angavrilov's generator and supporting code from dfhack into a standalone lib so as to not be forced to link whole dfhack into libgraphics.so.
[00:30:50] <lxnt> peterix, _Q: any objections?
[00:31:13] <lxnt> peterix, _Q: (to merging this ofc)

Sounds like a good idea! Thing is, I'd like it to still work with the stock precompiled libgraphices just like it works now...

From the technical point of view, you still need a good chunk of DFHack, as it needs to init some stuff - it needs to determine the version of DF and load up the appropriate version info (really an extension of DF's symbol table) from an xml file. All you'd be cutting out is the console and the plugin API, which are rather minimal anyway. The modules are helpful too, providing some abstractions on top of DF's structures...

On the other hand, the hackish way DFHack interfaces with DF's execution could be much improved. Right now, DFHack hooks some SDL calls, which isn't exactly ideal. It would be nice to be able to paint into DF's window and sync with the graphics thread for example. Or have libgraphics directly call Core methods.

Anyway, more details could certainly help.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on February 15, 2012, 02:10:52 pm

Quote from: peterix on February 15, 2012, 12:25:33 pm

Sounds like a good idea! Thing is, I'd like it to still work with the stock precompiled libgraphices just like it works now...

It is most certainly my intention to not disrupt dfhack operation in any way.

Quote from: peterix on February 15, 2012, 12:25:33 pm

From the technical point of view, you still need a good chunk of DFHack, as it needs to init some stuff - it needs to determine the version of DF and load up the appropriate version info (really an extension of DF's symbol table) from an xml file. All you'd be cutting out is the console and the plugin API, which are rather minimal anyway. The modules are helpful too, providing some abstractions on top of DF's structures...

I abstracted out whatever df-structures need from dfhack into

Code: [Select]

class essentials {
public:
    virtual std::string readClassName(void *) = 0;
    virtual void lock() = 0;
    virtual void unlock() = 0;
    virtual std::map<std::string, void *>& getVtable() = 0;
    virtual void *getGlobal(const char *name) = 0;
};

I mostly split dfhack and df-structures already, moving them into depends. Now I'm cleaning up resulting bugs.

Since the code that prepares data for a frame to be rendered needs to run as fast as practical, wrappers are out of question.

Since df-structures are in fact inseparable from DF version, I expect Memory.xml being removed from dfhack runtime, globals' and vtable addresses being moved into df-structures. Only code checking that the DF version is correct/compatible with the df-structures build is in fact needed; addresses can be compiled in since it is most likely that each DF point release would require verification of entire df-structures xml data, baking a corresponding release  compared to that is trivial.

Quote from: peterix on February 15, 2012, 12:25:33 pm

On the other hand, the hackish way DFHack interfaces with DF's execution could be much improved. Right now, DFHack hooks some SDL calls, which isn't exactly ideal. It would be nice to be able to paint into DF's window and sync with the graphics thread for example. Or have libgraphics directly call Core methods.

Anyway, more details could certainly help.

Well, I most certainly can define some weak no-op symbols (in my libgraphics.so) to be called wherever you like, so that when dfhack is preloaded, it will be able to substitute its own. I don't know much if anything about windows in this regard above suspicion that making a libgraphics.dll would be hell of a headache.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on February 22, 2012, 08:28:17 pm

Code: [Select]


# lxnt has created  fgtestbed , a lump of  python code
# all masterwork is of  dubious  quiality.
# it is studded with  bugs
# it is encrusted with  bugs
# it menaces with spikes of  bugs
# it smells of  bugs
# a picture of  giant bug  is engraved on its side
# ...
# lxnt cancels Debug: interrupted by  bug


https://github.com/lxnt/fgtestbed

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on February 24, 2012, 08:46:50 pm

So it works at last. Had to redo it in glsl 1.30 though.

This ulopc currently demonstrates stunning animated map display using curses_square_16x16.png . Marvelous. I also found my proposed raws format unfit for duty, and map dumping code obviously does it wrong.

Unleash your talents on animating stone walls right now!

https://github.com/lxnt/fgtestbed/downloads

needs python, pygame, pyopengl and OpenGL 3.0 / GLSL 1.30

Title: Re: [PRINT_MODE:SHADER]
Post by: xordae on February 24, 2012, 10:03:05 pm

Posting to watch.

Title: Re: [PRINT_MODE:SHADER]
Post by: guale on February 25, 2012, 01:38:47 am

I have no idea how I never saw this before, given how much of a serial lurker I am. I just read through the whole thread (skimming most of the actual code since it goes way over my head) and I have to say you are quite the badass, lxnt. I'm hoping this will give me the needed motivation to get a proper install of Ubuntu going on my new machine sometime this weekend and if I do I'll most certainly give it a go.

Title: Re: [PRINT_MODE:SHADER]
Post by: Mike Mayday on February 25, 2012, 05:27:50 am

Gonna set up some portable Ubuntu and try this today.
Don't get your hopes up, I'm terrible at setting up a proper software environment.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on February 25, 2012, 05:53:03 am

Quote from: Mike Mayday on February 25, 2012, 05:27:50 am

Gonna set up some portable Ubuntu and try this today.
Don't get your hopes up, I'm terrible at setting up a proper software environment.

You don't need ubuntu to try this yet - it's pure python.
Install this: http://www.python.org/download/releases/2.7.2/
then this: http://pygame.org/download.shtml
then this: http://pyopengl.sourceforge.net/documentation/installation.html

never tried this, but should be on par or easier than setting up Ubuntu.

Title: Re: [PRINT_MODE:SHADER]
Post by: Krakarn on February 25, 2012, 07:18:15 am

Actually I already tried it on windows, additional package required was numpy. Also, the "from o import cx" line was not working. Also, there was a runtime error concerning casting int as uint in a gl function.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on February 25, 2012, 11:16:53 am

aw,
o.cx isn't used by default, you can delete or comment out the

Code: [Select]

from o import cx as glnames
line in fgtestbed.py

Quote

runtime error concerning casting int as uint in a gl function.

this one is interesting though. Can you post the error?

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on February 25, 2012, 02:19:13 pm

new and improved version (re-download from the github).

works with full map dumps, only limit on zoom-out is minimum 2x2 tile size as drawn.

two map dumps to look at:
 5x5 embark  (http://dffd.wimbli.com/file.php?id=5692)
 16x16 embark  (http://dffd.wimbli.com/file.php?id=5693)

These are full map dumps, smaller has 180 z-levels, larger - 118. Decompress files aside the fgtestbed.py, run it like:

Code: [Select]

./fgtestbed.py bigdump

When you see a black screen - don't panic, zoom out, scroll around, change levels. Supplied raws just don't define enough tiles, so most are drawn black.

The big dump even right-mouse-button scrolls acceptably on my machine. Most probably because of SSD disk. Expect lag and disk thrashing if you don't have one.

Title: Re: [PRINT_MODE:SHADER]
Post by: Krakarn on February 25, 2012, 02:44:05 pm

fgtestbed.py, line 463

RuntimeError: Link failure (0): Vertex info
---------
0(44) : warning C7533: global variable gl_ModelViewProjectionMatrix is deprecated after version 120
0(82) : error C7011: implicit cast from "int" to "uint"
0(82) : error C7011: implicit cast from "int" to "uint"

Fragmet info
------------
0(48) : warning C7533: global variable gl_FragColor is deprecated after version 120



--
Also, those dumps you posted gives the same error for me.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on February 25, 2012, 03:03:15 pm

Quote from: Krakarn on February 25, 2012, 02:44:05 pm

--
Also, those dumps you posted gives the same error for me.

Please replace the line

Code: [Select]

blend = vec4(insn.z >> 8, insn.z & 0xffu, insn.w >> 8, insn.z & 0xffu) / 256.0;

with

Code: [Select]

   
blend = vec4(insn.z >> 8u, insn.z & 0xffu, insn.w >> 8u, insn.w & 0xffu) / 256.0;

in the file three.vs, try again and let me know.

Title: Re: [PRINT_MODE:SHADER]
Post by: Krakarn on February 25, 2012, 07:03:41 pm

Ok, the program works now but it looks like a mess of pink letters. Am I supposed to look at something here?

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on February 25, 2012, 09:19:17 pm

Quote from: Krakarn on February 25, 2012, 07:03:41 pm

Ok, the program works now but it looks like a mess of pink letters.

Many thanks for verifying it works somewhere else than on my box.

Pink letters are in fact "animated" tiles showing their types and material names .

Quote from: Krakarn on February 25, 2012, 07:03:41 pm

Am I supposed to look at something here?

Nothing in particular unless you're into tileset modding. Cavern outlines in the big dump are nice though.

You see, to replace those pink letters with something more appropriate, this something must be defined somehow.
At this stage the code draws only natural walls/ramps/floors and constructions - walls, stairs and such. 
Even this small subset is several hundred variants given lots of different rocks in the game.

The raws format I came up is not up to the task. Something better must be designed, but I have no idea how it should look like to be useful to the artists.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on February 28, 2012, 09:11:52 pm

Current version :

• reads standard DF raws and init.txt thus picks up any installed 3rd-party tilesets.
• panning finally finally fixed.
• small hud shows whatever's under mouse
• configurable number of zlevels to draw under current, with darkening - looks good at 4
• layer rock, veins, soil do work, rest of materials need some logic coded in
• grass has weird colors

Work continues at dumping trees, buildings, items and creatures.

Please re-download the small dump (http://dffd.wimbli.com/file.php?id=5692), older version is broken.

Code: [Select]

lxnt@bigbox:~/00DFGL/fgtestbed$ ./fgtestbed.py   ../dfa_linux/ smalldump
353 mats  13071 defined tiles, assembling...
hashtable 4096K code 206K
font: 128x3 16x16 tiles, 2048x48, 384K


Title: Re: [PRINT_MODE:SHADER]
Post by: Greendogo on March 01, 2012, 04:49:51 am

This is pretty cool!  What exactly is this?  A replacement for DF's default drawing method- a sort of 2D visualizer?

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on March 01, 2012, 07:26:24 am

Quote from: Greendogo on March 01, 2012, 04:49:51 am

A replacement for DF's default drawing method- a sort of 2D visualizer?

See the top post for this.

fgtestbed is work in progress on removing 256-tile restriction for tilesets.

Title: Re: [PRINT_MODE:SHADER]
Post by: Krakarn on March 02, 2012, 04:00:16 am

I tried it out but it seems an xml file is missing (df.buildings.xml).
I added an empty file and tried it again (with a modded df folder) and this time I found a bug: Your rawsparser is not ignoring the ':' (a tile character) occurences when parsing lines, so it messes up the parsing and gives an out of index error.

Also, smalldump.mats should be named smalldump.materials (because that's what it becomes in the code, or change the code so it becomes smalldump.mats).

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on March 03, 2012, 02:29:16 pm

Thank you for testing.

The code is now somewhat unusable, because I'm working hard on releasing a version based entirely on raw-type files instead of hardcoded material - tiletype mappings and such. I hope to release somewhat stable version today or tomorrow, which should allow people to experiment with replacing standard tiles and animation.

Title: Re: [PRINT_MODE:SHADER]
Post by: malvado on March 03, 2012, 06:36:06 pm

Awesome project!
Would it be possible for you to show us some images with one of the tilesets thats avaibable (ironhand , mayday etc)?
I personally will be really happy when this is implemented later on ^_^

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on March 05, 2012, 06:32:54 pm

Quote from: malvado on March 03, 2012, 06:36:06 pm

Would it be possible for you to show us some images with one of the tilesets thats avaibable (ironhand , mayday etc)?

They ain't that great, in fact liquids are plain ugly, though translucent, and most tiles aren't drawn at all as of last working version. And there isn't any working version left.

I wound up having to implement material template instantiation for the plant materials, that's why it's taking longer than anticipated, DF raws format being quite peculiar. Can only tremble in horror thinking of  what it would take for creature-derived materials. But it should be possible to define unique graphics for any item/base material/quality/encrustions and enscriptions combination in the end.

Title: Re: [PRINT_MODE:SHADER]
Post by: Matz05 on March 05, 2012, 09:21:56 pm

Wow. A proper graphics engine for DF. I salute you!

Keep up the good work, this could be the next LNP right here once it becomes playable.

Title: Re: [PRINT_MODE:SHADER]
Post by: Vandala on March 06, 2012, 11:12:09 am

Oh I am so gonna keep track of this.

Awesome work man.

Title: Re: [PRINT_MODE:SHADER]
Post by: dennislp3 on March 06, 2012, 02:51:05 pm

Quote from: lxnt on March 05, 2012, 06:32:54 pm

Quote from: malvado on March 03, 2012, 06:36:06 pm

Would it be possible for you to show us some images with one of the tilesets thats avaibable (ironhand , mayday etc)?

They ain't that great, in fact liquids are plain ugly, though translucent, and most tiles aren't drawn at all as of last working version. And there isn't any working version left.

I wound up having to implement material template instantiation for the plant materials, that's why it's taking longer than anticipated, DF raws format being quite peculiar. Can only tremble in horror thinking of  what it would take for creature-derived materials. But it should be possible to define unique graphics for any item/base material/quality/encrustions and enscriptions combination in the end.

I dont want an image for how pretty it is...I want to see something in action. At least for like updates to see whats changed.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on March 06, 2012, 05:04:55 pm

You can watch git repo at https://github.com/lxnt/fgtestbed (https://github.com/lxnt/fgtestbed). It's so much work in progress I can't guarantee anything that's there stays the way it is for any amount of time, but you can get general idea of what's happening from commit messages and comments, esp. in files undef fgraws directory.

I expect there would be something to play with by 9th.

Title: Re: [PRINT_MODE:SHADER]
Post by: Mike Mayday on March 08, 2012, 02:26:40 pm

Hey lx (Lex?), since you've apparently already coded viewing multiple layers, I imagine that perspective will be a cakewalk, eh?
http://mayday.w.staszic.waw.pl/~mayday/upload/perspective.jpg

Title: Re: [PRINT_MODE:SHADER]
Post by: Mike Mayday on March 08, 2012, 03:07:53 pm

Also I wanted to install all the dependencies in preparation and I think I'm having problems, could you gents help me out?
Got Python27, got Pygame, then I downloaded http://pypi.python.org/pypi/setuptools and then did c:\python26\scripts\easy_install.exe PyOpenGL PyOpenGL-accelerate
but that resulted in:

Spoiler (click to show/hide)

C:\Python27\Scripts>easy_install.exe PyOpenGL PyOpenGL-accelerate
Searching for PyOpenGL
Reading http://pypi.python.org/simple/PyOpenGL/
Reading http://pyopengl.sourceforge.net
Reading https://sourceforge.net/project/showfiles.php?group_id=5988&package_id=6
035
Reading http://pyopengl.sourceforge.net/ctypes/
Reading http://sourceforge.net/project/showfiles.php?group_id=5988
Best match: PyOpenGL 3.0.2a5
Downloading http://pypi.python.org/packages/source/P/PyOpenGL/PyOpenGL-3.0.2a5.z
ip#md5=18cd8e5f8b57fa2d091ac07b0de35dfd
Processing PyOpenGL-3.0.2a5.zip
Running PyOpenGL-3.0.2a5\setup.py -q bdist_egg --dist-dir c:\users\alamar\appdat
a\local\temp\easy_install-uy2h41\PyOpenGL-3.0.2a5\egg-dist-tmp-wbgyje
C:\Python27\lib\distutils\dist.py:267: UserWarning: Unknown distribution option:
 'use_2to3'
  warnings.warn(msg)
warning: no previously-included files matching '*.odt' found anywhere in distrib
ution
warning: no previously-included files matching '*.odp' found anywhere in distrib
ution
warning: no previously-included files matching '.cvsignore' found anywhere in di
stribution
warning: no previously-included files matching '*.diff' found anywhere in distri
bution
warning: no previously-included files found matching 'src\*.h'
warning: no previously-included files found matching 'src\*.xml'
warning: no previously-included files found matching 'src\*.zip'
warning: no previously-included files found matching 'src\*.pdf'
warning: no previously-included files found matching 'src\*.zip'
warning: no previously-included files found matching 'src\*.txt'
warning: no files found matching 'src\win32deps.py'
warning: no files found matching 'src\toglinstall\get_togl.py'
warning: no files found matching 'ChangeLog.txt'
warning: no previously-included files found matching 'OpenGL_accelerate'
zip_safe flag not set; analyzing archive contents...
OpenGL.wrapper: module references __file__
OpenGL.platform.ctypesloader: module references __file__
OpenGL.Tk.__init__: module references __file__
Adding pyopengl 3.0.2a5 to easy-install.pth file

Installed c:\python27\lib\site-packages\pyopengl-3.0.2a5-py2.7.egg
Processing dependencies for PyOpenGL
Finished processing dependencies for PyOpenGL
Searching for PyOpenGL-accelerate
Reading http://pypi.python.org/simple/PyOpenGL-accelerate/
Best match: PyOpenGL-accelerate 3.0.2a1
Downloading http://pypi.python.org/packages/source/P/PyOpenGL-accelerate/PyOpenG
L-accelerate-3.0.2a1.zip#md5=099a787babe44da9a250690eb45136a6
Processing PyOpenGL-accelerate-3.0.2a1.zip
Running PyOpenGL-accelerate-3.0.2a1\setup.py -q bdist_egg --dist-dir c:\users\al
amar\appdata\local\temp\easy_install-tprwau\PyOpenGL-accelerate-3.0.2a1\egg-dist
-tmp-fcwrdg
Unable to import numpy, skipping numpy extension building
Unable to import Numeric, skipping Numeric extension building
error: Setup script exited with error: Unable to find vcvarsall.bat

And now fgtestbed is crying that it can't find numpy :/

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on March 08, 2012, 04:35:09 pm

For numpy you go here (http://www.scipy.org/Download).

With PyOpenGL's problems I can't help you, I haven't had a windows installation in about 3 years now.
I think Krakarn (http://www.bay12forums.com/smf/index.php?action=profile;u=56509) managed to run it and can help you.

I pushed a version that draws 'something' while pulling most of info from DF's raws, at last, find it at github.
A dump for it to show is here (http://dffd.wimbli.com/file.php?id=5692)

Note that it needs 31.25 raws to function:

Code: [Select]

./fgtestbed.py  ../df_linux ./fugr.dump ./fgraws/

where ../df_linux is path to 31.25 directory and ./fugr.dump is the uncompressed dump.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on March 08, 2012, 04:35:59 pm

Quote from: Mike Mayday on March 08, 2012, 02:26:40 pm

I imagine that perspective will be a cakewalk, eh?

In fact, yes. But I want to make it work as is first.

Title: Re: [PRINT_MODE:SHADER]
Post by: Mike Mayday on March 08, 2012, 04:38:15 pm

Quote from: lxnt on March 08, 2012, 04:35:59 pm

Quote from: Mike Mayday on March 08, 2012, 02:26:40 pm

I imagine that perspective will be a cakewalk, eh?

In fact, yes. But I want to make it work as is first.

Of course! I meant- in the future!

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on March 08, 2012, 08:37:06 pm

a screenshot (http://dffd.wimbli.com/file.php?id=5818)

Title: Re: [PRINT_MODE:SHADER]
Post by: Matz05 on March 08, 2012, 10:00:54 pm

Nice! Looks like it is coming together, once there is enough community involvement to make skins...  8)

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on March 09, 2012, 10:04:51 am

A bunch of bugfixes has been pushed onto github. Vegetation, gems and non-material tiles (openspace, driftwood, etc) are now drawn correctly.

Compatible dumps uploaded to http://dffd.wimbli.com/file.php?id=5692 (http://dffd.wimbli.com/file.php?id=5692). Note that previously uploaded dumps won't work due to (fixed) bug in the dumping code.

libgraphics.so with integrated dumper for 3125 is at http://dffd.wimbli.com/file.php?id=5763 (http://dffd.wimbli.com/file.php?id=5763) Press F12 to dump.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on March 11, 2012, 08:20:00 am

For this project to move on I think we need a base tileset to work off of. Its tile size (16x16? 20x20? 24x24?) should be decided upon right now, and a standard (16x16 tiles) tileset (tilepage) should be made available asap.

Then as I move on to implementing buildings and items, I will need their definitions - that is how to draw them.

After that is some drawable shape, a decision must be made on how creatures are drawn - are they smaller than tiles, and if that's the case where to draw them on the underlying tile.

I also haven't got an idea on how to draw heaps of body parts lying around and pools of blood/vomit/whatnot that result from pounding a 'force of darkness' with couple of squads of marksdwarves and a catapult battery, and then releasing a butcher squad to finish them off.

But first let's decide on base tileset and its dimensions.

Title: Re: [PRINT_MODE:SHADER]
Post by: Vattic on March 11, 2012, 09:15:26 am

This sounds fantastic. Are you planning on having more context sensitive tiles that work like walls currently do? It would be great for things like this.
(http://i12.photobucket.com/albums/a226/Figgin/Misc/2DEdgeTileExample.png?t=1251254698)

You could then have ore that looks like it sits within the rock around it or even have rough stone walls overhang into open tiles.

Title: Re: [PRINT_MODE:SHADER]
Post by: Mike Mayday on March 11, 2012, 09:54:07 am

Quote from: lxnt on March 11, 2012, 08:20:00 am

For this project to move on I think we need a base tileset to work off of. Its tile size (16x16? 20x20? 24x24?) should be decided upon right now, and a standard (16x16 tiles) tileset (tilepage) should be made available asap.

Then as I move on to implementing buildings and items, I will need their definitions - that is how to draw them.

After that is some drawable shape, a decision must be made on how creatures are drawn - are they smaller than tiles, and if that's the case where to draw them on the underlying tile.

I also haven't got an idea on how to draw heaps of body parts lying around and pools of blood/vomit/whatnot that result from pounding a 'force of darkness' with couple of squads of marksdwarves and a catapult battery, and then releasing a butcher squad to finish them off.

But first let's decide on base tileset and its dimensions.

I you're going to obliterate the 80 tile minimum, I definitely vote for 32px. That's the minimal size in which I feel really free to pixel the way I want.
Otherwise 20px I guess?
As soon as we decide on the dimensions, I'm ready to produce any graphics you need.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on March 11, 2012, 11:09:25 am

Quote from: Vattic on March 11, 2012, 09:15:26 am

Are you planning on having more context sensitive tiles that work like walls currently do? It would be great for things like this.

Um. Haven't thought about this aspect. It would require some preprocessing, but I guess in the worst case I can make a hotkey to turn it off if FPS is hurt. Otherwise, I see no problem with this.

Quote from: Mike Mayday on March 11, 2012, 09:54:07 am

I you're going to obliterate the 80 tile minimum,

There will be no map window grid dimensions limits apart from those that are due to hardware, since at least some cards can't draw pixel sprites above some size (not sure though, my current can draw from 1px to 16384px, and I think the hd4870 had upper limit of 8192).
In other words, you won't have a monitor setup that would be able to display all of a single tile at maximum zoom.

In fact, it is possible to  switch tile/graphic sets at runtime, for example using smaller graphics for zoom-outs instead of plain linear interpolation, though that's for the future too.

Quote from: Mike Mayday on March 11, 2012, 09:54:07 am

As soon as we decide on the dimensions, I'm ready to produce any graphics you need.

I'm not sure if this dimensions questions for the first fg-set it that much an issue as I thought. So please go ahead with 32x32 and give me a 16x16 tile standard fontpage, and graphics for up/down stairway for a start. (I sure hate those X-es instead of stairways).
Then, I think, the driftwood tile can be redrawn, and maybe more diversity in tree tiles can be injected. A good example of simple animation
would be trees' leaves and branches swinging with the wind.

Also I'm not quite sure how to draw river tiles - as opposed to ocean/lakes which are just open space with 7/7 water, these are dedicated tiletypes with direction (see tilesets.txt). I think some animation can be put there too, or at least, some graphics differing by direction.

I discovered an issue with windows' version of mmap(), so my code does not work on windows yet. In the meanwhile, I had a degree of success installing dependencies under Wine:

Code: [Select]

1. python 2.7.2 32-bit msi http://python.org/download/releases/2.7.2/
2. numpy-1.6.1-win32-superpack-python2.7.exe http://sourceforge.net/projects/numpy/files/NumPy/1.6.1/
3. Python Imaging Library 1.1.7 for Python 2.7 http://www.pythonware.com/products/pil/index.htm
4. pygame-1.9.1.win32-py2.7.msi http://pygame.org/download.shtml
5. setuptools-0.6c11.win32-py2.7.exe  http://pypi.python.org/packages/2.7/s/setuptools/setuptools-0.6c11.win32-py2.7.exe
6. c:\python27\scripts\easy_install.exe -i http://c.pypi.python.org/simple PyOpenGL PyOpenGL-accelerate

the "-i http://c.pypi.python.org/simple " part in the last step is due to PyPi being down today.
the stuff being 32bit and not 64bit is because 64bit Python .msi refuses to install under Wine (known issue).

Title: Re: [PRINT_MODE:SHADER]
Post by: Mike Mayday on March 11, 2012, 11:27:49 am

Quote from: lxnt on March 11, 2012, 11:09:25 am

I'm not sure if this dimensions questions for the first fg-set it that much an issue as I thought. So please go ahead with 32x32 and give me a 16x16 tile standard fontpage, and graphics for up/down stairway for a start. (I sure hate those X-es instead of stairways).

I understand the tilepage is supposed to be for vanilla raws? Am I to place the up/down stairway icon on the tilepage (at 'X') or should it be separate?

Quote from: lxnt on March 11, 2012, 11:09:25 am

Then, I think, the driftwood tile can be redrawn, and maybe more diversity in tree tiles can be injected. A good example of simple animation
would be trees' leaves and branches swinging with the wind.

I'd hold off on animation until we've got all the static graphics working, but if you want to test it, I'll animate a tree, np.

Quote

Also I'm not quite sure how to draw river tiles - as opposed to ocean/lakes which are just open space with 7/7 water, these are dedicated tiletypes with direction (see tilesets.txt). I think some animation can be put there too, or at least, some graphics differing by direction.

Animating a river with proper directions is somewhat out of my area of expertise (I'm actually a noob when it comes to pixelart) but we'll see about it!.

BTW, I'm on 64bit Win7, will there be any trouble? SHould I have installed 32bit Python?

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on March 11, 2012, 12:25:30 pm

Quote from: Mike Mayday on March 11, 2012, 11:27:49 am

I understand the tilepage is supposed to be for vanilla raws? Am I to place the up/down stairway icon on the tilepage (at 'X') or should it be separate?

I'd prefer to have new graphics on a separate tilepage. This way superiority of the fg-mode can be made to look more overwhelming :)

just stuff'em into a separate png, I'll upload the modified fg-raws so you can look how it's done.

Quote from: Mike Mayday on March 11, 2012, 11:27:49 am

I'd hold off on animation until we've got all the static graphics working, but if you want to test it, I'll animate a tree, np.

No problem, I just wanted to show how it's done in the fg-raws format.

Quote from: Mike Mayday on March 11, 2012, 11:27:49 am

BTW, I'm on 64bit Win7, will there be any trouble? SHould I have installed 32bit Python?

Honestly, no idea at all. I posted what worked for me under 64-bit Wine on 64-bit linux. BTW I pushed fixed code to the github and dumps to the dffd, and it draws stuff same way as under linux. I guess since 32-bit python works for me under Wine64, it should work under win64 too.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on March 11, 2012, 12:27:55 pm

Quote from: Mike Mayday on March 11, 2012, 11:27:49 am

Animating a river with proper directions is somewhat out of my area of expertise (I'm actually a noob when it comes to pixelart) but we'll see about it!.

I thought about something to show which direction the water is flowing, in a translucent way. No idea how to do it though.

Title: Re: [PRINT_MODE:SHADER]
Post by: Mike Mayday on March 11, 2012, 01:11:07 pm

Oh ok.
But wait, is the main tileset supposed to be just ASCII then? Pure text symbols?

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on March 11, 2012, 01:42:35 pm

Quote from: Mike Mayday on March 11, 2012, 01:11:07 pm

But wait, is the main tileset supposed to be just ASCII then? Pure text symbols?

No way. It should be something like your, or Phoebus tileset, so that the code can fall back to standard tiles if there's (yet) no other definition.

It's so just because to draw anything at all I had to reference it (the std tileset), so that I can draw most of the map at all.

Remember that apart from stonewall tile, tree/shrub/grass tiles and creatures, everything is hardcoded, so to say, draw a wall, I had to get the graphics from somewhere, so I just got it from the standard tileset. What tile goes from where is described in tilesets.txt.

 

Title: Re: [PRINT_MODE:SHADER]
Post by: Rose on March 11, 2012, 01:49:42 pm

Quote from: Vattic on March 11, 2012, 09:15:26 am

This sounds fantastic. Are you planning on having more context sensitive tiles that work like walls currently do? It would be great for things like this.
(http://i12.photobucket.com/albums/a226/Figgin/Misc/2DEdgeTileExample.png?t=1251254698)

You could then have ore that looks like it sits within the rock around it or even have rough stone walls overhang into open tiles.

Stonesense does have a limited version of this, but it only detects things like open space, ramps, walls, and stairs, so you can't have grass borders, but you can have platform borders.

Title: Re: [PRINT_MODE:SHADER]
Post by: Mike Mayday on March 11, 2012, 02:39:53 pm

Here's some placeholder stuff.
Tileset is upscaled (sadly) Bisasam, icons are mostly from Dustycraft and Mack's Refmap Tilesets.
These are used without permission of their original authors, only as placeholders.

(http://mayday.w.staszic.waw.pl/~mayday/upload/32pxTILESET.png)

And here's some up/down stairs and driftwood:
(http://mayday.w.staszic.waw.pl/~mayday/upload/32pxGRAPHICS.png)

Title: Re: [PRINT_MODE:SHADER]
Post by: Blakmane on March 11, 2012, 04:50:19 pm

just posting so say this is downright amazing :-)

Title: Re: [PRINT_MODE:SHADER]
Post by: Mike Mayday on March 11, 2012, 04:52:34 pm

What should I do with the smooth walls? Keep them symbolic like that? Or just place one graphical icon for all smooth wall tiles for now?

This is it for now, most of those will be replaced by better versions once I get to see them in action (the style needs to be unified)

Title: Re: [PRINT_MODE:SHADER]
Post by: Rose on March 11, 2012, 04:55:44 pm

Man, this makes me want to make a version of stonesense that has the same view as DF. it wouldn't be hard, and you'd be able to have lots more stuff shown.

Title: Re: [PRINT_MODE:SHADER]
Post by: Mike Mayday on March 11, 2012, 05:15:21 pm

Haha, whoops, it just hit me that you probably wanted me to make a tileset according to tilesets.txt, not the standard DF tileset, right?

Title: Re: [PRINT_MODE:SHADER]
Post by: Vattic on March 11, 2012, 05:28:31 pm

Quote from: lxnt on March 11, 2012, 11:09:25 am

Quote from: Vattic on March 11, 2012, 09:15:26 am

Are you planning on having more context sensitive tiles that work like walls currently do? It would be great for things like this.

Um. Haven't thought about this aspect. It would require some preprocessing, but I guess in the worst case I can make a hotkey to turn it off if FPS is hurt. Otherwise, I see no problem with this.

Nice to hear. It makes things look a lot more natural when used right.

Quote from: Japa on March 11, 2012, 01:49:42 pm

Quote from: Vattic on March 11, 2012, 09:15:26 am

This sounds fantastic. Are you planning on having more context sensitive tiles that work like walls currently do? It would be great for things like this.
Image (http://i12.photobucket.com/albums/a226/Figgin/Misc/2DEdgeTileExample.png?t=1251254698)

You could then have ore that looks like it sits within the rock around it or even have rough stone walls overhang into open tiles.

Stonesense does have a limited version of this, but it only detects things like open space, ramps, walls, and stairs, so you can't have grass borders, but you can have platform borders.

Nice, I wasn't aware. I'm sorry to say that despite having started pixeling doing isometric stuff it's not my favourite perspective for gaming so I've not greatly looked into Stonesense. It seems like a lifetime ago that I did anything isometric. Here's the last building I did (http://i40.tinypic.com/4l2jy8.gif), it's a little cringeworthy looking through my old stuff; I think I could do a lot better now.

Quote from: Japa on March 11, 2012, 04:55:44 pm

Man, this makes me want to make a version of stonesense that has the same view as DF. it wouldn't be hard, and you'd be able to have lots more stuff shown.

I'd love something like that. From what I've read this will end up somewhat like that when it's done.

Quote from: lxnt on March 11, 2012, 12:27:55 pm

Quote from: Mike Mayday on March 11, 2012, 11:27:49 am

Animating a river with proper directions is somewhat out of my area of expertise (I'm actually a noob when it comes to pixelart) but we'll see about it!.

I thought about something to show which direction the water is flowing, in a translucent way. No idea how to do it though.

You could do the same as default Minecraft. Have a nice animated texture and scroll it.

Title: Re: [PRINT_MODE:SHADER]
Post by: Mike Mayday on March 12, 2012, 09:29:07 am

LX, I've just had a pretty good idea on textures+tinting- when there's a graphic tile and you want only some parts of it to receive tint (like a stone bookshelf- only the shelves should be tinted, not the books), could you try making it so that only pixels with 0 saturation (R=G=B) get tinted, while others are left unchanged?

This is, once again, for the future.

Another question: thinking of the avarage noob like me here- once the project is done, will you be able to include all the necessary libraries in the download so that installing any additional stuff isn't necessary? (well, except maybe for Python itself).

Title: Re: [PRINT_MODE:SHADER]
Post by: peterix on March 12, 2012, 01:13:42 pm

Hello again.

I'm looking at the changes you did within dfhack, libgraphics and df-structures to get this working and it's clearly the path forward. I'm not sure how well, or even if it will merge properly at this point, because the development in master branches of dfhack and df-structures moved ahead quite a bit since 31.25 support was dropped.

It's possible I'll have to manually redo some of the stuff you did. Anyway, it's the way forward :)

/me delves into the guts of the dfhack build system

Title: Re: [PRINT_MODE:SHADER]
Post by: Mike Mayday on March 12, 2012, 01:46:08 pm

NVM again! I think I got it all to work, the tilesets are in place :)
The program crashes with some mumbling about Quarry bushes and VEGETATION, but I'm using the latest commit and I see you're working now, so let me know when I can check it out!

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on March 12, 2012, 02:43:21 pm

Quote from: Mike Mayday on March 12, 2012, 09:29:07 am

LX, I've just had a pretty good idea on textures+tinting- when there's a graphic tile and you want only some parts of it to receive tint (like a stone bookshelf- only the shelves should be tinted, not the books), could you try making it so that only pixels with 0 saturation (R=G=B) get tinted, while others are left unchanged?

No problem. See, the code has several 'modes' for drawing tiles based on texture, "foreground" and "background" colors:

• -1 - no tile. draws nothing apart from liquids, so underlying tiles are visible
• 0 - no blending (AS_IS)
• 1 - classic

classic is the same mode that stock GL renderers use. It is selected if the cel has "classic" colorspec of fg,bg,br. Otherwise default is 0, where color is taken from the texture. Alpha is forced to 1.0 in both cases, so that solid tiles are not transparent.

Adding a dozen new modes is quite simple.

I see no problem with items, buildings and such, which have floor defined under them and thus can be (and will be) drawn in a separate pass over the whatever floor happens to be there.

Trees, boulders and such, like drifwood have a problem - they are tiles themselves, so I have no data to draw floor under them, and if I don't force alpha to 1.0, lower levels become visible, which is ugly.

Something needs to be invented.

Quote from: Mike Mayday on March 12, 2012, 09:29:07 am

Another question: thinking of the avarage noob like me here- once the project is done, will you be able to include all the necessary libraries in the download so that installing any additional stuff isn't necessary? (well, except maybe for Python itself).

I tried to make a self-contained executable out of this, but failed for now. Will try later.

I made your tileset work, all stuff is in git. It expects the two png files in the '32px' subdirectory where fgtestbed runs - see proto.txt for celpagedefs.

Some bugs still there, shrubs and trees and underwater driftwood. I'm investigating those.

Also fixed a bug in the dump generator where grass material overwrote basic material on a tile, so that you ended up with StoneStairD made out of grass. Fixed dumps uploaded.

Title: Re: [PRINT_MODE:SHADER]
Post by: Mike Mayday on March 12, 2012, 02:47:13 pm

With the latest commit I'm getting:


C:\Users\Alamar\Desktop\fgtestbed-7a>fgtestbed.py 31.25 31.25\raw\objects\

implicitly delimited PLANT_OIL_TEMPLATE in BUSH_QUARRY
implicitly delimited PLANT_SOAP_TEMPLATE in BUSH_QUARRY
Traceback (most recent call last):
  File "C:\Users\Alamar\Desktop\fgtestbed-7a\fgtestbed.py", line 1316, in <modul
e>
    pageman, objcode = raw.work(pa.dfprefix, ['fgraws']+ pa.rawsdir)
  File "C:\Users\Alamar\Desktop\fgtestbed-7a\raw.py", line 1307, in work
    objcode = compiler.compile(materialsets, fgdef.tilesets, fgdef.celeffects, f
gdef.buildings, 1)
  File "C:\Users\Alamar\Desktop\fgtestbed-7a\raw.py", line 243, in compile
    x.append(tilesets[tileset])
KeyError: 'VEGETATION'

DF is in fgtestbed-7a\31.25 of course. I assume I got the arguments wrong, care to help?

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on March 12, 2012, 02:47:52 pm

Quote from: peterix on March 12, 2012, 01:13:42 pm

I'm looking at the changes you did within dfhack, libgraphics and df-structures to get this working and it's clearly the path forward. I'm not sure how well, or even if it will merge properly at this point, because the development in master branches of dfhack and df-structures moved ahead quite a bit since 31.25 support was dropped.

Good news. I plan to merge upstream changes once df34 stabilizes somewhat and move the work over there.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on March 12, 2012, 03:00:25 pm

Quote from: Mike Mayday on March 12, 2012, 02:47:13 pm

With the latest commit I'm getting:

C:\Users\Alamar\Desktop\fgtestbed-7a>fgtestbed.py 31.25 31.25/raw/

Mmhmm. For some reason it did not parse raws in the fgraws directory.
And arguments are wrong, but should not have caused this.

Maybe it's something to do with uppercase vs lowercase in file names. Quick fix in in the git.

Proper way to launch would be

Code: [Select]

C:\Users\Alamar\Desktop\fgtestbed-7a>fgtestbed.py 31.25 dump\brook0.dump
where dump/brook0.dump is a dump from here (http://dffd.wimbli.com/file.php?id=5692).

Quote from: Mike Mayday on March 12, 2012, 02:47:13 pm

implicitly delimited PLANT_OIL_TEMPLATE in BUSH_QUARRY
implicitly delimited PLANT_SOAP_TEMPLATE in BUSH_QUARRY

These two are harmless warnings, ignore them.

Title: Re: [PRINT_MODE:SHADER]
Post by: Mike Mayday on March 12, 2012, 03:07:27 pm

Ok... forgot about the dumps
Now it's:


C:\Users\Alamar\Desktop\fgtestbed-14>fgtestbed.py 31.25 dump/brook0.dump
implicitly delimited PLANT_OIL_TEMPLATE in BUSH_QUARRY
implicitly delimited PLANT_SOAP_TEMPLATE in BUSH_QUARRY
Traceback (most recent call last):
  File "C:\Users\Alamar\Desktop\fgtestbed-14\fgtestbed.py", line 1316, in <modul
e>
    pageman, objcode = raw.work(pa.dfprefix, ['fgraws']+ pa.rawsdir)
  File "C:\Users\Alamar\Desktop\fgtestbed-14\raw.py", line 1307, in work
    objcode = compiler.compile(materialsets, fgdef.tilesets, fgdef.celeffects, f
gdef.buildings, 1)
  File "C:\Users\Alamar\Desktop\fgtestbed-14\raw.py", line 243, in compile
    x.append(tilesets[tileset])
KeyError: 'VEGETATION'

C:\Users\Alamar\Desktop\fgtestbed-14>


Could be I've installed the dependencies wrong?

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on March 12, 2012, 03:18:50 pm

Quote from: Mike Mayday on March 12, 2012, 03:07:27 pm

Could be I've installed the dependencies wrong?

No, that would be ImportErrors all over the place.

I made it print each file name it parses, try it. And please check if  tilesets.txt is in fgraws directory and has [object:full_graphics] on top.

Title: Re: [PRINT_MODE:SHADER]
Post by: Mike Mayday on March 12, 2012, 03:24:27 pm

C:\Users\Alamar\Desktop\fgtestbed>fgtestbed.py 31.25 dump\brook0.dump
Initparser parsed 31.25\data\init\colors.txt
AdvRawsParser parsed 31.25\raw\objects\material_template_default.txt
AdvRawsParser parsed 31.25\raw\graphics\graphics_example.txt
AdvRawsParser parsed fgraws\buildings.txt
AdvRawsParser parsed fgraws\proto.txt
AdvRawsParser parsed fgraws\tilesets.txt
TSParser parsed 31.25\raw\objects\inorganic_metal.txt
TSParser parsed 31.25\raw\objects\inorganic_other.txt
TSParser parsed 31.25\raw\objects\inorganic_stone_gem.txt
TSParser parsed 31.25\raw\objects\inorganic_stone_layer.txt
TSParser parsed 31.25\raw\objects\inorganic_stone_mineral.txt
TSParser parsed 31.25\raw\objects\inorganic_stone_soil.txt
TSParser parsed 31.25\raw\objects\plant_grasses.txt
implicitly delimited PLANT_OIL_TEMPLATE in BUSH_QUARRY
implicitly delimited PLANT_SOAP_TEMPLATE in BUSH_QUARRY
TSParser parsed 31.25\raw\objects\plant_standard.txt
Traceback (most recent call last):
  File "C:\Users\Alamar\Desktop\fgtestbed\fgtestbed.py", line 1316, in <module>
    pageman, objcode = raw.work(pa.dfprefix, ['fgraws']+ pa.rawsdir)
  File "C:\Users\Alamar\Desktop\fgtestbed\raw.py", line 1309, in work
    objcode = compiler.compile(materialsets, fgdef.tilesets, fgdef.celeffects, f
gdef.buildings, 1)
  File "C:\Users\Alamar\Desktop\fgtestbed\raw.py", line 243, in compile
    x.append(tilesets[tileset])
KeyError: 'VEGETATION'

C:\Users\Alamar\Desktop\fgtestbed>

Title: Re: [PRINT_MODE:SHADER]
Post by: Mike Mayday on March 12, 2012, 03:29:39 pm

Quote from: lxnt on March 12, 2012, 02:43:21 pm

Trees, boulders and such, like drifwood have a problem - they are tiles themselves, so I have no data to draw floor under them, and if I don't force alpha to 1.0, lower levels become visible, which is ugly.

Something needs to be invented.

Easiest solution would be to make this tile inherit its floor from one of the neighbouring tiles.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on March 12, 2012, 03:34:25 pm

Stranger and stranger. Try current version. Are you by any chance on IRC, Jabber or Skype?

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on March 12, 2012, 03:39:43 pm

I think I found the bug.

Try adding a dummy tileset at the end of the tilesets.txt, something like:

[tileset:dummy]

Title: Re: [PRINT_MODE:SHADER]
Post by: Mike Mayday on March 12, 2012, 03:45:00 pm

Quote from: lxnt on March 12, 2012, 03:39:43 pm

I think I found the bug.

Try adding a dummy tileset at the end of the tilesets.txt, something like:
[tileset:dummy]

That worked!!
I'm on Skype- mikemayday
Down to chat! ;)

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on March 12, 2012, 05:17:37 pm

Quote from: lxnt on March 09, 2012, 10:04:51 am

libgraphics.so with integrated dumper for 3125 is at http://dffd.wimbli.com/file.php?id=5763 (http://dffd.wimbli.com/file.php?id=5763) Press F12 to dump.

I tried this and it crashes in fortress mode.
Here is a backtrace for the crash.

Code: [Select]

./dfbacktrace
GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /media/Linux_Data/Dwarf_Fortress/Test_Fortress/printmodeshader/current/df_linux/libs/Dwarf_Fortress...(no debugging symbols found)...done.
Starting program: /media/Linux_Data/Dwarf_Fortress/Test_Fortress/printmodeshader/current/df_linux/libs/Dwarf_Fortress
[Thread debugging using libthread_db enabled]
[New Thread 0xf477db70 (LWP 25952)]
[New Thread 0xf3f7cb70 (LWP 25953)]
textures::load(): data/art/Phoebus_20x20.png 320x320 16x16 20x20
textures::load(): data/art/Phoebus_20x20.png 320x320 16x16 20x20
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
set_mode(): SDL_FULLSCREEN: 0
GLEW: 1.5.2
OpenGL vendor: NVIDIA Corporation
OpenGL renderer: GeForce GTX 560 Ti/PCIe/SSE2
OpenGL version: 4.2.0 NVIDIA 295.20
OpenGL GLSL version: 4.20 NVIDIA via Cg compiler
GL_MAX_VERTEX_ATTRIBS=16, needed=7
GL_MAX_VERTEX_UNIFORM_COMPONENTS=4096, needed=9
GL_MAX_FRAGMENT_UNIFORM_COMPONENTS=2048, needed=11
GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS=32, needed=0
GL_MAX_TEXTURE_IMAGE_UNITS=32, needed=3
GL_MAX_VARYING_FLOATS=124, needed=8
GL_MAX_TEXTURE_COORDS=8, needed=2
GL_POINT_SIZE_MIN=0, needed=4
GL_POINT_SIZE_MAX=63, needed=48
GL_ARB_sync: supported
makeansitex(): 2.
Embedded shader set 'rect'
Embedded shader set 'cbr_is_bold' x
Using embedded vertex shader code from 'cbr_is_bold'.
Using embedded fragment shader code from 'cbr_is_bold'.
GL_COMPILE_STATUS: true
GL_COMPILE_STATUS: true
GL_LINK_STATUS: true
GL_VALIDATE_STATUS: true
makeansitex(): 2.
gps_allocate(80, 25)
Resetting textures
texdumpst::init(): allocating 2048x288 (max 64x9 32x32 cells)
accepted font texture (name=1): 2048x288px oa
accepted txco texture (name=3): 64x9px oa
reshape(): got grid 0x0 window -1x-1 tile 20x20 texture_ready=1 stretch=0 snap=0
reshape(): final grid 96x50 window 1920x1000 viewport 1920x1000 Psz 20x20
gps_allocate(96, 50)
set_viewport(): got 1920x1000 out of 1920x1000
Frame drawn in 0 msec
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/dorfs.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/humans.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/goblins.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/elfs.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/koboldz.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/creature_birds.png 100x120 5x6 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/creature_domestic.png 440x120 22x6 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/creature_large_mountain.png 100x120 5x6 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/animals.png 240x600 12x30 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/water.png 80x140 4x7 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/gibbon.png 80x180 4x9 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/beasts.png 120x80 6x4 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/mans.png 240x340 12x17 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/newbeasts.png 120x160 6x8 20x20
Resetting textures
texdumpst::init(): allocating 2048x2656 (max 64x83 32x32 cells)
accepted font texture (name=1): 2048x2656px oa
accepted txco texture (name=3): 64x83px oa
Frame drawn in 0 msec
Embedded shader set 'rect'
Embedded shader set 'cbr_is_bold' x
Using embedded vertex shader code from 'cbr_is_bold'.
Using embedded fragment shader code from 'cbr_is_bold'.
GL_COMPILE_STATUS: true
GL_COMPILE_STATUS: true
GL_LINK_STATUS: true
GL_VALIDATE_STATUS: true
makeansitex(): 2.
reshape(): got grid 96x50 window -1x-1 tile 20x20 texture_ready=1 stretch=0 snap=0
reshape(): final grid 96x50 window 1920x1000 viewport 1920x1000 Psz 20x20
set_viewport(): got 1920x1000 out of 1920x1000

Program received signal SIGSEGV, Segmentation fault.
0xf7a91c94 in __gnu_cxx::new_allocator<df::unit*>::construct (this=0x10086c18,
    __p=0xffffffff, __val=@0xffffca3c)
    at /usr/include/c++/4.6/ext/new_allocator.h:108
108       { ::new((void *)__p) _Tp(__val); }
#0  0xf7a91c94 in __gnu_cxx::new_allocator<df::unit*>::construct (this=0x10086c18,
    __p=0xffffffff, __val=@0xffffca3c)
    at /usr/include/c++/4.6/ext/new_allocator.h:108
#1  0xf7a912fc in std::vector<df::unit*, std::allocator<df::unit*> >::push_back (
    this=0x10086c18, __x=@0xffffca3c) at /usr/include/c++/4.6/bits/stl_vector.h:830
---Type <return> to continue, or q <return> to quit---
#2  0xf7a90f77 in _bicache::update (this=0xffffd0d8, a=..., b=...)
    at /home/lxnt/00DFGL/PMS/print_shader/fugr_dump.cc:172
#3  0xf7a8f7eb in fugr_dump () at /home/lxnt/00DFGL/PMS/print_shader/fugr_dump.cc:388
#4  0xf79be297 in renderer_glsl::reload_shaders (this=0x9969928)
    at /home/lxnt/00DFGL/PMS/print_shader/renderer_glsl.hpp:570
#5  0xf79c0c67 in renderer_glsl::update_all (this=0x9969928)
    at /home/lxnt/00DFGL/PMS/print_shader/renderer_glsl.hpp:951
#6  0xf79b2b14 in enablerst::eventLoop_SDL (this=0x8c3e600)
    at /home/lxnt/00DFGL/PMS/print_shader/enabler.cpp:463
#7  0xf79b316c in enablerst::loop (this=0x8c3e600, cmdline=...)
    at /home/lxnt/00DFGL/PMS/print_shader/enabler.cpp:600
#8  0xf79b3bb8 in main (argc=1, argv=0xffffd3b4)
    at /home/lxnt/00DFGL/PMS/print_shader/enabler.cpp:795
#9  0xf751ce37 in __libc_start_main () from /lib32/libc.so.6
#10 0x0804c951 in ?? ()
(gdb) q
A debugging session is active.

Inferior 1 [process 25949] will be killed.

Quit anyway? (y or n) y


Quote from: lxnt on March 12, 2012, 02:43:21 pm

I made your tileset work, all stuff is in git. It expects the two png files in the '32px' subdirectory where fgtestbed runs - see proto.txt for celpagedefs.

You made this change in git but did not add the 32px folder or png files that are needed after this change so it just crashes unless the user fixes this themselves.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on March 12, 2012, 07:18:19 pm

Fixes for most outrageous bugs are pushed. Fg-raws directory now defaults to ./fgraws, which expects Mayday's 32px tileset,
 but there's a vanilla one now - fgraws-stdpage, which can be used with other df-standard tilesets like Phoebus'. Give it as third parameter to the fgtestbed.py and don't forget to make first parameter to point to the DF directory with the tileset installed. ./fgtestbed.py -h prints useful usage page.

Quote from: arclance on March 12, 2012, 05:17:37 pm

I tried this and it crashes in fortress mode.
Here is a backtrace for the crash.

Crap. I blame C++ ABI. :(

Quote from: arclance on March 12, 2012, 05:17:37 pm

You made this change in git but did not add the 32px folder or png files that are needed after this change so it just crashes unless the user fixes this themselves.

I expect those files to change a lot, and I don't think the github is the best place to store binaries. Will think up some solution.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on March 14, 2012, 03:02:38 pm

a bug was fixed that messed up material-tile mapping.

Title: Re: [PRINT_MODE:SHADER]
Post by: Mike Mayday on March 14, 2012, 03:05:28 pm

Dear testers- remember that you can always download the latest version of the tilesets at the top of this page!

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on March 14, 2012, 05:58:24 pm

Quote from: arclance on March 12, 2012, 05:17:37 pm

Quote from: lxnt on March 09, 2012, 10:04:51 am

libgraphics.so with integrated dumper for 3125 is at http://dffd.wimbli.com/file.php?id=5763 (http://dffd.wimbli.com/file.php?id=5763) Press F12 to dump.

I tried this and it crashes in fortress mode.
Here is a backtrace for the crash.

I think I fixed that one. Please test.

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on March 15, 2012, 02:33:13 pm

Quote from: lxnt on March 14, 2012, 05:58:24 pm

Quote from: arclance on March 12, 2012, 05:17:37 pm

Quote from: lxnt on March 09, 2012, 10:04:51 am

libgraphics.so with integrated dumper for 3125 is at http://dffd.wimbli.com/file.php?id=5763 (http://dffd.wimbli.com/file.php?id=5763) Press F12 to dump.

I tried this and it crashes in fortress mode.
Here is a backtrace for the crash.

I think I fixed that one. Please test.

It still crashes when F12 is pressed.
Here is another backtrace.

Code: [Select]

./dfbacktrace
GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /media/Linux_Data/Dwarf_Fortress/Test_Fortress/printmodeshader/current/df_linux/libs/Dwarf_Fortress...(no debugging symbols found)...done.
Starting program: /media/Linux_Data/Dwarf_Fortress/Test_Fortress/printmodeshader/current/df_linux/libs/Dwarf_Fortress
[Thread debugging using libthread_db enabled]
[New Thread 0xf477cb70 (LWP 2503)]
[New Thread 0xf3f7bb70 (LWP 2504)]
textures::load(): data/art/Phoebus_20x20.png 320x320 16x16 20x20
textures::load(): data/art/Phoebus_20x20.png 320x320 16x16 20x20
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
set_mode(): SDL_FULLSCREEN: 0
GLEW: 1.5.2
OpenGL vendor: NVIDIA Corporation
OpenGL renderer: GeForce GTX 560 Ti/PCIe/SSE2
OpenGL version: 4.2.0 NVIDIA 295.20
OpenGL GLSL version: 4.20 NVIDIA via Cg compiler
GL_MAX_VERTEX_ATTRIBS=16, needed=7
GL_MAX_VERTEX_UNIFORM_COMPONENTS=4096, needed=9
GL_MAX_FRAGMENT_UNIFORM_COMPONENTS=2048, needed=11
GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS=32, needed=0
GL_MAX_TEXTURE_IMAGE_UNITS=32, needed=3
GL_MAX_VARYING_FLOATS=124, needed=8
GL_MAX_TEXTURE_COORDS=8, needed=2
GL_POINT_SIZE_MIN=0, needed=4
GL_POINT_SIZE_MAX=63, needed=48
GL_ARB_sync: supported
makeansitex(): 2.
Embedded shader set 'rect'
Embedded shader set 'cbr_is_bold' x
Using embedded vertex shader code from 'cbr_is_bold'.
Using embedded fragment shader code from 'cbr_is_bold'.
GL_COMPILE_STATUS: true
GL_COMPILE_STATUS: true
GL_LINK_STATUS: true
GL_VALIDATE_STATUS: true
makeansitex(): 2.
gps_allocate(80, 25)
Resetting textures
texdumpst::init(): allocating 2048x288 (max 64x9 32x32 cells)
accepted font texture (name=1): 2048x288px oa
accepted txco texture (name=3): 64x9px oa
reshape(): got grid 0x0 window -1x-1 tile 20x20 texture_ready=1 stretch=0 snap=0
reshape(): final grid 96x50 window 1920x1000 viewport 1920x1000 Psz 20x20
gps_allocate(96, 50)
set_viewport(): got 1920x1000 out of 1920x1000
Frame drawn in 1 msec
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/dorfs.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/humans.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/goblins.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/elfs.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/koboldz.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/creature_birds.png 100x120 5x6 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/creature_domestic.png 440x120 22x6 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/creature_large_mountain.png 100x120 5x6 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/animals.png 240x600 12x30 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/water.png 80x140 4x7 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/gibbon.png 80x180 4x9 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/beasts.png 120x80 6x4 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/mans.png 240x340 12x17 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/newbeasts.png 120x160 6x8 20x20
Resetting textures
texdumpst::init(): allocating 2048x2656 (max 64x83 32x32 cells)
accepted font texture (name=1): 2048x2656px oa
accepted txco texture (name=3): 64x83px oa
Frame drawn in 0 msec
Embedded shader set 'rect'
Embedded shader set 'cbr_is_bold' x
Using embedded vertex shader code from 'cbr_is_bold'.
Using embedded fragment shader code from 'cbr_is_bold'.
GL_COMPILE_STATUS: true
GL_COMPILE_STATUS: true
GL_LINK_STATUS: true
GL_VALIDATE_STATUS: true
makeansitex(): 2.
reshape(): got grid 96x50 window -1x-1 tile 20x20 texture_ready=1 stretch=0 snap=0
reshape(): final grid 96x50 window 1920x1000 viewport 1920x1000 Psz 20x20
set_viewport(): got 1920x1000 out of 1920x1000

Program received signal SIGSEGV, Segmentation fault.
0xf7a909dd in std::vector<df::unit*, std::allocator<df::unit*> >::push_back (
    this=0x10063754, __x=@0xffffca0c) at /usr/include/c++/4.6/bits/stl_vector.h:828
828 if (this->_M_impl._M_finish != this->_M_impl._M_end_of_storage)
#0  0xf7a909dd in std::vector<df::unit*, std::allocator<df::unit*> >::push_back (
    this=0x10063754, __x=@0xffffca0c) at /usr/include/c++/4.6/bits/stl_vector.h:828
#1  0xf7a9040e in _bicache::update (this=0xffffd0b8, a=..., b=...)
    at /home/lxnt/00DFGL/PMS/print_shader/fugr_dump.cc:174
#2  0xf7a8ea7b in fugr_dump () at /home/lxnt/00DFGL/PMS/print_shader/fugr_dump.cc:390
#3  0xf79bd527 in renderer_glsl::reload_shaders (this=0x9969928)
---Type <return> to continue, or q <return> to quit---
    at /home/lxnt/00DFGL/PMS/print_shader/renderer_glsl.hpp:570
#4  0xf79bfef7 in renderer_glsl::update_all (this=0x9969928)
    at /home/lxnt/00DFGL/PMS/print_shader/renderer_glsl.hpp:951
#5  0xf79b1da4 in enablerst::eventLoop_SDL (this=0x8c3e600)
    at /home/lxnt/00DFGL/PMS/print_shader/enabler.cpp:463
#6  0xf79b23fc in enablerst::loop (this=0x8c3e600, cmdline=...)
    at /home/lxnt/00DFGL/PMS/print_shader/enabler.cpp:600
#7  0xf79b2e48 in main (argc=1, argv=0xffffd394)
    at /home/lxnt/00DFGL/PMS/print_shader/enabler.cpp:795
#8  0xf751be37 in __libc_start_main () from /lib32/libc.so.6
#9  0x0804c951 in ?? ()
(gdb) q
A debugging session is active.

Inferior 1 [process 2497] will be killed.

Quit anyway? (y or n) y


Title: Re: [PRINT_MODE:SHADER]
Post by: Greendogo on March 15, 2012, 05:31:00 pm

Question: Am I correct in asserting that this is only for Linux (specifically Ubuntu at the moment) and not working on Windows yet?  Can I compile it for Windows, or is it just flat out not supported?

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on March 15, 2012, 05:37:04 pm

Quote from: Greendogo on March 15, 2012, 05:31:00 pm

Question: Am I correct in asserting that this is only for Linux (specifically Ubuntu at the moment) and not working on Windows yet?  Can I compile it for Windows, or is it just flat out not supported?

The python testbed code runs on windows all right.

The print_mode:shader renderer was and is linux-only.

Unless something very unlikely happens, the end result will be linux-only as well.

Title: Re: [PRINT_MODE:SHADER]
Post by: Lac on March 23, 2012, 06:54:25 pm

Well that was a conversation stopper... are the reasons it is likely to be Linux-only technical?

Title: Re: [PRINT_MODE:SHADER]
Post by: Rose on March 24, 2012, 12:03:34 am

It's because on linux, the graphics rendering code is separate, and can be changed.

On windows, it's not.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on March 26, 2012, 08:47:45 am

Status update.

• unified material id - introduced, taking care of 100500 kinds of soap.
• the dumper crash arclance experienced - fixed.
• all map data from the dump uploaded as a single texture, once - done (hey, it's only about 110Mb for a 4x4 embark).
• fakefloor support (floors drawn under trees, boulders, etc) - in debugging.
• stenciled draw (like this (http://www.bay12forums.com/smf/index.php?topic=94528.msg3083590#msg3083590)) - foundation laid.
• textured ramps drawn as fakefloor combined with something like this (http://mayday.w.staszic.waw.pl/files/DF/slopes.jpg) -  thought over and deemed feasible to implement.
• oversized creature/item graphics (like this (http://mayday.w.staszic.waw.pl/~mayday/upload/rpgperspective.gif)) - kept in mind, no major obstacles seen yet.

Problems:

• Mysterious underground knocking and instances of hfs in shaders.
• Hilarious differences in glsl compilers between mesa, fglrx and nvidiablob.
• C++ insanity-inducing initialization.
• numpy's fortranity, grrr
• df::block_square_event_grassst::amount being something else.

Otherwise, it's moving on.

Title: Re: [PRINT_MODE:SHADER]
Post by: Vattic on March 26, 2012, 01:53:10 pm

Nice work! Glad to hear of progress.

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on March 26, 2012, 05:57:46 pm

Quote from: lxnt on March 26, 2012, 08:47:45 am

• the dumper crash arclance experienced - fixed.

Both of them or just the first one?
You have not had me test anything after I posted the second backtrace so I don't know how you confirmed it is fixed?

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on March 27, 2012, 08:04:36 am

Quote from: arclance on March 26, 2012, 05:57:46 pm

Quote from: lxnt on March 26, 2012, 08:47:45 am

• the dumper crash arclance experienced - fixed.

Both of them or just the first one?
You have not had me test anything after I posted the second backtrace so I don't know how you confirmed it is fixed?

It was a manifestation of "c++ insanity-inducing initialization". Valgrind complains no more so I'm quite sure it's gone.

You can try it, I uploaded latest version here (http://dffd.wimbli.com/file.php?id=5763). Better redirect the output,  it may spew some megabytes of debugging output.

I  noticed I accidentally the offscreen renderer, so trying to export world map crashes it. Phew.

Title: Re: [PRINT_MODE:SHADER]
Post by: Kamamura on March 27, 2012, 08:21:34 am

To anyone who tests - how large is the practical performance improvement? Does this alleviate the FPS death problem of many forts? Will it work with Phoebus tileset?

Title: Re: [PRINT_MODE:SHADER]
Post by: xordae on March 27, 2012, 08:31:38 am

I don't use this shader but I can already tell you that it will not prevent FPS death. Even with VBO grahics and ARB_SYNC enabled, you don't see much of a difference compared to 2D mode, and that's shoving as much onto the GPU as possible (on Windows). The game is just not that graphics intensive. It's all in pathfinding, temperature, active designations and so on..

Title: Re: [PRINT_MODE:SHADER]
Post by: starvingpoet on March 27, 2012, 08:37:20 am

I think this is a wonderful project, simply being able to get past the tileset limitations will completely transform this game for me.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on March 27, 2012, 10:58:20 am

Quote from: Kamamura on March 27, 2012, 08:21:34 am

To anyone who tests - how large is the practical performance improvement?

From hardly noticeable to insignificant unless you have some real slow but recent hardware.

You see, DF currently has two threads - renderer and simulation (which is one that's CPU limited).
Processing goes like that:

simulation -

• calculate game frame ( mainloop() function )
• if FPS-capped, wait some time
• pause if requested to pause.

renderer:

• process input events
• if GFPS-capped, wait until it's time to render next graphics frame;
  
• pause simulation thread
• submit input events to the simulation code
• call game's render_things() function which prepares the tiles/interface to be shown
• copy results
• unpause simulation thread
• actually draw stuff

The perfomance bottleneck is in the mainloop() function. Everything else eats much less CPU time.
In fact, if you've got dualcore or better cpu, the only thing you can do is minimize time that simulation thread is paused while the renderer fetches stuff to render. Which is small to begin with.

I did some optimizations in the print_shader so that there's no excess copying of data around while simulation is paused, and only absolutely required processing is done before handing off data to the gpu, so that cpu isn't held up much by rendering on single-core machines.

Beyond that there's isn't much that can be done to cut the time simulation is paused. Moving out the interface entirely (getting rid of render_things() call) might help, but this will be offset to some degree by inreased amount of data that the new interface would require to be copied out ( and this can't be done while simulation thread is running).

I thought about some clever dirty hacks with snapshotting  DF's data so that renderer can read it while simulation works on, but those are hacks, and linux-specific at that. And they won't give much speed-up anyway.

If the map data was contigously allocated AND there wasn't that much C++ glue between values and their meaning, then I'd gladly just upload needed parts of it directly to the GPU, spending almost no time on cpu (for that last little bit of speed), and it'd allow prototyping gpu-based pathfinding too which as I've heard is the culprit nowadays.

Quote from: Kamamura on March 27, 2012, 08:21:34 am

Does this alleviate the FPS death problem of many forts?

No. It gives you warm fuzzy feeling that you did as much as possible in this aspect.

Quote from: Kamamura on March 27, 2012, 08:21:34 am

Will it work with Phoebus tileset?

It was developed while using it.

Title: Re: [PRINT_MODE:SHADER]
Post by: gimli on March 27, 2012, 03:47:21 pm

Quote from: starvingpoet on March 27, 2012, 08:37:20 am

I think this is a wonderful project, simply being able to get past the tileset limitations will completely transform this game for me.

Yea, but we need Linux to run it.  :-\ However I read somewhere that you don't even have to install Linux, it runs from DVD too?..or something like that.

Title: Re: [PRINT_MODE:SHADER]
Post by: Ergzay on March 27, 2012, 05:08:03 pm

Quote from: gimli on March 27, 2012, 03:47:21 pm

Quote from: starvingpoet on March 27, 2012, 08:37:20 am

I think this is a wonderful project, simply being able to get past the tileset limitations will completely transform this game for me.

Yea, but we need Linux to run it.  :-\ However I read somewhere that you don't even have to install Linux, it runs from DVD too?..or something like that.

Yes most major linux distro supply "Live CDs" that basically let you boot from the CD. It's becoming the common installation method of the Operating System actually, boot into the OS and then install the OS from within the OS. If you're interested try http://www.linuxmint.com/download.php
Even more so, many distributions let you install Linux alongside Windows very easily and even resize partitions for you. So if you wana have Linux installed, its really not that hard.

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on March 27, 2012, 08:42:31 pm

Quote from: Ergzay on March 27, 2012, 05:08:03 pm

Quote from: gimli on March 27, 2012, 03:47:21 pm

Quote from: starvingpoet on March 27, 2012, 08:37:20 am

I think this is a wonderful project, simply being able to get past the tileset limitations will completely transform this game for me.

Yea, but we need Linux to run it.  :-\ However I read somewhere that you don't even have to install Linux, it runs from DVD too?..or something like that.

Yes most major linux distro supply "Live CDs" that basically let you boot from the CD. It's becoming the common installation method of the Operating System actually, boot into the OS and then install the OS from within the OS. If you're interested try http://www.linuxmint.com/download.php
Even more so, many distributions let you install Linux alongside Windows very easily and even resize partitions for you. So if you wana have Linux installed, its really not that hard.

You almost certainly will need to install some dependencies of Dwarf Fortress for it to work so you would need to use a USB Boot Drive instead of a CD/DVD if you don't install the OS to a hard drive.
This way you can test/play Dwarf Fortress in a live session without installing anything to your hard drive.
I wrote a post about getting Dwarf Fortress working in linux that should help people get the dependencies set up before. (http://www.bay12forums.com/smf/index.php?topic=94528.msg2763192#msg2763192)

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on March 27, 2012, 10:25:05 pm

Quote from: lxnt on March 27, 2012, 08:04:36 am

Quote from: arclance on March 26, 2012, 05:57:46 pm

Quote from: lxnt on March 26, 2012, 08:47:45 am

• the dumper crash arclance experienced - fixed.

Both of them or just the first one?
You have not had me test anything after I posted the second backtrace so I don't know how you confirmed it is fixed?

It was a manifestation of "c++ insanity-inducing initialization". Valgrind complains no more so I'm quite sure it's gone.

You can try it, I uploaded latest version here (http://dffd.wimbli.com/file.php?id=5763). Better redirect the output,  it may spew some megabytes of debugging output.

I  noticed I accidentally the offscreen renderer, so trying to export world map crashes it. Phew.

I tried it and it works until you press F12 and then it crashes. (CrunchBang 10 64bit BPO)

Code: [Select]

./df
/usr/share/themes/statler/gtk-2.0/gtkrc:86: error: unexpected identifier `border_shades', expected character `}'
textures::load(): data/art/Phoebus_20x20.png 320x320 16x16 20x20
textures::load(): data/art/Phoebus_20x20.png 320x320 16x16 20x20
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
set_mode(): SDL_FULLSCREEN: 0
GLEW: 1.5.4
OpenGL vendor: NVIDIA Corporation
OpenGL renderer: GeForce GTX 560 Ti/PCI/SSE2
OpenGL version: 4.1.0 NVIDIA 275.36
OpenGL GLSL version: 4.10 NVIDIA via Cg compiler
GL_MAX_VERTEX_ATTRIBS=16, needed=7
GL_MAX_VERTEX_UNIFORM_COMPONENTS=4096, needed=9
GL_MAX_FRAGMENT_UNIFORM_COMPONENTS=2048, needed=11
GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS=32, needed=0
GL_MAX_TEXTURE_IMAGE_UNITS=32, needed=3
GL_MAX_VARYING_FLOATS=60, needed=8
GL_MAX_TEXTURE_COORDS=8, needed=2
GL_POINT_SIZE_MIN=0, needed=4
GL_POINT_SIZE_MAX=63, needed=48
GL_ARB_sync: supported
makeansitex(): 2.
Embedded shader set 'rect'
Embedded shader set 'cbr_is_bold' x
Using embedded vertex shader code from 'cbr_is_bold'.
Using embedded fragment shader code from 'cbr_is_bold'.
GL_COMPILE_STATUS: true
GL_COMPILE_STATUS: true
GL_LINK_STATUS: true
GL_VALIDATE_STATUS: true
makeansitex(): 2.
gps_allocate(80, 25)
Resetting textures
texdumpst::init(): allocating 2048x288 (max 64x9 32x32 cells)
accepted font texture (name=1): 2048x288px oa
accepted txco texture (name=3): 64x9px oa
reshape(): got grid 0x0 window -1x-1 tile 20x20 texture_ready=1 stretch=0 snap=0
reshape(): final grid 96x50 window 1920x1000 viewport 1920x1000 Psz 20x20
gps_allocate(96, 50)
set_viewport(): got 1920x1000 out of 1920x1000
Frame drawn in 5 msec
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/dorfs.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/humans.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/goblins.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/elfs.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/koboldz.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/creature_birds.png 100x120 5x6 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/creature_domestic.png 440x120 22x6 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/creature_large_mountain.png 100x120 5x6 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/animals.png 240x600 12x30 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/water.png 80x140 4x7 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/gibbon.png 80x180 4x9 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/beasts.png 120x80 6x4 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/mans.png 240x340 12x17 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/newbeasts.png 120x160 6x8 20x20
Resetting textures
texdumpst::init(): allocating 2048x2656 (max 64x83 32x32 cells)
accepted font texture (name=1): 2048x2656px oa
accepted txco texture (name=3): 64x83px oa
Frame drawn in 0 msec
Embedded shader set 'rect'
Embedded shader set 'cbr_is_bold' x
Using embedded vertex shader code from 'cbr_is_bold'.
Using embedded fragment shader code from 'cbr_is_bold'.
GL_COMPILE_STATUS: true
GL_COMPILE_STATUS: true
GL_LINK_STATUS: true
GL_VALIDATE_STATUS: true
makeansitex(): 2.
reshape(): got grid 96x50 window -1x-1 tile 20x20 texture_ready=1 stretch=0 snap=0
reshape(): final grid 96x50 window 1920x1000 viewport 1920x1000 Psz 20x20
set_viewport(): got 1920x1000 out of 1920x1000
Segmentation fault
But now when I try to get a backtrace it crashes at startup.

Code: [Select]

./dfbacktrace
GNU gdb (GDB) 7.3-debian
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /media/Linux_Data/Dwarf_Fortress/Test_Fortress/printmodeshader/current/df_linux/libs/Dwarf_Fortress...(no debugging symbols found)...done.
Starting program: /media/Linux_Data/Dwarf_Fortress/Test_Fortress/printmodeshader/current/df_linux/libs/Dwarf_Fortress
[Thread debugging using libthread_db enabled]
/usr/share/themes/statler/gtk-2.0/gtkrc:86: error: unexpected identifier `border_shades', expected character `}'
[New Thread 0xf4ac4b70 (LWP 9704)]
[New Thread 0xf42c3b70 (LWP 9705)]
textures::load(): data/art/Phoebus_20x20.png 320x320 16x16 20x20
textures::load(): data/art/Phoebus_20x20.png 320x320 16x16 20x20
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
set_mode(): SDL_FULLSCREEN: 0
GLEW: 1.5.4
OpenGL vendor: NVIDIA Corporation
OpenGL renderer: GeForce GTX 560 Ti/PCI/SSE2
OpenGL version: 4.1.0 NVIDIA 275.36
OpenGL GLSL version: 4.10 NVIDIA via Cg compiler
GL_MAX_VERTEX_ATTRIBS=16, needed=7
GL_MAX_VERTEX_UNIFORM_COMPONENTS=4096, needed=9
GL_MAX_FRAGMENT_UNIFORM_COMPONENTS=2048, needed=11
GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS=32, needed=0
GL_MAX_TEXTURE_IMAGE_UNITS=32, needed=3
GL_MAX_VARYING_FLOATS=60, needed=8
GL_MAX_TEXTURE_COORDS=8, needed=2
GL_POINT_SIZE_MIN=0, needed=4
GL_POINT_SIZE_MAX=63, needed=48
GL_ARB_sync: supported

Program received signal SIGSEGV, Segmentation fault.
0xf32cce21 in ?? ()
#0  0xf32cce21 in ?? ()
#1  0x0c244c8b in ?? ()
#2  0xfd70908b in ?? ()
#3  0x448b0004 in ?? ()
#4  0x808b0824 in ?? ()
#5  0x000000e0 in ?? ()
#6  0x04244c89 in ?? ()
#7  0x0c244489 in ?? ()
#8  0x1024448b in ?? ()
#9  0x08244489 in ?? ()
#10 0x00000c1c in ?? ()
#11 0x0b74c985 in ?? ()
---Type <return> to continue, or q <return> to quit---
#12 0x04538942 in ?? ()
#13 0x41ff42c6 in ?? ()
#14 0x4204538b in ?? ()
#15 0x5389f089 in ?? ()
#16 0xc6072404 in ?? ()
#17 0x0cc1ff42 in ?? ()
#18 0x04538be8 in ?? ()
#19 0x04538942 in ?? ()
#20 0x89ff4288 in ?? ()
#21 0x04438bfa in ?? ()
#22 0x04438940 in ?? ()
#23 0x8bff5088 in ?? ()
#24 0x8b10245c in ?? ()
#25 0x8b142474 in ?? ()
#26 0x8318247c in ?? ()
#27 0x90c31cc4 in ?? ()
#28 0x0026748d in ?? ()
#29 0xe8240489 in ?? ()
#30 0x006249c8 in ?? ()
#31 0xeb04538b in ?? ()
#32 0x906690a0 in ?? ()
#33 0x892cec83 in ?? ()
#34 0x89202474 in ?? ()
#35 0x24448bc6 in ?? ()
#36 0x247c893c in ?? ()
#37 0x8bd78924 in ?? ()
---Type <return> to continue, or q <return> to quit---
#38 0x89382454 in ?? ()
#39 0x8b28246c in ?? ()
#40 0x8934246c in ?? ()
#41 0x891c245c in ?? ()
#42 0x8b102444 in ?? ()
#43 0x89302444 in ?? ()
#44 0x89142454 in ?? ()
#45 0x8b182444 in ?? ()
#46 0x463b0446 in ?? ()
#47 0x41830f08 in ?? ()
#48 0x83000001 in ?? ()
#49 0x0c7f07ff in ?? ()
#50 0x18247c83 in ?? ()
#51 0x218e0f07 in ?? ()
#52 0x90000001 in ?? ()
#53 0x0c1c968b in ?? ()
#54 0xd2850000 in ?? ()
#55 0x0096850f in ?? ()
#56 0x83400000 in ?? ()
#57 0x468907e7 in ?? ()
#58 0xfd1c8d04 in ?? ()
#59 0x00000000 in ?? ()
(gdb)
(gdb)
(gdb) q
A debugging session is active.

Inferior 1 [process 9701] will be killed.

Quit anyway? (y or n) y

It also crashes at "GL_ARB_sync: supported" (same place as the 64bit backtrace) even without trying to get a backtrace on my 32bit computer (doesn't work at all). (Ubuntu 11.04 32bit).

Code: [Select]

./dfbacktrace
GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /media/Data_9/Programs/Transfer/df_linux/libs/Dwarf_Fortress...(no debugging symbols found)...done.
Starting program: /media/Data_9/Programs/Transfer/df_linux/libs/Dwarf_Fortress
[Thread debugging using libthread_db enabled]
[New Thread 0xb4192b70 (LWP 10683)]
[New Thread 0xb3991b70 (LWP 10684)]
textures::load(): data/art/Phoebus_20x20.png 320x320 16x16 20x20
textures::load(): data/art/Phoebus_20x20.png 320x320 16x16 20x20
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
set_mode(): SDL_FULLSCREEN: 0
GLEW: 1.5.2
OpenGL vendor: NVIDIA Corporation
OpenGL renderer: GeForce 8600 GTS/PCIe/SSE2
OpenGL version: 3.3.0 NVIDIA 295.33
OpenGL GLSL version: 3.30 NVIDIA via Cg compiler
GL_MAX_VERTEX_ATTRIBS=16, needed=7
GL_MAX_VERTEX_UNIFORM_COMPONENTS=4096, needed=9
GL_MAX_FRAGMENT_UNIFORM_COMPONENTS=2048, needed=11
GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS=32, needed=0
GL_MAX_TEXTURE_IMAGE_UNITS=32, needed=3
GL_MAX_VARYING_FLOATS=60, needed=8
GL_MAX_TEXTURE_COORDS=8, needed=2
GL_POINT_SIZE_MIN=0, needed=4
GL_POINT_SIZE_MAX=63, needed=48
GL_ARB_sync: supported

Program received signal SIGSEGV, Segmentation fault.
0xb2bd6de0 in ?? ()
#0  0xb2bd6de0 in ?? ()
#1  0x0c244c8b in ?? ()
#2  0x0820908b in ?? ()
#3  0x24448bc6 in ?? ()
#4  0x247c893c in ?? ()
#5  0x8bd78924 in ?? ()
#6  0x89382454 in ?? ()
#7  0x8b28246c in ?? ()
#8  0x8934246c in ?? ()
---Type <return> to continue, or q <return> to quit---
#9  0x891c245c in ?? ()
#10 0x8b102444 in ?? ()
#11 0x89302444 in ?? ()
#12 0x89142454 in ?? ()
#13 0x8b182444 in ?? ()
#14 0x463b0446 in ?? ()
#15 0x41830f08 in ?? ()
#16 0x83000001 in ?? ()
#17 0x0c7f07ff in ?? ()
#18 0x18247c83 in ?? ()
#19 0x218e0f07 in ?? ()
#20 0x90000001 in ?? ()
#21 0x0c1c968b in ?? ()
#22 0xd2850000 in ?? ()
#23 0x0096850f in ?? ()
#24 0x83400000 in ?? ()
#25 0x468907e7 in ?? ()
#26 0xfd1c8d04 in ?? ()
#27 0x00000000 in ?? ()
(gdb)
(gdb)
(gdb) q
A debugging session is active.

Inferior 1 [process 10649] will be killed.

Quit anyway? (y or n) y
Other rendering modes than SHADER still work on the 32bit computer.

Title: Re: [PRINT_MODE:SHADER]
Post by: gimli on March 28, 2012, 05:59:54 am

Quote from: arclance on March 27, 2012, 08:42:31 pm

Quote from: Ergzay on March 27, 2012, 05:08:03 pm

Quote from: gimli on March 27, 2012, 03:47:21 pm

Quote from: starvingpoet on March 27, 2012, 08:37:20 am

I think this is a wonderful project, simply being able to get past the tileset limitations will completely transform this game for me.

Yea, but we need Linux to run it.  :-\ However I read somewhere that you don't even have to install Linux, it runs from DVD too?..or something like that.

Yes most major linux distro supply "Live CDs" that basically let you boot from the CD. It's becoming the common installation method of the Operating System actually, boot into the OS and then install the OS from within the OS. If you're interested try http://www.linuxmint.com/download.php
Even more so, many distributions let you install Linux alongside Windows very easily and even resize partitions for you. So if you wana have Linux installed, its really not that hard.

You almost certainly will need to install some dependencies of Dwarf Fortress for it to work so you would need to use a USB Boot Drive instead of a CD/DVD if you don't install the OS to a hard drive.
This way you can test/play Dwarf Fortress in a live session without installing anything to your hard drive.
I wrote a post about getting Dwarf Fortress working in linux that should help people get the dependencies set up before. (http://www.bay12forums.com/smf/index.php?topic=94528.msg2763192#msg2763192)

Nice! Thanks for the help guys!

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on March 28, 2012, 10:27:13 am

Quote from: gimli on March 28, 2012, 05:59:54 am

Quote from: arclance on March 27, 2012, 08:42:31 pm

Quote from: Ergzay on March 27, 2012, 05:08:03 pm

Quote from: gimli on March 27, 2012, 03:47:21 pm

Quote from: starvingpoet on March 27, 2012, 08:37:20 am

I think this is a wonderful project, simply being able to get past the tileset limitations will completely transform this game for me.

Yea, but we need Linux to run it.  :-\ However I read somewhere that you don't even have to install Linux, it runs from DVD too?..or something like that.

Yes most major linux distro supply "Live CDs" that basically let you boot from the CD. It's becoming the common installation method of the Operating System actually, boot into the OS and then install the OS from within the OS. If you're interested try http://www.linuxmint.com/download.php
Even more so, many distributions let you install Linux alongside Windows very easily and even resize partitions for you. So if you wana have Linux installed, its really not that hard.

You almost certainly will need to install some dependencies of Dwarf Fortress for it to work so you would need to use a USB Boot Drive instead of a CD/DVD if you don't install the OS to a hard drive.
This way you can test/play Dwarf Fortress in a live session without installing anything to your hard drive.
I wrote a post about getting Dwarf Fortress working in linux that should help people get the dependencies set up before. (http://www.bay12forums.com/smf/index.php?topic=94528.msg2763192#msg2763192)

Nice! Thanks for the help guys!

It is a little more complicated if you are using a 64bit OS.
I found a good guide on setting up dwarf fortress to run in a 64 bit environment here. (http://blog.isja.org/index.php?/archives/81-Setting-up-Dwarf-Fortress-in-64bit-Debian.html)
In addition to the 32bit libs mentioned there you will need the 32bit libglew, 32bit opengl libs for your graphics driver, and 32bit gtk-2.0 libs to use SHADER mode from this mod.
I had to add

Code: [Select]

GTK_PATH="/usr/lib32/gtk-2.0"
to the launch script (./df) since the multilib stuff in Debian/Ubuntu to tell it where the 32bit gtk-2.0 is located.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on March 28, 2012, 12:25:38 pm

Quote from: arclance on March 27, 2012, 10:25:05 pm

I tried it and it works until you press F12 and then it crashes. (CrunchBang 10 64bit BPO)

 ...

But now when I try to get a backtrace it crashes at startup.

 ...

It also crashes at "GL_ARB_sync: supported" (same place as the 64bit backtrace) even without trying to get a backtrace on my 32bit computer (doesn't work at all). (Ubuntu 11.04 32bit).

 ...

Other rendering modes than SHADER still work on the 32bit computer.

Aw. What a wonderful progress I've made.

Will fix this after fakefloors are drawn.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on March 28, 2012, 12:26:08 pm

Status update.

I resorted to hd and strings trying to understand how the hell DF parses its raws. I think I did.

Current Python code turned out to have a major misunderstanding with the dumper. It's waiting on raws parser rewrite to be fixed.

The dumper still does not crash on me like it does on Arclance, but there's certainly something very wrong with it. But first I'll fix the Python side.

Title: Re: [PRINT_MODE:SHADER]
Post by: Moonshine Fox on April 06, 2012, 08:36:40 am

lxnt, have you considered how much of a revolutionary you are? You are completely changing the whole basis of DF graphics. The possibilities are endless!

Now if we could only make them separate the graphics renderer on Windows as well...

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on April 09, 2012, 05:35:58 pm

Quote from: Moonshine Fox on April 06, 2012, 08:36:40 am

lxnt, have you ...

Thank you.

Status update:

DF raws parser now looks much like the ingame one. Dispatch/blitcode assembler works as far as can be seen without a functional renderer.

Shaders are being reworked, and even display a curiously convoluted map on nvidia hardware, result of simplifying coordinate conversions and texture upload (may fortran burn in hell, and numpy with it. also fglrx.).

Four more ways to export debug data from the shaders >:(

Since I managed to broke the dumper too, current focus is on porting it to 34.07, but first my forks of df-structures and df-hack (aw, dependencies).

(Forgot which way is north on the map I dumped wih last working version).

Title: Re: [PRINT_MODE:SHADER]
Post by: tahujdt on April 15, 2012, 03:48:21 am

lxnt, this looks awesome!

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on April 19, 2012, 10:37:45 am

Quote from: tahujdt on April 15, 2012, 03:48:21 am

lxnt, this looks awesome!

Thank you.

Status update.

• "a simpler code generator" has been written. See codegen.py (https://github.com/lxnt/df-structures/blob/master/codegen.py)

Now on to see if it generates usable code.

Title: Re: [PRINT_MODE:SHADER]
Post by: tahujdt on April 19, 2012, 11:36:27 am

This will work for 34.07, right? Also, does it work for windows?

Title: Re: [PRINT_MODE:SHADER]
Post by: Jeoshua on April 19, 2012, 01:04:43 pm

It does not work for Windows  :'(

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on April 19, 2012, 01:43:50 pm

Quote from: tahujdt on April 19, 2012, 11:36:27 am

This will work for 34.07, right? Also, does it work for windows?

The update to 34.07 is in progress or soon to be started.

Quote from: lxnt on April 09, 2012, 05:35:58 pm

Since I managed to broke the dumper too, current focus is on porting it to 34.07, but first my forks of df-structures and df-hack (aw, dependencies).

There is no windows version because we only have the source for the graphics interface for the linux version.
Also on linux the graphics interface is separate from the Dwarf Fortress executable so it can be replaced with a modified version.
On windows the game and the graphics interface are in the same executable so it cannot be modified.

Title: Re: [PRINT_MODE:SHADER]
Post by: Jeoshua on April 19, 2012, 04:10:27 pm

If only there was a compile for windows with a separate graphical interface.  If it already exists for Linux, then it couldn't be more than flipping a few (dozen) compile switches, could it?

Title: Re: [PRINT_MODE:SHADER]
Post by: Mike Mayday on April 19, 2012, 04:27:14 pm

I don't think that's so easy.

Title: Re: [PRINT_MODE:SHADER]
Post by: Jeoshua on April 19, 2012, 04:40:27 pm

I don't mean it would be simple, I mean it would take maybe a week's work to get it separated, in my estimation.  That's only a guess tho, since I haven't exactly seen the source code.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on April 19, 2012, 08:01:46 pm

Quote from: Jeoshua on April 19, 2012, 04:40:27 pm

I don't mean it would be simple, I mean it would take maybe a week's work ...

C++ ABI. It's more than enough pain on Linux, but at least we've got a de-facto standard compiler and as sane library symbol versioning as possible. Windows, well ... Keeping around a thumbdrive with Linux or a wubi (http://en.wikipedia.org/wiki/Wubi_%28Ubuntu_installer%29) instance is soo simpler.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on April 20, 2012, 09:57:20 am

status update:

• put most useful utilities into the code generator
• cmakefied the 34.07 stock renderer
• ported the dumper to this mess; rendumper (https://github.com/lxnt/rendumper). It segfaults on dump atm.

Title: Re: [PRINT_MODE:SHADER]
Post by: Baleur on April 20, 2012, 10:34:19 am

Quote from: Japa on March 24, 2012, 12:03:34 am

It's because on linux, the graphics rendering code is separate, and can be changed.

On windows, it's not.

But couldn't the DF dev himself correct this? I mean, supply an optional .exe with this rendering method included?
Surely that would be possible to get it to work in windows? If he cared, that is.

The word-of-mouth and youtube PR alone from a graphics rewrite like this must be more than enough incentive for getting this to work on windows..
Heck, i'd pay for an updated DF if this shader is as awesome as it sounds like it's gonna be.

Title: Re: [PRINT_MODE:SHADER]
Post by: Mike Mayday on April 20, 2012, 01:13:37 pm

Quote from: Baleur on April 20, 2012, 10:34:19 am

Quote from: Japa on March 24, 2012, 12:03:34 am

It's because on linux, the graphics rendering code is separate, and can be changed.

On windows, it's not.

But couldn't the DF dev himself correct this? I mean, supply an optional .exe with this rendering method included?
Surely that would be possible to get it to work in windows? If he cared, that is.

The word-of-mouth and youtube PR alone from a graphics rewrite like this must be more than enough incentive for getting this to work on windows..
Heck, i'd pay for an updated DF if this shader is as awesome as it sounds like it's gonna be.

Escaped lunatic.
(ie. this subject is much broader than you think, hundreds of people come to this forum voicing this exact opinion and then find out that it's not as simple and every body is pretty tired with explaining and somebody should probably make a FAQ about it and in fact somebody has but it wasn't stickied so it got buried).

Title: Re: [PRINT_MODE:SHADER]
Post by: Lac on April 22, 2012, 07:01:27 am

Quote from: Baleur on April 20, 2012, 10:34:19 am

But couldn't the DF dev himself correct this?

The rules of the game are that Toady makes it as hard as possible to deviate from his ascii curse, and the players have to think of ingenious ways to get it looking decent. And lxnt's is pretty ingenious.  Personally I'm waiting for the lazy noob pack to bundle it with a unix stick install :)

Title: Re: [PRINT_MODE:SHADER]
Post by: Baleur on April 23, 2012, 05:33:53 pm

That's exactly my point, also ties in with the upcoming way that rail tracks will use the same tile as walls.
I dont understand this logic from him, why make it harder for basic graphics mods?

I know if i could program and had a game i was proud of, i'd want to embrace anything people essentially do for "free" to make it even more popular, perhaps even leading to a paid version in the future.

I'm pretty sure the tilesets on these forums are a big big draw for new players compared to just seeing ASCII.
So again, i really do not understand this. Why wouldnt he want to do everything to make it EASIER for modders to basically add free graphics to the game while he can focus on the gameplay coding?
Heck, it actually ADDS to gameplay since you can see wtf is going on on the screen.

It just seems like a rather, i dont know if unresponsible approach is the right thing to say.. It just seems odd not to embrace any help and benefit to the games popularity and success he can get, for free. No salary paid, no graphics artist hired. Other indie devs would love that. Maybe there's some sort of "this game must be old-school" mentality, but again that would be rather unresponsible, in terms of what is good for the game itself.

Then again, i have no clue how DF is developed or what the future concept for it is. But from a new players perspective it seems as if the modders have to hijack any sliver of possibility for the most basic of graphics. I'm still surprised that the main DF website itself still boasts ASCII in the background and screenshots. If anything, it should show a selection of tilesets.
It is such a wonderful game in terms of gameplay that it is a real shame to see true opportunity NOT being siezed, just letting it crawl in the mud as modders desperately try to find ways to improve upon it. It also feels a bit arrogant, to ignore such potential for the sake of "must be old-school, cuz i say so".

The day when an ambitious indie comes along and actually flat out copies Dwarf Fortress, but does so with a proper context sensitive logical interface and basic rudimentary graphics that at least show enemies from hostiles, grass from mud, DF won't have a chance. He's lucky it's been relatively unhindered by any competition so far. Just look at what happened with Infiniminer compared to Minecraft.

When a competitor finally shows up, with the same game concept as DF, but with a better presentation and mod friendly support, it's over for Toady. I'd think he'd wanna cherish any advantage to evolve the game he could get.
Rant over, i apologize.

Title: Re: [PRINT_MODE:SHADER]
Post by: Blakmane on April 23, 2012, 06:14:11 pm

Quote from: Baleur on April 23, 2012, 05:33:53 pm

Then again, i have no clue how DF is developed or what the future concept for it is. But from a new players perspective it seems as if the modders have to hijack any sliver of possibility for the most basic of graphics. I'm still surprised that the main DF website itself still boasts ASCII in the background and screenshots. If anything, it should show a selection of tilesets.
It is such a wonderful game in terms of gameplay that it is a real shame to see true opportunity NOT being siezed, just letting it crawl in the mud as modders desperately try to find ways to improve upon it. It also feels a bit arrogant, to ignore such potential for the sake of "must be old-school, cuz i say so".

The day when an ambitious indie comes along and actually flat out copies Dwarf Fortress, but does so with a proper context sensitive logical interface and basic rudimentary graphics that at least show enemies from hostiles, grass from mud, DF won't have a chance. He's lucky it's been relatively unhindered by any competition so far. Just look at what happened with Infiniminer compared to Minecraft.

When a competitor finally shows up, with the same game concept as DF, but with a better presentation and mod friendly support, it's over for Toady. I'd think he'd wanna cherish any advantage to evolve the game he could get.
Rant over, i apologize.

Dwarf Fortress exists primarily as a creative outlet for Toady's imagination. As long as Toady has enough money to pay his bills and put food on the table he is entirely uninterested in commercial gain. As such he focuses on what *he* wants to see in the game, not what will get him the most players or make him the most money. Toady plays without tilesets (as do about half of all DF players, mind you) and is not particularly interested in graphics support at this point in development, so that is just what we have to live with. Is this good business sense? Most certainly not, but Toady doesn't care about money and in a way we should be grateful he doesn't and is willing to make this amazing game for free.

There are already DF-like games out or in development, but none have ever impacted on DF's niche popularity. What Toady has done in terms of depth of information, simulation and procedural generation is simply impossible to commercially replicate. By not focussing on graphics, toady has kept the game engine perpetually open to change, allowing a constantly evolving program with few constraints and an utterly unique outlook. If he was limited to a normal videogame development cycle of a few years, and had effectively handcuffed his engine early with graphics (see Armok 1), none of what we have now would exist.

I hope that helps answer your question. :-)

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on April 23, 2012, 07:45:53 pm

To put it simple, (as far as I understand, of course) Toady does not find it interesting neither doing graphics code nor maintaining any semblance of an API to formally allow others to do it. The latter I would not, too. Either one is a significant time sink for marginal gains in (re)playability, compared to carts, vampires and whatnot, and I for one applaud this decision. I see how can a (completely different) renderer be grafted upon the engine, it can be done and I'm doing it. However it's practically impossible to, say, patch in carts. Or vampires. Or city generation. So I'd say, let Toady do what he does best, the rest we can fix or cope with.

Besides, doing whatever interests you, as opposed to whatever others want, is the key to maximum specific creativity. Which is the one thing that makes things truly outstanding.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on April 24, 2012, 05:46:07 am

Status update.

• lwapi (https://github.com/lxnt/df-structures) doesn't enrage gcc or valgrind any more.
• Dumper sort of works. Please see if it crashes for you. http://dffd.wimbli.com/file.php?id=6210 (http://dffd.wimbli.com/file.php?id=6210).
• fgtestbed updated to work with 3407, converted to Python 3.

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on April 24, 2012, 04:26:00 pm

Quote from: lxnt on April 24, 2012, 05:46:07 am

Status update.

• lwapi (https://github.com/lxnt/df-structures) doesn't enrage gcc or valgrind any more.
• Dumper sort of works. Please see if it crashes for you. http://dffd.wimbli.com/file.php?id=6210 (http://dffd.wimbli.com/file.php?id=6210).
• fgtestbed updated to work with 3407, converted to Python 3.

The dumper does not crash for me anymore.
What should I expect to see if I feed the dump to fgtestbed?
It looks like this right now, though I am using python 2.7 since I don't have any python3 packages for PyOpengl.
(http://tnypic.net/images/b573a_thumb.png) (http://tnypic.net/b573a.png.html)
Also is the dumper the only thing you updated to 34.07 or did you also update the old SHADER mode as well?

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on April 25, 2012, 02:51:54 am

Quote from: arclance on April 24, 2012, 04:26:00 pm

The dumper does not crash for me anymore.

Great.

Quote from: arclance on April 24, 2012, 04:26:00 pm

What should I expect to see if I feed the dump to fgtestbed?
It looks like this right now, though I am using python 2.7 since I don't have any python3 packages for PyOpengl.

It should look something like that, since shaders themselves haven't been debugged yet.

I should have been clearer, it's not that code was 'converted' to python3, it's just I tried to make it run under both
versions. So python3 is not required for the fgtestbed.

Quote from: arclance on April 24, 2012, 04:26:00 pm

Also is the dumper the only thing you updated to 34.07 or did you also update the old SHADER mode as well?

I did not port the old shader code.

Title: Re: [PRINT_MODE:SHADER]
Post by: Jeoshua on April 30, 2012, 09:58:24 am

Just curious if this suggestion would be at all possible with this renderer:
http://www.bay12forums.com/smf/index.php?topic=108489.0

If it is, you're free to use the idea with or without credit for it's imagining.  If not... well then I am sad but I'll live ;)

Title: Re: [PRINT_MODE:SHADER]
Post by: [NO_THOUGHT] on April 30, 2012, 10:03:32 am

Curses Jeoshua! When I saw a new reply to this thread I thought that lxnt had posted an update! However I think that the shader here is already somewhat like your idea... except without the use of the cyan color.

Title: Re: [PRINT_MODE:SHADER]
Post by: Jeoshua on April 30, 2012, 10:11:30 am

HA!

I suppose it does!  I just looked through the thread very hard to find so much as a single screenshot, posted months ago.  It does do exactly my suggestion, only with Blue instead of Cyan.

Kudos, and this makes me want to make a USB stick mini-linux distro just to try it.  Is is working for 34.07 yet?

P.S. Post more screenshots.

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on April 30, 2012, 10:37:26 am

Quote from: Jeoshua on April 30, 2012, 10:11:30 am

Kudos, and this makes me want to make a USB stick mini-linux distro just to try it.  Is is working for 34.07 yet?

No not yet, lxnt did not update the old shader code for the 0.34.X series.

Quote from: lxnt on April 25, 2012, 02:51:54 am

I did not port the old shader code.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on May 26, 2012, 07:16:51 pm

Well, t's time to let you all know what's going on.

I've been busy with other stuff for the three weeks, and then killed a week's worth of hobby time on tearing my hair out at OpenGL's HFS.
So, enough of this. From about now, the project relies on and uses only GL 3.0 forward-compatible profile, which means mostly no legacy insanity, and also means that SDL 2.0 (fka 1.3) is required. This is because there's no way to create a sane OpenGL context using SDL 1.2.

While I was at it, I also decided to move to Python 3.2.  This is because for one, I need to not forget its caveats, and for another, py3k is here for several years already.

This all means that future code drops would require somewhat bleeding-edge environment to run. I'll move to uploading more-or-less self-contained archives, including whatever latest PyOpenGL, patched pgreloaded, latest SDL-2.0 and whatever accompanying libs  my code would require. However, supplying compiled code will mean that it'd run only on ubuntu 11.04 or later, and I probably won't have any time to devise ways to run it under windows or macosx (which is absolutely possible though).

On the positive side, I've already updated the dumper to work with df3410 and most of GL's kinks combined with my own misunderstandings have been purged with fire.


NB:

This project isn't currently anything one can play DF with. It's just a prototype, and very nonfunctional at that.

The 'old shader code' never did anything but insignificantly speed up the game. Thus I saw no reason to port it to .34xx.

Title: Re: [PRINT_MODE:SHADER]
Post by: Blakmane on May 26, 2012, 07:31:29 pm

Awesome update lxnt - you have our complete support! Unfortunately I have a windows-only machine and cannot help test, but please let me know if there is any other way I can aid you.

Title: Re: [PRINT_MODE:SHADER]
Post by: SalmonGod on May 26, 2012, 09:01:08 pm

I'll still probably try dual-booting Linux for the very first time just to try this, whenever it progresses to a semi-usable state.

Title: Re: [PRINT_MODE:SHADER]
Post by: Vattic on May 26, 2012, 09:26:35 pm

Same here SalmonGod. Either that or I'll try installing it on a thumbdrive or similar.

Title: Re: [PRINT_MODE:SHADER]
Post by: smirk on May 27, 2012, 01:31:16 am

Words cannot express the joy of finding out this project is still running! Installing Ubuntu right now, for the express purpose of looking at this shader. Godspeed, lxnt, you beautiful bastard.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on June 04, 2012, 03:17:09 pm

(http://img.ie/images/38963_thumb.png) (http://img.ie/38963.png.html)

Title: Re: [PRINT_MODE:SHADER]
Post by: Mike Mayday on June 04, 2012, 04:41:12 pm

WHAT IS HAPPENING

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on June 04, 2012, 05:02:58 pm

Quote from: lxnt on June 04, 2012, 03:17:09 pm

(http://img.ie/images/38963_thumb.png) (http://img.ie/38963.png.html)

Looks good, last time it tried it only water and magma showed up.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on June 05, 2012, 06:09:21 am

(http://img.ie/images/6b3b6_thumb.png) (http://img.ie/6b3b6.png.html)

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on June 07, 2012, 12:46:13 pm

(http://img.ie/images/85279_thumb.png) (http://img.ie/85279.png.html)

Fakefloors and animation work. Beware of zombie whirling driftwood.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on June 07, 2012, 02:16:24 pm

Code drop.

These archives contain working-for-me code, a set of  three map dumps and a set of libraries needed to run it.

You will need - Ubuntu Precise (12.04) 64bit or Oneiric (11.10) 64bit, Python 3.2, python3-yaml, working OpenGL drivers, and a bunch of libs that libsdl depends on.

oneiric: http://dffd.wimbli.com/file.php?id=6445 (http://dffd.wimbli.com/file.php?id=6445)

precise: http://dffd.wimbli.com/file.php?id=6446 (http://dffd.wimbli.com/file.php?id=6446)

typical launch:

Code: [Select]

./fgt -dfdir ../df3410 dumps/driftwood.dump raw/fakefloors

Known problems:

• AMD/ATI drivers are crap and do not work.
• Low framerate, about 25 fps for me without debug and show_hidden  (press keypad / and * to turn off)
• Tested only with 34.10 raws so far.
• Minecart rails are not there.
• Graphics for most tiles from HFS levels are missing.

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on June 07, 2012, 02:34:53 pm

Quote from: lxnt on June 07, 2012, 02:16:24 pm

Code drop.

These archives contain working-for-me code, a set of  three map dumps and a set of libraries needed to run it.

You will need - Ubuntu Precise (12.04) 64bit or Oneiric (11.10) 64bit, Python 3.2, python3-yaml, working OpenGL drivers, and a bunch of libs that libsdl depends on.

oneiric: http://dffd.wimbli.com/file.php?id=6445 (http://dffd.wimbli.com/file.php?id=6445)

precise: http://dffd.wimbli.com/file.php?id=6446 (http://dffd.wimbli.com/file.php?id=6446)

typical launch:

Code: [Select]

./fgt -dfdir ../df3410 dumps/driftwood.dump raw/fakefloors

Known problems:

• AMD/ATI drivers are crap and do not work.
• Low framerate, about 15 fps with debug off (press ~ to turn off)
• Tested only with 34.10 raws so far.
• Minecart rails are not there.
• Graphics for most tiles from HFS levels are missing.

What exactly is in those downloads?
Is it just the fgtestbeg code from github?
Is there something else in there as well?
Is there an already generated dump to test on or is a dumper included?

I'm not using Ubuntu anymore, I switched to Debian (specifically #!).
I have the OpenGL and libsdl setup and working already.
I checked and I can install python3.2 and python3-yaml, did you get rid of all the other modules you were using before or do I need python3 versions of them as well?

I had it working before the change to all python3 so I should be able to get the new version working as well.
Could you answer my questions so I can decide what I need to do to run it on a non-ubuntu system?

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on June 07, 2012, 02:49:32 pm

Quote from: arclance on June 07, 2012, 02:34:53 pm

What exactly is in those downloads?
Is there something else in there as well?
Is there an already generated dump to test on or is a dumper included?

Quote from: lxnt on June 07, 2012, 02:16:24 pm

These archives contain working-for-me code, a set of three map dumps and a set of libraries needed to run it.

Dumps from older dumpers won't work due to a subtle format change.

Quote from: arclance on June 07, 2012, 02:34:53 pm

I'm not using Ubuntu anymore, I switched to Debian (specifically #!).

I don't think it'll be any great problem as long as library versions more-or-less line up.

Quote from: arclance on June 07, 2012, 02:34:53 pm

I checked and I can install python3.2 and python3-yaml, did you get rid of all the other modules you were using before or do I need python3 versions of them as well?

Latest PyOpenGL, latest patched pygame2 and libsdl2 are included in the archives. Other than that and yaml, it's all python3 standard library.

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on June 07, 2012, 02:52:58 pm

Quote from: lxnt on June 07, 2012, 02:49:32 pm

Quote from: arclance on June 07, 2012, 02:34:53 pm

I checked and I can install python3.2 and python3-yaml, did you get rid of all the other modules you were using before or do I need python3 versions of them as well?

Latest PyOpenGL, latest patched pygame2 and libsdl2 are included in the archives. Other than that and yaml, it's all python3 standard library.

Is the user supposed to install the PyOpenGL, latest patched pygame2 and libsdl2 from the archive or is the code statically linked to the ones in the archive?

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on June 07, 2012, 02:55:52 pm

Ah yes, I forgot. The path to the HUD font is hardcoded, and ubuntu-specific. That one will have to be edited. I'll make it configurable or something.

Also, on FPS numbers.
25 is without show_hidden, with zeddown = 4 (6 z-levels drawn every frame) and without debug (which draws another z-level).
All this on a subpar box with intel E2140 1.6Mhz and nvidia GT218. Should look better on contemporary hardware.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on June 07, 2012, 02:57:30 pm

Quote from: arclance on June 07, 2012, 02:52:58 pm

Is the user supposed to install the PyOpenGL, latest patched pygame2 and libsdl2 from the archive or is the code statically linked to the ones in the archive?

I tried to make it runnable without installing anything but python3.2 and python3-yaml.

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on June 07, 2012, 02:59:54 pm

Quote from: lxnt on June 07, 2012, 02:55:52 pm

Ah yes, I forgot. The path to the HUD font is hardcoded, and ubuntu-specific. That one will have to be edited. I'll make it configurable or something.

Also, on FPS numbers.
25 is without show_hidden, with zeddown = 4 (6 z-levels drawn every frame) and without debug (which draws another z-level).
All this on a subpar box with intel E2140 1.6Mhz and nvidia GT218. Should look better on contemporary hardware.

I program in python, tell me where it is hardcoded and I can change it while you are working on making it configurable.
I think I found it, line 316?

I have a i7 2600k and a GTX 560 Ti we will see how much of a difference that makes.

Quote from: lxnt on June 07, 2012, 02:57:30 pm

Quote from: arclance on June 07, 2012, 02:52:58 pm

Is the user supposed to install the PyOpenGL, latest patched pygame2 and libsdl2 from the archive or is the code statically linked to the ones in the archive?

I tried to make it runnable without installing anything but python3.2 and python3-yaml.

I will try the oneric first that should be closest to my systems setup as far as fgtestbed is concerned.
I got

Code: [Select]

./fgt -dfdir ../df3410 dumps/driftwood.dump raw/fakefloors
Traceback (most recent call last):
  File "./fgtestbed.py", line 43, in <module>
    from raw import MapObject, Designation
  File "/media/Linux_Data/Dwarf_Fortress/Test_Fortress/printmodeshader3/fgt-oneiric/fgtestbed/raw.py", line 32, in <module>
    import lxml.etree
ImportError: No module named lxml.etree
I will see if there is a module missing that might be installed by default in Ubuntu but on #!.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on June 07, 2012, 03:09:55 pm

Quote from: arclance on June 07, 2012, 02:59:54 pm

I program in python, tell me where it is hardcoded and I can change it while you are working on making it configurable.
I think I found it, line 316?

fgtestbed.py:316

Also py3sdl2.py:1055 , if you run it standalone (will need setting up environment, see fgt script). When run standalone, it displays a rainbow grid with a couple of hud panels, just to show that basic rendering works.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on June 07, 2012, 03:11:48 pm

Quote from: arclance on June 07, 2012, 02:59:54 pm

I got

Code: [Select]

./fgt -dfdir ../df3410 dumps/driftwood.dump raw/fakefloors
Traceback (most recent call last):
  File "./fgtestbed.py", line 43, in <module>
    from raw import MapObject, Designation
  File "/media/Linux_Data/Dwarf_Fortress/Test_Fortress/printmodeshader3/fgt-oneiric/fgtestbed/raw.py", line 32, in <module>
    import lxml.etree
ImportError: No module named lxml.etree
I will see if there is a module missing that might be installed by default in Ubuntu but on #!.

python3-lxml

I rewrote so much stuff in there I tend to forget exactly how much :(

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on June 07, 2012, 03:14:54 pm

I already got python3-lxml.
But now I get

Code: [Select]

X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  143 (XInputExtension)
  Minor opcode of failed request:  46 ()
  Value in failed request:  0x12
  Serial number of failed request:  99
  Current serial number in output stream:  102
What version of libsdl do you have?
I can install a slightly newer version if yours is different that mine.
Do you know what libsdl submodules are needed I don't have them all installed.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on June 07, 2012, 03:33:09 pm

Quote from: arclance on June 07, 2012, 03:14:54 pm

I already got python3-lxml.
But now I get

Code: [Select]

X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  143 (XInputExtension)
  Minor opcode of failed request:  46 ()
  Value in failed request:  0x12
  Serial number of failed request:  99
  Current serial number in output stream:  102


Aw. I think it has to do with trunk sdl2 trying to use XInput2.

Quote from: arclance on June 07, 2012, 03:14:54 pm

What version of libsdl do you have?
I can install a slightly newer version if yours is different that mine.
Do you know what libsdl submodules are needed I don't have them all installed.

Like I said, the trunk, since SDL 2.0 haven't had anything resembling a release yet.

 libSDL2, libSDL2_image with png support, libSDL2_ttf are required.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on June 07, 2012, 03:49:20 pm

I replaced the archive here (http://dffd.wimbli.com/file.php?id=6445) with one having sdl with XInput crap compiled out. It now peacefully segfaults in fglrx on my precise box, which means the XInput problem should be no more.

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on June 07, 2012, 04:02:57 pm

Quote from: lxnt on June 07, 2012, 03:49:20 pm

I replaced the archive here (http://dffd.wimbli.com/file.php?id=6445) with one having sdl with XInput crap compiled out. It now peacefully segfaults in fglrx on my precise box, which means the XInput problem should be no more.

I now get

Code: [Select]

./fgt -dfdir ../df3410 dumps/driftwood.dump raw/fakefloors
INFO:fgt.sdl_init:SDL_GL_DOUBLEBUFFER requested 1 got 1
INFO:fgt.sdl_init:SDL_GL_CONTEXT_MAJOR_VERSION requested 3 got 3
INFO:fgt.sdl_init:SDL_GL_CONTEXT_MINOR_VERSION requested 2 got 2
INFO:fgt.sdl_init:SDL_GL_CONTEXT_PROFILE_MASK requested 1 got 1
INFO:fgt.sdl_init:SDL_GL_CONTEXT_FLAGS requested 2 got 2
INFO:fgt.raws._parse_raws:yamnomnom done.
Traceback (most recent call last):
  File "./fgtestbed.py", line 778, in <module>
    main()
  File "./fgtestbed.py", line 770, in main
    dump_dir = None)
  File "/media/Linux_Data/Dwarf_Fortress/Test_Fortress/printmodeshader3/fgt-oneiric2/fgtestbed/raw.py", line 1643, in __init__
    self._parse_raws(dfprefix, fgraws, dump_dir)
  File "/media/Linux_Data/Dwarf_Fortress/Test_Fortress/printmodeshader3/fgt-oneiric2/fgtestbed/raw.py", line 1667, in _parse_raws
    fontpath, colortab = InitParser(dfprefix).get()
  File "/media/Linux_Data/Dwarf_Fortress/Test_Fortress/printmodeshader3/fgt-oneiric2/fgtestbed/raw.py", line 589, in __init__
    self.parse_file(init, self.init_handler)
  File "/media/Linux_Data/Dwarf_Fortress/Test_Fortress/printmodeshader3/fgt-oneiric2/fgtestbed/raw.py", line 428, in parse_file
    data = open(fna, encoding=enc).read()
IOError: [Errno 2] No such file or directory: '../df3410/data/init/init.txt'
It crashes right after the window opens.
It looks like you did not include the 0.34.10 raws in the archive.

After changing the command to point to the v0.34.10 raws I get.

Code: [Select]

./fgt -dfdir /media/Linux_Data/Dwarf_Fortress/Vanilla_Games/df_34_10_linux/df_linux dumps/driftwood.dump raw/fakefloors
INFO:fgt.sdl_init:SDL_GL_DOUBLEBUFFER requested 1 got 1
INFO:fgt.sdl_init:SDL_GL_CONTEXT_MAJOR_VERSION requested 3 got 3
INFO:fgt.sdl_init:SDL_GL_CONTEXT_MINOR_VERSION requested 2 got 2
INFO:fgt.sdl_init:SDL_GL_CONTEXT_PROFILE_MASK requested 1 got 1
INFO:fgt.sdl_init:SDL_GL_CONTEXT_FLAGS requested 2 got 2
INFO:fgt.raws._parse_raws:yamnomnom done.
INFO:fgt.raws._parse_raws:init.txt done.
Traceback (most recent call last):
  File "./fgtestbed.py", line 778, in <module>
    main()
  File "./fgtestbed.py", line 770, in main
    dump_dir = None)
  File "/media/Linux_Data/Dwarf_Fortress/Test_Fortress/printmodeshader3/fgt-oneiric2/fgtestbed/raw.py", line 1643, in __init__
    self._parse_raws(dfprefix, fgraws, dump_dir)
  File "/media/Linux_Data/Dwarf_Fortress/Test_Fortress/printmodeshader3/fgt-oneiric2/fgtestbed/raw.py", line 1671, in _parse_raws
    boo.eat(stdraws)
  File "/media/Linux_Data/Dwarf_Fortress/Test_Fortress/printmodeshader3/fgt-oneiric2/fgtestbed/raw.py", line 490, in eat
    self.parse_file(f, self.parse_token)
  File "/media/Linux_Data/Dwarf_Fortress/Test_Fortress/printmodeshader3/fgt-oneiric2/fgtestbed/raw.py", line 433, in parse_file
    raise RuntimeError("File '{}' is neither utf8 nor cp1252".format(fna))
RuntimeError: File '/media/Linux_Data/Dwarf_Fortress/Vanilla_Games/df_34_10_linux/df_linux/raw/objects/language_ELF.txt' is neither utf8 nor cp1252
I will see what resaveing that file in utf-8 does.

After resaveing the elf and dwarf language files in utf-8 it worked.

Code: [Select]

./fgt -dfdir /media/Linux_Data/Dwarf_Fortress/Vanilla_Games/df_34_10_linux/df_linux dumps/driftwood.dump raw/fakefloors
INFO:fgt.sdl_init:SDL_GL_DOUBLEBUFFER requested 1 got 1
INFO:fgt.sdl_init:SDL_GL_CONTEXT_MAJOR_VERSION requested 3 got 3
INFO:fgt.sdl_init:SDL_GL_CONTEXT_MINOR_VERSION requested 2 got 2
INFO:fgt.sdl_init:SDL_GL_CONTEXT_PROFILE_MASK requested 1 got 1
INFO:fgt.sdl_init:SDL_GL_CONTEXT_FLAGS requested 2 got 2
INFO:fgt.raws._parse_raws:yamnomnom done.
INFO:fgt.raws._parse_raws:init.txt done.
INFO:fgt.raws._parse_raws:df material templates done.
INFO:fgt.raws._parse_raws:df materials done.
INFO:fgt.raws.RawsCart.compile:nonmat/NONEMAT/Waterfall no cels defined.
INFO:fgt.raws.RawsCart.compile:nonmat/NONEMAT/Chasm no cels defined.
INFO:fgt.raws.RawsCart.compile:nonmat/NONEMAT/Fire no cels defined.
INFO:fgt.raws.RawsCart.compile:nonmat/NONEMAT/Void no cels defined.
INFO:fgt.raws.RawsCart.compile:nonmat/NONEMAT/MurkyPool no cels defined.
INFO:fgt.raws.RawsCart.compile:nonmat/NONEMAT/GlowingBarrier no cels defined.
INFO:fgt.raws.RawsCart.compile:nonmat/NONEMAT/OpenSpace no cels defined.
INFO:fgt.raws.RawsCart.compile:nonmat/NONEMAT/Campfire no cels defined.
INFO:fgt.raws.RawsCart.compile:nonmat/NONEMAT/EeriePit no cels defined.
INFO:fgt.raws.RawsCart.compile:nonmat/NONEMAT/MagmaFlow no cels defined.
INFO:fgt.raws.RawsCart.compile:nonmat/NONEMAT/GlowingFloor no cels defined.
INFO:fgt.raws.RawsCart.compile:nonmat/NONEMAT/RampTop no cels defined.
DEBUG:fgt.raws.InflateFrameseq:len(keyframes) = 5
INFO:fgt.raws._parse_raws:compile done, 13088 code units.
INFO:fgt.raws._parse_raws:Pageman(): 2 pages 512 tiles, font 352K; findex 4K; surface: rgba_surface(size=2048x44, SDL_PIXELFORMAT_ABGR8888, do_free=True)
INFO:fgt.raws._assemble_blitcode:13088 code units emitted, maxframes=24 codedepth=24
INFO:fgt.raws._assemble_blitcode:tileflags: 699x1x1; 2K
INFO:fgt.raws._assemble_blitcode:dispatch: 478x699x1; 1305K
INFO:fgt.raws._assemble_blitcode:blitcode: 115x115x24; 4959K
WARNING:fgt.CArrray:65536 extra bytes
INFO:fgt.mapdata:loaded 192x192x144 81M
INFO:fgt.renderer.init:GridVAO(size=Size2(w=166, h=72) num=11952)
INFO:fgt.renderer.init:Size2(w=1280, h=800)
Trying to move with the arrow keys crashed with this error.

Code: [Select]

Traceback (most recent call last):
  File "./fgtestbed.py", line 778, in <module>
    main()
  File "./fgtestbed.py", line 774, in main
    rednr.loop(pa.choke)
  File "./fgtestbed.py", line 691, in loop
    boost = 10 if ev.mod & 3 else 1
AttributeError: 'SDL_Event' object has no attribute 'mod'

I am getting a gfps of 60-62 with a vanilla v0.34.10 install.
I will take some screenshots after I install a tileset, probably tomorrow.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on June 07, 2012, 05:06:14 pm

Wow.

It worked.

Cleaning up bits and pieces, like fonts, stale keybindings now.

Edit: you see, since I fixed right-mouse-button panning, I never used arrow keys.

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on June 07, 2012, 05:17:55 pm

Quote from: lxnt on June 07, 2012, 05:06:14 pm

Wow.

It worked.

Cleaning up bits and pieces, like fonts, stale keybindings now.

Edit: you see, since I fixed right-mouse-button panning, I never used arrow keys.

I did it by reflex and because there is no controls readme so I just tried things.
There is a controls list box but it goes away the first time you do anything.
Unless you read it before you try something you won't know to press F1 to get it back.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on June 07, 2012, 05:36:39 pm

It's all fixed in git now.


For the record, to use the git (latest) code, you clone the repository (https://github.com/lxnt/fgtestbed (https://github.com/lxnt/fgtestbed)), then do git submodule init ; git submodule update there to fetch the df-structures, then  move in lib and dumps directories from the code drop.

I don't expect libraries being updated much once they're working.

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on June 07, 2012, 05:48:55 pm

Quote from: lxnt on June 07, 2012, 05:36:39 pm

It's all fixed in git now.


For the record, to use the git (latest) code, you clone the repository (https://github.com/lxnt/fgtestbed (https://github.com/lxnt/fgtestbed)), then do git submodule init ; git submodule update there to fetch the df-structures, then  move in lib and dumps directories from the code drop.

I don't expect libraries being updated much once they're working.

I tried git and got this error

Code: [Select]

Traceback (most recent call last):
  File "./fgtestbed.py", line 779, in <module>
    main()
  File "./fgtestbed.py", line 772, in main
    hudfont = a_mono_font(pa.hudfont, 18)
  File "/media/Linux_Data/Dwarf_Fortress/Test_Fortress/printmodeshader3/fgtestbed_git/py3sdl2.py", line 943, in a_mono_font
    ttfname, unused = findafont(pref)
  File "/media/Linux_Data/Dwarf_Fortress/Test_Fortress/printmodeshader3/fgtestbed_git/py3sdl2.py", line 932, in findafont
    return (path, None)
UnboundLocalError: local variable 'path' referenced before assignment

Doing this reveals the problem.

Code: [Select]

def findafont(subnames = []):
    stuff = subprocess.check_output("fc-list : style family file".split())
    leest = []
    for l in stuff.decode('utf-8').split("\n"):
        try:
            path, fam, style = l.split(':')
            leest.append((path, fam, style))
        except ValueError as e: # <---------
            print(str(e))
            pass
    for subname in subnames:
        for path, fam, style in leest:
            if subname.lower() in fam.lower():
                print(path, fam, subname)
                return ( path, subname)
            else:
                print(subname.lower(), fam.lower(), style, "fail")
    return (path, None)
Errors

Code: [Select]

too many values to unpack (expected 3)
...
too many values to unpack (expected 3)
too many values to unpack (expected 3)
too many values to unpack (expected 3)
too many values to unpack (expected 3)
need more than 1 value to unpack
The problematic entries (all of them) look like this

Code: [Select]

/usr/share/fonts/type1/gsfonts/b018015l.pfb: URW Bookman L:style=Demi Bold:file=/usr/share/fonts/type1/gsfonts/b018015l.pfb
/usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono.ttf: DejaVu Sans Mono:style=Book:file=/usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono.ttf
/usr/share/fonts/X11/Type1/p052003l.pfb: URW Palladio L:style=Roman:file=/usr/share/fonts/X11/Type1/p052003l.pfb


Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on June 07, 2012, 07:02:05 pm

^
Changing line 921 in py3sdl2.py from

Code: [Select]

            path, fam, style = l.split(':')
to

Code: [Select]

            path, fam, style, file_test = l.split(':')
or

Code: [Select]

            path, fam, style = l.split(':')[0:3]
makes it work.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on June 07, 2012, 07:07:21 pm

Quote from: arclance on June 07, 2012, 07:02:05 pm

^
Changing line 921 in py3sdl2.py from

Code: [Select]

            path, fam, style = l.split(':')
to

Code: [Select]

            path, fam, style, file_test = l.split(':')
makes it work.

Thank you. I went another way and just used a fixed output format for the fc-list. Just pushed.
Font selection is hacky and crude, but there's a -hudfont option if you don't like what it decides to use.

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on June 07, 2012, 07:22:26 pm

Quote from: lxnt on June 07, 2012, 07:07:21 pm

Thank you. I went another way and just used a fixed output format for the fc-list. Just pushed.
Font selection is hacky and crude, but there's a -hudfont option if you don't like what it decides to use.

Your welcome.
I looked at what you did in git, it probably uses a little less cpu/memory since you don't make more variables or call a subset of the split output.

Yes it's a little hacky, from what I see it's basically doing "here are some decent fonts, try to use those. If all else fails use a monospace font".
But it should let people see if it works without having them find the file for a font they like themselves just to test fgtestbed.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on June 07, 2012, 07:40:26 pm

It's not that I care for optimizing a half-baked, run-once piece of code, it's just that I didn't expect fc-list output formats to differ between debian flavours.

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on June 07, 2012, 07:59:17 pm

It might be caused by a version difference actually.
Most of my system is Debian stable/backports but certain things are from unstable (ubuntu current or +1 equivalent).
My kernel, graphics card drivers, and certain programs are from unstable for bugfixes or to get a current version.
It works better than the when I used Ubuntu but it requires more user input than Ubuntu for everything to work smoothly.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on June 08, 2012, 05:18:51 am

3411 dumper uploaded.

 http://dffd.wimbli.com/file.php?id=6210 (http://dffd.wimbli.com/file.php?id=6210)

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on June 08, 2012, 12:52:47 pm

Stress test : a 16x16 embark dump.

Code: [Select]

INFO:fgt.mapdata:loaded 768x768x206 1854M

failed.

Code: [Select]

OpenGL.error.GLError: GLError(
err = 1285,
description = b'out of memory',
baseOperation = glDrawArrays,
cArguments = (GL_POINTS, 0, 4816)
)

:(

DF ate 3.6G of memory while embarking. SSD sure helps with swap. Gzipped dump file is 52M.

I need an upgrade.

What is most depressing is that this same stress test worked before. Might had less z-levels, but still.

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on June 08, 2012, 01:03:21 pm

Quote from: lxnt on June 08, 2012, 12:52:47 pm

Stress test : a 16x16 embark dump.

Code: [Select]

INFO:fgt.mapdata:loaded 768x768x206 1854M

failed.

Code: [Select]

OpenGL.error.GLError: GLError(
err = 1285,
description = b'out of memory',
baseOperation = glDrawArrays,
cArguments = (GL_POINTS, 0, 4816)
)

:(

DF ate 3.6G of memory while embarking. SSD sure helps with swap. Gzipped dump file is 52M.

I need an upgrade.

What is most depressing is that this same stress test worked before. Might had less z-levels, but still.

Let me try it I have 8GB of ram and a 2GB graphics card, I want to see how much slower it runs.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on June 08, 2012, 01:52:50 pm

http://dffd.wimbli.com/file.php?id=6454

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on June 08, 2012, 02:40:37 pm

It works though it's using 3.50GiB of ram (and very little gpu ram) the gfps is still 60!

Code: [Select]

./fgt -dfdir /media/Linux_Data/Dwarf_Fortress/Vanilla_Games/df_34_10_linux/df_linux ../16x16x206.dump raw/fakefloors
INFO:fgt.sdl_init:SDL_GL_DOUBLEBUFFER requested 1 got 1
INFO:fgt.sdl_init:SDL_GL_CONTEXT_MAJOR_VERSION requested 3 got 3
INFO:fgt.sdl_init:SDL_GL_CONTEXT_MINOR_VERSION requested 2 got 2
INFO:fgt.sdl_init:SDL_GL_CONTEXT_PROFILE_MASK requested 1 got 1
INFO:fgt.sdl_init:SDL_GL_CONTEXT_FLAGS requested 2 got 2
INFO:fgt.raws._parse_raws:yamnomnom done.
INFO:fgt.raws._parse_raws:init.txt done.
INFO:fgt.raws._parse_raws:df material templates done.
INFO:fgt.raws._parse_raws:df materials done.
INFO:fgt.raws.RawsCart.compile:nonmat/NONEMAT/RampTop no cels defined.
INFO:fgt.raws.RawsCart.compile:nonmat/NONEMAT/Void no cels defined.
INFO:fgt.raws.RawsCart.compile:nonmat/NONEMAT/GlowingBarrier no cels defined.
INFO:fgt.raws.RawsCart.compile:nonmat/NONEMAT/Campfire no cels defined.
INFO:fgt.raws.RawsCart.compile:nonmat/NONEMAT/Fire no cels defined.
INFO:fgt.raws.RawsCart.compile:nonmat/NONEMAT/MurkyPool no cels defined.
INFO:fgt.raws.RawsCart.compile:nonmat/NONEMAT/OpenSpace no cels defined.
INFO:fgt.raws.RawsCart.compile:nonmat/NONEMAT/Chasm no cels defined.
INFO:fgt.raws.RawsCart.compile:nonmat/NONEMAT/Waterfall no cels defined.
INFO:fgt.raws.RawsCart.compile:nonmat/NONEMAT/MagmaFlow no cels defined.
INFO:fgt.raws.RawsCart.compile:nonmat/NONEMAT/EeriePit no cels defined.
INFO:fgt.raws.RawsCart.compile:nonmat/NONEMAT/GlowingFloor no cels defined.
DEBUG:fgt.raws.InflateFrameseq:len(keyframes) = 5
INFO:fgt.raws._parse_raws:compile done, 13088 code units.
INFO:fgt.raws._parse_raws:Pageman(): 2 pages 512 tiles, font 352K; findex 4K; surface: rgba_surface(size=2048x44, SDL_PIXELFORMAT_ABGR8888, do_free=True)
INFO:fgt.raws._assemble_blitcode:13088 code units emitted, maxframes=24 codedepth=24
INFO:fgt.raws._assemble_blitcode:tileflags: 699x1x1; 2K
INFO:fgt.raws._assemble_blitcode:dispatch: 957x699x1; 2613K
INFO:fgt.raws._assemble_blitcode:blitcode: 115x115x24; 4959K
WARNING:fgt.CArrray:65536 extra bytes
INFO:fgt.mapdata:loaded 768x768x206 1854M
/home/arclance/.fonts/ubuntu-font-family-0.80/UbuntuMono-B.ttf
INFO:fgt.renderer.init:GridVAO(size=Size2(w=166, h=72) num=11952)
INFO:fgt.renderer.init:Size2(w=1280, h=800)
I takes a good 10-20s to load the dump.
I don't know if something is wrong with the dump or if fgtestbed can't handle a map this large but the tileset seems to only be applied to water.
(http://t.imgbox.com/aaof9bNg.jpg) (http://imgbox.com/aaof9bNg)

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on June 08, 2012, 03:20:51 pm

Quote from: arclance on June 08, 2012, 02:40:37 pm

It works though it's using 3.50GiB of ram (and very little gpu ram) the gfps is still 60!

Wow. The driver must me mapping system memory in rather than copying. Entire dump is used as a single texture.

Quote from: arclance on June 08, 2012, 02:40:37 pm

I takes a good 10-20s to load the dump.
I don't know if something is wrong with the dump or if fgtestbed can't handle a map this large but the tileset seems to only be applied to water.

Hm. Grey are the hidden tiles, that is, not revealed. Water was revealed obviously, since it's ponds at the surface. Green is the fill color, meaning nothing was drawn there. At zeddown=4 lots of it is to be expected since I deliberately chose a mountanious area.

Anything else not being drawn might have something to do with unusually high number of materials present - 957, where typical number is about 450. However it should've been able to handle at least 1024.

Framerate not dropping might be due to nothing being actually drawn.

Well.  I'm going to try integrating this into libgraphics now (so that it draws current view is a separate window).
I'm quite lost on how to submit building data for drawing, maybe that way I'll stumble on some ideas.

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on June 08, 2012, 03:51:04 pm

Quote from: lxnt on June 08, 2012, 03:20:51 pm

Quote from: arclance on June 08, 2012, 02:40:37 pm

It works though it's using 3.50GiB of ram (and very little gpu ram) the gfps is still 60!

Wow. The driver must me mapping system memory in rather than copying. Entire dump is used as a single texture.

It's only using about half my ram so it did not bog down my computer.
It was more than I expected but not the most a program has ever used either (the record is about 12GiB).
It uses less gpu ram than using opengl to play HD videos with mplayer.

Quote from: lxnt on June 08, 2012, 03:20:51 pm

Quote from: arclance on June 08, 2012, 02:40:37 pm

I takes a good 10-20s to load the dump.
I don't know if something is wrong with the dump or if fgtestbed can't handle a map this large but the tileset seems to only be applied to water.

Hm. Grey are the hidden tiles, that is, not revealed. Water was revealed obviously, since it's ponds at the surface. Green is the fill color, meaning nothing was drawn there. At zeddown=4 lots of it is to be expected since I deliberately chose a mountanious area.

Anything else not being drawn might have something to do with unusually high number of materials present - 957, where typical number is about 450. However it should've been able to handle at least 1024.

Framerate not dropping might be due to nothing being actually drawn.

Well.  I'm going to try integrating this into libgraphics now (so that it draws current view is a separate window).
I'm quite lost on how to submit building data for drawing, maybe that way I'll stumble on some ideas.

I was sure it was the surface because there is a brook about 10z down from that screenshot.
I recognized the gl "nothing here" green color, is it possible to make that color respect these settings in d_init.txt?

Code: [Select]

[SKY:178:3:0:0]
[CHASM:250:0:0:1]
I went up until the whole screen was green and everything was "unrevealed grey" or "water blue".
Going down is the same but just "unrevealed grey" at the bottom.
Everything but the water is drawn "unrevealed grey" even the tops of the mountains.

For buildings are you able to tell where they are (what tiles they take up)?
If you are you could just read their raws to determine what each tile should be.
Getting material based colors right would be more difficult though.

Have you looked at how buildings work in stonesense?
I know they get building locations but I don't know how they chose what color their sprites are shaded.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on June 08, 2012, 04:14:33 pm

Quote from: arclance on June 08, 2012, 03:51:04 pm

I recognized the gl "nothing here" green color, is it possible to make that color respect these settings in d_init.txt?

Code: [Select]

[SKY:178:3:0:0]
[CHASM:250:0:0:1]


no problem.

Quote from: arclance on June 08, 2012, 03:51:04 pm

For buildings are you able to tell where they are (what tiles they take up)?
If you are you could just read their raws to determine what each tile should be.
Getting material based colors right would be more difficult though.

Have you looked at how buildings work in stonesense?
I know they get building locations but I don't know how they chose what color their sprites are shaded.

Yes, I know all that df-structures project, and, by extension, DFHack and Stonesense can know about structures. I also do parse DF raws, since that's where the material colors and default tile graphics come from.

Problem is, each building tile is (at least) 44 bits of state not counting position, and this is plainly too much to use a 1 to 1.5 -level lookup, as is done with map tiles. On the other hand I don't want multiple rendering passes if I can help it, and certainly not an unbounded number of render passes per frame, like it would be if I draw each building separately. I want to upload something once per frame, and then tell the GPU to draw it all, like it's done now with the map.

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on June 08, 2012, 04:30:26 pm

Quote from: lxnt on June 08, 2012, 04:14:33 pm

Yes, I know all that df-structures project, and, by extension, DFHack and Stonesense can know about structures. I also do parse DF raws, since that's where the material colors and default tile graphics come from.

Problem is, each building tile is (at least) 44 bits of state not counting position, and this is plainly too much to use a 1 to 1.5 -level lookup, as is done with map tiles. On the other hand I don't want multiple rendering passes if I can help it, and certainly not an unbounded number of render passes per frame, like it would be if I draw each building separately. I want to upload something once per frame, and then tell the GPU to draw it all, like it's done now with the map.

You could use an array that defines what to send to the gpu.
Start by filling the array using the map data.
Then update the cells in the array for buildings (or anything else).
Last send the final array to a function that sends data to the gpu as defined in the array.

This way no matter how many changes are made you only draw once per update.

I haven't used any python arrays of this size so I don't know if this would be fast enough though.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on June 09, 2012, 12:17:34 am

Thanks for suggestion.

As for the arrays, fgtestbed doesn't use python ones, and I went away from using numpy ones, since their use as OpenGL textures was problematic and I needed to get as close to C as practical to ease later integration. See the CArray class in py3sdl2.py.

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on June 09, 2012, 12:20:30 pm

^ The CArray class looks interesting but I don't have the time to think through how it works right now.
I do think that using the python "array" (lists of lists of lists of .....) would have been too slow for this anyway.

What dimensionality did your arrays end up being?
I could see them being 4D or 5D depending on how you structured the data.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on June 09, 2012, 03:30:42 pm

Quote from: arclance on June 09, 2012, 12:20:30 pm

^ The CArray class looks interesting but I don't have the time to think through how it works right now.

It's a bytearray posing as a 3D array of structs (binary data, see struct module).

Quote from: arclance on June 09, 2012, 12:20:30 pm

What dimensionality did your arrays end up being?
I could see them being 4D or 5D depending on how you structured the data.

Since current hardware can't handle more that 3D textures natively, this is what I ended up with.

It's 3D for the map data, uploaded as texture, which holds, basically, the  (material, tiletype) tuple.

(material, tiletype) are coordinates into 2d dispatch texture, which holds (cx,cy) coords into blitcode texture (plus animation frame count in unused bits), current frame number is supplied externally. Aniframe count is used to loop animations properly.

(cx, cy, frame_no) are taken as coordinates into 3D blitcode texture.  The blitcode texel holds (mode|celindex, unused, fg, bg), where celindex is an index into texture album index  - 2D texture holding tile graphic size and location in the album - enabling non-uniform size of tile graphics - with which texture coordinates into the actual graphics texture (2D) are calculated.

Title: Re: [PRINT_MODE:SHADER]
Post by: King Mir on June 09, 2012, 07:21:11 pm

Buildings can be transparent (the floor tile shows through), so that means an additional layer of data, not a replacement.

One way to do it is by adding 3 additional fields to the map data: building (which building), building coordinate (ie which of the nine tiles of a workshop to use), and building material. You'll also need a feild for if it's walled or floored eventually. And for that matter, smoothed or engraved. You can probably figure out which directional walls to use on the GPU. When you do, remember that doors effect wall textures, so the building location must be part of the texture to compute the wall direction.

Another way to do it would be to have a list of buildings with coordinates. This is a sparse array. The GPU can merge it with the dense array of map data or render it as a second pass. The 3 fields are the same. In this case the building coordinate is not needed. You can then transform the list of buildings into a list of tiles on the GPU. The other fields stay on the map data.

Which you use probably depends on how the information is most efficiently obtained from the application. You probably want to offload as much onto the GPU as you can.

Also remember that you can use two textures if 1 texture has more than 32 bits of data per location. I don't know if that's your problem, but you mentioned 44 bits of building data being an issue.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on June 10, 2012, 05:37:46 am

Quote from: King Mir on June 09, 2012, 07:21:11 pm

Buildings can be transparent (the floor tile shows through), so that means an additional layer of data, not a replacement.

Certainly. Question is how to format this data so that work is offloaded to the GPU as much as possible, but without bogging it down.
I absolutely want to avoid walking around structures on the CPU determining how  a door is drawn in open vs closed state.

Quote from: King Mir on June 09, 2012, 07:21:11 pm

One way to do it is by adding 3 additional fields to the map data: building (which building), building coordinate (ie which of the nine tiles of a workshop to use), and building material.

That's 10 bits for material, 5 bits for tile number (trade depot and siege workshop are 5x5), and 7 bits for building type. Note how this lacks open/closed spinning/stopped, build stage, orientation for pumps/waterwheels, etc state. Which add up to 44 bits by my estimation. Now that I got those 44 bits onto the gpu, what do I do with them? Somehow they must ultimately be mapped to graphics, and this is my main problem.

(not to mention bridges, stockpiles, civzones and rooms, their arbitrary dimensions is an entirely separate problem I haven't even thought about)

Quote from: King Mir on June 09, 2012, 07:21:11 pm

Another way to do it would be to have a list of buildings with coordinates. This is a sparse array. The GPU can merge it with the dense array of map data or render it as a second pass. The 3 fields are the same.

That would result in the GPU having to walk this list for each tile drawn. Not a very big deal in itself, but I expect to draw 4-6 z-levels,  fake floors under trees and such require up to 8 texture lookups, and yet undetermined algorithm to apply stencils to tile borders will eat who knows how much gpu ticks. So brute-force methods don't cut it.

The building list would have to be sortied or indexed the list on the CPU,  each game engine frame. But what sort of index? It has to be suitable for craetures and items too.

Quote from: King Mir on June 09, 2012, 07:21:11 pm

Also remember that you can use two textures if 1 texture has more than 32 bits of data per location. I don't know if that's your problem, but you mentioned 44 bits of building data being an issue.

44 bits are an issue if you try to use them as an index into some table. Otherwise, GL3.0 textures can hold 32bits per channel, that is quite enough.

Title: Re: [PRINT_MODE:SHADER]
Post by: Vattic on June 10, 2012, 06:52:25 am

Quote from: lxnt on June 10, 2012, 05:37:46 am

Quote from: King Mir on June 09, 2012, 07:21:11 pm

One way to do it is by adding 3 additional fields to the map data: building (which building), building coordinate (ie which of the nine tiles of a workshop to use), and building material.

That's 10 bits for material, 5 bits for tile number (trade depot and siege workshop are 5x5), and 7 bits for building type. Note how this lacks open/closed spinning/stopped, build stage, orientation for pumps/waterwheels, etc state. Which add up to 44 bits by my estimation. Now that I got those 44 bits onto the gpu, what do I do with them? Somehow they must ultimately be mapped to graphics, and this is my main problem.

(not to mention bridges, stockpiles, civzones and rooms, their arbitrary dimensions is an entirely separate problem I haven't even thought about)

Also worth remembering that mods can include their own workshops of up to 31x31.

Title: Re: [PRINT_MODE:SHADER]
Post by: King Mir on June 10, 2012, 06:59:37 am

Quote from: lxnt on June 10, 2012, 05:37:46 am

Quote from: King Mir on June 09, 2012, 07:21:11 pm

One way to do it is by adding 3 additional fields to the map data: building (which building), building coordinate (ie which of the nine tiles of a workshop to use), and building material.

That's 10 bits for material, 5 bits for tile number (trade depot and siege workshop are 5x5), and 7 bits for building type. Note how this lacks open/closed spinning/stopped, build stage, orientation for pumps/waterwheels, etc state. Which add up to 44 bits by my estimation. Now that I got those 44 bits onto the gpu, what do I do with them? Somehow they must ultimately be mapped to graphics, and this is my main problem.

(not to mention bridges, stockpiles, civzones and rooms, their arbitrary dimensions is an entirely separate problem I haven't even thought about)

So as I understand it, you need to have the building lookup as 1 step, but the look up index can only be 32 bits. So as a solution, you'd have to separate the material data, which determines the color, from the other data that determines the tile shape. Look up the shape on one texture, and the colors on another texture. You might want a separate texture for each of the color involved (foreground and background for building and floor), so that you can have full color materials. Then overlay or otherwise merge the color and shape info.

Quote

Quote from: King Mir on June 09, 2012, 07:21:11 pm

Another way to do it would be to have a list of buildings with coordinates. This is a sparse array. The GPU can merge it with the dense array of map data or render it as a second pass. The 3 fields are the same.

That would result in the GPU having to walk this list for each tile drawn. Not a very big deal in itself, but I expect to draw 4-6 z-levels,  fake floors under trees and such require up to 8 texture lookups, and yet undetermined algorithm to apply stencils to tile borders will eat who knows how much gpu ticks. So brute-force methods don't cut it.

The building list would have to be sortied or indexed the list on the CPU,  each game engine frame. But what sort of index? It has to be suitable for craetures and items too.

No, it's all one sparse array, not several z levels of textures. So it's implemented as vertex data instead of a texture. So you have each building location as a vertex, the the data identifying that vertex contain the building data. That gets transformed into vertexes for each tile, so each workshop is transformed from 1 vertex to 9. Then the tile gets mapped to the actual graphic. All in parallel.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on June 10, 2012, 01:52:33 pm

Quote from: Vattic on June 10, 2012, 06:52:25 am

Also worth remembering that mods can include their own workshops of up to 31x31.

Aw, nice. Now it's 10 bits for the tile number. Thanks for the heads-up.

Quote from: King Mir on June 10, 2012, 06:59:37 am

So as I understand it, you need to have the building lookup as 1 step, but the look up index can only be 32 bits.

No, I don't exactly require single-step lookups, in fact splitting them into multiple steps help reduce needed memory for the indices.

Deciding how exactly to split, so that CPU has an easy time generating the data, GPU isn't bogged down, it all fits into the graphic card's memory,  and doesn't need to be updated too frequently is the hard part.

Quote from: King Mir on June 10, 2012, 06:59:37 am

No, it's all one sparse array, not several z levels of textures. So it's implemented as vertex data instead of a texture. So you have each building location as a vertex, the the data identifying that vertex contain the building data. That gets transformed into vertexes for each tile, so each workshop is transformed from 1 vertex to 9. Then the tile gets mapped to the actual graphic. All in parallel.

This might be the way for all the "transients" - things that aren't on 99% of map tiles. Thanks for the idea.

Title: Re: [PRINT_MODE:SHADER]
Post by: King Mir on June 10, 2012, 08:24:33 pm

Yeah, good luck with it.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on June 11, 2012, 04:21:24 pm

In the meanwhile I embedded a python interpeter into the libgraphics.so, modified the lib to run with SDL2, rewrote my old print_mode:shader renderer in python and almost made it all work but for a memory corruption I can't yet trace down. I suspect it has something to do with df executable referencing SDL 1.2 lib. Guess, arrogantly substituting refenced symbols with ones from SDL2 was not going to work after all.

When I'm done with that corruption, it'll be possible to run the fgtesbed both standalone and from inside DF, in a separate window.

The code is here: https://github.com/lxnt/rendumper/tree/fullgraphics (https://github.com/lxnt/rendumper/tree/fullgraphics).

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on July 18, 2012, 02:18:04 pm

It's been a while since you last posted.
Have you made any progress on the memory corruption problem?

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on July 20, 2012, 03:06:27 pm

Quote from: arclance on July 18, 2012, 02:18:04 pm

It's been a while since you last posted.
Have you made any progress on the memory corruption problem?

I strongly suspect it is due to sdl12 - sdl20 interaction. Worse yet, disproval of this conjecture would require quite a lot of work. And even if it is not so, having both libraries (and two sets of  dependecies) in the same address space is a recipe for some other disaster.

Instead I decided to "do it right" and split the libgraphics into platform dependent/independent parts, latter to live in dynamically loaded modules. Got burned out while designing renderer interface, so took a month off.

The basic idea is to get rid of any platform-dependent code in the main executable and to make the rendeder live in .dll on win32 while at it. There are five interfaces - musicsound, textures (creature graphics index), keyboard (keybindings, ...), platform (read/write/create/delete files, messageboxes, ...) and the renderer (which isn't finalized yet).

First stage would be a (fully functional, of course) libgraphics.so which instead of containing all the PRINT_MODE and musicsound implementations, will dynamically load them.

After that I hope to persuade Toady to extract whatever code uses the sdl12 calls and is still not in g_src, so that executable itself will not in any way depend on third-party libraries. With some win32-specific glue code and recompilation of the game for win32 using my work, we will at last have means to swap around renderers in win32 too.

I just pushed whatever commits there were, see https://github.com/lxnt/rendumper/tree/interfaces (https://github.com/lxnt/rendumper/tree/interfaces). More work was done, just not committed yet.

The time is ripe :). SDL 2.0 is going to have a release at last, and it seems that Mesa guys will deliver OpenGL 3.0 soon enough for autumn distro releases, so it just might be that my work won't have to rely on dependencies'  bleeding edges.


Edit: committed all pending changes in one lump.

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on July 20, 2012, 03:27:42 pm

Sounds promising, though I don't know much about C so the code does not mean much to me at that level.

I understand getting burned out and taking a break.
It reminds me of an assignment we got in the python class I took in college to boost my GPA.

The professor had us use a stripped down version of turtle graphics and told us to program a resizeable snowman using it.
This required that our code draw vector objects which was fine except for the requirement of using circles.
Drawing a circle with turtle graphics is hard because you can't designate individual pixels or draw curves, everything must be done by drawing straight lines at least 2 pixels long.
Several people dropped the class because they could not do it.
I got fed up trying to find a good (i.e. fast) way to do it and instead just did a brute force calculation on every pixel in the canvas to see if it was a part of the circle.

The part that really caused people to get burnt out was that the full version of turtle graphics includes a circle drawing function but we were not allowed to use it.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on July 20, 2012, 04:51:42 pm

Might be he thought of drawing a circle with those restrictions as a mathematical programming (http://en.wikipedia.org/wiki/Mathematical_optimization) problem of maximizing a function like f(x,y)=1/(x*x+y*y - r*r) where r is the circle's radius. Might be he did not in fact realize how he was seeing it. It was cruel of him none the less.

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on July 20, 2012, 05:07:09 pm

Quote from: lxnt on July 20, 2012, 04:51:42 pm

Might be he thought of drawing a circle with those restrictions as a linear programming (http://en.wikipedia.org/wiki/Linear_programming) problem of maximizing a function like f(x,y)=1/(x*x+y*y - r*r) where r is the circle's radius. Might be he did not in fact realize how he was seeing it. It was cruel of him none the less.

I doubt it this was a Programing 101 class, which I was disappointed to find out no longer taught C or C++, which I wanted to learn, but was Python 2.7 instead.
The class was not intended to require math skills on that level, just high school level algebra (passing the "I got a C or worse in high school algebra" math class was the minimum required to take the class) .
We barely covered that type of programing in my 400 level physics classes.

This is my "I don't want to work on this anymore" solution, comments counted towards your grade.

Code: [Select]

def drawCircle(snowMan, circCenterX, circCenterY, radius, lineWidth): # draw a circle with a line width of approximately lineWidth
snowMan.up() # stop drawing
for x in xrange(int(circCenterX - radius - 1),int(circCenterX + radius + 1)): # loop over all pixels in x that the circle could be in
for y in xrange(int(circCenterY - radius - 1),int(circCenterY + radius + 1)): # loop over all pixels in y that the circle could be in
distance = math.sqrt(((x-circCenterX)**2) + ((y-circCenterY)**2)) # find the distance from the circles center to the current x,y position
if int(distance) == radius: # check if the current distance is the radius of the circle
x2 = x+(lineWidth-1) # add linewidth to x point to get second point to draw current outline point
y2 = y+(lineWidth-1) # add linewidth to y point to get second point to draw current outline point
snowMan.move(x,y) # move to current found edge point of circle
snowMan.down() # start drawing
snowMan.move(x2,y2) # move in towards center to draw edge
snowMan.up() # stop drawing
#endif
#endfor
#endfor
#enddef
It's slow enough that you can see it paint the circle on an old computer.

Title: Re: [PRINT_MODE:SHADER]
Post by: Lac on July 28, 2012, 08:43:37 am

Good to hear Windows is back on the cards, albeit with cooperation needed from Toady...which we can pretend might happen!

PS
I thought the convention in Turtle is to draw many-sided polygons to represent circles.  Maybe the tutor didn't expect you to push the number of sides to minimise side length right down to a guaranteed 2px.  Although I'd imagine it is possible to calculate the number sides that would give a side length of 2 for a given radius.   [I found this: side length = 2* radius * sin (PI / num_sides).  I was going to try it on a turtle website, but found it only had arctan and not arcsin, which makes it harder.  But I agree it seems unfair to inflict such maths on a programming course.

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on July 28, 2012, 10:54:54 am

Quote from: Lac on July 28, 2012, 08:43:37 am

PS
I thought the convention in Turtle is to draw many-sided polygons to represent circles.  Maybe the tutor didn't expect you to push the number of sides to minimise side length right down to a guaranteed 2px.

My way gets you down to 1px accuracy in the circle but has a minimum line width of 2px because I draw the line from the outside edge towards the center.

Most people cheated and looked up your solution online, I ran out of time to come up with it without cheating so I did it a different way.
The professor did not give us any hints on how to make the circle and most people could not do it on their own.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on November 16, 2012, 03:46:38 pm

Today I was surprised to see that my existing code in fact works on open-source amd drivers as of now (ubuntu 12.10, oibaf ppa, kernel 3.7-rc5, hd6850), with minor modifications and quite sad fps.

SDL 2.0 wasn't released yet, though :( 

Seems like the pattern of making a renderer for the previous DF release will continue this time :-/

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on November 16, 2012, 04:08:24 pm

It is good to see that you are still planning to work on it since it has been a while since your last post.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on November 18, 2012, 03:03:46 pm

Yeah, feels good to be interested in this again.

I even rewrote the readme file and pushed a dependency-building script.
Other stuff broke though. Open space ceased to be open for example  :P

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on December 07, 2012, 02:56:58 pm

Quote from: lxnt on July 20, 2012, 03:06:27 pm

First stage would be a (fully functional, of course) libgraphics.so which instead of containing all the PRINT_MODE and musicsound implementations, will dynamically load them.

I have achieved this, sort of.

As of now, I have a  ncurses-mode renderer module, and a stub musicsound module. Plus so-called platform module which implements what's in platform.cpp. And the simulation loop ended up as a separate module too, since it has to be shared between different renderers.

Link is the left part of my sig.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on December 10, 2012, 04:10:09 pm

That's it.

DF runs in ncurses mode almost without SDL at all.

All platform-dependent code was either moved outside libgraphics.so or converted.

Only the world_graphic-regionN-YYY--XXXXX.bmp generating code is still in the binary itself, and:

 0x00000001 (NEEDED)                     Shared library: [libSDL-1.2.so.0]

 :'(


edit:
Aw, no, I forgot to move out input processing. That and ttf_manager are all that's left to integrate, though ttf_manager would require a graphics-capable renderer to develop with. Well, seems I'll have to revive print_mode:shader for this, meaning GL 2.1 support.

After that there will be experiments on glueing in fgtestbed itself.

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on December 10, 2012, 04:21:34 pm

So the only thing left that depends on SDL is some hardcoded part of the worldgen code you can't change?
If so that sounds frustrating.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on December 10, 2012, 04:38:07 pm

Quote from: arclance on December 10, 2012, 04:21:34 pm

So the only thing left that depends on SDL is some hardcoded part of the worldgen code you can't change?
If so that sounds frustrating.

If it gets in the way again I'll resort to hacking dynamic loader. Something like this (http://www.apriorit.com/our-company/dev-blog/181-elf-hook), but in reverse.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on December 10, 2012, 06:22:09 pm

Input has been unified between key-repeating and nonrepeating backends.

Title: Re: [PRINT_MODE:SHADER]
Post by: King Mir on December 10, 2012, 07:05:28 pm

It's good to see this is moving.  :)

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on December 11, 2012, 10:26:52 am

Next step - a game of life (http://en.wikipedia.org/wiki/Conway%27s_Game_of_Life) using the modular backend for input/rendering - here (https://github.com/downloads/lxnt/rendumper/life.7z). Linux 32-bit, needs libncursesw5. Unzip and launch from the directory:

Code: [Select]

cd /tmp
7zr x life.7z
./life . ncurses

Minor bugs galore, minimal functionality. Intended as a test subject when developing other modules.
Debugging and adding features is left as an excerise to the reader.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on December 21, 2012, 03:51:59 pm

With the latest push, SDL2/OpenGL2 renderer seems to be in a good shape.

Input event handling, especially mouse, still needs some work.

Vertex buffer streaming will have to be simplified, current overengineered metabuffer scheme doesn't belong to what is to become an OpenGL ES 2.0 renderer.

The modularization work easily allows network transport between DF core and the renderer, so with a modest amount of work one can push DF interface to an android tablet or some sorry netbook while the DF itself runs on a ridiculously overpowered box somewhere in the basement. You'd need a decent keyboard though :)

Now, have to fix the input and on to trying to see how it compiles for windows and works under Wine.

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on December 21, 2012, 03:59:50 pm

Sounds like you are making good progress.
If you need someone to test anything you are working on just let me know.
If you are using a current Ubuntu (or I think Fedora) I would have to compile it myself though since it is using a newer version of glibc than Debian.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on December 21, 2012, 04:11:55 pm

Quote from: arclance on December 21, 2012, 03:59:50 pm

Sounds like you are making good progress.
If you need someone to test anything you are working on just let me know.
If you are using a current Ubuntu (or I think Fedora) I would have to compile it myself though since it is using a newer version of glibc than Debian.

Thanks.

Build system is in shambles, unfortunately, custom paths hardcoded everywhere, binaries looking for stuff in obscure places, etc. This also needs some attention, or a readme at least.

I'll be building "releases" in a VM, since fgtestbed development kept pushing me onto the bleeding edge because of Mesa GL3 support. I currently build 32bit builds with gcc-4.5, the version that df3411-linux seems to be built with, but for the libc, and various SDL's dependencies it ain't that simple. Is ubuntu 12.04 a good choice? 11.10 might be possible, but beyond that I'm afraid it'll get hairy.

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on December 21, 2012, 04:25:23 pm

Quote from: lxnt on December 21, 2012, 04:11:55 pm

Quote from: arclance on December 21, 2012, 03:59:50 pm

Sounds like you are making good progress.
If you need someone to test anything you are working on just let me know.
If you are using a current Ubuntu (or I think Fedora) I would have to compile it myself though since it is using a newer version of glibc than Debian.

Thanks.

Build system is in shambles, unfortunately, custom paths hardcoded everywhere, binaries looking for stuff in obscure places, etc. This also needs some attention, or a readme at least.

I'll be building "releases" in a VM, since fgtestbed development kept pushing me onto the bleeding edge because of Mesa GL3 support. I currently build 32bit builds with gcc-4.5, the version that df3411-linux seems to be built with, but for the libc, and various SDL's dependencies it ain't that simple. Is ubuntu 12.04 a good choice? 11.10 might be possible, but beyond that I'm afraid it'll get hairy.

The glibc version in Debian is 2.13 right now (http://packages.debian.org/sid/eglibc-source), I don't expect that to change in the next few months since they are in a package freeze/bugfixing period as they prepare for their next stable release.
I know that 12.04 won't work, I started seeing .deb packages from individual developers stop working due to being complied with a newer version of glibc when it was released.
This is what makes running the Steam linux beta such a pain in the ass in Debian since you have to extract the glibc 2.15 from 12.04 into the Steam install directory to make it work.
I am not sure how stable that is though, I have not gotten around to trying it yet.

It looks like 11.10 should work, it looks like it is using glibc 2.13 (http://packages.ubuntu.com/oneiric/eglibc-source).

You might be able to build in Debian unstable/Sid if that does not work for you.
Most of the packages you would be interested in are about the same version as in a current Ubuntu release, glibc is just an annoying exception to that.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on December 22, 2012, 11:44:45 am

Quote from: arclance on December 21, 2012, 04:25:23 pm

It looks like 11.10 should work, it looks like it is using glibc 2.13 (http://packages.ubuntu.com/oneiric/eglibc-source).

You might be able to build in Debian unstable/Sid if that does not work for you.
Most of the packages you would be interested in are about the same version as in a current Ubuntu release, glibc is just an annoying exception to that.

Well, apart from glew 1.6 not knowing about one obscure extension, it builds on 11.10 fine. I fixed up cmakelists some, it should work fine as long as you start from installing SDL2 into a prefix and keep setting CMAKE_INSTALL_PREFIX to that prefix (the code depends on SDL2 and SDL_pnglite which is on my github). I'll do a build-deps script like the one in fgtestbed later.

Now I'm trying to build a win32 version with mingw-w64. That's where the hairiness starts.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on December 23, 2012, 06:33:15 am

(http://tnypic.net/images/rg7nu_thumb.png) (http://tnypic.net/rg7nu.png.html)

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on December 23, 2012, 10:13:41 am

I fixed all the breakage that resulted from making it work on win32.

A problem remains: GLEW refuses to build properly using mingw-w64 and they don't distribute import libs for mingw, so I just can't test anything interesting under wine.

Fixed that too. It works.

http://dffd.wimbli.com/file.php?id=7250

get the shaders from github, .png from any df

now all I need is a vast underground cistern of beer

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on December 26, 2012, 04:11:56 pm

Anyone got a win32 compiler other that mingw32msvc or i686-w64-mingw32? Preferably something from MSVC series.

The time has come to test if the modularization works across different C/C++ runtimes.

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on December 26, 2012, 04:15:24 pm

I could try building in my 32bit Vista VM but I have never built anything on Windows before so I may not be able to figure it out.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on December 26, 2012, 04:53:49 pm

Thank you.

I'm alas in uncharted territory here, so it's only guesses:

It should be possible to *persuade* the cmake (http://www.cmake.org/cmake/resources/software.html) to make a msvc project out of rendumper/modules directory (this works on linux as in not trying to touch anything above) that includes only test-whatever binaries. It should require only glue.cpp and contents of include directory (iwhatever* + glue.h).

As a fallback I guess you can handcraft a project out of glue.cpp, tests/life.cpp and includes/*.

The resulting binary would be most helpful.

edit:

unchecking all of PLATFORM_* RENDERER_* SOUND_* should force the cmake to build generate project for only glue and tests

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on December 26, 2012, 05:45:21 pm

Okay I will see if I can get that to work.
I am going to make a backup of my Windows VM first though since I really don't want to install that again, the updates take forever.
I don't think I can handcraft a project, I don't know much about C or C++.
I program enough in other languages I can see if someone has a typo in a variable name or forgot a "}" but I have never played with setting up the compiling side of it.
Edit: Downloading MSVC 2010 (the one used to build dfhack) now, this could take a while.

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on December 26, 2012, 06:26:56 pm

I am getting "Permission denied (publickey)" when I run "git submodule update" and it tries to get "df-structures" in Windows.

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on December 26, 2012, 08:30:25 pm

Okay it starts building if I remove "-Wextra -Werror" from the CMakeLists.txt file but fails at

Code: [Select]

2>..\modules\glue.cpp(42): fatal error C1083: Cannot open include file: 'dlfcn.h': No such file or directory
when I try to build glue.cpp.
Looking at the code it seems your check for Windows compilers is not working.

Title: Re: [PRINT_MODE:SHADER]
Post by: TheCoolSideofthePIllow on December 26, 2012, 08:37:27 pm

Why does an ASCII game need a shader mod? lol

Title: Re: [PRINT_MODE:SHADER]
Post by: Rose on December 26, 2012, 08:49:32 pm

All games need a shader mod

Title: Re: [PRINT_MODE:SHADER]
Post by: Bloax on December 26, 2012, 08:55:39 pm

From what the purpose was, then this is for dumping the graphics over to the GPU, freeing up CPU power for the game stuff - not just for effects.

Unlike the usual "shader mod" stuff, which is  just effects.

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on December 26, 2012, 09:25:04 pm

Quote from: arclance on December 26, 2012, 08:30:25 pm

Okay it starts building if I remove "-Wextra -Werror" from the CMakeLists.txt file but fails at

Code: [Select]

2>..\modules\glue.cpp(42): fatal error C1083: Cannot open include file: 'dlfcn.h': No such file or directory
when I try to build glue.cpp.
Looking at the code it seems your check for Windows compilers is not working.

Changing

Code: [Select]

#if defined(__WIN32__) || defined(__CYGWIN__)
to

Code: [Select]

#if defined(_WIN32) || defined(__CYGWIN__)
gets it farther but it fails as an unsucessful build.
I don't know why this time.

Build log for glue on pastebin. (http://pastebin.com/WgBxJTdZ)

test-life

Code: [Select]

Build started 12/26/2012 9:18:08 PM.
     1>Project "C:\Users\arclance\Documents\Print_Mode_Shader\rendumper_2012-12-26_2\build\test-life.vcxproj" on node 3 (build target(s)).
     1>InitializeBuildStatus:
         Touching "test-life.dir\Debug\test-life.unsuccessfulbuild".
       CustomBuild:
         Building Custom Rule C:/Users/arclance/Documents/Print_Mode_Shader/rendumper_2012-12-26_2/modules/CMakeLists.txt
         CMake does not need to re-run because C:\Users\arclance\Documents\Print_Mode_Shader\rendumper_2012-12-26_2\build\CMakeFiles\generate.stamp is up-to-date.
       ClCompile:
         C:\Program Files\Microsoft Visual Studio 10.0\VC\bin\CL.exe /c /I"C:/Users/arclance/Documents/Print_Mode_Shader/rendumper_2012-12-26_2/modules/include" /I"C:/Users/arclance/Documents/Print_Mode_Shader/rendumper_2012-12-26_2/modules/common" /nologo /Wall /WX- /O2 /Oy- /D "DF_MODULES_PATH=\"C:/Program Files/dfmodules/lib/dfmodules\"" /D "CMAKE_INTDIR=\"Debug\"" /D _MBCS /Gm- /MD /GS /fp:precise /Zc:wchar_t /Zc:forScope /Fo"test-life.dir\Debug\\" /Fd"C:/Users/arclance/Documents/Print_Mode_Shader/rendumper_2012-12-26_2/build/Debug/test-life.pdb" /Gd /TP /analyze- /errorReport:prompt ..\modules\tests\life.cpp  -std=c++0x -fvisibility-inlines-hidden -fvisibility=hidden -ggdb3
     1>cl : Command line warning D9002: ignoring unknown option '-std=c++0x'
     1>cl : Command line warning D9002: ignoring unknown option '-fvisibility-inlines-hidden'
     1>cl : Command line warning D9002: ignoring unknown option '-fvisibility=hidden'
     1>cl : Command line warning D9002: ignoring unknown option '-ggdb3'
         life.cpp
     1>C:\Program Files\Microsoft Visual Studio 10.0\VC\include\stdint.h(105): warning C4668: '_INTPTR' is not defined as a preprocessor macro, replacing with '0' for '#if/#elif'
     1>C:\Program Files\Microsoft Visual Studio 10.0\VC\include\cstdint(36): warning C4668: '_HAS_TR1_DECLARATIONS' is not defined as a preprocessor macro, replacing with '0' for '#if/#elif'
     1>c:\users\arclance\documents\print_mode_shader\rendumper_2012-12-26_2\modules\include\itypes.h(72): warning C4480: nonstandard extension used: specifying underlying type for enum 'DFKeySym'
     1>c:\users\arclance\documents\print_mode_shader\rendumper_2012-12-26_2\modules\include\itypes.h(321): warning C4480: nonstandard extension used: specifying underlying type for enum 'df_input_event_t::ev_type'
     1>c:\users\arclance\documents\print_mode_shader\rendumper_2012-12-26_2\modules\include\itypes.h(322): warning C4480: nonstandard extension used: specifying underlying type for enum 'df_input_event_t::but_num'
     1>c:\users\arclance\documents\print_mode_shader\rendumper_2012-12-26_2\modules\include\itypes.h(328): warning C4820: 'df_input_event_t' : '3' bytes padding added after data member 'df_input_event_t::reports_release'
     1>C:/Users/arclance/Documents/Print_Mode_Shader/rendumper_2012-12-26_2/modules/include\iplatform.h(70): warning C4820: '<unnamed-tag>' : '2' bytes padding added after data member '<unnamed-tag>::wParam'
     1>C:/Users/arclance/Documents/Print_Mode_Shader/rendumper_2012-12-26_2/modules/include\iplatform.h(77): warning C4668: 'and' is not defined as a preprocessor macro, replacing with '0' for '#if/#elif'
     1>C:/Users/arclance/Documents/Print_Mode_Shader/rendumper_2012-12-26_2/modules/include\iplatform.h(77): warning C4067: unexpected tokens following preprocessor directive - expected a newline
     1>C:/Users/arclance/Documents/Print_Mode_Shader/rendumper_2012-12-26_2/modules/include\iplatform.h(77): warning C4067: unexpected tokens following preprocessor directive - expected a newline
     1>..\modules\tests\life.cpp(55): error C2470: 'blse' : looks like a function definition, but there is no parameter list; skipping apparent body
     1>..\modules\tests\life.cpp(63): error C2470: 'twentyfive' : looks like a function definition, but there is no parameter list; skipping apparent body
     1>..\modules\tests\life.cpp(70): warning C4510: 'lfidxntry' : default constructor could not be generated
                 ..\modules\tests\life.cpp(70) : see declaration of 'lfidxntry'
     1>..\modules\tests\life.cpp(70): warning C4512: 'lfidxntry' : assignment operator could not be generated
                 ..\modules\tests\life.cpp(70) : see declaration of 'lfidxntry'
     1>..\modules\tests\life.cpp(70): warning C4610: struct 'lfidxntry' can never be instantiated - user defined constructor required
     1>..\modules\tests\life.cpp(74): error C2065: 'blse' : undeclared identifier
     1>..\modules\tests\life.cpp(75): error C2065: 'twentyfive' : undeclared identifier
     1>..\modules\tests\life.cpp(196): warning C4820: 'gofsim_t' : '3' bytes padding added after data member 'gofsim_t::tor'
     1>..\modules\tests\life.cpp(203): warning C4365: 'argument' : conversion from 'int' to 'size_t', signed/unsigned mismatch
     1>..\modules\tests\life.cpp(204): warning C4365: 'argument' : conversion from 'int' to 'size_t', signed/unsigned mismatch
     1>..\modules\tests\life.cpp(352): error C2146: syntax error : missing ')' before identifier 'and'
     1>..\modules\tests\life.cpp(352): error C2065: 'and' : undeclared identifier
     1>..\modules\tests\life.cpp(352): error C2143: syntax error : missing ';' before '!'
     1>..\modules\tests\life.cpp(352): error C2146: syntax error : missing ';' before identifier 'and'
     1>..\modules\tests\life.cpp(352): warning C4552: '!' : operator has no effect; expected operator with side-effect
     1>..\modules\tests\life.cpp(352): error C2065: 'and' : undeclared identifier
     1>..\modules\tests\life.cpp(352): error C2146: syntax error : missing ';' before identifier 'event'
     1>..\modules\tests\life.cpp(352): error C2059: syntax error : ')'
     1>..\modules\tests\life.cpp(352): error C2143: syntax error : missing ';' before '{'
     1>..\modules\tests\life.cpp(352): warning C4553: '==' : operator has no effect; did you intend '='?
     1>..\modules\tests\life.cpp(367): error C2065: 'not' : undeclared identifier
     1>..\modules\tests\life.cpp(367): error C2146: syntax error : missing ';' before identifier 'paused'
     1>..\modules\tests\life.cpp(368): error C2181: illegal else without matching if
     1>..\modules\tests\life.cpp(405): warning C4365: '=' : conversion from 'int' to 'uint32_t', signed/unsigned mismatch
     1>..\modules\tests\life.cpp(408): warning C4365: '=' : conversion from 'int' to 'uint32_t', signed/unsigned mismatch
     1>..\modules\tests\life.cpp(416): warning C4365: '=' : conversion from 'int' to 'uint32_t', signed/unsigned mismatch
     1>..\modules\tests\life.cpp(431): warning C4365: 'argument' : conversion from 'uint32_t' to 'int', signed/unsigned mismatch
     1>..\modules\tests\life.cpp(431): warning C4365: 'argument' : conversion from 'uint32_t' to 'int', signed/unsigned mismatch
     1>..\modules\tests\life.cpp(434): warning C4242: '=' : conversion from 'int' to 'unsigned char', possible loss of data
     1>..\modules\tests\life.cpp(434): warning C4365: '=' : conversion from 'int' to 'unsigned char', signed/unsigned mismatch
     1>Done Building Project "C:\Users\arclance\Documents\Print_Mode_Shader\rendumper_2012-12-26_2\build\test-life.vcxproj" (build target(s)) -- FAILED.

Build FAILED.

Time Elapsed 00:00:00.21


Title: Re: [PRINT_MODE:SHADER]
Post by: smirk on December 26, 2012, 09:31:46 pm

Quote from: TheCoolSideofthePIllow on December 26, 2012, 08:37:27 pm

Why does an ASCII game need a shader mod? lol

From what little I understand, this mod should eventually allow such things as layering ground tiles visibly under creatures, and supporting different sizes of tiles (possibly at the same time?).
Kudos to lxnt and arclance; still eagerly following this even if I barely understand any of it =D

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on December 27, 2012, 09:53:29 am

Quote from: arclance on December 26, 2012, 09:25:04 pm

... valiant efforts ...

Many thanks for this.

I redid the build system and moved code around a bit so that tests now do get built by VS Express 2010.

Haven't tested them yet, though. Building modules themselves will surely turn out a nightmare since C++-0x support in VC-2010 is, ahem, barely visible. I'll put out crosscompiled binaries for win32 today if all happens to just work.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on December 27, 2012, 12:28:06 pm

Of course is doesn't work  >:(

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on December 27, 2012, 01:02:03 pm

Running MSVC-compiled test-alert.exe with Mingw-compiled .dlls has become successful. The VM doesn't have enough GL to test the renderer.

Had to use latest mingw-w64 though, there was some abi mismatch present before gcc 4.7 at least.

http://dffd.wimbli.com/file.php?id=7250

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on December 28, 2012, 09:21:03 am

test-life.exe works in wine though.

this proves that cross-platform modular rendering backend is possible.

hooray.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on December 28, 2012, 05:33:34 pm

A stub (https://github.com/lxnt/rendumper/blob/interfaces/g_src/dwarf_fortress.cpp) has been made to simulate building real Dwarf Fortress with the modular backend.

It works as in compiling ok on every compiler I have - linux gcc, mingw gcc, msvc. Can't persuade msvc to link with zlib atm, but it's a settings problem, and compession should be moved to the platform .so anyway.

Title: Re: [PRINT_MODE:SHADER]
Post by: Meph on December 28, 2012, 05:38:18 pm

I will follow this as well. Even if I feel a bit like smirk, and cant follow the discussion. For being a graphics centered addition, you might want to consider a screenshot (with/without) at the first post. Once there is a major difference to see...

Title: Re: [PRINT_MODE:SHADER]
Post by: King Mir on December 29, 2012, 11:49:15 pm

Quote from: lxnt on December 26, 2012, 04:11:56 pm

Anyone got a win32 compiler other that mingw32msvc or i686-w64-mingw32? Preferably something from MSVC series.

The time has come to test if the modularization works across different C/C++ runtimes.

I can get Microsoft Visual Studio 2012, and try this out.

It has better C++11 support btw.

Title: Re: [PRINT_MODE:SHADER]
Post by: Rose on December 29, 2012, 11:59:01 pm

If you want to stick this into DFhack (which can be done, actually) the only MSVC you need is 2010.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on December 30, 2012, 03:11:04 pm

Quote from: King Mir on December 29, 2012, 11:49:15 pm

I can get Microsoft Visual Studio 2012, and try this out.

It has better C++11 support btw.

Thank you.

I made it to compile and run with VS 2010 Express since. Any extra testing is always very welcome of course.

Quote from: Japa on December 29, 2012, 11:59:01 pm

If you want to stick this into DFhack (which can be done, actually) the only MSVC you need is 2010.

Well, I'd like to stick DFhack into this, not the other way around. To this end, I'd like suggestions on the API to do that, assuming DFhack be loaded as a module on startup.

The shim would have to have a dependencies function, depending on the platform and simuloop interfaces, and some means to become activated, pause simuloop to mess with the internals, etc?

I guess UI can be handled in a separate thread and a separate window or something.

Would very much appreciate suggestions on this.

Title: Re: [PRINT_MODE:SHADER]
Post by: Rose on December 30, 2012, 09:08:53 pm

Dfhack has the abillity to replace the renderer used by DF, which is exactly what you need. Not to mention giving full access to the internals of the game

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on January 01, 2013, 05:23:50 pm

Quote from: Japa on December 30, 2012, 09:08:53 pm

Dfhack has the abillity to replace the renderer used by DF, which is exactly what you need. Not to mention giving full access to the internals of the game

No, Japa, DFhack just won't cut it. The combined metahack level will make it all crash and burn.

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on January 10, 2013, 05:01:34 pm

Quote from: lxnt on December 30, 2012, 03:11:04 pm

Quote from: King Mir on December 29, 2012, 11:49:15 pm

I can get Microsoft Visual Studio 2012, and try this out.

It has better C++11 support btw.

Thank you.

I made it to compile and run with VS 2010 Express since. Any extra testing is always very welcome of course.

This is why you use VS 2010 and not something else for things like this and dfhack.

Quote from: Quietust on January 10, 2013, 04:08:51 pm

Note that if you're going to write a plugin, you must compile it with VS2010 - VS2012 will not work because it'll use the wrong C runtime (msvcr110 instead of msvcr100) and thus use the wrong heap (for malloc/free and operator new/delete).

It might appear to work for simple tasks such as "reveal", but if the plugin tried to allocate memory and DF then tried to free it (e.g. with the "trigger siege" sample I just posted earlier), it would cause the game to crash.

I did not know the actual reason before.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on January 14, 2013, 05:13:30 pm

Bummer.

Got seriously fed up with C++ doing the TTF font rendering (twin threadsafe LRU caches) (and not to mention the tabulation hack, brrr). Did it in plain C, ditched SDL_ttf in favor of HarfBuzz+Freetype, but too exhausted to integrate it yet. Will first test it all in fgtesbed. No idea how to get it go faster than craaawl in (not yet implemented) full-software SDL mode _and_ not spray hacks all over the code either.

This full-feature-parity-with-the-g_src-but-modular-maintanable-and-extensible goal is quite an undertaking after all. Not to mention nothing's yet done on the sound side.

--

./lxnt

Title: Re: [PRINT_MODE:SHADER]
Post by: Thundercraft on February 10, 2013, 01:43:21 pm

Question: If you do manage to "stick DFhack into this" would that, in theory, allow one to get a version of this to run on Windows?

Also, I'm having a hard time finding screenshots of this thing. Most of the image links in this thread are either broken or lead to DFFD files that have since been removed.

If you've gotten the combined 32x32 or 20x20 world view and 12x12 interface to work, I'd love to see it.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on March 04, 2013, 03:23:50 pm

Well, ok. Status update.

The goal of the entire project at this point was and is an source-level unified cross-plaform renderer. Apart from TTF font rendering it had been reached.

This means that in the perfect universe, where the work would have been merged into the DF, there would be no artificial barriers for writing multiple renderers across the platforms, be they Linux, OSX or Windows.

This in turn means that whatever rendering bug fixes and features were to come up, they would be a recompile away from being accessible not only to Linux users, but to all. Also this would simplify DFHack (and anything else) integration.

As for the lack of screenshots - it's because the project's first and foremost goal is to produce exact same result as the stock GL renderer, and since that goal was attained about a year ago, there isn't anything new to display. Now, the separate fgtestbed project while not playable, had something above and beyond, but mainly in flexible redefinition and animation of stock tilesets, so again nothing that can really be shown in static.

EDIT: stupid rant removed.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on June 20, 2013, 03:07:12 pm

TTF over OpenGL:

(http://img.ie/images/gpzol_thumb.jpg) (http://img.ie/gpzol.png.html)

Title: Re: [PRINT_MODE:SHADER]
Post by: Vince on June 20, 2013, 03:08:14 pm

Oh, that looks nice.

Title: Re: [PRINT_MODE:SHADER]
Post by: insanemal on June 20, 2013, 11:47:21 pm

It seems this has gone missing from DFFD... Or is it available some otherway and I missed the post?

EDIT: Also did anybody contact Toady about this. I saw a comment by him recently (possibly the June report) about not being able to implement something because he did not know how the graphics system worked. Could be that all this awesome work might be something he would like to pick up?

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on June 21, 2013, 04:23:31 am

Quote from: insanemal on June 20, 2013, 11:47:21 pm

It seems this has gone missing from DFFD... Or is it available some otherway and I missed the post?

It's so heavily bug-ridden there wasn't much sense uploading the binaries.
But I put today's build here: http://sourceforge.net/projects/tolisnitem/ (http://sourceforge.net/projects/tolisnitem/)

To run, being in a copy of  Dwarf Fortress directory where you un7zipped the archive, type:

Code: [Select]

./libs/Dwarf_Fortress

for the ttf + opengl3,

./libs/Dwarf_Fortress sdl2gl2

for opengl2 version, or

./libs/Dwarf_Fortress ncurses

for the pure text version.

It will most likely crash on you. Shouldn't corrupt your saves, though.

If it refuses to launch, remove libs/libgcc_s.so.1 and libs/libstdc++.so.6 files.

If it doesn't look like TTF is working, make sure the size in  [TRUETYPE:size]  token in the init.txt equals your tileset vertical size.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on June 21, 2013, 08:28:10 am

Quote from: insanemal on June 20, 2013, 11:47:21 pm

EDIT: Also did anybody contact Toady about this. I saw a comment by him recently (possibly the June report) about not being able to implement something because he did not know how the graphics system worked. Could be that all this awesome work might be something he would like to pick up?

I think you refer to this:

Quote from: Toady One on May 31, 2013, 02:35:27 am

Quote from: arkhometha

Toady, how hard do you think it is to implement the fourth thing the in eternal suggestion voting (Full graphics support) and how high is it in your priority list?

Quote from: CLA

Will we be able to use graphic sheets for plants like we can with creatures at some point?

As far as I know, implementing things like item or map tiles won't work without multiple texture atlases, or something, and I don't know how to do that in the new graphics code.

The most straightforward way would be for the game code to draw the map using internal tile types, plus supply some kind of material color, or code, and maybe have a default translation table from tile types to font/tileset characters somewhere in the raws,
or give it somehow to the graphics code. Then leave actual translation to the renderer plugin, which will be free to load additional graphics and whatnot.

Currently it does that conversion from tile types to characters internally, which results in the limits that can only be overcome with dfhack methods, and that would be slow and cumbersome.

In fact, there's a prototype of just such renderer I wrote before starting work on this modular stuff. Link's in the signature.

The hardest part I think would be persuading Toady that he doesn't need to do everything himself, and that he won't lose any control that way.

The whole idea with pluggable renderers is to separate game from graphics, so that Toady can be sure that no matter what he changes in the game, he won't need to touch graphics side, and existing graphics code will continue to work, and on the other hand, that graphics code can be updated without any need for Toady's attention, much less for recompiles or, Armok forbid, any modifications to the game code.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on June 21, 2013, 08:31:25 am

~

Title: Re: [PRINT_MODE:SHADER]
Post by: Taffer on June 21, 2013, 10:12:17 am

Quote from: lxnt on June 21, 2013, 08:28:10 am

Quote from: insanemal on June 20, 2013, 11:47:21 pm

EDIT: Also did anybody contact Toady about this. I saw a comment by him recently (possibly the June report) about not being able to implement something because he did not know how the graphics system worked. Could be that all this awesome work might be something he would like to pick up?

I think you refer to this:

...[snip]

The most straightforward way would be for the game code to draw the map using internal tile types, plus supply some kind of material color, or code, and maybe have a default translation table from tile types to font/tileset characters somewhere in the raws,
or give it somehow to the graphics code. Then leave actual translation to the renderer plugin, which will be free to load additional graphics and whatnot.

Currently it does that conversion from tile types to characters internally, which results in the limits that can only be overcome with dfhack methods, and that would be slow and cumbersome.

In fact, there's a prototype of just such renderer I wrote before starting work on this modular stuff. Link's in the signature.

The hardest part I think would be persuading Toady that he doesn't need to do everything himself, and that he won't lose any control that way.

The whole idea with pluggable renderers is to separate game from graphics, so that Toady can be sure that no matter what he changes in the game, he won't need to touch graphics side, and existing graphics code will continue to work, and on the other hand, that graphics code can be updated without any need for Toady's attention, much less for recompiles or, Armok forbid, any modifications to the game code.

He may be open to having somebody else work on the graphics code. It's worth sending him an e-mail, if you haven't already. If memory serves he's expressed confusion over the graphics code several times now, and if the status quo is to wait for Baughn to reappear, then perhaps he'd be similarly open to having yourself look at things, given that you've already demonstrated the desire and ability to do so.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on June 21, 2013, 10:38:49 am

Quote from: Taffer on June 21, 2013, 10:12:17 am

He may be open to having somebody else work on the graphics code. It's worth sending him an e-mail, if you haven't already. If memory serves he's expressed confusion over the graphics code several times now, and if the status quo is to wait for Baughn to reappear, then perhaps he'd be similarly open to having yourself look at things, given that you've already demonstrated the desire and ability to do so.

Well, the existing graphics code shows its age, so to say, and it wasn't exactly pretty to begin with.

I think best time for any discussion of doing something about graphics would be after this year's release is out and most egregious
 bugs are fixed in the point releases. Say, somewhere about the next Future of the Fortress question submission time after the release goes out.

Until that time, I'll be engraving polishing.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on June 26, 2013, 12:07:38 pm

I apologize for a bug in the packaging script which rendered previously uploaded archives unusable.

It has been fixed, and the latest upload (http://sourceforge.net/projects/tolisnitem/files/nitem-20130626-16.7z/download) is verified to work.

It has TTF support on par with original  - ttf tab hack and pixel-perfect alignment, and more-or-less working sound support.

The README (https://github.com/lxnt/rendumper#this-is-df-modular-backend) file has also been expanded.

Title: Re: [PRINT_MODE:SHADER]
Post by: Maklak on August 13, 2013, 11:34:02 am

I just dropped by to see how this is going, since SDL2 came out.

TODO list: Wow, looks complicated.
> show fps+averaged times on an overlay. maybe do a graph ala eve online
Well, it would be somewhat useful to have a "DwarfMark" - a Dwarf Fortress save that has 200+ Dwarves, lots of items and some liquid flows, then unpause it on different computers, look at average uncapped FPS over a minute and have a benchmark for which one seems to be the fastest.

BTW, this thread should be moved to Modding/Tilesets and Graphics. It may get more visibility that way.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on August 18, 2013, 10:35:11 am

Quote from: Maklak on August 13, 2013, 11:34:02 am

I just dropped by to see how this is going, since SDL2 came out.

It did, but there isn't much sense in reacting to that until SDL2 gets into major distributives. And that may take some SDL2 point releases to happen.

Quote from: Maklak on August 13, 2013, 11:34:02 am

TODO list: Wow, looks complicated.
> show fps+averaged times on an overlay. maybe do a graph ala eve online
Well, it would be somewhat useful to have a "DwarfMark" - a Dwarf Fortress save that has 200+ Dwarves, lots of items and some liquid flows, then unpause it on different computers, look at average uncapped FPS over a minute and have a benchmark for which one seems to be the fastest.

200 dwarves, say 50K items ... it'll just drown any signal from the renderer change in the noise. At those numbers the renderer just doesn't matter. Any fort above 100 dwarves is going to suffer, period. Maybe if Toady implements emigration out of the fort, that would help keeping the population down to something sensible. Barring that, we're stuck - mastery of the dwarf management is just another way to lose, and not particularly fun at that.

As I said somewhere above, slow rendering can't really kill the FPS, it just makes the inevitable quicker. Thus the focus on cross-platformness and modding/distributed development here lately.

Besides, I did a test on how fast one can kill FPS. Draining an aquifer into a cavern does that quite reliably, no need for hundreds of dwarves, just a suitable map. Watch the water cover 2-3 embark places of cavern and the game wents below 1 fps, then just crashes.

Bad thing is, optimizing liquid model would require quite a change in the map internal representation, and this is just not going to happen.

Quote from: Maklak on August 13, 2013, 11:34:02 am

BTW, this thread should be moved to Modding/Tilesets and Graphics. It may get more visibility that way.

It might, but that isn't up to me.

PS.

For some reason my attempt to carve a mountain hall barely worthy of its name - out of a cavern section - measly 55x110x5 tiles - is also being met with random crashes. Although this might be due to bugs in the dwarf therapist.

Title: Re: [PRINT_MODE:SHADER]
Post by: Maklak on August 18, 2013, 12:17:47 pm

Ah, maybe I wasn't clear. I know that renderer has little influence on FPS and that certain things can kill FPS. I just saw "fps+averaged times" in your TODO notes and it resonated with something I'd find useful. Play till an old fort runs out of FPS, then run it on a new computer and it's playable again, except there is no hard data on it, just an approximation from looking at fluctuating FPS. I didn't want to compare renderers or find ways to kill FPS, I wanted to compare which computer handles my forts better and by how much exactly.

Good luck with your project. Especially if you manage to take Baghun's place.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on August 18, 2013, 04:21:44 pm

Quote from: Maklak on August 18, 2013, 12:17:47 pm

I just saw "fps+averaged times" in your TODO notes and it resonated with something I'd find useful. Play till an old fort runs out of FPS, then run it on a new computer and it's playable again, except there is no hard data on it, just an approximation from looking at fluctuating FPS. I didn't want to compare renderers or find ways to kill FPS, I wanted to compare which computer handles my forts better and by how much exactly.

This compares nicely in my code, since the primary metric it uses is time-to-render (or simulate) a frame and time-elapsed-between-renders/simulations.

Guess I'll do the graphs after all, if only to enable such comparisons. FPS numbers, however averaged, just don't show enough information.

Quote from: Maklak on August 18, 2013, 12:17:47 pm

Good luck with your project. Especially if you manage to take Baghun's place.

With Toady insisting on understanding all of the code there isn't much chance of this part getting anywhere. Human mind is only so vast, especially when there are much more interesting things to write.

It took me a couple of months to just understand how to make cross-platform plugin loader, make MSVC-compiled executable to load GCC-compiled plugins, and then make the contraption to not crash. I wouldn't wish anyone to go down this path.

Title: Re: [PRINT_MODE:SHADER]
Post by: arclance on August 19, 2013, 12:14:49 pm

Quote from: lxnt on August 18, 2013, 10:35:11 am

Quote from: Maklak on August 13, 2013, 11:34:02 am

I just dropped by to see how this is going, since SDL2 came out.

It did, but there isn't much sense in reacting to that until SDL2 gets into major distributives. And that may take some SDL2 point releases to happen.

SDL2 is in Debian Testing & Unstable. (http://packages.debian.org/sid/libsdl2-2.0-0)
I would use the unstable package though it is more up to date.

Title: Re: [PRINT_MODE:SHADER]
Post by: lxnt on November 04, 2014, 10:31:11 pm

Here's a build for 40.14. Obviously linux only.

https://sourceforge.net/projects/tolisnitem/files/nitem-20141105-03.7z/download (https://sourceforge.net/projects/tolisnitem/files/nitem-20141105-03.7z/download)

(extract into libs, make sure to delete/rename libstdc++.so.6 and libgcc_s.so.1)


Changes:

Fixed world map export crash.

Forced all text to be rendered with TTF. This includes the thought screen (ex. http://img.ie/drh6l.png (http://img.ie/drh6l.png) ) and probably much more.

To enable TTF rendering, make sure the xx in  [TRUETYPE:xx] in data/init/init.txt matches exactly your tileset height.

To disable aforementioned forcing, add [TRUETYPE_FORCED:NO] to data/init/init.txt.

Default renderer requires GL3.0. To try GL2.0 or ncurses renderers, pass corresponding parameters at df launch:

./df sdl2gl2
./df ncurses

The [PRINT_MODE:...] setting is currently ignored. TTF is only supported in GL3 renderer (integers in GLSL and all that).

And yes, the fps/gfps indicator is misplaced. Sorry about that.

Title: Re: [PRINT_MODE:SHADER]
Post by: Moonshine Fox on June 03, 2017, 01:24:02 pm

Sorry for the horrible necrobump, but did this project just die out?