nice job keep up with the good work

There you go getting me all excited and whatnot again!

I really want it for 510. What I'm trying to figure out is what kind of syntax I'll be looking at for the master plane object.

There were a couple isometric games being made, but I think they all got cancelled. I'm pretty sure there are no isometric games released, ever, aside from more or less test of concept stuff.

I've been hoping to change this in the not too distant future, if I get time, but I suspect it may be a challenge. Otherwise I would think more people would make isometric.

Lummox JR wrote:

I really want it for 510. What I'm trying to figure out is what kind of syntax I'll be looking at for the master plane object.

How about a /planeEffects datum that holds all of the attributes you mentioned above. And then getter and setter functions under /client for these things?

To be frank, I don't see much point of making this an atom.

I'm afraid that's not quite how it works, whilst I fully expect Lummox JR to be an incredible DM guru, I doubt he's better than a few other faces. Mostly because he doesn't have time to play around, though I do believe his game - http://www.byond.com/games/LummoxJR/SotS2 - is supposed to showcase the engine's capabilities (Don't quote me on that!) it hasn't been updated in a while.

Lummox might be great at making hammers and chisels, but he isn't a master sculptor, so to speak.

The matrix given as an example in MapColors() (although that's as args, rather than a list) is a good example. Apply that to client/color and you have a nice nighttime moonlight effect.


In this simplified RGB-only form (which leaves out an alpha column and row), every three values represents a row in the matrix. The first row is what color the red component will become; the next is what green becomes; the last is what blue becomes. All of the result color values get added together.

In this matrix, full red rgb(255,0,0) becomes rgb(255*0.2,255*0.05,255*0.05). It's darkened a lot, and a little bit of blue and green are added to pull it closer to gray. Blue goes through something similar, except it isn't darkened nearly as much. Green does the same, but a little more blue is added so it experiences a hue shift. As a result of this, yellow rgb(255,255,0) becomes rgb(255*0.2+255*0.1+0*0.1, 255*0.05+255*0.3+0*0.1, 255*0.05+255*0.2+0*0.4), or rgb(77,89,64), a very dark and desaturated yellow-green.

Here are some real examples from SotS II.

In the original game code, I had a lot of icons that were shades of dark gray. The wall icons for instance were mostly dark colors, and they were colorized like so:


In this way, any white in the original icon stays white, and black becomes the color. 509's matrix support let me change this by simply applying a color to the wall instead of changing its whole icon:


That's the full format that uses an alpha column and an alpha row. The first row is what red becomes, which is the inverse of the red color I actually want. Green and blue get the same treatment. The last row is the constant row that gets added to everything, so that's what I expect to see when the original color is black. I actually built this into a proc so that it's a little easier to work with.


This is basically using a "cheat" to let the internal matrix parsing do most of the work for me, avoiding the need to parse the RGB() values of a color string and divide by 255. First I create a new color matrix on a temporary image. The first row is set so that red becomes yellow, so that the result will always be a matrix. (If the target color c is black, that wouldn't have been guaranteed.) The green, blue, and alpha rows are left as the defaults, and the constant row is c, the target color. I then grab the matrix into a list, make adjustments, and send that list back as the result.

This matrix is very similar to a typical inverse matrix:


In SotS II, I don't actually use that WhiteMatrix() proc very often. I use a more complex matrix, where I can add blue pixels to the walls that will become black, for cracks and (for effects) outlines.

Here's another matrix I use, when I want to have one icon become a colored version that has highlights. I've often stated my fondness for this sort of thing, which I did in Incursion a lot:


Unfortunately this technique either requires two icons, or it at least requires the color and highlight parts to be separate states in the same icon. A different approach is to combine them, using the red component for your target color and the green for highlights. That would have looked like this before 509:


But in 509, you don't need to do any icon math. You can simply set the atom's color to list(c,"#fff","#000") instead, and all the highlights are created.

Kumorii wrote:

Man, I really need to spend some time wrapping my head around matrices. I should've known skipping math classes would bite me in the ass one day.

Seriously. I'm kicking myself in the ass for sleeping through 11th grade math...

Matrices are not, in principle, a very difficult concept. The simple case of a function in n variables is a good illustrating example. That is, say you have a function f(x) = a₁ x₁ + ... + a_n x_n, where x is a vector with x = <x₁, ..., x_n>.

Then you can rewrite this as a product of two matrices as

                         [ x1 ]
                         [  .  ]
 f(x) = [ a1  ... an ] . [  .  ]
                         [  .  ]
                         [ xn ]

In this case, matrix multiplication is essentially simply the application of coefficients to another vector. More specifically, when you have a row vector and a column vector, your result is a 1x1 matrix (mathematically, you would say it's isomorphic to an element of your field—but a simpler way of stating it is that it becomes something that acts 'the same' as a function or a number).

That is, the row vector tells the column vector how to change. If you want to make, say, x₃ twice as big and x₉ a third as big, then you set a₃ = 2 and a₉ = ⅓.

Likewise, if you have a left-hand side matrix with, say, three rows, you get

                [ x1 ]
  [ a1 ... an ] [  .  ]   [ a1 x1 ... an xn ]
  [ b1 ... bn ] [  .  ] = [ b1 x1 ... bn xn ]
  [ c1 ... cn ] [  .  ]   [ c1 x1 ... cn xn ]
                [ xn ]

Now, you have something similar to above, but instead it's saying that your result is a vector in three dimensions instead of one, and the row vector <a₁, ..., a_n> wants the output to behave in one way in the first dimension, the row vector <b₁, ..., b_n> tells it to behave another way in the second dimension, and <c₁, ..., c_n> tells it to behave a third way in the third dimension.

This is related to an extremely important result of linear algebra, which says that if you have a transformation T with certain restrictions (specifically, that T(a x + b y) = a T(x) + b T(y) for all a, b in the base field and all x, y in your vector space, so that T is what is called a linear transformation), then once you have chosen what is called a basis, you can represent the linear transformation as a matrix acting on that basis.

An example of how useful these techniques are can be see here, where I was able to build up a new function from an initial function C'(t) = <sin(t), -½ cos(t) + ½> by knowing the necessary transformations—that all you had to do was squish the function down, stretch it out, and rotate it.

As another example, imagine you have a function f(x) = 3x³ + x² that describes the motion of a particle in your game, and you like how it looks but you'd like to be able to change it on the fly a bit (maybe stretch it out, or squish it, or flip it around). There are a couple ways to do this, but matrices are one of them. This may be confusing at first if you've been paying attention, as f is clearly not a linear function of x: f(2x) = 24x³ + 4x² ≠ 6x³ + 2x² = 2 f(x). The difference is, you view it in another way, as a function g(a, b) = a x³ + b x² at the point (3, 1). Why does this make sense? We want to keep the general shape of f, but that is dictated by x³ and x², not by its coefficients which indicate the 'scale' or the function, or more like its specific appearance.

Thus, we can treat g as a two dimension function where a is its first-dimensional component (influencing the x³ term) and b its second-dimensional component (influencing its x² term). What if we want to flip it around in the x² component and make it half as big, and make the x³ component four times larger? The suitable matrix for this is

  T = [4  0]
      [0 -½]

and then we have the result given by T(<a, b>)as,

  T(<a, b>)

  = [4  0] [ a ]
    [0 -½] [ b ]

  = [  4a ]
    [ -½b ]

Using the linearity of g, then we have g(T(<a, b>)) = g(4a, -½b) = 4a x³ - ½ b x², and recalling that we were at the point (3, 1) our final result for our transformed function f* is then: f*(x) = 12x³ - ½x².

Exentriks Gaming wrote:

I just have a couple questions:
So with this you would turn an icon completely white? Was this not possible before by just doing src.color = rgb(255,255,255)?

Also, in your example what is "c", and why are you passing it to the proc?

My WhiteMatrix() proc, which returns a color matrix, is not designed to make an icon white. If you wanted to make an icon completely white, all you'd need is this:


That matrix will specifically alter only the rgb, but the alpha will be left alone.

WhiteMatrix() on the other hand was designed so that the range black -> white would become c -> white instead, where c is the color I want the wall icon to be. Since my wall icon is mostly dark shades of gray with a crayon-drawn look to it, it looks like I took a c-colored crayon and drew on a white background.

What is happening with the matrix exactly, what is L[ 1] = 1-L[17] doing and what would be the result of that subtraction?

Let's go through the proc line by line. First, let's say the target color I want the wall to be is purple, "#8000FF" (which is the result of rgb(128,0,255)). That's the value of c that's being passed in.

First, I create a new image and assign it a color matrix of list("#ff0",null,null,null,c). This is the matrix that results:


The first row (red) got the yellow value; basically, I forced L[2] to be something other than 0 because this way I.color is definitely a matrix. The green, blue, and alpha rows are the defaults which means those color components will be left alone. The constant row has my purple color, which is added to the result.

Now the proc changes L[2] to 0, since the only purpose in setting it was just to force a matrix.


At this point the matrix is equivalent to taking the original color and adding purple.

Next, I want to change what the red, green, and blue rows will do. I want the red in the original icon to add whatever's missing to make white from a base color of purple, so that'd be 1-128/255. Likewise for green, and blue.


And that's my finished matrix.

Now, if I set a wall to use this color, it's basically the same as saying rgb * (white-purple) + purple. The black parts become purple. The white parts become (white-purple)+purple which is just white. And any shade in between is somewhere between purple and white.

edit: Also a big question that I have is: Would it be possible to use this color matrix to have a multi colored client.screen?

I don't follow. The client.color value is basically map-wide, if that's what you mean.