ID:688906
 Apr 20 2012, 11:33 pm (Edited on Apr 21 2012, 12:10 am)
|
|||||||
| |||||||
maptext_background could be set to an rgb() value, and would simply display a box behind the maptext that represents its writing area (maptext_width/height). This would be especially useful when trying to setup/debug the maptext, and also provide a simple way to draw a background "window" behind things like chat.
| |||||||
|
Apr 21 2012, 12:10 am
|
|
Falacy
 |
Without any actual text in maptext, this feature could also be used to draw general boxes across the game, or on the screen. This could provide a simple way to better group (or even create entirely) HUDs, and could also provide screen-wide color effects like turning the screen red when hurt.
|
I had assumed we were supposed to use image underlays for our own window frames and background effects. The map_text variable is already tied to an object, you could also tie your background to it as well.
| |
SuperAntx wrote:
I had assumed we were supposed to use image underlays for our own window frames and background effects. The map_text variable is already tied to an object, you could also tie your background to it as well.For a chat output, that may be feasible, since you would only ever need one. But even then, this feature could still be beneficial during the setup process, and would simplify the work before needing to create a graphical image to provide as the background. However, for most other cases, (as far as I've used it) maptext would be driven by dynamic objects. Having to create the background for these every time literally kills the game. As seen in this screenshot, world.cpu is increased to 40+%, mostly from creating a background for the text that is displaying world.cpu. Without rendering backgrounds, world.cpu is at a steady 0%. It also generally freezes the game during the icon generating process, and quickly raises memory usage until the game crashes. | |
We can probably do this with an html tag.
| |
I've been looking at this and it seems like it'd be easy enough to add, but it does raise the question of how the background should be done. Should it be the whole text area, or just behind any text that's drawn? Both? Or, should the default background (e.g., red) cover the entire combined rectangle of all drawn text?
The way HTML is parsed, each section of text would have the opportunity to display its own separate background color; the background color would essentially be part of that object. But because text inherits from the body, I could see this causing some issues if we drew a larger background with a partially transparent color, since the text would inherit that same background (not transparent), and want to draw it again, unless I put in some logic specifically to deal with that. It also seems like whatever background color is chosen before any output should extend to a single rectangle over all the text, but not necessarily to the full width/height. | |
I'd say shade the entire text box. I can't think of a good reason to only highlight the text aside from making an ugly interface just to show it can actually do that.
| |
Well we actually do support a background color for text, as far as HTML/CSS parsing goes. I could see a user wanting to put a background around a single word.
| |
Before the 494 update, I was experimenting with my own map-text.
My method was to create my own grid of screen-objects and to give each screen-object the size of the symbols plus extra pixels for comfort. Then I can alter said screen-objects in the grid to the symbol they will represent via icon-state. On a relevant note, this screenshot may help determine what to do with map text, as far as what the background ability should look like (kind of as an example shot). My personal opinion, I don't think I'll be using map-text any time soon until I do performance tests over network. But, I feel the background should be per-character if applicable, but then again I would assume you can toggle per-character and per-textbox via an argument or variable. | |
All of the above options, if possible? Also, would it be possible to have the background size to the overall text, and create as small a background as possible within the given area, for mouse-over tool-tips and such. As seen in this screenshot, I have attempted to size the bounds of the maptext to best display around the text. However, since the letters of various fonts are usually not equal widths, you have to overestimate size, which often leaves large blank areas on the right of the tip. It is also a rather clunky calculation to begin with, since the text takes up multiple lines
| |
If the background covers the entire maptext bounds this is only useful as a convenience - it's already pretty easy to create a colored box on the screen. If the background covers only the space the text occupies, it'd be useful for tooltips* and other things.
* they'd be ugly tooltips since it's only a solid background color, but people seem to flip over features that are better than nothing but still not on par with what you'd see in a decently-made game. | |
Forum_account wrote:
it's already pretty easy to create a colored box on the screen.It is actually ridiculously complicated and inefficient to do that. people seem to flip over features that are better than nothing but still not on par with what you'd see in a decently-made game.Because BYOND doesn't have many/any features that are on par with legitimate games/engines. | |
Falacy wrote:
It is actually ridiculously complicated and inefficient to do that. It's not complicated: proc BYOND doesn't handle these things as efficiently as it could, but unless you're changing this every tick you're not going to have problems. Because BYOND doesn't have many/any features that are on par with legitimate games/engines. Being able to draw a solid colored box doesn't help a whole lot. To use this to create nice looking tooltips you'd want a border, background image, drop shadow, transparency, fade in/out effect, etc. (and have it be controlled completely by the client). | |
Forum_account wrote:
Being able to draw a solid colored box doesn't help a whole lot. To use this to create nice looking tooltips you'd want a border, background image, drop shadow, transparency, fade in/out effect, etc. (and have it be controlled completely by the client). Yeah, I'd have to say I agree. The way the feature is looking right now they might as well not even bother and use their time working on something useful. | |
Forum_account wrote:
It's not complicated:That only creates an icon, without actually displaying it. That code itself is also somewhat advanced, and because of the clunky way icon procs work, most people probably wouldn't be able to figure it out at all; you can't create an actual /box object and then run src.icon.Scale() on it. BYOND doesn't handle these things as efficiently as it could, but unless you're changing this every tick you're not going to have problems.Technically, they should be updated every tick. Based on every other platform that I have used, that is how it works. Vaguely comparable to stat panels in BYOND. Now, creating multiple icons every tick isn't exactly necessary, but with BYOND, that is how it would be comparatively done. If there were atom.color/transparency/scale settings, then you would simply change those, and everything would be redrawn naturally (and presumably more efficiently). To use this to create nice looking tooltips you'd want a border, background image, drop shadow, transparency, fade in/out effect, etc. (and have it be controlled completely by the client).A lot of those sound like overlapping concepts that would hardly work together. You can already easily apply a background image to maptext, but you have to make that image (the point of this request is so that you don't). Transparency can be applied (using Blend), but there should be an atom.transparency var, such a setting would also be put to use for a fade in/out effect. Drop shadows of both the text or a background image could be pretty easily accomplished, though a drop shadow setting for maptext would make for a good built-in option. Borders are really the only "impossible" thing mentioned there, and perhaps they could just include those with this request. | |
Falacy wrote:
You can already easily apply a background image to maptext, Not all of these features (background color too) are completely possible. If the background/border/shadow is sized so it's only shown for the space occupied by the text (instead of the space specified by maptext_width and maptext_height) then there's no easy way to know how large to make the background image (or border, shadow, etc.). The feature we should really be asking for is a way to get the size of the text, since this can be used to implement many effects yourself, instead of asking for each individual feature that requires knowledge of the text's dimensions. That only creates an icon, without actually displaying it. That's the same with how maptext works. Maptext, or the proposed maptext_background, don't cause the text (or background) to be displayed, you have to place the object on the map or on the client's screen. We're both assuming the user will take care of that. That code itself is also somewhat advanced, and because of the clunky way icon procs work, most people probably wouldn't be able to figure it out at all However easy DM is to use, you always have to assume that people can read the reference and understand how to apply what they see there (this only becomes more necessary as you add more built-in features). These procs (Shift and Blend) might be ones you don't often use but their usage here is straightforward. You may need to double-check the reference page for these procs but there's nothing advanced or confusing about this. | |
Forum_account wrote:
Not all of these features (background color too) are completely possible.You can generally calculate the width and height needed for the text, though it most likely won't be 100% accurate. A bigger issue with displaying images as backgrounds that match the text size is that scaling an image with graphical borders will undesirably scale those borders. The feature we should really be asking for is a way to get the size of the text, since this can be used to implement many effects yourselfThat would also be useful, but requesting a simple background on text is far from something that should be complicated. Within a few hours, Tom replied with a way this could be done, and Lummox listed several possible implementations, so it seems like they pretty much have the available features figured out already. maptext is something that should have been in from the start; every legit game in the history of games uses on-screen text. That's the same with how maptext works.Displaying maptext is far from intuitive or user friendly. there's nothing advanced or confusing about this.The advanced/confusing part is what I mentioned; for some reason you cannot actually run atom.icon.Blend(). | |
Falacy wrote:
A bigger issue with displaying images as backgrounds that match the text size is that scaling an image with graphical borders will undesirably scale those borders. 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. You can also draw the borders at runtime using DrawBox(), assuming you don't want a very fancy kind of border. That would also be useful, but requesting a simple background on text is far from something that should be complicated. By now you should know that features, for some reason, are more difficult to add than they seem =) I have a feeling they'll add a couple of features like this - ones that cover up the need for knowing the size of the text but still don't make it possible to use maptext in many ways that look decent. 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. 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.). Displaying maptext is far from intuitive or user friendly. What would you change about it? 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. 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. | |
The width and height are the icon_size by default now. Probably not that useful either (who makes text that is one tile?) but at least something will show up.
Getting width & height is not really possible since the means to do so many not even exist on the server. I'm not sure what the issues are with the existing maptext ("debugged at turtle speed"). We'll probably add some remaining html tags like the background_color and link support, but it should basically work for common usage. We hope that people develop their own features through libraries-- that is far more efficient than doing it ourselves. There may be some performance tradeoff but having something is better than nothing. | |
Yut Put wrote:
Though many of the features requested in this forum are well thought-out and would certainly improve the software, the ones that are most likely to be added(Very few of them) won't be added for a very long time- long enough for soft-coded implementations of things to be made by the community that exceed the quality of the native implementations by far, and kind of make the native features seem useless anyway. If you could run custom code on the client it'd make maptext obsolete. It'd also open the door to lots of other things. There are many things that are easy to code but perform poorly. On-screen text was easy to do without maptext, but it bogged down the server's CPU to create all of those objects and it used a lot of bandwidth to transmit them to the client. If you could execute a proc on the client, you'd only need to send a message saying "execute the 'draw on-screen text' proc on the client with the argument 'hello, world!'". It'd use the client's CPU to create the objects and it'd use very little bandwidth. Also, imagine if atoms had variables to control their display properties (scale, angle, opacity, etc.). You can do something like this to make a, object fade in or out: for(var/o = 0 to 100) But that requires sending 101 updates to the client. If you could execute that on the client, it's just a single message being sent to the client. BYOND can add features like maptext that cover up the need for the larger, more difficult feature (client-side processing), but at some point it would have saved them to just implement the harder feature (and let us use it to implement the other features, like maptext, ourselves). The argument that maptext is easy for the staff to implement would hold up, but it took months to add/debug (and is still rather limited). I'm not sure why they are hesitant to add big features. I get different impressions from the staff. At times it seems like they're confident that BYOND can be used to make a successful game and doesn't need additional features. Other times it seems like they are afraid of any decently-sized feature (but, then they knock out a feature like pixel movement rather quickly). Other times they want BYOND to be on par with other tools. Other times they're content for BYOND to lack features and be the game development tool for kids. | |