We could handle CSS (at least some limited subset of effects-- not sure about things like glow) but at the moment it would apply as a whole to the entire piece of maptext; that is, we could fairly easily setup a <span>maptext</span>. I assume that's not what you want.
Processing inline formatting (whether it be through CSS or normal html tags) is harder, because it requires writing our own layout engine instead of using the one built-in with GDI/DX. It's totally do-able and something I'd look into if this appears to be a feature people end up using (positive comments aside, I'm not 100% sold the lack-of server-side information about the text isn't a dealbreaker).
I'm pretty sure DX has a glow effect built in, I'm not entirely sure though. I know for sure ActionScript does (GlowFilter), so porting said feature to the Flash client would be easy. Outlines could also be done with the same filters by setting the glow to a single pixel (in ActionScript at least). Said glows/filters could even probably be set to any object, but, that gets into a whole different feature request. Haha.
Anyway, I personally wouldn't use the text without outlines and glows (at this point) for my current project, but it is a nice addition nonetheless. Any addition to the DM language is a good thing, I think. | |
Tom wrote:
The internal (windows) implementation of valign=bottom actually does trim excess text from the top, but I figured it was more convenient to trim from the bottom (thinking in terms that for a single-output, it's better to see the beginning then the end, but either way you lose text so it's probably not a big deal). I can change ours to match so we can at least try it out. I've uploaded a new version 1121 at http://www.byond.com/download/build/BETA that handles the valign=bottom (default) and valign=middle styles as noted above, where the top can be truncated when text exceeds the maptext_height. This should help with concatenated output chat situations, although I still don't love that way of doing things since it can result in a lot of extra text transmission and display (I guess the dev could at least truncate strings that are obviously too large to fit in the rect, but there's no way of currently knowing exactly where to do the truncation). Let me know if this is preferable to the other method (v.1120). | |
Oh man, this is awesome. It actually works as a chat output now. I'm about ready to put it into my game just as it is now.
| |
I had it working as a properly scrolling chat output before this update. This update does definitely make it easier to pull off though.
| |
Just make sure you truncate your text after some point, because you really don't want to be setting maptext to huge strings that are 90% truncated.
| |
Tom wrote:
Just make sure you truncate your text after some point, because you really don't want to be setting maptext to huge strings that are 90% truncated. I could see this being a big problem for people who don't really understand the issue. Just leaving a server running by itself for a few minutes produced some startling results. CPU usage was up to 95% and DS was using 200k system memory. It also seemed like the text started to overlap onto itself. Not sure exactly how that happened but you can see it in the screenshot. I guess you'll just have to be especially thorough when writing the documentation. | |
Was that directly correlated to huge maptext strings? That is, by truncating did the memory/cpu go down?
| |
Yeah, according to Profile World the CPU hog was the proc combining the old maptext with new text. Using copytext() to trim maptext down if it got too long cut down on CPU/Memory usage considerably and prevented it from ballooning out of control. It also capped the amount of data the server was sending out to clients.
| |
That's good to know.
One thing that just occurred to me is that trimming your maptext could cause layout problems as your text "starts" from a different position after you trim it (even if the part you truncate is never displayed). Has this been an issue, or do you have a workaround? I can look into some stuff we can do internally to manage this (although it's still better to trim server side to save on the bandwidth of sending so much text, unless we can come up with a good heuristic on that end). | |
Wouldn't that only effect valign=middle?
I can't really see anyone designing a chat output using middle rather than top or bottom. It'll probably be used for things like menus and alert boxes; things which don't have to deal with a constantly changing maptext. When they do have their maptext changed it will probably be cleared first. | |
So I was messed around for about ten minutes and managed this much. This is much simpler and and faster than softcoded versions.
Kudos and good luck with this! | |
The latest beta is here:
http://www.byond.com/download/build/BETA/494.1122_byond.zip This supports inline styles, including the <img> tag (currently img width/height isn't properly supported-- it just goes by the file-- and I'm not 100% sure remote http images work properly as I forgot to test it, but cache-based images, eg: <IMG src=\ref['foo.dmi'] ICONSTATE='state'> should work. I suppose we'll want stylesheet support next, so it basically mimics the text control. That shouldn't be a big deal. This routine is most likely slower than the previous iteration because of the custom parsing and the inability to cache quite as aggressively. In particular, I'm not sure how well it will handle long blocks of text such as a non-truncated on-map chat system (but you should be truncating anyway). It's also likely there are some bugs in the layout engine. Test it out and let me know. | |
BTW, if you do use this for onscreen-chat, I recommend counting newlines and using a basic heuristic to decide when to truncate. For example, if your chat box is 300 px high and you use a 12 pt font, at most you would expect 300/12 = 25 lines. In truth it'll be less than that because of word-wrapping & space between lines, but that's OK. So simply truncate the top chat line (easy to track if you always end with a \n) after 25 lines are output and neither the server nor client should be too taxed. It's still way more overhead than our traditional chat since the entire history has to be sent with each update, but it's still much better than sending the full body of stuff that won't even be displayed. I am curious how this performs, so someone do some tests and let us all know.
If performance is acceptable, this is the kind of thing that would work well in a library. | |
Throwing text at the screen faster than any chat output would normally have to deal with barely registered a dent in my CPU usage. Outbound traffic from DD to DS didn't seem to change at all. Throwing in font colors bumped up outbound traffic by about 1.5K/s.
It didn't hang, stutter, or show any performance issues under abnormal stress, it's my opinion that it would run fine during normal usage. The biggest performance changer is simply how users decide to trim their text. Trimming based on string length isn't ideal as it can leave half lines and more extra text than necessary. Keeping a line count while trimming based on maptext_height/font size seems to be ideal. | |
That's good to hear. Play with the inline styling as much as you would in a full implementation and let me know how that works out. I don't expect it to be much added overhead but I want to be sure.
We might be able to do some heuristic-based culling of text on the server. Ideally we could even account for changes in text since a lot of output will just be cuts + appends to the last output, which can be sent more efficiently. | |
And suddenly, I have the motivation to finish rewriting my HUD menus library. This feature not only makes the old setup a hundred times better, but allows for the extremely dynamic setup that I've sought since day one (which was about three years ago).
Thank you, Tom. Just. Thank you. | |
Will this be able to support links in the future?
| |
Link support should be do-able, although it does somewhat conflict with existing map click messages.
BTW, I have a new version with much improved alignment. I'll upload that tonight. I'm trying to fix an unrelated bug atm. | |
Well, I can always dream. Haha.