Share the most challenging problem you solved recently! What made you feel proud?

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)

My recent achievement is getting asset hot swapping to work. Stuff like scripts, textures, data definitions, anything within a specific folder, are monitored and any modifications to these files are detected, and the file in question is reloaded. Since most of my code works with handles to these assets, the handles stay the same while the asset itself is reloaded, and everything works.

This has allowed me to do is create an ingame output console with a command prompt mode which executes any valid Lua code. This has been done completely in scripts (from logic to rendering), which means i developed the entire feature from the ground up in the matter of 2-3 hours without terminating the game at all :D

I switched most of my AI code (~80%) from single core to multi-core. Most challenging was to get the logic, which is written in lua (which does not support multithreading), distributed on several cores. All without using any additional lock-synchronsation like critical sections or semaphores etc., thought most of the sync is done in the 20% left for a single core.

Nevertheless, it works and make me proud

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.

*Woosh* Right over my head...

My recent achievement is getting asset hot swapping to work. Stuff like scripts, textures, data definitions, anything within a specific folder, are monitored and any modifications to these files are detected, and the file in question is reloaded. Since most of my code works with handles to these assets, the handles stay the same while the asset itself is reloaded, and everything works.

This has allowed me to do is create an ingame output console with a command prompt mode which executes any valid Lua code. This has been done completely in scripts (from logic to rendering), which means i developed the entire feature from the ground up in the matter of 2-3 hours without terminating the game at all

I actually had to do something similar just recently too.

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 literally just got done doing this yesterday!

I had an idea for a voxel polygonization technique (isosurface, etc..) about three years ago, and proceeded to get distracted by life up until just recently. My goal was to produce something similar to marching cubes but without fine displacement of vertices to approximate isosurface. The goal was to come up with an algorithm that isn't marching cubes.

The ultimate goal was breaking the problem down into simple steps. I finally figured it out, and it was ultra gratifying. I haven't felt accomplished like that in years!

I started a blog about my project, with a better explanation if anybody is interested. http://deftware.blogspot.com/

I had an idea for a voxel polygonization technique (isosurface, etc..) about three years ago, and proceeded to get distracted by life up until just recently. My goal was to produce something similar to marching cubes but without fine displacement of vertices to approximate isosurface. The goal was to come up with an algorithm that isn't marching cubes.

The ultimate goal was breaking the problem down into simple steps. I finally figured it out, and it was ultra gratifying. I haven't felt accomplished like that in years!

I started a blog about my project, with a better explanation if anybody is interested. http://deftware.blogspot.com/

@radioteeth this blog is pretty cool, I favourited it so after tmrs testhopefully I'll be able to take a closer read through!

@Everyone I'm glad this has got so many responses and I see you guys are communicating with each other and learning new things here, as I guess happens in manye other places on these forums lol, but still, Awesome! And keep up the good work in general!

Got a deferred renderer working. G-buffer pass writing albedo + encoded normals. Then light pass decoding normals and applying diffuse lighting (single directional light for now). I need to get position reconstruction working so I can do specular lighting.

EDIT: Oh, and "published" my Artemis fork (journal link in my signature).

Meh... the only real challenge I've had recently that I can publicly talk about would probably involve this sucker, which I've not touched in months.

Compilers are hard.

My latest most challenging problem: Not going mad while trying to release two of our games ported to Android...

So far, almost 100% success.

Still not completely released yet though...

Also a bit proud of my xml/C++11 UI framework that runs on our in-house engine that made the ports possible :P