There are two things I'd like to know, and please all coders great and small.
1. What kind of programming challenge do you envisage being feasible for a possible Sumea programming challenge?
2. How many hours of work should each programming challenge consist of approximately, and what kind of investment of time can u put in?
Personally, I'm not sure I could spend more than a few hours a week on any programming challenge, and to code anything substantial takes more than a few hours, so I think some form of challenge every month or maybe bimonthly would be good from *my* point of view.
However, if other people have more time to invest in this, and want more frequent challenges opinions would be nice.
As far as what the actual challenge should be, I think it would be good if it wasn't in anyway "interactive" in terms of the final product. I'd also like to see each challenge build upon contents of the previous challenge, and also maybe steal a bit of help from the artistic challenges?
Sounds good... simple too.. just say, write a routine that does this...and then we interpretate it to display what we think it should look like..I do like the idea of the smaller the better.. as who really wants to see a 'water' routine thats 4 mb? Also some limitations as no video textures to be allowed, etc.. Has to be all code, actually would be nice if NO art was used, but have everything generated from the code itself..
Just my thoughts..
Ok Guys I think it is a great idea to procedurally generate textures.. and Geez rewyre it is very easy. Just look up some fractal mathematics. it's fun.. you'll be laughin in no time..
Rezn0r. No as to judge at this point I am to busy judging as is..
Alcohol lubricates Marks I swear...
As for creating a texture generator Daemin and Sh0ck. yeah agreed i think it sounds interesting.. I think it would be a good challenge, and useful for coders everywhere in reducing texture components. ;>
Besides opening and closing textures is something people should be able to do on the fly.
Though i still like the idea of a water simulation, i think it should not be limited by size. though I would add a simple rule of
1. No models, Mesh must be created dynamical, if indeed u choose that path.
2. Hard ware Req min of Pixel and Vertex sader capable equipment. As in get the person or ppl voting to have Pixel and Vertex shader capable equipment. The judges or coders will understand if it lags up on a p166 really who would expect otherwise. (hey it wont even support a agp slot most likely)
3. Size who are you kidding if there aren't models only textures I suggest no more than 2 meg in textures. and no movies. let the program blow out to what ever though. with those restrictions i dont think it will matter too much.. Code Monkeys of any note will have it optimised anyway. (And if you dont know how to optimise code, Are you in the right place?)
I say Cut corners, make it fast, make it look good and realistic. I also dont think it should be judged on textures at all.
If we forced everyone to have a wireframe simulation or a switch to wireframe than we could sort the chalk and cheese a little easier. really. we could see the poly count, the movement and flow of vertices and triangles, which would seem like a more logical approach to evaluation.
Regards to that issue of not submitting your code...... Are you serious, you get the chance to have people look at your code and maybe point out optimisations and learn from mistakes, etc, you could also learn from others code, really i would take the policy of no code, no submission, Coding contests need to be judged on code it self.
Anyway, just had to comment.. been off and aways a bit. in never never land.
0xBaaDf00d
-----------------------------------------
I see you Schwartz is as big as mine
-----------------------------------------
Ok, the programmer challenge will start at the end of this week - (13th of April, Sunday) with approximately 2 months to work on it (until 15th, June, Sunday) . The guidelines will be based on what 0xBaaDf00d was written. If you feel like you want to add anything more, or suggest any ammendments, you have until this Sunday. I'll post the finished guidelines on the front page so everyone can see and get started. [:)]
Water simulation
1. No models, Mesh must be created dynamical, if indeed u choose that path.
2. Hard ware Req min of Pixel and Vertex sader capable equipment. As in get the person or ppl voting to have Pixel and Vertex shader capable equipment. The judges or coders will understand if it lags up on a p166 really who would expect otherwise. (hey it wont even support a agp slot most likely)
3. Size who are you kidding if there aren't models only textures I suggest no more than 2 meg in textures. and no movies. let the program blow out to what ever though. with those restrictions i dont think it will matter too much.. Code Monkeys of any note will have it optimised anyway. (And if you dont know how to optimise code, Are you in the right place?) - 3mb limit
4. Wireframe simulation or a switch to wireframe then we could sort the chalk and cheese a little easier. really. we could see the poly count, the movement and flow of vertices and triangles, which would seem like a more logical approach to evaluation.
5. Source code must be submitted??
Okay I said I wasn't going to comment....but I'm a little pissed that alot of good debating has gone to waste.
1. Look back on the last couple of pages, no one has yet agreed on a good minimum hardware spec that it must be compatible on. If we agree on a high level of hardware (pixel/vertex shader - what versions then?), then obviously presentation is going to be an issue in the demo's judgement, I don't care how much you tell the judges that. If you specify a low level of hardware that must be supported then the code becomes the dominant factor in the judging process.
And look at the mess of Pixel Shader spec? You try running 1.4 on a nVidia card and see how badly is blows it's load. 1.3 not too bad etc.
2. I was going on about creating a series of coding competitions that would ultimately produce one nice big demo as a result. Now it seems as if people wouldn't mind all of a sudden having a small competition like texture generation etc etc to support the later competition. That ****s me off.
3. Source code means what? What libraries can be used - what level of framework is permitted?
I'm not giving my opinion on these things and what should be implemented, I'm just observing. It seems that everytime I hand out my ideas, the good points get ignored and people just bash out the points they disagree with.
Anyway, like I said, good luck guys, but I think what badfood has put down is only some ideas, not a good set of guidelines.
i think the guidelines are a good idea, i mean if you really want to make it run on a high tech machine then you can go for it, but how many people will be able to run it.
Source code, means open source, complete open source, everything thats not a standard api (like directx or opengl), if you have some cool engine your working on and dont want to share it then dont use it. Its only a demo, the framework should be pretty small maybe 100 lines of api/windows setup and then your demo code on top of that.
The main reason we havent been setting rules to go by and making things more open is so coders of all levels can get in on the contest. Thats also why the topic is so general, "water sim" it can be anything about water.
The option to still have a series of demos that all piece together can still happen, later on i plan to put pirate ships on my water with cannons, and then pirates on board that have to insult short fight :P
Also i'll just add this is the 1st sumea code contest, so it would be nice to just get it started one day, and then learn from there. At the moment I'm not even sure how many people are still interested in doing the contest so most this debating over rules could be a waste.
Lets try this again:
1. Challenge: Water mesh must be created dynamically, if indeed you choose that path. You are allowed models for objects that may interact with the water, etc.
2. Hardware spec: Must be able to run on minimum gf2mx. That means selecting software vertex shaders and disabling pixel shaders when nessisary. (The maximum vertex shader version on pre-DX9 hardware is vs1.1, however higher versions can be run in software.)
3. Entry Size: 3MB limit (ZIP or RAR), this includes all libraries needed other then DirectX or OpenGL. (ie. fmod, glut, etc).
Should be able to run after being extracted from the archive.
4. Tech: You must provide a way to turn on and off wireframe rendering of the water at runtime.
5. Source: All source code relevent to the simulation must be submitted in a seperate ZIP or RAR file. (There is no reason to MAKE people give their entire source tree, however they should be free to do so)
6: Entry must be submitted by midnight Sunday 15th of June. Details to follow on how to submit.
Note that if you code an effect that specifically requires pixel shaders, #2 will be waived. But if people can't watch it, they can't vote for it.
Edited cause 3 days isn't enough.
quote:Originally posted by Maitrek
Okay I said I wasn't going to comment....but I'm a little pissed that alot of good debating has gone to waste.Anyway, like I said, good luck guys, but I think what badfood has put down is only some ideas, not a good set of guidelines.
I can take the blame for all that - I'm just trying to get some progress happening and get the challenge off the ground. There's obviously a lot of interest in the challenge, but with no one really taking the reigns of organising the guidelines and finalising all the aspects, it's doomed to remain just a debated topic. (C'mon, it's been 3 weeks already since you started the post!). Granted, a programmer challenge is suitably more complicated than the modeller challenge, but I think it needed a nudge. I thought another 5 days to add and finalise those rules was ample of time to sort things out, and make everyone happy.
And Redwyre, I think you meant must be submitted by midnight Sunday 15th of June? :)
Just thought i should respond to the comments, as Maitrek said mine were just suggestions not the holy grail and that is all I was hoping to achieve, I like the guidelines set out by Redwyre, there they sound good. Personally, The only one I would change is all source code is submitted, this is a create from scratch challenge. Create a new framework to do, that way anything you write will be required for the application and the whole workspace could be submitted ;>
0xBaaDf00d: well, I have a codebase of >20,000 lines of code, some I am proud of, some I am not, and some are my precsious secrets :) I don't want to release it all at this stage, but I will be releasing something that compiles :) And who said it was create-from-scratch? It is my understanding is that the only thing that matters is that all the water simulation code is totally yours.
Maitrek: Just saw your sumea profile, very nice :)
Strik3r: Oh grow up. Poo poo head.
Yes exactly that is the reasoning Redwyre, Small and sweet, we dont want you engine, we just want a tech demo, that is what this contest is about.
How modularised is it, you should be able to pull parts out that are relevant to the contest only and use them alone not the whole structure.
I still think a complete workspace should be submitted, however it is the groups descision, not mine.
PS.
Maybe this place needs a code of conduct to stop people calling each other names? This is not a school yard and as such we shouldn't need rules but Strik3r you have made like 3 posts on here and already you throw insults?
perhaps i have a lighter outlook on life than some people..
i would also like to point out that those supposed "annoying posts" on QANTM forums were not my doing.. i still don't know for sure who did it, but it WASN'T me.
either way im still interested in this programming challenge, and today is the day
yep, yep, yep, yep, yep, and yep.
yep, it all sounds good to me,
im ready to start.
anyone else wanna say something?