[URL removed]
It has begun.
1) Everything must exist in your main function.
[...]
5) Your program must be contained within a single file.
6) You may not write your own functions.
7) You may not use the preprocessor.
You realize that 1) implies 5), 6) and 7)?
You also realize that with the preprocesso one cannot include allegro.h? Or the allegro provided macros including END_OF_MAIN()?
You cannot use timers.
You cannout use any callback functions.
Besides that nitpicking, what's the idea behind it?
Yay, yet another comp 
And yes, those rules (especially regarding the preprocessor) seem a bit odd ...
The rules have been clarified a bit.
You cannot use timers.
You cannout use any callback functions.
Find another way to do it, that's the idea.
Why don't you add a requirement like "you may not use any functions containing the letter 'n'"?
In other words, what you want us to do is to code in the worst style possible, right?
Anyway... you can still use Macros without any problems. All you need to do is to call the preprocesser explicitely, and then submit the output of the preprocessor run.
And by using c++ you can circumvent that anyway, since you are allowed to define types (including classes which can include methods) outside of main().
rule: You may not write your own functions. (methods be functions)
methods are no functions. That's why they are called methods.
Anyway... by using some global vars you can fake function calls anyway. It's just more effort. What you'd need to do is to make all your functions part of a giant switch.
Then use a big array to store the call stack.
Would work well, but is pretty pointless to do. It's also no real fun. The "code a game in 23 lines" was more fun and more hackish
I agree. the 20 line game thread did rock.
But yeah, a big switch would work, and apparently it got done the first time arround, someone made a VM in thier main loop to do all the tricky stuff...
oh, method == fancy function. same thing. they just get some extra context.
Which reminds me, I had an archive of all the Allegro 20 liners posted in that thread. I'll see if I can dig it up and post it, some of those games were nice.
Hmm... maybe it'd be fun to do something like that again?
Maybe a 20 line demo compo or something?
Or how bout the scarriest C code you've ever seen compo?
I have some scarry code, that isnt working how I thought it should.. but then, thats the nature of scarry code.
| 1 | #include <stdio.h> |
| 2 | #include <setjmp.h> |
| 3 | |
| 4 | jmp_buf main_buf, func_buf; |
| 5 | int thrown = 0, reset = 0; |
| 6 | int released = 0; |
| 7 | |
| 8 | #define say(a,b...) ({ \ |
| 9 | char *buf__ = NULL; \ |
| 10 | asprintf(&buf__, a, #b); \ |
| 11 | printf("%s:%s:%i :: %s\n", __FILE__, __FUNCTION__, __LINE__, buf__); \ |
| 12 | }) |
| 13 | |
| 14 | #define throw() RESET: ({ int ret = setjmp(func_buf); if(ret==2 && !reset) { reset = 1; goto RESET; } \ |
| 15 | else if(!reset) { thrown = 1; longjmp(main_buf, 2); } else { reset = 0; } }) |
| 16 | #define catch else |
| 17 | #define try DOME: ((setjmp(main_buf) == 2) ? ({ goto DOME; }) : (void)0 ); if(!thrown) |
| 18 | #define release() thrown = 0; longjmp(func_buf, 2) |
| 19 | |
| 20 | int func(int fail) |
| 21 | { |
| 22 | say("Yatta!"); |
| 23 | if(fail) { |
| 24 | say("throwin..."); |
| 25 | throw(); |
| 26 | } |
| 27 | say("Done!"); |
| 28 | |
| 29 | return 1; |
| 30 | } |
| 31 | |
| 32 | int main() |
| 33 | { |
| 34 | say("Do IT!"); |
| 35 | |
| 36 | try { |
| 37 | say("func() 1"); |
| 38 | func(0); |
| 39 | say("after func 1"); |
| 40 | say("func() 2"); |
| 41 | func(1); |
| 42 | say("after func 2"); |
| 43 | say("func() 3"); |
| 44 | func(2); |
| 45 | say("after func 3"); |
| 46 | say("..."); |
| 47 | } catch { |
| 48 | say("Caught!!"); |
| 49 | |
| 50 | if(!released) { |
| 51 | released = 1; |
| 52 | say("Releasing ;)"); |
| 53 | release(); |
| 54 | say("after release"); |
| 55 | } |
| 56 | |
| 57 | say("Keeping..."); |
| 58 | } |
| 59 | |
| 60 | say("all done."); |
| 61 | return 0; |
| 62 | } |

