maptext_background

Page: 1 2 3
Apr 26 2012, 6:27 pm (Edited on Apr 26 2012, 7:07 pm)
In response to Forum_account
Forum_account wrote:
Scaling an image will undesirably scale the image too. You'd probably want to have a background image large enough for the most amount of text you'll show and crop it to the size you need.
In most cases I would expect the border to be part of the image, or an image itself.

You can also draw the borders at runtime using DrawBox(), assuming you don't want a very fancy kind of border.
And perform 4 more inefficient icon operations? =P

By now you should know that features, for some reason, are more difficult to add than they seem =)
If anything, I'd say its actually the opposite of that.

This isn't an unreasonable feature request, but if I had to pick between this and the ability to find the size of the text, I'd prefer being able to get the size of the text.
Finding the general size of text are just some simple calculations
width = length(text) * estimated letter width
height = length(text) * estimated letter width / maptext_width * estimated letter height
The problem is that these aren't 100% accurate, (mainly the width, you should be able to get an accurate height) but because an i and w would commonly take up different widths, it will generally force you to overestimate the width.

This feature is also less useful because, as you've mentioned, BYOND should have more capabilities to perform graphical operations on the client (scale images, change opacity, etc.).
This wouldn't really change that. In fact, I assume this would be processed by the client.

What would you change about it?
* For almost any practical use of maptext, you have to create an object of some type for it, but for some reason there wasn't a default type created for it
* In most cases you are going to add maptext objects to overlays. overlays do not properly update, which means you have to remove the overlay, change the text, then re-add the overlay.
* Controlling who can see maptext is a pain in the ass that requires an awkward application of /images
* In most cases, you are going to want a drop shadow and/or background so that the text is easily readable.
* If you could set maptext_x/y, you could actually use the default maptext of an atom to display at least 1 portion of text on it, instead of having to use a separate object for practically every situation.
* If text is too long it just gets completely cut off
* probably some other things

The only thing I'm aware of that's unintuitive is that maptext_width and _height are both zero by default (unless this has changed) so that only setting maptext doesn't have an effect.
As Tom mentioned, that has been changed.

I'd have preferred if there was a /maptext type of atom instead of having maptext vars on atoms, but that doesn't make it much more intuitive.
This isn't really something that needs to be an instead, but just something they should also include. You're pretty much going to need to make a /maptext type, having one by default would help get the point across.

If you could run custom code on the client it'd make maptext obsolete.
Not really. Being able to do maptext="text" is still going to be used far more often than having to manually icon 50+ frames for letters, parse text, create and manage objects, etc. And it would probably still be more efficient.
Apr 26 2012, 6:33 pm
In response to Falacy
Falacy wrote:
* In most cases you are going to add maptext objects to overlays. overlays do not properly update, which means you have to remove the overlay, change the text, then re-add the overlay.

Please elaborate on this with a bug report. If you are changing maptext and it isn't updating because it's on an overlay, then that's a bug.

* Controlling who can see maptext is a pain in the ass that requires an awkward application of /images

I'm not sure how else we'd do it since /image is the defacto class for controlling client-specific visibility. We're just treating maptext like any other appearance object (eg, icons).

* In most cases, you are going to want a drop shadow and/or background so that the text is easily readable.

