Development news: short and sweet

ID:1898181
 
Jul 17 2015, 5:10 pm
The webclient DSification continues. After a ridiculous amount of trouble, I got screen objects working. Now flicks are working too. Animations use flags to determine which parts of the appearance shouldn't change. (They weren't before, but now they're in sync with DS with the possible exception of pixel animations on movables, which I need to test. And transitions need more testing too.) Verbs now work properly with the new setup as well; I really, really want to find a better way to handle verb updates that doesn't involve offloading the parser onto the client, but that's something I can handle later.

Images, view, and missiles are the big targets next. Integrating the view code is non-trivial, but I'm ahead of the game on that by having ported the main engine's view code into Dart; it's just a matter of hooking it up. Missiles I expect not to be too bad; they're basically just temporary appearances with position info, so they should drop in without a lot of trouble now that the flick issues are settled. For the webclient's purposes, I plan to give missiles a temporary atom ID that I'll have to mark as invalid (counting as null) for mouse routines.

Astute viewers of the bug forums will note there's a bug with mouse hits in 508.1293. As a result I plan to do a DS-only release to correct that; I'm expecting to get that up as 508.1294 tomorrow. (That's right, a weekend release!)

Not much news on other fronts at the moment with so many plates spinning, but I haven't forgotten about them. A very minor hub update is coming, and I still want to get in the ban changes to help out big games like SS13--which I may have to do early next week to make sure nothing is badly broken, though I really hate to pull off the webclient when I'm on a roll. I've also been planning ahead with a list of features I want for 509, to the point where there's an actual to-do list there now.

This is what my 509 wish list looks like right now:
  • appearance.plane (effectively deprecates stuff like BACKGROUND_LAYER)
  • Expansion of atom.color to use optional color matrices (note: I'm not expanding the matrix datum to 5D, because that's crazy)
  • Floating point glide_size and gliding offsets
  • Color/alpha/transform reset flags (need an appropriate var name and syntax)
  • Cardinal (non-Euclidian) glide flag, so diagonal or odd-angled glides take no longer than cardinal-direction glides
  • Linear matrix interpolation easing flag (or separate animate() flag?)

The reason those are put off till 509 is because they involve either new vars or message format changes, which always requires a new major version.
Jul 17 2015, 6:46 pm
You're doing a great job for a one-man army, Lummox. The webclient just might be the future at your hands.
Jul 17 2015, 8:51 pm
Were you able to get in contact with N3X15?
Jul 17 2015, 9:14 pm
Lummox JR wrote:
Expansion of atom.color to use optional color matrices (note: I'm not expanding the matrix datum to 5D, because that's crazy)

Could you explain what this would entail exactly?
Jul 17 2015, 9:24 pm
http://docs.rainmeter.net/tips/colormatrix-guide

@Lummox: Can we get a client color matrix as well so we can apply color operations to the client's entire viewport? It'd be sweet to be able to apply effects to the screen on damage or death.
Jul 17 2015, 10:48 pm
In response to Ter13
Ter13 wrote:
http://docs.rainmeter.net/tips/colormatrix-guide

@Lummox: Can we get a client color matrix as well so we can apply color operations to the client's entire viewport? It'd be sweet to be able to apply effects to the screen on damage or death.

++
Jul 18 2015, 12:34 am
Hrm, rats. I was thinking all along a color matrix should be trivial to implement, but apparently only the webclient could support this. Sprite drawing only modulates color; it doesn't support a matrix as far as I can see. Doh! Might have to wait on that one. That's a shame, because I can imagine so many ways for that to be awesome.

A post-processing filter operation to modulate the entire color would probably require shader programming, which I don't really know anything about.
Jul 18 2015, 1:30 am
Man, being able to apply shaders at least to the client viewport would be so cool.
Jul 18 2015, 1:39 pm
Screen blurring has always been a faint dream to me. Any chance the webclient could support blurring someday?
Jul 18 2015, 5:01 pm
Does this mean isometric will be fixed for the webclient next update?
Jul 18 2015, 5:07 pm
Before I release the DSified webclient I'll test isometric in it for sure.

Kumorii: I'm certain blurring can be done in the webclient right now. I believe all you need to do is apply an SVG filter to the map div's styles, or else you can do that on a div that's on top of the map.
Jul 19 2015, 9:05 am
wolololo expose the ability to load shaders!
Jul 19 2015, 4:20 pm
Looks like the only way to do color matrices would be a shader. Grr. I think that'll have to miss 509 after all. If anyone has good shader tutorial links I'm happy to take a look, but my Googling the last few days has been fairly fruitless.
Jul 19 2015, 4:28 pm
Shaders basically require abandoning PlgBlt(), Lummox. You need to start rendering using Vertices rather than Blitting.

Direct Blitting to surfaces has been deprecated for a long, long time except as a means of working with texture buffers.
Jul 19 2015, 4:38 pm
Well for shaders I'm only talking DirectX anyway; I don't use PlgBlt() outside of the software mode.

Mainly I've been trying to find easily digestible material out there on how to create a basic shader and use it, and how the process works, but a lot of tutorials are defunct and lots of others are either too basic or try to spend the whole time teaching HLSL. It's frustrating to try to figure this stuff out without a good guide.
Jul 19 2015, 5:06 pm
Are you currently using vbos?
Jul 19 2015, 10:07 pm
Well VBOs are an OpenGL feature, not DirectX. In DirectX all we're really using is a sprite blitter. (And now, a temporary render target for the upscaling.)