It used to be that images just south or east of 'you' were drawn semi-transparently so as not to obscure the player. This was a good idea but in practice was a source of much confusion ('why is the beholder partly invisible?').

I think this may have been because it was done on all objects, eg, walls and mobs.

Also it was, with exceptions, unnecessary because we didn't have many 'tall' objects (nearly all walls were of the double variety where they are only drawn at half height in those positions anyway, so the problem is fixed without the need for transparency.

When we went to truecolour, this ability to transparentise graphics on the fly was lost. But this wasn't a problem, considering the last two paragraphs.

However, with some of the new hq graphics it is becoming a problem.

The most extreme example is some excellent tall trees TPK (the artist) and I (the coat-tail hanger-on) are working on (see this thread)

These look great:


Until you walk round behind them:


So perhaps an answer would be to extend the client's handling of .u/.d images to also handle .t (for transparent) images.

Simply, there would be two images for objects which needed transparentising. The first would be named image.101.png and would just be the normal fully opaque image. The second would be named image.t.101.png and would be the same image at, say, 40% opacity. The face in the arch would be this second image.

Thus we'd add a new flag to map.h, FACE_FLAG_TRANSPARENT. Then add a couple of line to client.c. This:
Becomes this:
Then in map.c after the code for FLAG_UP (which only draws those objects when they're north or west -- basically -- of the player) we add similar code for FLAG_TRANSPARENT (it draws the .t image or not .t image depending on the object's position relative to the player. So instead of the second image we get something like this when the player is behind a tree:


I'm not clear enough on the client code to implement this properly, but I think it would work:

A drawback is that it would need extra memory to store two copies of the graphics, but I think we're past worrying about a few k. Also, only specific images would be done.

???

sounds like a nice fix for this issue.  I'm in support.

I would support this as well. But, like the others posting, i don't know how to (help) implement it.

Unislash

If I sit down and study it I can modify the existing code I am sure.

The fundamental question is is this (static transparent images) the best solution in the long run? If transparent images can be software-generated on the fly, this is surely better as it is more flexible (for example, make them more opaque the further away your avatar is) and reduces the daimonin.p0 footprint. Clearly this is possible, but SDL apparently can't do it. If/when we use OpenGL perhaps there will be no problem.

It's pretty clear that Alderan should say something now...

OpenGL support would be awesome, but even the .t image idea is good... server could run one bash script using imagemagick on every image collection change and that would be it... Though problem might be with Win users, unless we support Cygwin...

ring of etheriality  could turn a player semitransparent (on the test server), but i believe it was done with a half tone mask.

Halftransparency would/should be done on the fly when needed with per-pixel calculations. Maybe its also possible to do it with an in-between blit, but for that i have to take a look in the sdl docs.

Having a seperate already halftrans image is also nice, means much less coding;-)

With the tilestretcher i have implemented, no i have put in (aka copy&paste) a really nice LRU-cache someone did on the angelion client (sry have forgetten the name). This could also easylie be adopted to also store the semitrans images.

With caching on-the-fly calculating isn't such an problem, all the grey/redscales are done in the same way.