I think the main problem here is the stretching in hw-mode. Maptext looks pretty good at any scale in sw-mode in my tests, but on one of my machines is absolutely terrible in hw-mode (admittedly most graphics are terrible when stretched but it's especially bad for text since you have to be able to read it). I've been trying to figure that out.

* If you could set maptext_x/y, you could actually use the default maptext of an atom to display at least 1 portion of text on it, instead of having to use a separate object for practically every situation.

I figured you could just make a maptext object and control offset with step_x/y. Unless there is a huge need to merge the atom.icon with the atom.maptext (which could still be done with overlays), I don't see what the problem is.
Apr 26 2012, 6:42 pm
In response to Tom
Tom wrote:
Please elaborate on this with a bug report. If you are changing maptext and it isn't updating because it's on an overlay, then that's a bug.
If you add an object to overlays, and then update the object, it doesn't update the overlays, and it breaks the connection to the object. So, if you remove an object from overlays after anything on that object has been changed (visual or otherwise) it will not be removed from overlays. That's how overlays have worked forever now.
Changing an object doesn't trigger an update for references where it is used as an overlay, it breaks the connection to those references.

I'm not sure how else we'd do it since /image is the defacto class for controlling client-specific visibility. We're just treating maptext like any other appearance object (eg, icons).
http://www.byond.com/forum/?post=92006

I think the main problem here is the stretching in hw-mode. Maptext looks pretty good at any scale in sw-mode in my tests, but on one of my machines is absolutely terrible in hw-mode (admittedly most graphics are terrible when stretched but it's especially bad for text since you have to be able to read it). I've been trying to figure that out.
Its just a general color issue. In most games, you can't really predict the ground color. One minute you may be standing on white snow, and then on black rocks. If your text is only a single color, in one of those places it is probably going to be impossible to read, so you offset it with a shadow of the opposite color.

I figured you could just make a maptext object and control offset with step_x/y. Unless there is a huge need to merge the atom.icon with the atom.maptext (which could still be done with overlays), I don't see what the problem is.
That is what you do now, you make an object and/or overlay. This is kind of a waste though. If all I want to display on my character is their name, I shouldn't need to build an entire maptext "library" into my game. I should just set maptext_x/y to the lower left, increase the maptext_width, and set maptext to src.name.
Apr 26 2012, 6:50 pm
In response to Falacy
Falacy wrote:
Tom wrote:
Please elaborate on this with a bug report. If you are changing maptext and it isn't updating because it's on an overlay, then that's a bug.
If you add an object to overlays, and then update the object, it doesn't update the overlays, and it breaks the connection to the object. So, if you remove an object from overlays after anything on that object has been changed (visual or otherwise) it will not be removed from overlays. That's how overlays have worked forever now.
Forum_account's Overlays library does what I've always been meaning to do, but never got around to doing: let procs handle removing from overlays, modifying the overlay, and re-adding it. Of course, if I want to modify a lot of variables at once, it's more efficient to re-add the overlay once instead of once per variable. A MapText() proc can be easily added to the library, too.
Apr 26 2012, 6:53 pm
Thanks Falacy. I'll take a look at that stuff. It's not really a big problem to add maptext_x/y, but I wasn't sure there was much need, I think we could add some css style for shadowing text (in fact I thought we had something already) and/or bg support.
Apr 27 2012, 6:24 am
In response to Falacy
Falacy wrote:
Tom wrote:
Please elaborate on this with a bug report. If you are changing maptext and it isn't updating because it's on an overlay, then that's a bug.
If you add an object to overlays, and then update the object, it doesn't update the overlays, and it breaks the connection to the object. So, if you remove an object from overlays after anything on that object has been changed (visual or otherwise) it will not be removed from overlays. That's how overlays have worked forever now.
Changing an object doesn't trigger an update for references where it is used as an overlay, it breaks the connection to those references.

When adding an object to the overlays list, you are not actually adding an object but a snapshot thereof. The actual item in the overlays list is an Appearance.

You have two options for updating the maptext. First, you can keep an unaltered copy of the object you added so you can subtract it again, or simply keep a copy of the reference that was actually added (which you can grab from the list right after adding). Alternatively, you can loop through the items in the list and look for one with item:maptext, and remove that. In either case you remove the old overlay before adding a new one. Overlays do not update in place.

I think the main problem here is the stretching in hw-mode. Maptext looks pretty good at any scale in sw-mode in my tests, but on one of my machines is absolutely terrible in hw-mode (admittedly most graphics are terrible when stretched but it's especially bad for text since you have to be able to read it). I've been trying to figure that out.
Its just a general color issue. In most games, you can't really predict the ground color. One minute you may be standing on white snow, and then on black rocks. If your text is only a single color, in one of those places it is probably going to be impossible to read, so you offset it with a shadow of the opposite color.

Stretching aside, you can draw an outline around backgroundless text by giving your maptext underlays with pixel offsets. (An overlay can have overlays and underlays of its own.) I've tested this myself. I really wouldn't mind a more built-in alternative though I'm not sure what the ideal syntax would be.

I figured you could just make a maptext object and control offset with step_x/y. Unless there is a huge need to merge the atom.icon with the atom.maptext (which could still be done with overlays), I don't see what the problem is.
That is what you do now, you make an object and/or overlay. This is kind of a waste though. If all I want to display on my character is their name, I shouldn't need to build an entire maptext "library" into my game. I should just set maptext_x/y to the lower left, increase the maptext_width, and set maptext to src.name.

I see what you're saying; the only things really standing in the way of the "simple" name overlay are an easy way to offset the text and an outline. Although I'd suggest that the use of the same layer as the mob is non-ideal for a name, where a higher or (sometimes) lower layer would be preferable.
Apr 27 2012, 6:38 am
In response to Lummox JR
Lummox JR wrote:
Overlays do not update in place.
I wasn't saying this is a bug, it is just an annoyance with maptext. Most overlay objects are not meant to constantly change, if you add a shirt, that shirt is most likely done. maptext, on the other hand, is something that will pretty much always be changing. Player names are often changeable, over-character chat is going to pretty much constantly update, in the card game I am working on there is on-map display of players and how many cards they are currently holding, as well as general rules that update regularly, etc.

Stretching aside, you can draw an outline around backgroundless text by giving your maptext underlays with pixel offsets. (An overlay can have overlays and underlays of its own.) I've tested this myself. I really wouldn't mind a more built-in alternative though I'm not sure what the ideal syntax would be.
I'm not sure how well of an outline that would make, but that is the basic concept for casting a drop shadow. Tom mentioned that this may also be possible through the map's CSS, but I haven't messed with that yet.

I see what you're saying; the only things really standing in the way of the "simple" name overlay are an easy way to offset the text and an outline. Although I'd suggest that the use of the same layer as the mob is non-ideal for a name, where a higher or (sometimes) lower layer would be preferable.
If your game properly layers, basically what SIDE_MAP does, then I've actually found the same layer as the mob to be best. Offsetting the text shouldn't really be an issue, especially if you're using an actual overlay. Assuming maptext_x/y are basically just offsets specifically for text, that shouldn't really be an issue. You just offset say 96 left, make the maptext_width 192 and use the center align tag. As for the shadow, if that isn't possible through CSS, then you would just add a shadow underlay (which would just be a /MapText proc).

Basically though, the native implementation of maptext is clunky, and to do almost anything practical with it, you need to build a "library" around it.
Apr 27 2012, 7:27 am
In response to Falacy
Falacy wrote:
Lummox JR wrote:
Overlays do not update in place.
I wasn't saying this is a bug, it is just an annoyance with maptext. Most overlay objects are not meant to constantly change, if you add a shirt, that shirt is most likely done. maptext, on the other hand, is something that will pretty much always be changing. Player names are often changeable, over-character chat is going to pretty much constantly update, in the card game I am working on there is on-map display of players and how many cards they are currently holding, as well as general rules that update regularly, etc.

I see your point with all of those, but unless the over-character chat is made to scroll, I'd call those things semi-static--they won't change very frequently, in much the same way a character icon won't. (Chat is more dynamic, but I'd call it semi-static still because it has to be displayed for a while.) This is as opposed to a health display for example which is more dynamic, but I think health bars as overlays have been working out just fine. As a rule I don't think the fact that overlays can't be changed in place will present too much of a hindrance.

Stretching aside, you can draw an outline around backgroundless text by giving your maptext underlays with pixel offsets. (An overlay can have overlays and underlays of its own.) I've tested this myself. I really wouldn't mind a more built-in alternative though I'm not sure what the ideal syntax would be.
I'm not sure how well of an outline that would make, but that is the basic concept for casting a drop shadow. Tom mentioned that this may also be possible through the map's CSS, but I haven't messed with that yet.

The only caveat I'd mention is I had a devil of a time doing this in isometric, but there are probably other solutions for handling that that I haven't explored. Isometric layering still needs some work anyway.

Right now the maptext CSS does not itself support a shadow since we don't parse the text-shadow attribute, nor do we have anything similar built in for an outline. I wouldn't mind such things, although I think we'd probably want to keep them simple. The Gaussian blur allowed by CSS is simply going to be more trouble than it's worth for our text rendering.

Basically though, the native implementation of maptext is clunky, and to do almost anything practical with it, you need to build a "library" around it.

To an extent, I'm not sure that's avoidable. There are countless ways a user might want to apply maptext, and it's difficult to foresee or easily accommodate them all. Far better is if we can cover the common simple cases, and make sure any other cases can be done with soft code. In fairness I do think names would count as a common simple case and you make a compelling argument there, though I'd like if we could balance that to preserve simplicity without introducing a ton of new vars. Overhead chat and tooltips would, I think, be better handled with a library. Right now the very simplest thing maptext will work with is the HUD, and in that venue it can do very well since it's easy to update.
Apr 27 2012, 9:48 am
In response to Lummox JR
Lummox JR wrote:
I see your point with all of those, but unless the over-character chat is made to scroll, I'd call those things semi-static--they won't change very frequently, in much the same way a character icon won't. (Chat is more dynamic, but I'd call it semi-static still because it has to be displayed for a while.) This is as opposed to a health display for example which is more dynamic, but I think health bars as overlays have been working out just fine. As a rule I don't think the fact that overlays can't be changed in place will present too much of a hindrance.

Every time a player says something, you would want to update their maptext. Whether it has a scrolling message list, or more likely just displays their most recent message for a few seconds. You also have to clear these messages in some way after a few seconds. If you are using shadows, then this becomes more of an issue, because you then either have multiple maptext objects to update, or you have overlays inside of overlays that need updating.
Apr 27 2012, 10:12 am
In response to Falacy
Falacy wrote:
Every time a player says something, you would want to update their maptext. Whether it has a scrolling message list, or more likely just displays their most recent message for a few seconds. You also have to clear these messages in some way after a few seconds. If you are using shadows, then this becomes more of an issue, because you then either have multiple maptext objects to update, or you have overlays inside of overlays that need updating.

Agreed, shadows do add another layer of complexity here, though perhaps no more than a speech bubble or any scrolling options would in the first place. I still think it's justifiable to call chat bubbles semi-static though, in comparison to something like a health meter which would probably update frequently if a player's health slowly rises over time.
Apr 27 2012, 10:14 am
In response to Lummox JR
Lummox JR wrote:
in comparison to something like a health meter which would probably update frequently if a player's health slowly rises over time.

If maptext could draw a background, you could technically use it to display both an HP bar and/or HP text, by updating maptext_width and/or maptext.
Apr 28 2012, 2:06 am (Edited on Apr 28 2012, 2:53 am)
In response to Kaiochao
Kaiochao wrote:
Falacy wrote:
Tom wrote:
Please elaborate on this with a bug report. If you are changing maptext and it isn't updating because it's on an overlay, then that's a bug.
If you add an object to overlays, and then update the object, it doesn't update the overlays, and it breaks the connection to the object. So, if you remove an object from overlays after anything on that object has been changed (visual or otherwise) it will not be removed from overlays. That's how overlays have worked forever now.
Forum_account's Overlays library does what I've always been meaning to do, but never got around to doing: let procs handle removing from overlays, modifying the overlay, and re-adding it. Of course, if I want to modify a lot of variables at once, it's more efficient to re-add the overlay once instead of once per variable. A MapText() proc can be easily added to the library, too.

I'm pretty sure it has a MapText proc already (edit: I checked, it does. It's had the ability to use maptext since March 25th). The library also let's you specify who is allowed to see each overlay and it internally transitions between using overlays and images. It has procs for setting the pixel offset too.

