I'm in class now so I'll share mine when I get a chance. I just think it would be cool to be able to share the problems we solve. I think it would be motivating.

I just got a nice wrapper for GLSL shader programs working. Now, with just a single line of code, I can create a shader program.

I wrote a simple query language for my super tiny database engine.

I guess the only reason Im proud is because writing parsers is the one thing I detest more than anything.

Not sure if that counts as a problem or not.

Hmmm, with the "recently" qualifier... I'm most proud of finally figuring out how to write and use shaders in XNA and selectively apply those to what I wanted. Downloading the bloom tutorial was easy-peasy. But understanding it along with the XNA SpriteBatch nuances took quite a bit longer. When it finally came together I was quite excited. :)

https://db4sgowjqfwig.cloudfront.net/assets/301809/GlowEffect2.jpg

I'm also pretty proud of my "Effects queue" for a turn-based combat system I'm working on. You piece-meal different effects together like a visual laser effect with a sound effect and random particles at the destination. The laser effect is drawn until the sound effect finishes playing while random particle effects are emited at the target end of the beam. When I first ran into the issue of "hey now there's sound in my game" the duration I was showing the laser blast, was completely off. :) I had to take a step back and think about the problem to come up with a decent design. Then it came together pretty quickly.

- Eck

Wow, you guys sound like you're doing some very interesting things. I am very inexperienced but I can get the gist of the level of productivity you guys are describing and I like it lol. My latest and greatest will probably seem very simple in comparison but I'll share. I have been working through some pygame tutorials I found on youtube to get a handle on syntax and general game dev techniques. I decided to work ahead of the tutorials and found myself working on a sprite walking animation where the user controls direction with the arrow keys and the sprite alternates pictures of left and right foot. The problems came because the movement was done in if statements in a for loop based on if a key was pressed and I wanted the alternating of images to also happen in that loop so the animation of walking only happened when the sprite was actually moving. Well I solved the alternating images by creating a counter that counted up to ten cycles through the for loop before switching images.Another big issue was that on a key release the sprite would stop even if another direction was still held down and the realization that came when I had basically given up and decided I didn't know enough was simply to check if both variables I already had which stored key releases, had been set to zero, and then set an alternate flag to 0 in that case, otherwise set it to 1. This is obviously very basic stuff but even so I feel proud of the way I thought through that problem, using techniques from experiences of years ago in college, and some from more recently, to have that little victory.

I wrote a class that acts as a double for most purposes, but it almost magically computes the gradient of any function you define, with an CPU cost that is a fixed multiple of the cost of computing the function, no matter how many partial derivatives you are computing.

So for instance, you can write:

template <typename Real>
Real compound_interest(Real x, Real y, int n_periods) {
  for (int i = 0; i < n_periods; ++i)
    x *= y;
  return x;
}

When you instantiate this function with Real set to my class (I call it `Variable'), you can do this (actual code):

  Variable x{30000.0};
  Variable y{1.06};
  
  Variable z = compound_interest(x, y, 20);
  std::cout << "The value of the function is: " << z.get_value() << '\n';
  
  z.set_derivative(1.0);
  compute_gradient(); // This actually re-runs the computation in reverse, using a generalized form of backpropagation
  
  std::cout << x.get_derivative() << ' ' << y.get_derivative() << '\n';

A coworker mentioned an old paper that supposedly proved this was possible (just the algorithmic part, not the wrapping it nicely in a class). The paper wasn't easy to read, but my coworker did a great job at coming up with increasingly simplified explanations, until I understood it. My proof that I understood it was the class I wrote.

The catch is that it uses an amount of memory that is linear in the number of operations that describe the function (because it needs to be able to run the computation in reverse after it's done computing the function), which is a bit too large in the particular case we are interested in. Still, it was a neat challenge and we were quite pleased with the solution.

Figured out how to give my enemies random movement and pattern movement "AI".

Guys. GUYS. Hey... Listen.
Guys. Guys, listen...

I finally figured out how to write a proper CakePHP code. And it only cost me my soul!
What a bargain!

Self rolled animation controller. Though the harder part wasn't the controller but to get the data import right. And still is

@Álvaro: Interesting: Is that paper available online ?

Implementing a 3D character controller entirely from scratch without a physics engine has been fun and certainly challenging. And also probably stupid.

(What a nice, cheerful and positive thread by the way)