KrampusHack 2020 !

Rules: https://tins.amarillion.org/krampu20/rules/
To join: go to https://tins.amarillion.org/, register and log in. Then click “Join a competition”.

The game jam is very free and open, there are almost no hard rules. The main point is just to have fun and do something together during the holidays. Below are the rules as I posted them on the site, as you can see they are not very strict. I could still make some modifications in the coming week – so let me know your comments, if there is anything you’re unhappy with.

1. goal: Create a game as a gift for your secret santa.
On Sunday 13 December 2020, you will be assigned one of the other participants and you have to make your game as a gift for them. Each should post a wishlist of features that they would like to see in the game. But this wishlist is not a requirement list – you should tune the game to your giftee, taking the wishlist as well as the person itself into account, and create something that is a nice and thoughtful surprise to them.

2. progress log: Keep an interesting progress record here on the tins website. This progress record is very important, as it will be voted on, and used for determining the winner. During krampushack, your secret santa’s logs will be hidden from you to maintain the surprise a little bit longer.

3. Deadline: Thursday 31 December 2020. End time is midnight in your own time zone. I’m not going to be very strict about time, a few hours off is fine.

4. Dropping out: As is common with game jams, there is always a risk that some people will drop out. Life interferes, you ate a little too much Turkey, or you got that cool new PS5 for X-mas and lost all motivation to do anything else. We won’t be mad. To limit the impact, please let us know as soon as possible, so that we can notify your secret santa.

If your future giftee is dropping out, then you will be notified, your gift will go to the next person in the chain (your giftee’s giftee). You then get the choice of using the original wishlist, the new wishlist, or a clever mix of the two. You’ll have to see what is achievable based on the remaining time. Remember, the wishlists are for fun and inspiration, you won’t be judged on adherence to them.

5. size: There is no size restriction, but for convenience sake I recommend keeping it under 5Mb (zipped). The upload system may have trouble handling larger files. If your entry ends up too large, you have to upload it in your own webspace and send around a link.

6. source: We encourage submission of the complete source code with your entry but this is not compulsory. Of course you don’t have to include the source to Allegro or other publicly available libraries or frameworks

7. Code re-use: You may re-use any code and assets that you are legally allowed to do so: public domain, your own, etc. You do not have to start from scratch, you are allowed to do prep work before, or even re-use an existing game.

8. Allegro & other libs: You are encouraged to use allegro, but this is not compulsory.

Easier pthread mutex deadlock detection

Thread programming is fun, starting a tons of process and syncing them on a task, or asynchronously process a bunch of data. But that fun is having a cost: data sharing have to be somewhat locked or well ordered when accessing it. Else you’re going to face some seriously strange situations like time warping variables at the best and big crashes at worse.

On top of that let’s add that the main tools to protect our datas reads / writes by threads can also lead to strange situations where only parts of the code is still running and the rest is in “deadlock” state.

On little examples detecting those deadlocks seems easy, but when scaled to a bigger project/api, it’s a living hell.
Tools like valgrind may detect the problems at the cost of big performance loss which may lead to being unable to run into the problem before running into the machine limits.

I was searching for a good ressource to help me in my debugging quest when I stumbled upon that article from Aurelian Melinte which I think is very good (both the author and article): https://linuxgazette.net/150/melinte.html that provide some code samples to superseed the pthread functions with some that will make some checks during the calls.

There is also the gdb deadlock detector script by DamZiobro : https://github.com/DamZiobro/gdb-automatic-deadlock-detector

And finally valgrind- helgrind: http://valgrind.org/docs/manual/hg-manual.html

Now back to code and monitoring/debugging !