Yes people, this is C. It WILL NOT compile as C++ code.. or if it does, you're damn lucky.
Please don't post if you aren't going to participate, sorry but I don't like coming here and reading a bunch of crap posts about peoples' opinions.
Here is my entry... I could add alot more too it (like explosions and stuff), but I want to keep it the way it is for now.
[URL removed]
Heh your entry isn't valid, it breaks the rules
... checking ...
Quite funny indeed. Some serious macro action going on
I do belive he meant no #define ing on your part...
He said no macros besides "END_OF_MAIN".
So, no MIN, MAX, SCREEN_W, SCREEN_H, LOCK_XXX(), TRUE, FALSE, KEY_XXX, etc.
How does that "random" thing work? I can't see any randomization anywhere ...
Give up now and change the rules. 
And where did you come from? You dare bitch about us posting crap. You've only have three posts total. All in this thread.
Hes a regular in #allegro...
How does that "random" thing work? I can't see any randomization anywhere ...
using what was in a certian memory position last... thats likely to be fairly random.
It's just as likely to be all zeroes.
It's just as likely to be all zeroes.
Yup. Just as an infinite amount of monkies taping an infinite amount of keys on an infinite number of typwriters can produce all of Shakespeare's plays.
It's not random - it's just undetermined.
I think this compo is a good idea. It remembers me the old good times I program in GW-BASIC...:)
The random isn't hard to get, just with some maths that includes divisions of odd numbers, mods, rounds and all that...
May be I'll try, if I have a good idea this weekend;)
A question: #define M_PI 3.141569... is a macro/preprocessor directive?
It's not random - it's just undetermined.
Then, what is random?
One feature of the randomosity required here would be fairly even distribution - something that reusing old memory definitely will NOT have. 
A question: #define M_PI 3.141569... is a macro/preprocessor directive?
Yes. So is END_OF_MAIN, SCREEN_W, SCREEN_H, MIN, MAX, GFX_AUTODETECT, etc ...

