I tried to do a quick review for bugs, but I have to go get the dishes done before my dearest returns! <3 I noted the above. I don't know WTF it's for, but it appears to destroy the bitmap without resetting the pointer and then attempts to use the pointer again later... Seems sloppy and probably a bug. That said, I'm assuming that would only occur if you called the function twice. The best way to figure it out is an interactive debugger.

That's odd. All it does is allocate and load bitmaps. It could be making the large Atlas a memory bit.ap if you do t have a large enough texture. I'll explore later when I get home. You're using the second version I provided right?

I took a look and found that Takaaki Furukawa's avatar had a capital "K" in each of its avatar files. Making that a lower-case "k" fixed it. However, now the screen just appears black (it still updates and ends after 5 seconds like it should though). I don't even bother to call GetAvatar().

The Create* routines set the drawing target. You have to reset it first. Then draw one of the images from GetAvatar. Also, windows is not case sensitive. That's why it didn't care for me, but failed on Linux. Don't know how that sneaky capital K got in there. I'll upload a fixed version tomorrow.

I submitted my thing too, with about 30 hours on the clock from me and about 4 hours from Max.

I roughly got where I wanted, but I got plenty of new ideas. I could easily spend another 30 hours developing the same game for Krampushack 2017

I really like this polish-hack style though... Take an old game, keep it in a releasable state but replace features one by one. I've got so many old competition entries that I could treat the same way. Maybe they have some potential, but really they are just unfinished. Maybe we can make this something regular. What do you think?

You shouldn't implicitly change the state, then expect the user to both know what you changed and also have to clean up afterward. I haven't looked at your code, but it sounds like you're changing the drawing target within a function call. Whenever you do that, you should always change it back:

As an (almost holy) principal, any function should have no side effects. If a side effect is essential for the operation of that function, then the side effect should be isolated into a separate function call, and you should make it the responsibility of the user to call it.