How do you think this will end?

I just submitted this question to Rhapsody customer support:

"Long ago, I had an account set up with Musicmatch, using the Musicmatch

desktop application. I purchased quite a few songs for that account, but then I forgot about it for three or four years.

Since Musicmatch was acquired by Yahoo and subsequently Rhapsody, I am afraid my account, and the songs I purchased, have been lost in the shuffle.

I believe the username I was using for the Musicmatch desktop application was "getimoliver".

However, I can't log into Rhapsody using this username. I have also tried using the "forgot your password" link.

Would it be possible to retrieve my old account, or at least the songs I purchased on it? I am able to provide the credit card number I used to purchase the songs, my full name and address, and my old login information.

Thank you!"

I'm not getting my hopes up. Will post the response I receive.

Question Reference #100615-004308

Japanese Bowling

The way Japanese people will hold a conversation with each other is very different from the way most Westerners converse. In Japan, a conversation is like a game of bowling. The most respected of the group will bring up a topic, and mention something about it. Then, the next person in line will take a swing at the same subject. Just like we take turns in bowling and do not directly compete.

Western conversation, however, is more akin to a game of tennis. One person will direct the conversation either at one person in particular hoping to elicit a response, or will throw a topic out for the another person to send back.

The Japanese lead a very structured and rules-driven life. It is not surprising that they would hold conversations differently than those of the west. It is also not surprising that the XP practice of Kanban came from the Japanese. Unlike the West who loves to "cowboy code," Kanban presents a very structured and detailed way to accomplish work which (no surprise) works better than the ways of the cowboy.

I think we should consider adopting the Japanese way of conversing for some situations.

I was in a meeting today with another part of our company, discussing integration points. I brought up a very simple question: how detailed do we want an invoice? It took literally 30 minutes to get this question answered. I threw the ball out there to be returned, but instead of it being returned to me it was stolen by my project manager, who went on to play his own game of tennis with other people in the meeting. It was only after no one was playing at all that I had a chance to ask my question again, and stay involved enough to get an answer.

When I go to a meeting I come with a set of a few simple questions that I would like to get answered. Once they are answered, I have no problem casually tossing the ball around to get a better idea of general topics. When I wanted the answers, though, I could not concentrate on what was being said. Instead, I was seeing when I could get the ball back in my possession. There has to be a better way to do meetings.

The military is another place we can see structure. Rank is strictly enforced, but all are given a chance to speak, albeit with respect and with a staunch time limit. The military must be trained to focus and move as a single unit. If they do not, they will fail in their tasks, or at least be much less effective.

Therefore, instead, we try the structured Japanese way of conversing. We all sit in a circle. The highest ranking member brings up a topic, and we all comment on it in turn until there is nothing more to be said about the topic. A time limit of a minute or so is placed on each person. Then the next person in line repeats the process. We do not ping-pong the ball back and forth between two or three people in a meeting of six. Everyone is given equal opportunity to speak, and no one leaves feeling they have unanswered questions. We increase focus and effectiveness.

You may recognize this meeting schedule; It is a derivative of the standup meeting.

Now the only problem is getting people to try it...

Coder Journey

Listening to a random Reddit-linked YouTube clip of a man carving a Big Daddy Alpha Series out of wood. There is a Bioshock medley playing in the background... and it has some grand violin flourishes. You know the ones -- the lone violin reaches some high note while the rest of the strings do that background noise thing they do.

There is one point near the end of the clip when one of those flourishes occurs and it sends shivers through me. This happens to me with this style of violin, and I get a really sad feeling. I decided to meditate over that feeling and ended up having a small journey.

