Print

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

[ag]

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.

No it isn't. If you didn't realise how to extrapolate from the two white/black tiles, here is a version with tiles actually colored by only the fg and bg. The one with the black background does have a black background.

http://i.imgur.com/1jkZr.png

Then write nother script for dfhack to inject into the renderer_2d_base rendering method, with the same test data, and compare the results.

There is no other rendering method. The way rendering works is the game writes tiles into arrays in gps, then code in g_src takes them from there and feeds the selected renderer, which converts it into actual pictures on the screen. DFHack works exactly the same - it can even adjust tile info produced by native screens.

The script will likely run only on dfhack built from the latest source due to changes in the api:

https://github.com/angavrilov/dfhack/blob/master/scripts/devel/inspect-screen.lua

P.S. Really it is pointless to argue that something as fundamental as painting foreground + background is broken without very substantial evidence, or identifying a special boundary case. It would have been noticed long ago otherwise.

[rayanth]

I can see that we're at a bit of an impasse, seemingly due to my inability to properly express what I'm trying to say. It's alright, I'll let it lie. I have what I need for now anyway and belaboring the point won't accomplish anything.

If in my continued adventures I derive a method of actually explaining myself properly, then I'll give it another shot. Until then, I'll just let it go. The dance around the bush isn't accomplishing much but frustrating us both, I think.

- Rayanth

[ag]

OK, I actually downloaded that tileset and a random save using it from dffd, and I see that that tile is not for unmined ore at all. It is for stones, and they have black background:

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

If you really want to use the script, you can download a recent development dfhack build from here. The above script should work with it if you put it in hack/scripts/ somewhere.

http://www.qmtpro.com/~quietust/df/dfhack-0.34.11-r2-Windows.7z

[rayanth]

OK, I actually downloaded that tileset and a random save using it from dffd, and I see that that tile is not for unmined ore at all. It is for stones, and they have black background:

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

If you really want to use the script, you can download a recent development dfhack build from here. The above script should work with it if you put it in hack/scripts/ somewhere.

http://www.qmtpro.com/~quietust/df/dfhack-0.34.11-r2-Windows.7z

Well, I was prepared to drop the subject... but... uh....

well, damn.

My hat's off to you, sir. I feel like a complete putz now 

Everything I was doing was based on the assumption that 'black' came from the fact that the semi-transparent image was copied to a surface that had been initialized as black, thus it took on the black trait and then became 100% opaque. That assumption was false, and you've just shown me that. (I was using the colors from the raws for the material as shown by the wiki, evidently that was misleading.)

So... now I'll look into updating my photoshop routine for this. It should be a very simple fix.

A lot of the confusion, I think, in our discussion was my lack of proper terminology, and getting things slightly confused in my head. I was working sometimes from memory, as I can't have a computer at work, and coding on my phone in any large quantity is just... well, unreasonable.

So thanks for sticking with this and working it out with/for me. I was not trying to doubt you, just trying to argue different points of what I thought was the same side of the same argument. black. pfeh!

-- Rayanth