Text and Graphic on same tile

[Gambit37]

Hey, it's cool that you implemented this! Although I might have to reconsider using it! The text can take up so much room, that a graphic of a stone plaque underneath would have to be the size of the entire wall.... I'll have to see what I can achieve with my creative juices!

Anyway, I noticed a small problem with this. There is a small area in the middle of the wall that is rendered incorrectly -- it appears to be transparent. I checked this with both my custom graphics file and the original csb graphics file and it's the same.

Here's a shot with the original csb graphics.dat. I have a 'dent' graphic underneath the text, you can just see it in the middle of the tile:

[Guest]

The text can take up so much room,

Sorry about that. I probably should have pointed that
fact out before offering to make the changes to CSBwin.

[Gambit37]

It's not a problem, I'll just stick to smaller lines of text!

[Paul Stevens]

Ok. The transparent spot is explained.

FTL very carefully removed that intersection
of two blocks when drawing text on the wall.
Probably because it made the text difficult to read
and perhaps because it looked funny seeing the
line disappear behind the text.

So, when they were about to draw the text, they
copied another section of wall to that spot. Of course
your graphic was there so it erased a bit of your
graphic.

In particular, the rectangle at x=0x6e to 0x71,
y = 0x25 to 0x3e is copied from the same size rectangle
at x=0x5e, y=0x1c. Notice in your example that the line
is missing. They did not worry about the lines in the
nex row of blocks down, however. Why?

So, if you get rid of the green in that source rectangle then
you will not see it behind your text. Or I could not perform that
little copy operation if there is a decoration covering all or
part of the destination rectangle. Or I could skip that little
copy operation altogether. I think any solution
will work for some particular cases and not for others. I
guess the second solution is the best. Certainly the most
difficult. The third solution is trivial. Since they did not worry
about the lines in the next row of blocks, why worry about it
in the first? The first solution is trivial for me.

The third solution is also the easiest to explain since it
leaves nothing to explain. It removes the special case
that currently exists.

Any ideas? Anyone?

[Gambit37]

Ah, I understand now.

The simplest solution for you is option 3 -- skip the copy operation altogether. That works fine for me -- after all, if there is a decoration under the text, I think it's safe to assume it's been put there so that the text will look good sitting over it.

[Paul Stevens]

I think it's safe to assume it's been put there so that the text will look good sitting over it.

Right. But not all decorations are at that level. Some are
near the floor. And the reason they did it was not because
of the decorations there but for the case when there is
no decoration there and the text is on the wall. Then the
text would be drawn on the space between two blocks.
As it is on the next row.

So they had not really anticipated your problem. Solution
three would skip the deletion of that vertical line whether or
not a decoration was there. That is the question....should
we do this? It is easy to do, easy to explain (nothing to explain),
but some folks may think it is too much sacrifice so that you
can have your plaque.

Actually, doing nothing is maybe the best option and you
can redesign your wall graphic to make things right.

[Gambit37]

I can easily modify my graphic to take account of this -- it seems like that's the best solution so as not to affect other potential custom dungeon builders

Are you sure of those coordinates by the way? My research shows that the rectangle copied from starts at x=78, y=37. (You have x=94 and y=28 described above).

[Paul Stevens]

This is what I am basing my information on:

Code: Select all

      if (drawingText)
      {
         TAG0088b2(d.pWallBitmaps[9],  // src
                  d.pViewportBMP, // dst
                  (RectPos *)d.Byte4192,     // 0x00,0x4a,0x14,0x5a
                  94,             // src x
                  28,             // src y
                  d.uByte3026[4], // src byte width
                  112,            // dst byte width
                  -1);

The (94,28 ) appears to be relative to the wall bitmap, not
to the viewport or window. But that should make both numbers
bigger whereas you think the x should be smaller and the y bigger.

How did you determine the source rectangle coordinates?

It should be easy to check. Put a single red pixel in there
and see where it goes. Is it the mirror image of the bitmap
you provided?

[Gambit37]

I worked it out simply by looking for the shape of the copied rectangle and seeing where it was on the original wall graphic. From there I found the coordinates based on the dungeon view window, using 0,0 top left. That window is 224x136.

Your original coordinates of (110,37)(113,62) work perfectly in defining the central 4 pixels within the viewport window. But using the same origin, your (94,28) would be where the red box is in the image below, not a place you'd want to copy from due to the horizontal lines. The coordinates I determined are the blue box.

[Paul Stevens]

As I said, I think the source coordinates are relative
to the wall graphic, not to the viewport or to the screen.

The wall is 128 wide. 94-97 is then 34-31 from the
right side of the wall. Remember that the wall is mirrored
in every other cell. If you subtract the distance from the
left of the viewport from your x you get 30. And if you
add the 9 pixels in the ceiling to my y you get 37.

So we agree within one pixel and my computations are
sorta off-the-cuff.

The destination rectangle is relative to the viewport and
that is why we are in agreement there.

[Gambit37]

Ah, I see -- odd that coordinates are specified from different origins. Anyway, it's all sorted -- I've modified my graphic accordingly so that it looks good when copied by the engine.

Thanks for the help.

[Paul Stevens]

odd that coordinates are specified from different origins

Hardly odd. If you are going to copy a decoration into
the viewport area it is perfectly natural to copy the source
bitmap starting at ( 0, 0 ) (relative to the decoration) into the
destination at, say, ( 100, 100 ) (relative to the viewport).

In this case it is the wall rather than a decoration but the same
argument applies. How else could it work? They are copying
from the wall bitmap to the viewport, not from the viewport
to the viewport because if they copied from the viewport to
the viewport they would get something different if the mirror
image of the wall were showing.

[Gambit37]

Doh! Oh yeah! I should really go to bed....!