Dec 9 2011, 6:50 pm
|
|
Tom
 |
Is that an issue with maptext, or just with movement? Try the same settings but on objects with no maptext. I think the problem is just with the use of bounds_ here. I'm switching to a separate system.
|
Changing any bound to a number that isn't a multiple of world.icon_size forces the entire game into pixel movement mode, where you'll jump between tiles.
| |
Aside from the bugs reported, I found a pretty significant issue with using the new client to connect to old games. Since this build is mostly useless, I've removed it, and will put up a new one once I have this stuff patched up.
| |
Yeah, that build seems to have a sliding bug with map text. It's a good thing you posted here and not in the forums Tom.
Otherwise, it would've turned into a huge disaster. | |
Ok, new build at http://www.byond.com/download/build/BETA
Use the new atom.maptext_width & atom.maptext_height vars to control placement. | |
Working much better, going to test some more and I'll get back to you. The onscreen chat system I had going is working awesome now.
| |
Very nice. Definitely works now. :D
Edit: There seems to be a slight bug with maptext updating. When you change the maptext variable, it doesn't affect the currently displayed text until the object moves. Other than that though, works well so far. | |
Okay, some testing done. Everything appears to be drawing properly and moving around properly. There's a couple of minor things.
The font color 'black' is not supported. When setting maptext to an empty value the text doesn't vanish until the atom moves. [Edit: Just saw Bandock posted the same thing.] | |
Nadrew wrote:
Okay, some testing done. Everything appears to be drawing properly and moving around properly. There's a couple of minor things. Yeah, it appears to only update when an atom moves. I know because I was updating maptext through a procedure test and didn't show any updating till any movement. | |
Yeah, it only updates without moving if there was no text previously.
| |
Ok, I'll try to fix those bugs right now.
| |
How does this compare to the soft-coded solutions? Worth keeping?
| |
It's definitely quite a bit faster than the soft-coded solutions, and easier to work with.
Of course the limits to how you can stylize the text and keep track of how much space is being used hurt it pretty badly for any usage outside of basic stuff. It's worth keeping, it makes basic casual games and little stuff like displaying someone's name over their mob a WHOLE lot easier. It's a pain in the butt having to refine a whole screen-text library to draw someone's score on the screen without doing each part manually. This makes that stuff much more viable. Make it more extensible as far as stylizing and perhaps font-face support of some kind and I'll hump your leg and call you Tommy. | |
This feature is working very good so far Tom. I think it is worth keeping.
I'll make sure to implement support for it in my library (possibly allowing for a dual-mode feature since it also supports for icon-based fonts). In fact, I'm going try to at least partially implement it right now. | |
Ok, new build 1120 is up at http://www.byond.com/download/build/BETA
* maptext changes weren't updating until movement * black font wasn't supported | |
Updated build works like a charm. I'll let ya know if there is anymore bugs to be found.
| |
From what I've tested this seems to be quite fast, there was little to no CPU usage and I noticed measurable drop in server to client traffic over a network. It's much faster than conventional methods of displaying screen text using objects and images.
It's also incredibly easy to set up. I can see this becoming another noob-friendly feature like the native pixel movement, a simple alternative to the more complicated methods the rest of us are used to. That being said, it's not without faults. For practical use it could use a little expanding. Not having inline formatting is an inconvenience but it's not a deal-breaker. One important feature I think this needs is a way to deal with text overflow; it needs a way to trim the top line of text in order to make room for new text. As far as I can tell there's no real way parse for a line on its own since the line breaks are automatic. Parsing for \n could end up snipping multiple lines at a time. In order function as a base level chat output I think it needs at least this feature. | |
Good to hear it.
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 think there are always going to be issues like this as long as the dev doesn't have a way of knowing the true maptext_height, but unfortunately (as I noted below), that's a hard problem. | |
Any chance of CSS3 support in the future? Just curious. I could remove a lot of code and resources and live a lot better if outlines and glow effects were supported. :)
| |
I imagine CSS3-type support would be damn-near impossible with this system lol.
| |