ID:1858131
 
(See the best response by Ter13.)
Code:
n/a


Problem description:
What would be the best way to turn the maptext into an icon?
My reason in asking is that I'd like the names of items to be confined to a certain space, then applied as an overlay or underlay with a bit of an offset.

To achieve this effect :




Best response
Honestly, no need. Simply give maptext to an object then use transform to supply offsets and then use the object as an overlay.
Simple and easy. thanks
Is there any way to actually do this though? If you could turn maptext output into an icon, you could make cool warping effects, like redrawing the characters at different angles, or stretching them out.
In response to Multiverse7
Nope, but you can still use Lummox JR's dmi fonts stuff to do all that.
In response to Kaiochao
That defeats the purpose though, because then you can't take advantage of all of the different system fonts, or make use of the built-in maptext rasterization.
Maptext can't currently be rendered to an icon. I've tried quite a lot of things to get decent control over Maptext, but all of them have failed. I've tried MSIE transforms, and nothing has really worked. Honestly, I'd really have preferred a built-in DMIfont implementation to maptext, but you know, c'est la vie.
In response to Ter13
Well, it would have to be a new feature. I wonder if it would be possible to have something like an icon.DrawText(text, x, y) proc.
Suprisingly enough I was running a test, while this topic was posted, on my screen-text, which uses a screen_obj grid-based method.
The CPU was surprisingly great at 0.003 Average. The only reason why stressTestGrid is a ridiculous Total/Real Time is because it's a loop to go through 9999 calls. The beef of the operation is changeStates which is what changes the icon_states of each individual grid tile.

The result of the screen_obj grid is a fully customization grid on the client screen which allows various things like on-screen text, bars, grids (A grid in a grid), and etc. Plus it's all icons so I can put anything I want from healthbars to clickable quest text and so on.
http://puu.sh/hZl9R/5c64206d7c.png
http://puu.sh/hZlFD/bfed1701d9.png
http://puu.sh/hZlyP/c803ed7401.png





In response to Multiverse7
I actually have something like that.
It just writes text on an objects overlay.
I just wanted to use maptext because of the ability to cleanly cut lines (something I have yet to master.)

In response to Multiverse7
My entire HUD/INTERFACE element is made of screen objects but I never thought of using it that way.
Idk it just seems a bit wasteful.
In response to Avidanimefan
Maptext still doesn't have clickability which I submitted a request back in 2012.
http://www.byond.com/forum/?post=705799
Using the format Tom, Flick and everyone mentioned would make great progress with maptext.

Avidanimefan wrote:
My entire HUD/INTERFACE element is made of screen objects but I never thought of using it that way .
Idk it just seems a bit wasteful.

That's what I first thought when I was making a small chat program using the method so I turned it into it's own system. Then I realized I could handle everything on the player's screen much more organized and efficiently this way. I can group off parts of the grid into smaller grids and use that as a healthbar, I can create special effects without having to figure any of the positioning and configuration in the effect code itself. I could theoretically make a nice fade technique for day/night or weather. The possibilities are great. Everything is easily achieved without using a screen grid, but having the screen grid just makes it much easier for me especially if I want to precache every and all possible icons like healthbar and special effects.
A lot of the problems I've had with HUDtext (using objects/overlays) is that there's a silent, unprofiled CPU consumption introduced by a large number of objects in the client's screen. The server has to check each individual object in the client's screen list and view every frame for graphical updates.

Then even if you do write a HUDtext approach that uses overlays rather than unique objects per letter, you wind up with something called "appearance churn", as Lummox refers to it.

Every time you add an overlay to an object, a new unique overlays list has to be generated. The more objects you add at once, the longer this takes, as each individual overlays list needs to check the overlay dictionary for identical overlays lists and then basically create a unique overlays list id.

Maptext steps around this quite a bit. It would certainly be nice to have some form of embedded HTML5 element that could render transparent webpages inside the map element, but the web client provides that functionality ABOVE the canvas, rather than in the canvas.
In response to Ter13
I haven't experienced either of those issues yet. The system test I did for 9999 calls changed every single grid object icon_state every tick (and that's out of 3,422 screen_obj I was testing). I can of course increase and decease the size of the grid, I can create a grid, then create separate groups (for on-screen chat, effects, healthbar, etc) and remove the grid boxes that won't ever be used. I was using fps of 30, and 16x16 icon.
You haven't noticed them. They only show up when you start stacking players into your world, because the appearance update loops are small, but as you stack more crap into them, it adds up over time.
In response to Ter13
I thought that might be an issue too.
I was thinking for many elements that you don't need multiple instances of *like objects that only respond when the player clicks on them for instance* - just making one set would be enough.

For instance if you have a menu which has the sole purpose of to open an inventory. even if the inventory has to be built specifically for the player, the button itself doesn't.

I've tried applying this concept to a few things in one of my games. Speed seems to have increased fairly considerably but I would need to test it under 20-30-50 groups of players to be certain. So far though, everything seems very, very minimal and no one has complained of "lag" or slow down. (that I know of)
In response to Ter13
Why would this be the case?

Surely 10,000 updates from 1 player is the equivalent of 1,000 updates from 10 players?

Again, it's because it's unprofilable. The problem I'm talking about comes from a deeply internal bit of housekeeping the engine needs to do.

The individual updates themselves aren't the problem. It's simply the fact that every single frame for every single player, every object in the view or screen needs to be checked by the engine for appearance updates.

You simply can't see it. Yet.