As you know, the upcoming version 510 is a feature extravaganza. It's actually a huge release in terms of new content and potential for games, so there's a lot on the to-do list. That list has been clearing out gradually, and I'm really in the thick of things now with the new visual changes. I'm almost at the point where I can work on the rendering end of the new KEEP_TOGETHER and PLANE_MASTER features, at which point I expect I'll be tearing my hair out for a few days. (Hence the title of this post. Just as my car is buried under a couple inches of snow, I'm working through the deepest parts of the atom grouping stuff right now.)
One of the tasks I had on my list--an important one--was getting a lot of the new additions documented. Some of them are not yet, like the aforementioned flags and also list.Join and savefile.Flush (which both need to be tested). But I've added reference entries for all the new text procs and for regular expressions.
While I was at it, I decided to divert--as a mental distraction from slogging through the atom grouping stuff--some attention to the reference's appearance. I thought the web reference can be spruced up a bit to replace those awful [-] and [+] expansion links with graphics, and that it'd be nice if instead of showing the entire reference in the right frame, if only the currently selected article showed up, just as it does when viewed in Dream Maker. And in both, it occurred to me that DM syntax highlighting would be fairly awesome, and I happened to have a JavaScript DM syntax highlighter I was working on. So the reference for 510 will have syntax highlighting, and I plan to make the JavaScript code public so anyone can reuse it.
Last week I mentioned being on the fence about whether replacetext() and replacetextEx() would be needed. I'm on the fence no longer; they're in, and documented. When a regular expression is not in play, they'll work as a replace-all--because there's really no good way to say "replace once". I might be persuaded to add another argument for a single replacement, but I suspect that's not important. Whether you're using a regular expression or not, a proc can be used as the replacement value.
For the atom grouping stuff, as I mentioned there's a bit of a slog factor. It's not easy, the change I'm making, because so much of the code is built around the concept of icons being individual, not so much grouped. But that being said, I'm making steady progress. However, I think it's unlikely that this feature will make the cut for the webclient in the early beta versions; that's because I want to get this out in beta as soon as possible, so cutting-edge users (I'm looking at you, Bravo1) can do awesome things with it and I can get feedback right away. On the bright side, some of the concepts I'll need--like icons that are parents to other icons--are somewhat easier to manage in Dart, so while there's a slog factor even for the webclient I know I'll get there.
There are a few bug reports (and a couple of features) on my short list, and I'd like to assure everyone that I do plan to get to the ones I've taken notice of, but I'm putting special effort into 510 to get it ready sooner. I'll probably try to knock out a few webclient bug reports next week, though, and I'm sure some of the items on my list will get attention during the 510 series rather than first thing. (One of the minor features I want to get to before release, though, is for a tick completion percentage var that might help certain proceSSor-1ntensive gam3s manage their big-impact operations better. Some of them are doing this now with a helper .dll, but there's been some call to make this native functionality so I'm looking into it.)
A couple of little web things are on my list too: nothing major so they probably won't get attention in the super-near term, but they are on the List. (And the List is an actual text document I have to help me keep organized.)
With all this winter weather going on, let's see some winter-themed games! Or heck, you could build a bit of winter into an RPG for flavor. And get ready building some assets for lighting, like circles that start out white in the middle and fade out to black, because 510 is coming.
ID:2018832
![]() Jan 15 2016, 2:18 pm
|
|
![]() Jan 15 2016, 5:22 pm
|
|
*coughs loudly* (Keep in mind I made this like ten years ago and never bothered to update it further because a certain Tom changed his mind about using it)
|
Yut Put wrote:
is there a post explaining more about what atom grouping is and how it changes things? There isn't a comprehensive post on it, but basically the gist is that when an atom has KEEP_TOGETHER in its appearance_flags, it and its overlays/underlays will be drawn as one. That means any alpha applied to the atom will be applied to the combined image rather than to each icon individually. The PLANE_MASTER flag will mark an atom as being in charge of its whole plane. (HUD objects would be in a different plane from a non-HUD object.) With it you can, for instance, give all your light sources a lighting overlay in plane 2 with blend_mode=BLEND_ADD, and your plane master for plane 2 could have blend_mode=BLEND_MULTIPLY. All the objects on the plane get drawn together, and then they're blended according to the rules set by the master object. |
With KEEP_TOGETHER no, because the flag is only meant to keep the parent object with its overlays. (Or, an overlay with its sub-overlays.) It doesn't work across multiple objects.
With the PLANE_MASTER thing you could do that, but only if the objects are all on a different plane from the other stuff you don't want to hide. That's unlikely to be very useful for most games. Also hiding in that way would be nothing like proper invisibility. |
I'm not sure what this enables that grouping objects in a list doesn't. its sounding like its just a much more efficient way of turning all the turfs in a world blue This allows post-processing-like effects, such as making an entire atom uniformly transparent rather than each overlay being partially transparent. It also allows stuff like dynamic lighting that doesn't use an object per turf by building a separate renderpass, using additive blending during the pass, but then when the entire master atom is drawn, multiplying it into the final render to create an effect like this: ![]() Effectively, this can be used to create masked effects that would otherwise be impossible to produce at the moment. This will give you a ton more milage on what visual effects you can do without calculating them manually on the server. |
Maximus_Alex2003 wrote:
Nadrew, I'm aware, and I have no plans to remedy the problem anytime soon. |
I was trying to get more testing done on the lighting effects until I read this post.
The hype is real. I'll definitely have to try abusing KEEP_TOGETHER. |
webclient full screen is one thing I'm reeaally looking forward to... for the mobile gaming possibilities.
|
So I heard that BLEND_MULTIPLY doesn't work in software mode, and I understand why, but, can we PLEASE get some way of detecting what a user is running the game in? Some call when they change it?
What if I make a stealth game that uses BLEND_MULTIPLY for the lighting, and people with software mode can simply see everything? What can I as a game designer possibly do to prevent that without butchering my game? |
Temporary stopgap: Control Freak on, and then you can winget whether they are in hardware or software mode, manually switch them to hardware mode, then check if they are still in software mode and boot them. But yeah, more exposure to some of the stuff the client does using onAction callbacks similar to the onResize or onClose verb callbacks would be great.
onMove, onFocus, and onRenderMode would be pretty great tools to have for controlling the response. Now that we can call purely clientside winfoo, Tom's reason for rejecting those requests (serverside overhead) are gone. |
I believe there happens to be a feature request for that. :)
|
Rushnut wrote:
What if I make a stealth game that uses BLEND_MULTIPLY for the lighting, and people with software mode can simply see everything? What can I as a game designer possibly do to prevent that without butchering my game? BLEND_MULTIPLY lighting, at least in the form implemented for Baystation12 (SS13), results in featureless pale squares in software mode, it's certainly not a way to "see everything". |
GinjaNinja32 wrote:
Rushnut wrote: Rushnut means that if BLEND_MULTIPLY isn't available because of software mode, effects intended to hide things wouldn't appear and therefore players in software mode would have an advantage. Although there is an interesting way around this. Because multiplication is commutative, you could draw all your lighting first by putting it all on a negative plane, create a plane master for plane 0 with BLEND_MULTIPLY, and then in software mode all the user would see is the lighting but not the objects. |