Print

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

[CLA]

I am posting these at their actual size, which is 16x16. This is to prevent stretch-distortion from getting in the way.

Just resize them with Nearest Neighbor and only use multiples of 16 as the output size. No resizing artifacts that way.

[rayanth]

yeah i was half asleep at the time and wasn't thinking clearly. was more interested in finishing the post - I'll redo them later the same way I did the Copper one in the post that followed.

[rayanth]

As promised, I've updated the photos to much larger ones, in my older post with the hematite ore. ... much, much larger. sorry if that's overwhelming, but it's easier to see what I'm doing there =)

Working on adding spoiler tags to them, now.

- Rayanth

Edit: I would like to note that even though there IS alpha and BG color taken into account in the code formula, they have no effect if my tests are correct. This is why:
When the transparencies are merged with the black layer in the first step of my reproduction, ALL alpha becomes 100%. In the left half of the equation, this equates to a '1' in the alpha portion, and anything times 1 is itself, so it's rather pointless. On the RIGHT half of the equation, alpha is 1, minus 1 is 0, and the rest is being multiplied by this 0, including the background color - so the background is negated entirely, and thus rather pointless.

My tests are accurately reproducing what DF shows, for this tileset. I can't think of anything else the tileset may have changed, to cause the formula in the code to be negated. This leads me to believe the formula in the renderer code is, in fact, "bugged" - it's not doing what it should be. Further, it's a minor performance hit that these calculations are added in, that do nothing, three times per pixel!

[ag]

Backgrounds most definitely work, otherwise you won't be able to render text with a color background: http://i.imgur.com/hj5nI.png

Note that in that picture some characters like digits have faint rectangles around them; that's because they have a low-alpha, but not totally transparent background in the tileset. The green line highlight and the screen title on the other hand have a true non-black background color. The 'o' in 'coal' on the highlighted line especially shows the interaction between foreground and background.

[rayanth]

ok, so my sample set is too limited. I'll look for similar interactions in Mayday, and see if I can figure that part out.

What tileset is your screenshot from?

Edit: On second thought, it looks as if your screenshot is rendered at TTF Level... that's a whole different rendering system than the one I'm poking at. ALL text that's rendered by the 2d renderer, in my current game, has the same color background (different shade) as the foreground.But when I zoom to the level where it switches over to TTF, then I have colored text with black backgrounds...

Edited edit: But then that doesn't explain why your o's and n's are background colored. bluh. ok... I need your tileset =)

[MasterShizzle]

Well, I think I understand the principles then. I did some playing around with my own tileset, and I got a result that I like. Here's how I drew the walls and floors:

Spoiler (click to show/hide)

The tiles all have a dark gray background, which colors itself the same as the wall tiles (more or less) so it's not EYE-RAPING BRIGHT when engraving. The cut-off corners are all the same shade of gray as the rest of the floor, but with the alpha cranked down to 180. These get rendered as their color plus black when not engraved, and gray when they are engraved, similar to the squigglies in Phoebus or the dotted borders in Mayday.

Shot of my bedrooms, with smoothed floors and walls:

Spoiler (click to show/hide)

Shot of the dining hall, everything engraved:

Spoiler (click to show/hide)

[CLA]

tileset

The tileset appears to be Phoebus.

Why don't you construct a tileset for color blend testing? That is, tiles that don't necessarily make sense in Dwarf Fortress, but provide a controlled environment to test things in.
For example, there could be tiles with 10%, 20%, 30%, etc transparency. Some with 10%, 20%, etc grey. And so on. And I suggest using the default colors, since their values tend to simplify things and control predictions easier. There only are colors with 0, 255, or 128 as values.

[rayanth]

will admit I'm not familiar with sets other than mayday....can't even remember how i got introduced to mayday, but it's the only reason I still play DF =P

constructing my own set to test colors seems logical, in a fashion. I can still think of a reason why ag's example appears the way it does, so I'll peek closely at that tileset (and others) when I have time this weekend. Then I'll poke at coming up with some form of testing tileset to play with all the variables.

In other news, I just had a tantrum spiral of epic proportions, in a 10x10 embark 10 years old with 500 dorfs...there's only a select handful of survivors. Guess I get what I deserve, for "testing" my mist generator in the middle of the main dining hall....

[ag]

Edit: On second thought, it looks as if your screenshot is rendered at TTF Level... that's a whole different rendering system than the one I'm poking at.

In my opinion TTF rendering (or more precisely the way it interacts with the tile grid) as it currently exists is broken, looks ugly and needs major restructuring, so DFHack does not support doing anything with it. Therefore all of its screens use pure tileset-based rendering. The only TTF thing in the screenshot is the FPS indicator, and see how stupid it looks.

Also, it's not my screenshot, it's falconne's 

[rayanth]

In my opinion TTF rendering (or more precisely the way it interacts with the tile grid) as it currently exists is broken, looks ugly and needs major restructuring, so DFHack does not support doing anything with it. Therefore all of its screens use pure tileset-based rendering. The only TTF thing in the screenshot is the FPS indicator, and see how stupid it looks.

Also, it's not my screenshot, it's falconne's 

I have no real issues with TTF rendering - it seems to work reasonably well in my games, but I do play on insanely large screens, zoomed pretty far in just to see what's going on. (if I zoom way out, I can't even make out tiles, due to my resolution)

