Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[lxnt]

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.

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.

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.

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.

[arclance]

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.

[lxnt]

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

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.

[lxnt]

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

[arclance]

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.

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

[lxnt]

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

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.

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.

[lxnt]

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?

[arclance]

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)

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)

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)

This page on the wiki about colors says

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)

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)

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)

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.

[lxnt]

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.

[lxnt]

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.

[Mike Mayday]

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?

[lxnt]

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.

[Mike Mayday]

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   (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?

[arclance]

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.

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

[Mike Mayday]

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.