| |
Monte Carlos
Registered: Jun 2004
Posts: 355 |
Event id #2416 : First CSDB "Unintended OpCode coding competition"
Just wanted to make my new compo idea more visable to the audience:
First CSDb "Unintended OpCode coding competition"
(unintended opcode coding competition)
Feedback welcome! |
|
... 19 posts hidden. Click here to view all posts....
|
| |
Monte Carlos
Registered: Jun 2004
Posts: 355 |
Politics is the best example how to interpret rules most extended ...
Soci: Please do not wait, if you have a good idea fitting into this compo ;-) |
| |
T.M.R
Account closed
Registered: Dec 2001
Posts: 749 |
i sort of like the idea but the rules... nah, they're more frustrating than trying to get something interesting going with UOCs in the first feckin' place! i think i'll go sit with soci and wait to see if the rules get simplified before writing any more code. |
| |
Monte Carlos
Registered: Jun 2004
Posts: 355 |
I look very positively forward regarding this compo as the discussion signals principal interest of the CSDB community.
Despite this there is a little bit frustration about the rules which is shared by several members.
Of course my interest is a lively competition and therefore i though about simplification of the restrictions.
To avoid changing the rules again and again i post my new proposal here so that everybody can give feedback within the next three days. Then i'll work through the critiques, find a compromise and fix the new rules permanently.
new rulez
The Demo must
- make heavy use of NMOS6510 unintended opcodes and gain profit from the extended instruction set
- emphasize on coding and the main effect
- be onescreen and onefile
- include the credits and reference to csdb and this compo
- be runable on a stock c64
- be startable with the "run" command
The demo may
- use also other elements like sprites/grafics/music but they should not be as dominant as the
the main effect
- use material from some CSDB competition before, preferably which is unused else.
- show a simple text screen (without any other elements) with explanation directly after run from which you turn to the main part using space.
There must be some explanation of where, how and for what the UOCs have been used and what advantage you get over normal ops.
Additional information which does not fit on a single textscreen can be supported in a readme.txt or using the CSDB. You may write prose or include the explanation as a commented source.
In this case not every opcode should be documented but only the essential parts. |
| |
T.M.R
Account closed
Registered: Dec 2001
Posts: 749 |
That looks a lot easier to deal with at least to me and i have about an idea and a half now.
The only "worry" i've got is "use also other elements like sprites/grafics/music but they should not be as dominant as the the main effect" because how do you call that? With the winner being decided by CSDb vote there are always going to be people scoring on other elements apart from the code... |
| |
Monte Carlos
Registered: Jun 2004
Posts: 355 |
I can understand this although i had another idea:
What is about parts which needs some grafics? For example
sprite multiplexers need sprites which are probably drawn by a grafician, 7 sprites over fli needs an example picture or texture mapped cubes needs textures.
How do we distinguish unneccessary design from essential one? Wheres the limit?
Thats why i allowed these things generally.
Could you live with some unconvential solution, for example voting every contribution with 10 as bad as it could be?
Then we could make a competition without pressure of getting good votes and just profiling from the comments of other users?
This would also circumvent the situation of genious invention presented in a small area on an otherwise empty screen. |
| |
Count Zero
Registered: Jan 2003
Posts: 1878 |
T.M.R. - just write on screen that you "UOC" is used on 51% of the rastertime and the digi sound is only at about 10% :) |
| |
T.M.R
Account closed
Registered: Dec 2001
Posts: 749 |
Quoting Monte CarlosI can understand this although i had another idea:
What is about parts which needs some grafics? For example
sprite multiplexers need sprites which are probably drawn by a grafician, 7 sprites over fli needs an example picture or texture mapped cubes needs textures.
How do we distinguish unneccessary design from essential one? Wheres the limit?
Even if design is necessary there's no guarantee that people voting will be able to distinguish it from the UOC-powered effect... but my worry is that, even if you're not planning to police this too closely, it could still flag someone's hard work as a "false positive".
The only way to remove the issue is to either be reasonably sure that people vote for elements you want them to by selecting a panel of judges or, because it's a fun compo, not worrying about it; the winner will, ultimately, be the person with the most impressive code even if the votes here don't reflect that. |
| |
T.M.R
Account closed
Registered: Dec 2001
Posts: 749 |
Quoting Count ZeroT.M.R. - just write on screen that you "UOC" is used on 51% of the rastertime and the digi sound is only at about 10% :)
Yeah, because nobody is going to be delving around the source or anything... oh, hang on. =-) |
| |
Oswald
Registered: Apr 2002
Posts: 5074 |
btw, could we call it - as it is better known by this name - illegal opcode ? UOC makes my brain hurt :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11290 |
imho this compo only makes sense if a (well commented) source is mandatory... else you can just call it "onefile demo compo" :) |
| Previous - 1 | 2 | 3 - Next |