It started out at the base of a hill. There was a small door with a huge wooden statue of the Moose over it. I went in and headed down the red-carpeted steps faster than I usually do. I opened the door revealing a hilly area where the colors did not make any sense. I saw the Moose and started walking toward him but it was one of those illusions where I keep walking and get no closer. Eventually I went into a hole in the ground and slid down into an area that looked like Rapture. There was only one room with a glass wall to the ocean outside. I saw the Moose floating there, and I put my hand on the glass. He put his hand there in return and then slammed his face into the glass and screamed. I stepped back and turned around to see the room had expanded, to a kind of hall. There was an indent in the middle of the room. There was water coming down from a crack in the glass ceiling. It formed into a small stream that defied gravity and went up the small 2 steps leading into the indent. I followed it and it lead me down a tube where the floor was curved and got higher and higher until I was crawling with the water in my face, still following it down. The tube opened up some and I fell, and I saw the tube circle back into the rock that was supporting the first room. I didn't want to leave the tube, or leave Rapture, or maybe I didn't want to go into the rock. But I did, and it lead down some sharp steps. The rock was an inversion of my first meditation plateau. I followed the water to the bottom where it just vanished into nothing, and there was nowhere for me to go. I felt very sad and nervous. Then the Moose started coming down the steps, two or three of them. I got on my knees, my hand touching the floor where the water was disappearing. I saw random images at this point, one of which being a whale and the other being a guardian I had seen before. They were all fleeting. Suddenly, I appeared on a wheat or tall grass filled plain and I saw the girl I usually see when I meditate, who lives across the river. I reached out to her but the same illusion occurred where I walked but got no closer, but in reverse. I just reached and it was like her and her surroundings were pulling away. Then I was back at the bottom of the rock, and the Moose was on top of me, enveloping me and we sank into the Rock. I lost track of myself then.

I think there are two places to go when you meditate. You can expand your presence and see how far up you can go, or you can shrink your presence and see how far down you can go. The journey ended and I felt so incredibly minuscule. But I also felt like I had found something.

I think many of us are afraid to look too deeply inside. Religions seem to all play to the opposite, and go up as high as you can. We should go to both ends when we ponder that which we are trying to understand.

Automation

No nice code snippets to show this time, but hey, we have liftoff!

Caveats:

• I'm re-reading the doors every time a tile is rotated or flipped. This isn't what I had envisioned initially, but it works. The problem with my last post was, while it worked, it didn't work with the tile randomizer I envisioned. The automator relies on finding an open door on the floor somewhere and keeping that as the "potential door." The automator then shuffles through all available tiles, and when it finds one with a matching door, proceeds with flipping it and moving it around until it can be placed. If we rotate the tile in this process, we lose track of which door it was selected to fit into the potential door. Re-reading the doors after rotation also loses the original potential door, but finds a new one in it's place. Granted, this could be done with the old method too, but frankly it was easier this way. The old way also didn't work with rectangular tiles.
• Automation is not fully complete, although it is a huge step forward. There are times when I'll end up with open doors and tiles that I know will fit, but the automator has run out of iterations.

To get this far I had to take a step back from the automator I had in place, and essentially re-write it. When the manual placer placed a tile, we have a concept of a "tile position" which is the upper left corner of the tile. The automator had no such luxury. We had to decipher the tile position given only the position of the potential door and the inner position of the selected tile.

There are a few places in the code where I got screwed up with this logic, and it was hard to track down where I messed up until I started over.

My original plan is still what I ended up sticking with! I got caught up with figuring this out and threw out Orientation in favor of Direction, thinking knowing more would help me out. However, how do you determine direction? I thought it was easy, but ended up being not worth it at all.

This is also a good example of where the brain is superior to the CPU. We can look at two jigsaw pieces and see if they fit relatively easily. A jigsaw puzzle is essentially what this automator is. A CPU, though, has no such luxury. Our brains can get caught up in making a seemingly easy task understandable by a purely logical system that can only evaluate one thing at a time.

Bugs I won;t make again:

1. I assumed only one door could match a time, and only removed one door at a time when placing.
2. I tested with doors that took up all of one side, missing a bug where the vertical/horizontal displacement of a door had to be taken into account.

Rotation... Again

Down to finally matching doors, but it took a helluva effort.

I figured out how to rotate an array completely, but given a certain index in the array? This was just as difficult as figuring out how to rotate an array in the first place.

The problem was, I was looking for an easy formula I could plug-in and just go. It seems like, given an index, it should be easy-peasy to find the rotated variety. What I was forgetting, however, was that it's never that easy.