As for efficiency, I'm not sure there's much of a difference. BYOND should be sending one update per tick regardless of how many changes you make in that tick. There's the cost of the extra add/remove from the overlays list, but this should be minor.
Apr 28 2012, 2:52 am
Falacy wrote:
In most cases I would expect the border to be part of the image, or an image itself.

If it's part of the background image and you scale it, you'd scale the border (which you wouldn't want). If you crop it, you'd lose the border.

Finding the general size of text are just some simple calculations
width = length(text) * estimated letter width
height = length(text) * estimated letter width / maptext_width * estimated letter height
The problem is that these aren't 100% accurate, (mainly the width, you should be able to get an accurate height) but because an i and w would commonly take up different widths, it will generally force you to overestimate the width.

These are very rough estimates. The width value doesn't take maptext_width into account and the height value isn't correct. The height should jump from one line to two, you'd want something like:

round(length(text) * estimated letter width / maptext_width + 1) * estimated letter height

If the text wraps, there's a pretty slim chance the estimate will be correct. If the text fits on one line you might have a decent estimate, but the problem is that the slightest difference will look bad. If you were playing a game and it had a tooltip that looked like this:

+----------------------------+
| This is the tooltip        |
+----------------------------+

You'd notice how bad the extra space looks.

For almost any practical use of maptext, you have to create an object of some type for it, but for some reason there wasn't a default type created for it
This isn't really something that needs to be an instead, but just something they should also include. You're pretty much going to need to make a /maptext type, having one by default would help get the point across.

If you had a mob with vars like weapon_name, weapon_power, weapon_speed, weapon_icon, etc. you'd realize it's better to create an object to represent the weapon. Having lots of vars with the "maptext_" prefix is a sign that an object should be used somehow. Since you'll almost always have to add maptext as an overlay, forcing people to add a /maptext object as an overlay wouldn't be a big deal. It'd also let you give the object variables with better names - instead of modifying an atom's maptext_background var you'd modify the /maptext object's background var.
Apr 28 2012, 3:01 pm
In response to Tom
Tom wrote:
... I think we could add some css style for shadowing text (in fact I thought we had something already) ...

I tried using text-shadow and it doesn't seem to work yet. Being able to use text-shadow CSS would make maptext much more useful. Text shadow CSS would allow both outlines and glows/shadows, which would make the text not only look nicer, but be easier to read on top of the chaotic and colorful maps.

Apr 30 2012, 10:42 am
In response to Lummox JR
Lummox JR wrote:
Stretching aside, you can draw an outline around backgroundless text by giving your maptext underlays with pixel offsets. (An overlay can have overlays and underlays of its own.) I've tested this myself. I really wouldn't mind a more built-in alternative though I'm not sure what the ideal syntax would be.

You could always support the CSS3 text-outline property.
Apr 30 2012, 10:51 am
In response to Hiro the Dragon King
Hiro the Dragon King wrote:
You could always support the CSS3 text-outline property.

It seems like text-shadow would be more useful, and the implementation details are the same either way.
Apr 30 2012, 11:19 am
Useful, maybe, but outlines would help SUBSTANTIALLY in actually viewing the text if it has no background. They would both be nice additions. Furthermore, the effects that they have are incredibly different, with the text needing at least four text-shadow effects to look even similar to text-outline. And how are they the same, implementation-wise?
Apr 30 2012, 11:36 am
They're the same in implementation because the outline or shadow would have to be drawn the exact same way, by calculating a blur grid (if blur is in use) and drawing the shadow/outline text multiple times. Outline vs. shadow doesn't really change that, although I do see the difference in terms of the intended result. Point taken about the need for multiple shadows though, which would make outlines the domain of soft code only (as they are now).
Nov 3 2012, 9:25 pm (Edited on Nov 3 2012, 9:41 pm)
I think it makes more sense to just support the text-shadow tag and ignore the blurring. There's a definite need and demand for outline or basic shadow capability and blurring isn't very important to most users nor is it even used very often outside of CSS tutorials haha. I honestly find it annoying that maptext is controlled by HTML but I'm not one to complain too much when we're at least given some type of solution. Let's at least get support for the text-shadow tag if at all possible.
Nov 4 2012, 6:34 am
What kind of outline/shadow do you guys want, can yall create a picture, because I know how to code using maptext, to make things like this happen...you tell me what you want, i'll create & host something with it in it, and you tell me if that's what you were looking for, and I can show the code...
Page: 1 2 3