From: Andrew A. <aj...@ne...> - 2002-08-21 00:01:46
|
Hi all, J. Ali Harlow writes: > On 2002.08.14 13:44 Andrew Apted wrote: > > The main problem is that it's not very clear within the code that > > (71,108,108) is *the* transparent color. E.g. DEFAULT_BACKGROUND > > doesn't suggest transparency in any way. > > Well, the comment in tile.h does say "For transparancy", but I agree > the documentation could be clearer. I guess the best place would be > in tile.doc. tile.doc : Okidoke. A paragraph about transparency, mentioning DEFAULT_BACKGROUND, would be good. > > Another problem is that some tiles are using that color as valid > > parts of their images, especially the standard walls in the 32x32 > > set. I guess these tilesets need fixing to use a different (but > > close) color like (64, 100, 100). This has a potential problem of > > the two colors being mapped to the same pixel value (e.g. in RGB > > 5:5:5 space), but it's unlikely. > > Yes. Mitsuhiro Itakura used a system of sperate transparancy encoding > (which I avoided for the compatibility issues we've talked about). > It would certainly be better if the 32x32 tileset was changed so as > not to use (71,108,108) when an opaque colour is intended. Whether > it's best to use a close existing colour or add a new colour I'm not > sure. oth32fl.txt uses (72, 108, 108), but it doesn't survive merging. The other closest existing colors are: (64, 128, 128) (96, 128, 128) where the second one looks a bit closer. I reckon using (72,108,108) or a new color like (64,104,104) is the way to go. All the tile tools need to be updated to treat DEFAULT_BACKGROUND as transparent (tiletext.c in particular). Shall I tackle this ? > > You mentioned dithering -- hadn't thought of that, but yeah I see > > the problem. Anywhere where the images are loaded indirectly > > (like gdk_create_pixmap_from_xpm or whatever it is) these problems > > can pop up. I guess the only reliable solution is to always load > > tilesets as directly as possible. > > There are two slightly different problems. One is that if you load > the tileset with dithering, then you can mis-identify transparent > pixels. This is serious and the Gtk port takes care that this > does not happen. Right... > The other is that even if you have correctly > identified the transparent pixels, dithering further down the line > can pollute the transparent pixels with colours from the opaque > pixels (not a problem if you maintain the transparent information > seperately after loading, as the Gtk port does). The same dithering > can also pollute the opaque pixels with the default background > colour (this is a real error that the Gtk port suffers from). > Luckilly, the background colour is normally something sensible so > while this is wrong, the final outcome doesn't look too bad. Since the transparent information is separate, perhaps you can change the (71, 108, 108) pixels which sit next to a solid color to be the same as that solid color, so that any dithering that GTK does will not be polluted. > Sadly, it really isn't sensible to just turn off dithering since > the final output system may not have enough colours available > (and a closest match colour system will look much worse). Ideally > you want a dithering system which understands transparancy, but > Gtk, at least, doesn't seem to have such a system. Yeah. > > In the case of ports that don't support transparency (like X11), > > or ports that don't support transparency on certain tiles (like > > GTK with the furniture/traps ?), I think they should replace the > > transparent pixels themselves with a background tile ("floor of a > > room") when loading the tileset. Should be easy, right ? > > I've generally tried to keep things so that vanilla windowing > interfaces can be bolted onto Slash'EM and will work to an > acceptable level without alteration. Aha, the plot thickens :). I think that's an important policy decision that should be documented somewhere (tile.doc). That policy is fine by me BTW. > I'd be loath to change things so that windowing interfaces that > don't understand transparancy produce something that looks > really bad. In that case, I think we need to make *two* 32x32 tilesets, one with full transparency, and one where the transparent parts are filled in with a solid background (using txtbg). (The 16x16 tileset never has transparency, and the 3D tileset requires it). So it could be like: x11tiles : 16x16, solid x11bigtiles : 32x32, solid x11bigtrantiles : 32x32, transparent x11big3dtiles : 48x64, transparent What do you think ? > If you're playing with glyph layers, > I should warn you that print_glyph_layered is slated to be > replaced with print_glyph_layer as we discussed some time > ago. The idea is that clear_nhwindow() will be extended to > give the number of layers for a window (ie., this can alter > between levels of the dungeon) and that print_glyph_layer > will print one line of one layer. Sounds good (I've noticed the DISPLAY_LAYERS #define, but haven't really looked into yet). > > One last thing. Are the compiled XPM tilesets interchangeable > > with the normal XPM tilesets ? I didn't notice any code in the > > GTK port's tile_scan that checks for the compiled version. But > > they seem to share the same names ("x11bigtiles", etc). I'm > > thinking of using the compiled format for the SDL/GL port (rather > > than PNG, which glHack uses). > > Um, what's a compiled XPM tileset? Do you mean XPM format rather > than TIL format (the format that the .txt source files are written > it)? I mean the format defined in include/tile2x11.h : /* * Header for the x11 tile map. */ typedef struct { unsigned long version; unsigned long ncolors; unsigned long tile_width; unsigned long tile_height; unsigned long ntiles; unsigned long per_row; } x11_header; which tile2x11 generates when USE_XPM is undefined. "Compiled XPM" is probably a figment of my imagination :). Seeing that most window ports need USE_XPM enabled, and that the SDL/GL port should co-exist nicely with them, I'll stick with PNG and write a "txt2png" tool. (I don't want to use XPM since it adds an explicit dependency to X libraries and I want to avoid that). BTW, thanks for taking the time to discuss this. I know you're very busy lately. Cheers, __ \/ Andrew Apted <aj...@us...> |