Native Maptext vs Coded On-Screen

ID:1833593
 
Apr 15 2015, 12:26 pm (Edited on Apr 15 2015, 2:03 pm)
I've been looking over old lost code from my On-Screen Text demo and I have been optimizing it a bit.

Now, the native maptext is nice, I have played with it a little bit about a year ago and since then I have not been in-touch with any updates to it. I believe the last time I did anything with it was a feature request to have the maptext click-able or at least any mouse support with maptext.
http://www.byond.com/forum/?post=705799

So, since then I figured I would come up with something that would open a huge market of options for on-screen text that wouldn't be a bogged down as the old (and by old I mean WAY old. Think 10 years ago when people were using a bunch of icons and making them into screen_objs every time text was displayed). So, my current method is to generate a grid of screen_objs on the client screen, and the screen_objs are adjustable via code (setting individual grid box height, width, spacing, grid width and grid height, etc). This allows me to use more than just text too, since I can change the grid screen_obj icons/icon_states to things like a Health bar, or on-screen compass system, etc.

Example: (I'm using someone's tutorial for my example, which explains the RPG Maker icons since I don't have an actual game created yet).
Untitled


Each one of those boxes is a screen_obj grid box, and by default will be a blank icon_state. There are icon_states right now based on each alphabetical and numerical character on a standard US keyboard in my icon file.


Now, I haven't finished with optimizing my code so I haven't been able to really test but does anyone know what the estimated efficiency of screen_obj icon_states being updated or would maptext be more efficient. I do know the last time I used maptext it wasn't very efficient when there were a large group of players in one server running simple but continuous tasks.

I know from a utilization standpoint, the screen_obj grid based would be a bit superior as it has more functionality and many different uses.
Apr 15 2015, 12:59 pm
Maptext is more efficient hands down, however I cant stand the way BYOND renders the screen making it ugly when scaled.
Apr 15 2015, 1:03 pm
How would maptext would be more efficient? Does changing icon_states (since the grid-boxes are pre-cached icons and pre-cached icon_states) really make such more performance than the native maptext?
Apr 15 2015, 1:39 pm
In response to Maximus_Alex2003
Well, it's change one variable (maptext) vs change the icon_state of at most all of those boxes.
Apr 15 2015, 1:53 pm (Edited on Apr 15 2015, 1:59 pm)
In response to Kaiochao
Kaiochao wrote:
Well, it's change one variable (maptext) vs change the icon_state of at most all of those boxes.

But does maptext itself run more efficient than screen_obj's changing icon_states?

I'm not familiar with the actual inner workings of maptext (if it acts as a label with transparency, acts as another map with text placed on-top of the existing map, etc.)

I think once I get a working demonstration I'll have to see what Dream Daemon shows.

Edit: When using maptext, transparency will cause Dream Seeker to switch hardware rendering which doesn't seem too efficient in the grand scheme compared to an icon that already has a transparent background (or not, depending on how you actually create the icon).

maptext:
(Alpha transparency will be ignored when the map is drawn without hardware rendering, so anything below 50% opacity is not displayed in those cases.)
Apr 15 2015, 2:15 pm
I've never had any issues with maptext performance-wise. I use images instead of screen objects though.

But then again, I've only tested it on a small scale (less than 10 players at once). The overall output I get from the profiler after spamming, say, 10,000 calls, is beautiful though - and I use 8 images instead of the do-able 4 (for a crisp border), so that should tell you something.
Apr 15 2015, 2:42 pm
In response to FKI
FKI wrote:
I've never had any issues with maptext performance-wise. I use images instead of screen objects though.

But then again, I've only tested it on a small scale (less than 10 players at once). The overall output I get from the profiler after spamming, say, 10,000 calls, is beautiful though - and I use 8 images instead of the do-able 4 (for a crisp border), so that should tell you something.

In your tests do you have transparency on the maptext?
Apr 15 2015, 2:45 pm
In response to Maximus_Alex2003
No sir. I'm wondering why you would need (or do) that though. O_o
Apr 15 2015, 2:57 pm
In response to FKI
FKI wrote:
No sir. I'm wondering why you would need (or do) that though. O_o

If for instance I wanted to create a 'fade in and out' effect. Or to have, for example, a "log" of recent events displayed such as "You leveled Up!" or Chat and then have the previous lines of log fade by a percentage to show they are older and not as current. It's not something I would generally need use for at this time, but the option to use it is nice.

Edit:

Also, regarding the original post, has clickable maptext been implemented yet?
I requested it back in 2012 on a previous key.
http://www.byond.com/forum/?post=705799
Apr 15 2015, 3:19 pm
I think you can achieve some, if not all of that modifying the alpha variable of the object the text is attached to.

I just tested it, and no, maptext does not appear to be clickable.
Apr 15 2015, 4:36 pm
In regards to the OP, changing a maptext value has much less impact on the server over changing several screen objects. maptext is simply a string, in which the result shows the value on screen (with HTML and CSS formatting, if used).

Maptext is not clickable by itself, and still uses the source object's own icon. Should you want the maptext box to be clickable, it is possible to create an overlay using an icon and scale/translate it to the size of the maptext box using a /matrix.

maptext_obj
    parent_type = /obj
    maptext = "No Text"
    maptext_width = 320
    maptext_height = 240
    icon = 'blank.dmi' // a 10x10 pixels, arbitrary, filled with rgb(0,0,0,1) (1 alpha)
    icon_state = ""

    New()
        ..()
        var/matrix/m = new()
        m.Scale(32,24) // scaling occurs from the middle of the icon
        m.Translate(160,120)
        transform = m


I also tinkered a bit with using grid-styled HUD stuff a little while back, and use a simplified version of it in my current project.
http://www.byond.com/forum/?post=1520720
Apr 15 2015, 4:50 pm
In response to Mr_Goober
Heh, funny. I tried searching for the grid-styled HUD before and haven't came up with anyone similar to mine, except yours now. At least I'm not the only one with the ideal.

So, how effective has the grid-styled HUD been? Would you prefer using maptext or the grid-styled HUD?

I think I'll ultimately stick with my grid-styled HUD and possible use maptext for things that don't require any special controls like clicking and whatnot.
Apr 15 2015, 5:08 pm
http://www.byond.com/forum/?post=1746968
This post shows off some of the HUD stuff I was working on for the project. It pretty much spat out a bunch of text characters, but it took over 6 seconds to fully complete rendering. I remade this and now it renders completely in about 1 second.

It's a solid idea. I haven't tested it out for online gameplay, so I am not sure if it hogs bandwidth when doing blocks of grid cell updates. The one in the post was really unoptimized and took about 7 seconds for it to render on DreamSeeker (and oddly enough about a half second in the webclient).

Grid-styled HUDs offer a great variety of flexible grid-styled controls to be created, but are more resource heavy. It's your call.