You are far more the expert at how dfhack handles rendering its own custom screens than I am, but poking at falconne's code for the screen you show me, as well as the Phoebus tileset, it appears to me that dfhack is using its own rendering subsystem... or perhaps falconne's system is. Tracing the drawing calls back it looks like they're going straight from the Screen:: class, which I recognize as a windows forms inherited class. OK, it's actually not the inherited class from windows forms (that confused me - dfhack is cross-platform) but defined within. Now I need to download the entire master branch and start checking crosslinks, because I do see some calls to the rendering system of DF itself, but I need to go back and find that entry point to verify it's the same point I was looking at.

This very easily explains how the highlighted green line with white text came to fly in the face of my findings - it's not drawn by DF!

Punching my same method through all of the various Phoebus tilesets reaches the same conclusions that I reached for the specific portion of the mayday tileset I tested earlier - with Phoebus, I just tested the whole tileset as one image. I tested all 6 versions of it, due to differences between them, and they all match my earlier findings, as well as the screenshot (with the exception of the highlighted line - by the way I did find the *specific* portion of Falconne's code that specifies that to be green highlight with white text, and it's linked to a call to Screen::PaintString)

.... as always, correct me if I'm wrong. I *will* get to the bottom of this!

- Rayanth

[ag]

DFHack doesn't render anything, it fills the same screen arrays df uses. I know for certain because I implemented those APIs.

I can think of one thing that may be going on: it's not a given that df actually uses the same background color for minerals as defined in the raws - it may be trying to do something clever. Using dfhack it is possible to actually inspect the screen tile arrays and find out which colors are used; it only requires writing a script to provide a nice ui.

[rayanth]

DFHack doesn't render anything, it fills the same screen arrays df uses. I know for certain because I implemented those APIs.

I rather thought that was the case, the closer I looked.

There are multiple rendering systems in DF, though, and I'm not discounting the possibility that more than one are active at the same time. The part that dfhack injects into is a part I was getting confused about and didn't pay much attention to once I found the renderer_2d_base class. I'll now go back and trace what, exactly, is going on with the calls from falconne's code, since it gives me something very specific to work with (and the screenshot as an example of the outcome)

[rayanth]

My initial suspicion seems to be correct. I've just spent quite a while tracing the rendering calls made by DFHack, as well as the rendering calls that I propose are used for materials. They are completely separate from each other. Unfortunately I don't have an example of when each one would be used by the game because i have no code that makes the calls toadd a tile using either system - that would be in the game's code that hasn't been released. Here are my findings:

The dfhack injections use direct writes to gps (which is an instance of the graphicst class). this class has its own drawing routines, which use direct mapping to the screen surface.

There is also the (by default) renderer_2d_base class which I was poking at, which is derived from the renderer class, and implements the render() functiona s well as many other things that are not implemented by the renderer class (they are implemented by various subtypes depending on the drawing mode set in the init's, which by default is 2D, hence why i was looking at renderer_2d_base).

The method dfhack uses seems to be lower level as it works regardless of which renderer is chosen - I suspect that method is ONLY used for text - if even that. Ultimately, however, both methods are putting tiles on the same surface, which is then blitted by the implemented renderer subclass.

What's this mean?

Well it means BOTH of us are right, in a way. My calculations appear to be commensurate with everything I've seen rendered, as far as nontext is concerned. I've yet to thoroughly poke at engravings as was brought up in this thread by someone else, but I think it's still in line with my findings.

That there is an alternate, equally valid method of rendering as revealed by dfhack is interesting. But I've never seen that actually come into play in an unmodded game. Examples would be welcome. (The example would have to show two different colors for 'foreground' and 'background' - where neither is black (due to the multiply step, anything multiplied by black is always black))

For my purposes, I will stick with my original findings under the renderer_2d_base class's drawing method. It accomplishes what I would see as the most-common use for the tileset, and is thus the best way to focus design of one.

Thanks to all for their input, and I'll keep monitoring this thread in case anyone wants to shine a different colored light on the subject =)
- Rayanth

[ag]

Take it from me, dfhack rendering works exactly the same as native non-ttf DF rendering (and ttf is different only when rendering the text).

Here's a screenshot from a simple script that reads a tile from the screen arrays, and shows its component fields. You can see the numeric values, and also the tile rendered white on black (to show the colors), black on white (to show transparency), and the exact fg and bg colors used for the original combination.

http://i.imgur.com/FFR4o.png

[rayanth]

Take it from me, dfhack rendering works exactly the same as native non-ttf DF rendering (and ttf is different only when rendering the text).

Here's a screenshot from a simple script that reads a tile from the screen arrays, and shows its component fields. You can see the numeric values, and also the tile rendered white on black (to show the colors), black on white (to show transparency), and the exact fg and bg colors used for the original combination.

http://i.imgur.com/FFR4o.png

You just have to go and make things all complicated for me, don't you? x.x

don't suppose you could PM me that script? or be willing to work in private with me some more on this?

- Rayanth

Edit:  actually it looks like you just proved me right.
yes, you are showing that the background color is set- but i'd already said as much. I was just saying that the background color doesn't affect the outcome, and this is the case in your latest example. the foreground color is solely responsible for the coloration of the entire square.

I think we're agreeing with each other without realizing it.

The best way to confirm my theory at this point is a combination of tests. Compare the values shown by the script you just showed, using the rendering method that dfhack injects into, with a specific test tile. Then write nother script for dfhack to inject into the renderer_2d_base rendering method, with the same test data, and compare the results. This is at the limits of my programming experience right now-- dfhack and df are such huge codebases i'm struggling to trace them as it is, but i could probably accomplish something in the next couple...months...=(