Short of rereading the door positions every time I rotate, I figured I could look up rotating a point around another point:

x' = Cos(Theta) * x - Sin(Theta) * y

y' = Sin(Theta) * x + Cos(Theta) * y

Where Theta is radians from degrees of desired rotation. This showed me, though, my biggest mistake -- it only rotates around the origin. X=0, Y=0. I had to specify the origin as the center of the array. After I came to that realization, it all fell into place:

private void rotate(Vector2 point, Vector2 origin, int degrees)

{

float radians = MathHelper.ToRadians(degrees);

Vector2 v = point - origin;

v = new Vector2((int)Math.Round((v.X * Math.Cos(radians) - v.Y * Math.Sin(radians))),

(int)Math.Round((v.X * Math.Sin(radians) + v.Y * Math.Cos(radians))));

point = v + origin;

}

That big chunk in the middle is the standard rotation formula.

Now, my doors fit as long as the orientation and positions match! Although the positions when rotated are no longer exclusively the upper-left... so I have to work in the door width for the final fitting calculations.

Victory!

The speed of the doors

A lesson I learned from Super Comrade Oriam is that as much as I hate to admit it, runtime speed is a great equalizer among games. SCO was bloated, and probably relied too heavily on it's physics simulator. The game ran well, but only on pretty new machines.

When I found doors in the post below, I used a Tile object. When I wrote the rotating 2D array code, I also included twin methods that rotated an array of ints. Is the int rotation faster? I don't know, but it certainly can't be slower. So I took a look at my findDoors() method on my Tile class, and thoght, "How can I make this work with just integers?"

* * *

C# has support for enums, as any good high-level language does. So instead of worrying about "Blocks" and "Block types" I translated all the info I would need into an enum. Essentially, the enum is the tileType, meaning I don't have to compare strings when I want to figure out Block types.

I had to get rid of the idea of a 'visited' block, or at least, the idea of a boolean that lives on the Block object. That changed the logic of my findDoors() in such a way that I couldn't figure out how to move forward. It was one of those instances where I just had to put the idea on a back burner, and let it simmer.

After about a week, something clicked and I knew I knew the answer, I just had to code it. Instead of checking whether or not a block was 'visited', I simply gave it a new BlockType of 'Visited.' 'Visited' is only given to door blocks that have been visited by one of the Peek() methods. So when looking at a door to figure out the width, it must simply be a BlockType.Door. When Peeking() right or down to determine the width of a door, though, either BockType.Door or BlockType.Visited will count toward the width. This is because Doors can share corners. Also, Since each Block is only looked at once, this also guarantees that I won't accidentally make duplicate doors.

Pretty exciting if I say so myself.

XNA and Drawable Game Components

XNA has this feature of letting your classes inherit from DrawableGameComponent, or GameComponent. What this inheritance does is let you write your own overridden Draw, Update, Initialize, etc. methods that will be executed during the corresponding base.* call in the main game class.

The overridden Draw, however, does not take a spritebatch, or anything else but gameTime, though. So how do you actually draw anything in those methods? The answer is two-fold:

1. Don't make too many classes that actually draw something. Make more 'master classes' that draw everything contained in them, like maps or menus.
2. Game.Services.GetService

"Game.Services.GetService?" you say, "how does that do anything?" To that I say, "ah, it lets you pull generic services defined on the game!" So when your spriteBatch gets initialized in the main game class:

spriteBatch = new SpriteBatch(GraphicsDevice);

you can add it to the services of the game:

Services.AddService(typeof(SpriteBatch), spriteBatch);

and pull this service from any class:

spriteBatch = (SpriteBatch)Game.Services.GetService(typeof(SpriteBatch));

Just remember to declare your own spriteBatch variable in the subclass, and pull it from the game some point after it's been initialized!

There are very few articles or threads I could find that dealt with this exact problem. Most ranged from either a really simple drawing that occured in the main game Draw(), or more complex drawing that didn't use a spritebatch, at least not on the top level. I finally found an article here that was simple and consice enough for me to decypher what was going on. Props to the author!