Randy: Find a way that allows the use of, at least, END_OF_MAIN, please...:'(
X-G: You can use the int value of GFX_AUTODETECT instead, as well as screen->w and screen->h...
[edit]I find it:
7) You may not use the preprocessor (except for allegro.h and END_OF_MAIN).
All rules has exceptions8-);D[/edit]
X-G: PROVE to me that "randomosity" requires "even distrobution".. That sounds a wee bit contradictory... but then I'm no expert at this stuff.. (physics, etc..)
I said randomosity for this purpose required it - how random is a function that only results in stars on the left side of the screen, for instance?
Would you call a PRNG whose next result you couldn't predict exactly, but that would be "7" in 99% of all cases and "2" in 1%, random? I wouldn't.
The two most important criteria when it comes to judging PRNGs are their 1) number distribution and 2) "unpredictability". 1) means just what you think it does: in the ideal case, all numbers within the generator's range have an equal probability of being generated. 2) is pretty important when dealing with cryptography and the like: think of it as the possibility to guess the next number(s) from its previous outputs.
Or how bout the scarriest C code you've ever seen compo?
[url http://www.ioccc.org/]

An Obfuscation Work Of Art
| 1 | #define _ F-->00 || F-OO--; |
| 2 | double F=1.01,OO=00; |
| 3 | main(){F_OO();printf("%f\n", 4.*-F/OO/OO);}F_OO() |
| 4 | { |
| 5 | _-_-_-_ |
| 6 | _-_-_-_-_-_-_-_-_ |
| 7 | _-_-_-_-_-_-_-_-_-_-_-_ |
| 8 | _-_-_-_-_-_-_-_-_-_-_-_-_-_ |
| 9 | _-_-_-_-_-_-_-_-_-_-_-_-_-_-_ |
| 10 | _-_-_-_-_-_-_-_-_-_-_-_-_-_-_ |
| 11 | _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ |
| 12 | _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ |
| 13 | _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ |
| 14 | _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ |
| 15 | _-_-_-_-_-_-_-_-_-_-_-_-_-_-_ |
| 16 | _-_-_-_-_-_-_-_-_-_-_-_-_-_-_ |
| 17 | _-_-_-_-_-_-_-_-_-_-_-_-_-_ |
| 18 | _-_-_-_-_-_-_-_-_-_-_-_ |
| 19 | _-_-_-_-_-_-_-_-_ |
| 20 | _-_-_-_ |
| 21 | } |
Can anybody guess what is the output of the program (without running)?
Believe it or not , the value of PI !!!
There is one rule: Allegro only code.
In essense:
a bunch of rules
The wording of the compo rules description implies that the rules list follows from the one rule, and that the absurd list of bad coding style restrictions are somehow an important aspect of code being "allegro-only". Which makes no sense to me. It's like this is attempting to be a themed compo but failing.
Ultimately I think that if a competition is enforcing or asking for bad style, that's okay. But it should then let people be creative in designing their bad style, giving them the option to take advantage of the obscure features of a language. These rules, and even moreso the sample entry, do not seem to focus upon or even encourage language or even allegro-library abuse.
So, as spell said, what's the idea behind this?
As a side note, another 20 line compo would be rather cool. The 20 line idea is really interesting / fun to play with ...
Also as a side note, I know I'm hesitant to spend time on a compo when I don't know the person running it at all, because I have no faith that my entry will even see the light of day, be judged, etc. A quick webpage on the compo would probably encourage entrants.
Please don't post if you aren't going to participate, sorry but I don't like coming here and reading a bunch of crap posts about peoples' opinions.
Tough. If you don't want to read people's opinion of your competition, then don't tell people about it. Since you told people, you have to expect to hear their opinion on the subject.
There is one rule: Allegro only code.
1) Everything must exist in your main function.
2) You have to use Allegro.
3) You cannot use any libraries, including libc, only what Allegro needs from it.
4) You cannot include any header files except allegro.h
5) Your program must be contained within a single file.
6) You may not write your own functions.
7) You may not use the preprocessor (except for allegro.h and END_OF_MAIN).
8) C++ embedded functions are a no-no.
9) Type definitions are all that is allowed outside of main.
10) C++ new is also a no-no, it is equivalent to malloc in C.
11) External datafiles are OK.
12) VMs may be used, but they must be implemented as said above.
13) Last but not least, it does NOT have to be a game!
If the one rule is "Allegro only code", how does that necessitate that all code lives in "main()" and that the user can't have functions?
At least with Speedhack, you aren't forced to write really crappy code.
Considering at least 3 other contests are on now/coming soon, this one doesn't sound like it's going to get a big turnout
I asked him that on #allegro... oh well.
If the one rule is "Allegro only code", how does that necessitate that all code lives in "main()" and that the user can't have functions?
Think. If I allow functions how easy is it for someone to just cut and paste an entire Allegro add-on library into their program? Or some other library?
Secondly... the allowance of Allegro-defined macros was clear with my entry, and just because the wording of my rules wasn't clear at 4:30 AM doesn't mean any different.
Also as a side note, I know I'm hesitant to spend time on a compo when I don't know the person running it at all, because I have no faith that my entry will even see the light of day, be judged, etc. A quick webpage on the compo would probably encourage entrants.
I am limited on bandwidth this month so this forum is all you guys get for a site.
If you would be willing to host it, I'd be happy to make a site... I make them all the time. But I refuse to put it on some free host with a hundred advertisements forced onto my pages.
Think. If I allow functions how easy is it for someone to just cut and paste an entire Allegro add-on library into their program? Or some other library?
This is a danger in most of our comps, and it's usually an unfounded fear. Some like SpeedHack require you keep some kind of log, for example. For something like BlitzHack, cheating is either more trouble than it's worth or easy to get caught in
But ultimately, we go by the honor system; you're told not to do that, and you don't. It certianly beats a "no functions" rule. 
Let's outlaw variables while we're at it. We can still use HTML ...
This is a danger in most of our comps, and it's usually an unfounded fear. Some like SpeedHack require you keep some kind of log, for example. For something like BlitzHack, cheating is either more trouble than it's worth or easy to get caught in But ultimately, we go by the honor system; you're told not to do that, and you don't. It certianly beats a "no functions" rule..
I'm glad you live in a world free of cheaters. Come to Real Life(tm) sometime.
Hmmmmm .... has there ever been a cheater in an Allegro comp?
EDIT: There are slight security measures for Speed/BlitzHack (essential info withheld until go time) but that's about it. No need to suck the fun out of it
Is there some cash prize or something?
The safeguards in those compos actually do very little to stop determined cheaters.
Eh. The safeguards in YOUR compo actually do quite a bit to deter possible entrants. 
Anyway, good luck with it.
determined cheaters
What! Where?
A question: #define M_PI 3.141569... is a macro/preprocessor directive?
Use AL_PI.
There are no other rules.
If you want to cheat and preprocess your code before submitting it, that is your decision.
... so you already acknowledge that your rules are ineffective and you use an honor system, but you don't think that an honor system works? That's retarded.
Anyway, to basically have functions you can still call main recursively like this:
| 1 | int main(int f, char**args) |
| 2 | { |
| 3 | switch (f) |
| 4 | { |
| 5 | case 1: |
| 6 | // function 1 |
| 7 | return n; |
| 8 | case 2: |
| 9 | // function 2 |
| 10 | return q; |
| 11 | default: |
| 12 | } |
| 13 | // all the main program junk |
| 14 | int j = main(1, null); // call function 1 |
| 15 | int d = main(2, argarray); // call function 2 |
| 16 | // more main program junk |
| 17 | |
| 18 | return 0; |
| 19 | } |
Furthermore, I think you may be able to change the definition of main as you like it and just get warnings (mangled_main()?) ...
So yeah. These rules continue to be completely rediculous. If you want a pure allegro competition, just have a pure allegro competition. In contrast with, for example, this crap.
So yeah. These rules continue to be completely rediculous. If you want a pure allegro competition, just have a pure allegro competition. In contrast with, for example, this crap.
This thread has become so full of crap that those who are entering have to sift through tons of garbage just to get any actual information regarding the competition.
Those who have posted here saying that it is 'retarded' and things like that have accomplished nothing but help ruin it for those who are entering.
Just because you don't like it, don't mess it up for others.
1) A thread is started about a competition.
2) People comment about this competition.
This is a perfectly normal sequence of events. If a the compo in question has serious fallacies in construction that would prevent (it seems) most of the forumites from wishing to enter and it's a compo that doesn't sound like it would be entirely bad if it said errors in construction were corrected, it seems perfectly reasonable to me to explain / discuss what the problems are and how to fix them. That is all that has occured.
Since it seems feedback of all degrees and intonations is entirely ineffective, this isn't getting anywhere and I suppose it shall stop. ... shrug. That's not my fault.
I see nothing but lameness.
Give up now and change the rules.
And where did you come from? You dare ßî+çh about us posting crap. You've only have three posts total. All in this thread.
[EDIT] This post was not edited
So yeah. These rules continue to be completely rediculous. If you want a pure allegro competition, just have a pure allegro competition. In contrast with, for example, this crap.
Sorry, but it's my opinion it's a lame compo
Especially with a bunch of (IMHO) superior ones running now too.
Is anyone actually entering? I hope you're getting better luck on that other thread you linked to ...
I've been called a b**ch and retarded in this thread,
Uhhh.. neither of those happened... Someone said you were bitching (theres a major difference), and that the compo is retarded.
Sorry, but it's my opinion it's a lame compo
It wasn't so lame 2 years ago when I got over 15 entries (alot for that time), and most of them were really good (some guy wrote a VM that ran sub-Perl code).
Quite frankly I've had enough, competition closed.
You could have just been a little more flexible with your rules, you know. 
Oh well ...
Maybe, just maybe, 2 years ago, the idea of cdding style, readavle code, etc. where not that common?
I still don't get the point. If you want to see what one can do using allegro only, all you need is a single rule:
1) You may not use any functions (or macros) besides those provided by allegro or those you have written yourself during the compo.
I think that would work well 
Regarding using the pre-proc before submitting: My whole point is that it's pretty ppointles. But using macros you could at least make your code slightly more structured.
Using Macros you could for example create a human readable state machine inside your main loop, including "methods" to put parameters on the stack which could then be fetched again by the states, etc.
And, after looking at your code, I had another idea how to circumvent the restructions...
| 1 | int main(int argc, char**argv) { |
| 2 | int init_width, init_height; |
| 3 | |
| 4 | goto game; |
| 5 | |
| 6 | init: |
| 7 | /* ... */ |
| 8 | goto init_return; |
| 9 | |
| 10 | game: |
| 11 | init_width = 640; |
| 12 | init_height = 480; |
| 13 | goto init; |
| 14 | |
| 15 | /* alternativly use ASM code to call the game label */ |
| 16 | game_init_return: |
| 17 | /* ... */ |
| 18 | |
| 19 | } |
In combination with a global stack and some parameter vars, this would work nicely as well.
As you can see, providing too many obstacles which are not even related to the actual goal ("pure allegro"), just to prevent cheating will do your compo more harm.
From what I can tell, most people just did not like it because they personally felt that the rules were too strict for them or were too messy for their style, and hence decided to just flame it instead.
And I haven't seen code like yours for a very long time, it is not that I just wanted to stop cheaters, I wanted to see how people would find other ways to do things when they couldn't just write 50 functions with commonly documented algorithms to replace those in the C library.
We actually had a good time talking about this on IRC, for example using create_bitmap or create_sample to replace malloc, may seem extremely hackish and taboo, but it would still be interesting to see how other Allegro functions could be used to make a working program or game.
Obviously only a few people shared such an interest.
We actually had a good time talking about this on IRC, for example using create_bitmap or create_sample to replace malloc, may seem extremely hackish and taboo, but it would still be interesting to see how other Allegro functions could be used to make a working program or game.
Then maybe telling us something like that would have been a good idea as well? I asked for your motivation quite some time ago, and that's the first time you replied to it.
You might have been talking about that stuff on IRC alot, but that doesn't help those who want to get the info from the web 
I wanted to see how people would find other ways to do things when they couldn't just write 50 functions with commonly documented algorithms to replace those in the C library.
You won't need that many functions with algos anyway. But it's nice to reuse code, it's nice to reduce code clutter etc.
For memory allocations, I'd still say that creating one or 2mb big array and managing handles to that memory yourself would work equally well.
Combine that with the state machine approach to simulate functions calls, and you could even create more complex games.
but I will most likely host a much less complex competition in December
Less complex? 
You mean you won't allow loops in the next compo?
Or did you mean "less messy"?