2011 – Brian Turner

Posted on 2011-06-122011-06-23 by Brian — Leave a comment

Why Math?

When I was in high school I took a class most students take. It was a trigonometry class. Most of my classmates had a frequent recurring question, “Why do we need to know this?” The teacher wasn’t very helpful with giving an answer. So I took it upon myself to come up with one. Being a youth myself it proved a difficult task. What I came up with were two rather unsatisfying answers. The first answer was simply, “for the test.” My other answer looked a little further into the future and was, “for next year’s class.” Little did I know that I would continue using it for years to come.

Most recently I used trig in programming the camera movement for Windom. There were two rules for it’s motion. One, the camera should move in a parabolic shape vertically, close to the character when low and high and far from the character when in the middle heights. And two, it should move in a circle horizontally around the character. Those of you who know your trig should already see how it will come into play.

I was working from a drawing of what the motion should be. But what I needed was a function which defines the distance from the character. So as a starting point, I decided to find the function which defines the drawing. Here’s a visual.

Here’s what I knew. The line of symmetry goes through the top of the character, there is a point on the parabola at the character’s feet and one above the character. The function which defines this is h(sqrt(-x/m)+1) where h is the height of the character and m is the furthest distance modifier. It turns out this function isn’t very useful. It gives a height when provided with the distance from the character. I wanted a distance from the character provided with the height. Easy, just take the inverse. The result with some simplification is hm(1-x^2). That is what defines the distance which the camera should be from the character given the height of the camera.

The rest is comparatively easy. I know the rotational point where the camera should be in radians. It is just a matter of using trig to convert to x and z coordinates. I went with x=d*sin(r) and z=d*cos(r) where d is the distance provided by the the function in the previous paragraph and r is the rotational position in radians.

If I didn’t know trig the circular motion part would have been immensely more difficult. When I was in high school I never expected to need trig for very much but now I have more appreciation for it.

Posted on 2011-06-02 by Brian — Leave a comment

Apple Sales Tax

There has been much talk lately over Apple’s recent changes to its app store guidelines. It seems apps aren’t making much profit from ebook sales. You see, anytime an app on iOS makes an ebook sale, 30% of the sale goes to Apple.

When I first heard about the rules I thought they seemed a little odd. I tried to think of an equivalent rule with brick and mortar stores. It took a long time, but finally I found something. It’s not quite the same, but it is quite similar. What I came up with is sales tax.

As with any fees, businesses have a choice to make. Are the fees passed on to customers or absorbed into costs? I can’t imagine ebook retailers having large margins. Passing fees onto customers is a risky option.

However, that’s not the main problem. The ebook retailers have a competitor who is unaffected by these fees, Apple. Apple runs its own ebook store in iBooks. But how does a company apply a fee to itself? This gives the iBooks store an unfair advantage over all other ebook retailers. This would be like the state tax department running a competitive retail store. To me that doesn’t seem fair. But then again, I’m not a retailer and don’t run a business selling ebooks.

Posted on 2011-03-272011-03-27 by Brian — Leave a comment

Javascript Controlled SVG Part 2

I have already covered utility functions and GUI code, but most of the code is for calculations of color data. This post will explain how all of the code ties together.

When the user first loads the color picker the default state is loaded. All values are zero and correspondingly the color is black. RGB (0,0,0) is black and HSV (0°,0,0) is black.

All event handlers do basically the same thing. First the master color color data is updated to reflect the changes made by the user. Next the RGB, HSV, and hex code are updated to reflect the color data. If the user is changing RGB values, those copied to the color date and used to calculate HSV and hex code. If the user is changing HSV values, those copied to the color date and used to calculate RGB and hex code.

All event handlers ultimately call the update function. This in-turn updates the handle locations, background gradients, and preview area. each is separated into its own function.

The updateHandles function uses the color data to update the locations of the sliders. Let’s go over one group in the function.

var redHandle = max - colorData.red / 255 * 199;
document.getElementById("redHandle").setAttribute("y",redHandle);
document.getElementById("redLabel").firstChild.nodeValue = Math.round(colorData.red);

The first line is responsible for calculating the top side of the red value slider handle. Yes, I know it has magic numbers. if you read my earlier posts you would know this is more like a proof of concept than a finished product. magic numbers never make it into my finished works. 255 is the maximum value for red, 199 is for the size of the slider. Looking at it now, 199 could be replaced with (max - min). The second line moves the handle to the new position. The third updates the value displayed below the slider. These three lines are repeated for every slider with different constants.

The background of each slider shows the resulting color of moving that particular slider. These gradients need updated every time the color data changes. doing so is as easy as calculating color data as if the slider is set to each end. The hue background is slightly different. It has one gradient with all the hues represented and two overlays. one overlay is completely white representing the saturation. the other is black representing the value. The opacity of each overlay is adjusted according to the current location of the corresponding slider.

The preview is easier to compute than any topic discussed so far. Using the RGB color data, the hex code is calculated. Each color is converted using the deciToHexDigits function to ensure placement of zeros. The resulting string is then shown to the user and applied as the fill of the preview area.