Native map text

Dec 6 2011, 7:44 am

I agree, but that isn't relevant to this thread. This is something that was easy and consistent to build into the new notation and that I always felt should fundamentally be a part of the language. It will probably never be as customizable as some of the DM-based text systems out there (eg, yours or Lummox JRs), but that's ok as users can always have a choice based on their needs. Also, similar to the pixel movement, this may be something that soft-coded libraries can incorporate if it turns out to provide efficiency boosts; I suspect that for constantly changing text, it will give better performance server-side and comparable-or-worse performance client-side.

Or maybe no one will use it. That's fine too because it just wasn't much of an investment and doesn't hurt anything.

Dec 8 2011, 10:23 pm
Nadrew	Yay, our talk last week actually resulted in something!

Dec 9 2011, 4:18 pm (Edited on Dec 9 2011, 7:11 pm)

Tom

Some of you have expressed an interest in trying this out, so I've uploaded a zip file here: href=http://www.byond.com/download/build/BETA
(just unpack and run from its own dir so you don't have to install).
(bad build, BAD!)

I probably shouldn't have announced this in the feature tracker as this is really still up in the air. I just want to see if it's relatively stable and useful at all. If not, I may just scrap it as it will be more work to support in the Flash etc. So give me some feedback.

The main drawback of this implementation is that the fonts and display all occur client-side, which means the server has no knowledge of the actual text span. This makes it difficult to properly align multiple text outputs (you can probably get a ballpark estimate by looking at the amount of text & size). Ideally we could compute this on the server; it would be easy for single-player games since they have an attached client, but otherwise it requires knowing about the fonts which may not even be present on the server (eg, in the case of a linux server). It's very similar to the limitations we have in parsing sound foo (which are also currently a part of the client). I am hoping this is not too much of a problem. In general, I suspect that complex operations will need to be done using the existing icon-based systems, but I'm hoping that there is a place for this stuff for typical maptext usage. In particular, I think it works well for attaching names and small chat to icons (probably as overlays). It should be considerably more efficient than an icon-based approach. Again, if the limitations are too much for this to be of any use, then no sense going further with it.

Usage should be straightforward. Just create an object and set the maptext and the bounds_ vars for the bounding box for the text (it may make more sense to use new maptext_width/height vars so that non-movables and atoms that otherwise use bounds can have text, but I think near 100% of the time you'll just make text a standalone object so it probably doesn't matter). By default, the text is aligned to the BOTTOM of the bounds rect (this can be changed if TOP makes more sense). Unless overriden the text is drawn using the map control's font & color (which can be now set in the interface editor). You can override individual text by using the font tag (color, name, size, align=left/right/center and valign=top/middle/bottom). Only tags up until the start of text are supported, so you can't do inline changes. Example:

mytext.maptext = "<font color=blue align=top>hello"

I've done pretty limited testing just to make sure everything works and text extents are respected by the server. There may still be major bugs. Let me know what you think.

Dec 9 2011, 5:20 pm
Nadrew	It only seems possible to display text boxes over 32x32 if you put the object directly on the map. Putting it as an overlays or screen object smashes it all into a single tile.

Dec 9 2011, 5:21 pm
Tom	Feh, I'll take a look.

Dec 9 2011, 5:23 pm
Nadrew	And sticking them on a moving atom just looks bad, as we figured it would. I don't expect it being a good idea to be sticking them to moving atoms anyways, best to leave that stuff to existing soft-code solutions.

Dec 9 2011, 5:25 pm
Tom	Really? I found that text looked pretty good with moving atoms. But I did confirm your overlay issue. I'll have to see what's do-able here. I assumed those were propagating bounds() but if they aren't, then we'll need to use different vars for the width/height settings.

Dec 9 2011, 5:27 pm
Nadrew	When I changed mob.maptext, it displayed properly, but as I moved around it jumped all over the tile I was on, rarely appearing in the same place after I moved.

Dec 9 2011, 5:29 pm
Tom	Does your mob have very large bounds_ settings? When I use, eg bounds_width/height = 200, it moves just fine. Why don't you show me what your code is here. I think we'll need to use separate maptext_width/height vars anyway to get this to work as I want for overlays & screen objects, so I'm looking into that now. Maybe that will fix both problems here. Sheesh.

Dec 9 2011, 5:32 pm
Nadrew	Okay, got this figured out. When using bounds that enable movement gliding the text jumps into new position instead of gliding so it looks choppy, but when you use bound_ values that aren't multiples of 32 the jumping fits into the lack of gliding.

Dec 9 2011, 5:36 pm

Nadrew

This is the code I'm using for my screen object test, the background.dmi is a 128x128 box image. The box background displays fine, but the text is contained entirely at the bottom-left 32x32 of it.

mob
    icon = 'icons.dmi'
    icon_state = "mob"
    verb
        Test()
            for(var/obj/screen_dummy/S in usr.client.screen)
                del(S)
            usr.client.screen += new/obj/screen_dummy
    
turf
    icon = 'icons.dmi'
    icon_state = "turf"
    

obj
    screen_dummy
        icon = 'background.dmi'
        bound_height = 128
        bound_width = 128
        bound_x = 0
        bound_y = 0
        screen_loc = "1,8"
        maptext = "<font valign=top color=yellow>  Some map text"

Outside of these couple of issues, seems to work great. I think having variables for the maptext bounding box separate would fix things up nicely.

Dec 9 2011, 5:39 pm
Tom	ok, I'll see what I can do! I am working on something else so I may not be able to get an update right away, but I'll do my best. I think this is fixable.

Dec 9 2011, 5:47 pm
SuperAntx	Same problem here, bound_width and bound_height don't seem to effect the text. It's all crammed into one tile. Also, when the text is applied to a map entity it has a weird effect when moving around. When an atom moves EAST the text seems to jump WEST a tile then travel two tiles EAST before stopping on the correct tile. This happens in all directions.

Dec 9 2011, 5:53 pm
Tom	I think you are seeing the same problems Nadrew experienced. To get the gist of how this will work when I fix these bugs, just attach some text to normal pixel-movement objects (that you set step_ and bounds_ for) and move them around etc.

Dec 9 2011, 5:59 pm

SuperAntx

Tom wrote:

just attach some text to normal pixel-movement objects (that you set step_ and bounds_ for) and move them around etc.

Ah, I'm using tile movement rather than pixel movement. With pixel movement I see a different but similar effect. Each step an atom takes the text seems to step double that distance. Every time the text gets a full tile out of sync it resets back to where it should be.

Dec 9 2011, 6:05 pm
Tom	Can you post a snippet?

Dec 9 2011, 6:11 pm
SuperAntx	client New() ..() MT = new screen += MT var/obj/text/MT verb/Chat(MSG as text) MT.maptext = MSG mob.maptext = MSG obj/text screen_loc = "1,1" bound_width = 64 bound_height = 64

Dec 9 2011, 6:23 pm

Bandock

It appears the glitch with the text sliding happens when you set certain boundaries based on whatever multiples your icon size is based off of. To avoid such a glitch for instance at this time for a 32x32 icon (either world icon_size or the icon's size), avoid any boundaries that are contain a multiple of 32. That means no 64, 96, 128, etc.

However, even it can be glitchy (especially near the edge of the map).

Edit: Yep, it seems to depend on the world's icon_size calculations. Tested it under 64x64 conditions and using any boundaries within the multiples of 64 causes glitching.

Dec 9 2011, 6:25 pm
Nadrew	Yeah, that's the same issue I posted earlier. It has to do with how BYOND handles gliding with icon_size in multiples of 32.

Dec 9 2011, 6:30 pm (Edited on Dec 9 2011, 6:35 pm)

Bandock

Nadrew wrote:

Yeah, that's the same issue I posted earlier. It has to do with how BYOND handles gliding with icon_size in multiples of 32.

Isn't just multiples of 32. There seems to be a glitch with world/icon_size and any map text that uses boundary settings based on the multiples provided by the world/icon_size variable.

Tested it with 24x24 and glitches up as well.

Edit: Seems like the glitch is even more interesting on the world/icon_size variable where width and height are not the same. Try 32x31 for instance and using 32 as the width boundary and 31 as the height boundary will have the issue. Changing either setting not a multiple of 32 for boundary width and not a multiple of 31 for boundary height causes it to get tacky by slowing shifting a particular direction.