MinorHack is coming up for this weekend, and we need a thread!
5 people interested in playing, let's hope we can get at least that many entries!
Old threads:
I don't think I am going to be able to participate, I have a few things I need to do. Of course, I still haven't figured out what those things are, but with a bit more prying, I should have that much straightened out.
This brings to the total down to 6 people interested in participating
I couldn't get in in time 
I will keep working on this totally amazing game though!
This is definitely the crappiest entry I ever submitted to MH
. It is supposed to be about cracking safes - you have to align all of the rings in the red zone before the time ends. You can speed up a ring by clicking it with the RMB, or slow it down with LMB.
It turned out that the concept isn't all that fun, and I was very short on time today (I almost missed the upload margin)... But it's 30 degrees Celsius here (this being 10pm), and I've been having too little sleep for a week now - so I think I can use this as my excuse
.
Oh, the rings don't have to be stopped to be considered aligned, so...
You also might wan't to tweak the control sensitivity a little - it's the last constant in lines 123 and 129. I find it most fun at 0.007, but you might want another value (the default is 0.01).
EDIT:
I have uploaded the binaries for competition entries. The list of changes I had to make to get them compile:
- Krzysztof's entry needed -lwinmm which the standard makefile doesn't provide
- I needed to add END_OF_MAIN() for Elias's entry to get it to compile under Windows
Now, to actually play them
.
I'm not too happy with my entry too, but at least you can call it a game.
What I wanted to do: simplified remake of server cracking game
What I managed to do: game, where you have to type 'h4x' as fast as you can 
At least I have random terrain generator, console and matrix-like effect in place. 
EDIT: Yes, my entry uses timeGetTime, which is in winmm library, as timeGetTime is simplest method of measuring time accurately.
For Linux people - if you want to compile my entry on Linux, I can dig timeGetTime emulation for Linux which I've posted in one of earlier Minorhack threads.
Yes, my entry uses timeGetTime, which is in winmm library, as timeGetTime is simplest method of measuring time accurately.
Because you obviously need delta-time accurate down to a millisecond for a game where you have to type 'h4x' as fast as you can
.
Anyway, did you come up with the map generator on the spot? Because I think I saw something exactly like that in an ancient "Bajtek" (an '80s Polish computer magazine, for those not familiar) and was just wondering if it's a coincidence.
Well, I tried to make a DDR-style game. You would goo along a track and when you came to an arrow you would have to press that arrow. Timing properly would gain you points and such. It's just too hard to code quickly, though.
Because you obviously need delta-time accurate down to a millisecond for a game where you have to type 'h4x' as fast as you can
.
I just don't remember how to use Allegro timers so it saved me a peek to the manual. 
Anyway, did you come up with the map generator on the spot? Because I think I saw something exactly like that in an ancient "Bajtek" (an '80s Polish computer magazine, for those not familiar) and was just wondering if it's a coincidence.
I needed simple map generator and recalled one that I've found in some ancient magazine, so it was probably "Bajtek". I didn't remember the algorithm too well when it comes to changing direction and obviously the algorithm was crafted for smaller screen sizes so I had to play some time with it to get something which resembled a continent.
Krzysztof: You should consider adding support for timeGetTime to Allegro itself. You've already got functions for Windows and Linux... Just wrap them up in al_get_milliseconds or something
Wheeeeeeeeeeeee! MP44 H4X
One hour is just too short. I went well over the one-hour deadline, so of course MP44 H4X doesn't qualify for the competition - but I'm rather proud of what I eventually came up with.
By the way guys, you need to vote
Just play each of the games and rank them from your favorite to your least favorite.
Well, here are my votes:
- Krzysztof Kluczek - mainly for presentation and sticking with the 1337 theme
- Elias - for having the only other completed game. It doesn't actually feature any text though...
- ixilom - though it's not complete, it seems more of an effort than guilt's entry
- guilt - well, there's not much there, and I couldn't even get it to exit without killing it manually.
My votes:
- Jakub Wasilewski - for making something close to complete game
- Elias - for overall coolness, although it looks more like techdemo than a game
- ixilom - incomplete game, but good effort
- guilt - nice idea, but bugs don't allow to play the game
Congratulations everybody for participating. 
Krzysztof: You should consider adding support for timeGetTime to Allegro itself. You've already got functions for Windows and Linux... Just wrap them up in al_get_milliseconds or something
Well, I don't know Allegro internals good enough to provide fallback for platforms that don't support timeGetTime() nor gettimeofday() (DOS for example). If you know any Allegro developer that could be interrested in this, I could PM him and with his help it could be done.
Well, I don't know Allegro internals good enough to provide fallback for platforms that don't support timeGetTime() nor gettimeofday() (DOS for example). If you know any Allegro developer that could be interrested in this, I could PM him and with his help it could be done.
Yeah, me either. I submitted a patch yesterday that added it for those two, though. On the remaining platforms (Mac OS X, BeOS, and DOS), the function simply returns 0 always.
This portability issue should be resolved before it gets to Allegro. Also al_get_milliseconds could require install_timer() call on all platforms to encourage portable coding.
I'd also suggest adding something like al_get_time_delta() on top of it, which would return zero on first call and time delta in milliseconds on all next calls.
When it comes to Windows platform, you should be aware that timeGetTime() can get confused when called from various threads on various processors due to dynamic downclocking of CPUs. Also simply system moving the thread from one processor to other processor can make timeGetTime() confused. Because of this, Microsoft suggest:
- calling timeGetTime() only from one thread,
- making sure that the thread won't get moved to other processor (SetAffinityMask, or something),
- only using differences from separate timeGetTime calls,
- clamping these differences to sensible values (eg. deltas below doesn't make sense)
These points were made for QPC/QPF, but probably apply to timeGetTime() too, so if you'd like to add it to Allegro, then make sure that its done properly, or people with dual core processors will start to complaint.
[edit]
I'd like to continue this conversation in a separate thread, to make it more widely-discussed.
OK, back to the topic. I'd like to know two things:
1. Where is the rest when they have to judge the entries? 
2. Why everybody has 'DQ' in place of his score?
1. Where is the rest when they have to judge the entries?
They've missed the window. Judging is now over.
2. Why everybody has 'DQ' in place of his score?
I hadn't added your votes to the database yet. Unfortunately, since no one voted, you two are tied. Well, congratulations
So we have made yet another "Teraz Polska".
Well, it actually was "Only Polska", so I don't really know if that counts
.
No one noticed my late 'entry'
Well, we did, but we couldn't vote for it
. For me, it was the best, but the difference between 1:30 and 1:00 for a complete game is huge.
Bruce Perry: 'No one posted abouted' != 'no one noticed'. Personally, I found it cool.
Yay! \o/ (I wasn't looking for comparison
Just acknowledgement
)
In other news, I went to work yesterday and today and rewrote a polygon triangulator that never worked, and it works now and the code's much simpler. I feel so proud!
polygon triangulator
Heh, I think the common term for that is tesselator
Heh, I think the common term for that is tesselator
It depends on whether you want to triangulate or tesselate the polygon. In the first case you want to split it into triangles, which isn't always straightforward in case of concave, nonplanar, self-intersecting or polygons with holes. On the other hand, tesselation aims to split polygon into smaller ones, but this doesn't mean the smaller polygons have to be triangles.
Triangulesselator!