No new release yet this week, but I'm still waiting for some debugging results from users who've had issues with 509.1315. That was supposed to be the stable release, but some kind of issue--apparently introduced in 509.1314 even though there's no code that can explain it--has caused hangups for Windows 10 users. Those of you who've seen the problem in action, I encourage you to follow the debugging steps listed in the bug report and send me your data.
Because of the aforementioned bug, the pager still lists 508.1299 as the stable release (although I haven't switched the download page back). Once the bug is fixed, I'll be moving to 509.1316.
But while that goes on, I've begun work on 510. As I mentioned previously, 510 is going to be big on text processing as well as some visual updates. The visual stuff I've only begun to work on, which should hopefully streamline a lot of the rendering code that has gotten a little too complex. Some of the work in that department includes figuring out how to handle some weird cases: like for example what should happen if a plane master atom responds to client.color but one of its children doesn't, or what happens if the child of a group master atom has RESET_TRANSFORM or RESET_COLOR set.
To clarify those two new terms, I think that 510 should have the concept of a "plane master"--which collects all atoms in its plane and draws them onto a temporary surface, than uses its own transform, color, and blend_mode to draw on the map--and a "group master". A group master would be useful for situations like when you have a mob with a lot of overlays, and you want the whole mob to fade out by changing its alpha; then the atom and its overlays are treated as a single group, and render to a temporary surface just like a plane master does.
So the exception cases I listed are some of the things I have to puzzle out, but the rendering code should, I think, be simplified and also much more powerful once I do.
The text processing stuff for 510 already has some code put together, and I've added some new routines I hadn't discussed previously: json_encode() and json_decode(). These powerful routines will allow for much better communication with the webclient, and should also be beneficial for games like Space Station 13 that already use quite a lot of JSON in their interfaces. The json_encode() routine can turn associative lists into object literals, regular lists into arrays, and can handle other values intelligently. json_decode() will create lists or associative lists as needed.
I'm extremely pleased to say that regular expressions also look like they're going to be viable in 510. I have yet to come up with a scheme for handling those internally, but what I expect is that they'll end up being a special object type much like /matrix is.
On the webclient front, I'm looking into a couple of ongoing things like improving FPS, and also a nasty hangup bug that appears to impact a very small minority of games. Some controls like the info control can probably be given much better support for tab styles now, so that's a thing on my to-do list.
Naturally it'll take a bit to pull 510 together, but with all the new features it's going to be a big-impact release when it's ready. But while you're waiting for the new stuff, it's time to start making games with 509! Now that it's December, I say we need some fun little winter-themed games. Throw some cool stuff together and shoot me some screenshots--and while you're at it, send them to Higoten too for the next Within BYOND post.
As always, thanks to those who have become BYOND Members or have donated. You're the lifeblood of this operation.
ID:1992788
 Dec 4 2015, 3:47 pm
|
|
I cannot wait for the plane master atom stuff.
On a different note though, do you think we could get some alpha masking blend modes? Maybe this could work with your group blending stuff. | |
The plane master stuff will probably handle that, but I'd have to figure out what combination of effects would do it.
| |
D4RK3 54B3R wrote:
do you think we could get some alpha masking blend modes? Maybe this could work with your group blending stuff. THE WORDS. WHAT DO THEY MEEEEAN Please give diagrams of things possible with this ty. | |
json_encode() and json_decode() I've been putting off writing the bit of StdLib that does exactly this. Thanks Lummox. | |
Really looking forward to the group master.
| |
Will json_encode/decode only work on DM lists?
| |
It won't do datums/objs except to convert them to names, if that's what you mean.
| |
Lummox JR wrote:
It won't do datums/objs except to convert them to names, if that's what you mean. Don't you think that'll be kind of odd behavior? Won't be able to serialize objects, unless you json_encode(datum.vars), I guess. How will the recursion work for json_encode? Will there be a limit as to how deep your list structure can go? | |
I haven't specified a limit yet (I may), except that a list that contains itself will output null in place of itself in the recursed form.
The problem with serializing objs (well, one of them) is that to deserialize them, you need to know exactly what type to expect. Also I expect in a lot of situations, people won't want objs within a list to be serialized; they'll often just want names. Other problems fall into the realm of the kinds of things that savefiles have to do: flattening icons, storing icons as file info, etc. | |
Any chance of a (some kind of) datum/proc/json_write() and datum/proc/json_read(), so that one could override the default behavior of serialization/deserialization in the same regard that one would override the default behavior when writing to/reading from a savefile?
| |
Well the write override would be feasible, although it isn't on the map for 510. (If I did it I'd call it WriteJson(), for consistency.) Reading however wouldn't be feasible because it would first have to know it was dealing with a specific type of datum. The read process is as serial as it gets; the only way I could force a type to be applied would be to hijack a specific value as a reserved word to use as the type (I wouldn't want it to be just "type"), and then after the list is populated, use that to apply all the vars. It'd be an ugly solution.
| |
I reckon that a lack of read wouldn't be so bad- ideally, one wouldn't use json for serialization of their game objects with the expectation of getting them back in their original format later-- there's too many ways to break that to work reliably.
| |
json_encode? Oh man - awesome!
| |
Interesting!
| |
Lummox JR wrote:
Also I expect in a lot of situations, people won't want objs within a list to be serialized; they'll often just want names. The \ref/tag might be more useful. Though if someone is mad enough to try and pass a datum into json_encode(), why not go ahead and print it as an object?
{ "__dmType": "/obj", "name": "obj", "ref": "[...]" }
Do you have any tricks in mind for encoding paths, or will they just have to deserialize into strings? What about +/- Infinity and NaN? | |
Does freeze tag count as winter?
I'm so making a freezetag remake.