I haven't done much game development stuff, because my job as a web dev and preparation for entering college have been taking most of my time in the past few months. I couldn't find a tutorial about how to render a camera which focuses on the character for my 2D RPG, so I coded it myself with PyGame one free afternoon. I needed to store the entities' world coordinate, and calculate their screen coordinate based on the character's world coordinate. It was fun, drawing the logic on a piece of paper and wrote the code right away. It's nothing big, but I'm kinda proud about it. I still need to learn so many things.
Share the most challenging problem you solved recently! What made you feel proud?
I liked the result of my work on implementing a packages system for the engine's filesystem, that supports simultaneous reading, actual file reading, and zip decompression :).
One I'm proud of (although it's not game-related): I found a way to store our XML configuration files in a way that allows us to share said configuration in multiple programs directly, without the need to load the XML file again. I did this by pinpointing a shared memory block at the same address in each process.
But the most challenging part was to make sure that we were able to read/modify the configuration concurrently without the help of mutexes to limit context switches. So we went the road of spinlocks. But spinlocks introduced some weird priority inversion issue - so in the end we have what is called a Test-and-Test-and-Set spinlock with a variable backoff parameter (it took me a while to figure it out).
The classical test-and-set spinlock is mostly written like this:
class spinlock
{
int sl;
public:
void lock()
{
while (!atomic_test_and_set(&sl, 0, 1)) { }
}
void unlock()
{
atomic_set(&sl, 0);
}
};
A TTAS+Backoff is a bit more complex (I added the priority boost, as it also had a major impact on the contention).
class ttas_backoff_spinlock
{
int sl;
int old_priority;
public:
void lock()
{
while (1) {
if (atomic_test(&sl, 0) {
if (atomic_test_and_set(&sl, 0, 1))
old_priority = save_and_boost_process_priority(HIGH_PRIORITY);
return;
}
microsecond_sleep(rand() % 1000);
}
}
void unlock()
{
set_process_priority(old_priority);
atomic_set(&sl, 0);
}
};
With carefull research, you'll find numerous explaination of both the TTAS algorithm. The backoff principle is a bit more obscure: first, its a wait for a random very short time (in the example above: at most 1 millisecond). Second, the wait is done through a system call - that gives the OS the opportunity to schedule.
It should be noted that while I'm proud of the solutions I used in this program (it even have a carefully written garbage collector that use some weird heuristic to discover if a block os sizeof(void*) bytes is a pointer to another part of the same memory area or not), it must be noted that I found a better solution to implement the lock. My original reason to use a spinlock had to do with the poor state of the pthread mutex implementation (read: weird, difficult to explain behavior on mutex release when more than one other process waits on the mutex) when the mutex is shared by multiple processes (I'm working on a not-that-recent version of Linux). I finaly found relatively painless solutions to implement named mutexes on Linux that overcomes the pthread mutex limitations - yet I haven't had the time to implement it and fully test it.
Writing a FLAC decoder from scratch. While not really hard in itself, figuring out details that were not mentioned in any documentation certainly was. It was a bit trial-and-error, combined with looking at other source code of other OS-projects, and also manually decoding a stream to figure out what really goes on.
Debugging the audio player for a weird 'glitch' that audio drops out for shorts amounts of times. It happens once in a while, on a rare occasion, only to find similar behaviour on other audio applications on the same computer. Suspecting 'app nap' feature on OS X Maverics at the moment, or even slow throughput due to hardware latency, although increasing buffer size doesn't help, and the data is still read since it 'seems' like the audio is playing just fine, except for being silent for a fraction of a second.
Writing a disassembler in a 'smart' way - yet seeing lots of potential for improvements.
Figuring out ways with extremely limited CPU-time to determine sunlight and atmospheric contribution levels for each voxel. It turns out, it's not a good idea to try to do this realtime. My results are quite ok - and I'm very happy with how I managed to survive with just 1 ray and some clever usage of atmospheric contribution. But in the end, some pre-processing will be needed. Unfortunate when the world is anything but static.
The problem is mostly that there's no way to make it acceptable with anything less than ~16 rays. Which is ridicolous considering I'm making it look OK-ish with just 1 ray. It's kind of mind-blowing what a decent hack can do, that doing it the right way with 16+ rays can't.
@Álvaro: Interesting: Is that paper available online ?
"The complexity of partial derivatives", by Baur and Strassen.
I'm jealous of so many of above posters accomplishments :)
I recently got 6 degrees of rotation and movement for my goofy space sim working and implemented the collision detection. It's been my first foray into 3d game programing and openGL as well. It nearly made me give up on opengl entirely, but I got through it eventually. Now that the movement and collision are working properly and I've streamlined the code to run a bit smoother with so many objects in the game, the basic structures seem to be in place. I can finally move on to the fun parts of programming the gameplay for awhile :D Here's to hoping the annoying hurdles are mostly behind me until the last 10% of everything. Wishful thinking I'm sure, but at the moment I can't bear any more math problems :P
Congratulations to everyone above!
Not so much of a "Boy, how cool", but i dont want this thread to die. :P
So... My most recent accomplishment was a first running version of a iso surface extraction algorithm i thought of and implemented from scratch. The results are (almost) equal to those of the marching cubes algorithm, but since my algorithm extracts and then triangulates pathes from a grid LOD should be easily implementable ( Which i will have a look into soon. ) :P
So far its running pretty fast concerning its a very naive approach and just meant as a prove of concept... But a remake is in the forge atm and its goin good :P
"Complex" cases like a 6-Node Path are simplified atm thus details are lost, but this method (with the right implementation) Also allows for sharp features as tested with rotated cubes. This is a little fiddly, tho :P
I would post a picture of it, but as wireframe its just messy ( As usual: Iso surface with shit tons of triangles ) and i didnt implemented lighting for it yet so its just a clump of... well... Colored Triangles... Every color beeing the same. :P
If there is intereset i might post more details or try to implement a quick and dirty lighting solution for actual usefull pictures.... ^^"
DONT DIE, THREAD! The world needs peo... topics like you! (Or at least i do, against the boredom!)
Im pretty proud of my ISO file generator (cd-rom image maker), which can be found here. It's old but it work flawlessly, so far. I decided to make this after browsing around to find something similar but found nothing that was easy to use. The only drawback it has is that everything as to be done in one go. You can't edit a current iso file atm. The core of the code is a bit hard to understand but the interface to use it is really slick.
Although, the real gem is this, a remote pc client-server application that let you control other peoples computers that run the server. It has something like 25k(maybe more) lines of codes, biggest project i've ever made.
And of course, my library.