Alright! My first competition!

Thanks for the link...I have been there (and have that page saved on my hard drive). I get the concept...but I'm just having a slightly hard time getting it all straight in my head and ready to code. I'm sure it will come, though...many things I've found "impossible" in the past now seem quite easy. Maybe a competition will be a catalyst for my pathfinding knowledge...or maybe not. Maybe I can come up with a way that I don't need pathfinding (probably not, but we'll see).

It will be fun anyway!

I also don't see a problem with voxel engines. In doors only works okay for me though. I'd like to do something third-person, so please don't require first person!

Voxel heightmaps are cool...8-)...and can be achieved using raycasting techniques, so definitely should be at least considered for entry.

Wow! That's a bunch of free textures! Bookmarked
Definitely looks like a very good source for the compo art.

I added myself to the list...

Although...I feel I must protest the 640x480 limit...or is it for compatibility? Is 320x200 (or 320x240), 8-bit or otherwise, unsupported on modern video cards? My nVIDIA GeForce 2 (I know...modern! ) supports it fine...
If it has to be limited to 640x480 for reasons other than appearance, then so be it...but otherwise I think this is a little "unfair"...

I mean, look at good old wolfenstein 3d! There's a nice low res (think it's 320x200)...and Doom (even though it's not raycasting) was 320x200...

So it's really a matter of trying to reach a framerate you think will win you sufficient votes...

Yes - it's the lowest that many laptops can display fullscreen. Most will switch to a 320x240/200 display and only use a quarter of the display but mine being an Apple, it doesn't even pretend to support 320x240 mode and Allegro always fails when trying to set that as a fullscreen display. That said, the Apple version of Wolfenstein 3d was in 640x480 as were most other Mac games of the time so there isn't the need to support even for legacy reasons.

In the PC realm, Duke Nukem 3d had full SVGA support.

Anyway, I think it's pretty explicit that 640x480 must simply be one of the list of allowed resolutions and therefore can be the top resolution if you like. I guess I should also revive the idea of source releases being restricted to the judges. That way it is possible to write code for 640x480 for the competition then only do a 320x200 release for the public if you want.

Seems that it is. Otherwise, I couldn't participate Or maybe I could, but the graphics quality would suffer too much.

I've decided to implement a new system to determine what is a valid entry and what isn't. The system is that if any judge thinks an entry does not meet the competition criteria during judging then he indicates as such. If any entry obtains such indications from at least half of the judges then it is disqualified.

The advantage to this system is that I don't somehow gain greater authority over the meaning of ray casting just because I happen to have started the competition. The disadvantage is lack of certainty - how exactly can a potential entrant be certain that a complicated idea they want to implement will be accepted?

Given the nature of the competition and the fact that what is or isn't a ray caster is considered obvious by most people I think the advantage outweighs the disadvantage. But I'll pay attention to any comments people have on this idea.

Yes it is, although you will be inelligible for the category related to those programmed entirely within the given time frame. Also, I am strongly bending in favour of a rule imposing a 25% mark down for all entries started before the competition in any categories that could be called purely implementational. For example, I am considering a 'neatest code' category since we are running a programming competition and source distribution amongst judges is obligatory.

Any such categories will be clearly flagged up as such. None of these categories have yet been added to the competition. I remain mindful that nobody wants a category overflow so quite possibly none will.

In addition, what do people think of trying to get a few Allegro.cc luminaries on board as judges without requiring them to be entrants or else running a parallel poll for the 'popular vote' in each category or a subset of them? We could possibly persuade Matthew to run it using the existing Allegro.cc voting architecture?

Only for the judges, which is intended to ensure that everyone can play. Since there are only 7 entrants (so far - let's all keep mentioning the competition as widely as possible) I suppose we could instead all state the platforms for which we will require support in order to be able to allocate any points to your entry.

If, for example, it turns out I'm the only awkward one on Mac OS X then you'll be free not to distribute the source at all and in the absense of an OS X build simply get no points from me. Or you can chose to send only me the source code if you trust me enough!

I think this is best dealt with by simply stating that a judge is entitled to award 0 points to any entry he cannot run and is not required to go to any great effort to make things work. This also acts to inhibit eliminates buggy entries or entries aimed at impossibly great hardware targets.

As concerns the programming time limits, the reason for the demarcation between those created 'in time' and 'out of time' is meant to reward those who really enter into the spirit of the competition without barring those with existing work. It would be silly and against the community spirit to bar the competition to those who have some code they can dust off but are unwilling to rewrite it all just to meet the competition requirements.

Since the idea of a restriction on plot lines has been scrapped this has become substantially harder to do. How would people feel about placing a time limit on some categories ("best engine created in under a month", "best engine created within 24 hours", etc) and a deadline so that judging is effective but not explicitly starting the competition at any point? This is perhaps pandering a little too far to my natural anti-strict tendencies and moves the competition into the realm of a nonsense but given how heavily trailed it is and the fact that we'll all just be relying on trust anyway perhaps isn't so bad an idea?

It'd certainly mean that people like me could, for example, spend the best part of a month or so putting together the 'ideal' ray casting engine with all the fancy features I can think of and then also try and hack together a separate Wolfenstein clone block based thing in 24 hours so as to enter twice in different categories. There would probably have to be a source requirement for double entrants unless they could come up with some other substantial evidence that they hadn't just duplicated code.

As always, I'm open to suggestions and comments!

Okay, contest time is probably going to be some ridiculous long length like 2 months, allowing for the fact that most people have exams coming up. I'd say make the official period begin at the start of June and end at the end of July? That gives us, more or less, a month to find and consolidate art resources, etc.

Personally I'm enjoying what are best described for the international audience as bar finals, so perhaps I'm thinking too lengthily in terms of deadlines as my spare time is approaching zero.

Naturally I don't think that we should tell Windows users they can't submit in code format, but I don't think that is what you're suggesting! So, the rule is "in a form that the judge can use without undue effort, or else expect 0 points".

Once everything is finalised I'll deal with the proper collection and distribution of machine specs and varieties, etc, shortly before the start of the competition.

I suppose I'll also need people to indicate whether they have AllegroGL or not for those of us that overwhelmingly intend to just distribute source and forget about it.

First of june to the end of july works for me.

Language wasn't specified either; Java is my weapon of choice...

I just got my raycaster to run in 640x480 mode, to make sure I could still enter!
But, I found that drawing 640 scaled wall slices at twice the size they were before using 23yrold3yrold's DrawSlice() function (from the old raycasting threads) was very slow...I lost half my fps (60+ down to 30-ish, and standing right up to a wall didn't affect my framerate before, but now takes it down to the 15-25 range of fps!)
23's scaling function was pretty decently fast, but not fast enough for these massive purposes.

I like the idea of a hardware scaling routine, but I of course have no idea how to do that. Does allegro's stretch_blit use hardware scaling? Probably not...it's just I know for a fact that 23's does not.

Maybe on your guys's 3gazillion GHz macines this isn't a problem, but I'm developing with only 300mhz at my disposal. If we can't find a faster scaling method, I probably will have to drop from the comp...:'( Maybe not, though, but we'll see.

Also:

Will we be giving source code to the judges...or binaries? And what version of allegro will be used? I don't know if it matters anymore, but when I moved from Allegro 3.11 to Allegro 4.0.3, I had to go through and change some code. Probably doesn't matter anymore, though.

Believe me, that crossed my mind, but I figured if I'm entering a competition, my raycaster should probably look as little like crap as possible . The 640x480 is nice, but is much too slow on my old computer.

Well, that's better than me then, I loose 79% of fps. 640 fps in 320*200 to 140 fps in 640*480, both windowed.