| |
Didi
Registered: Nov 2011
Posts: 478 |
Event id #2526 : Intro Creation Competition 2016
Sorry for skipping this event last year, but life is life and I simply would not have had the time to host this event in a proper way.
So finally X 2016 is over and the big productions are out. So maybe you are in the mood for a smaller project.
Competition runs from November 1st, 2016, until January 3rd, 2017. So you have a full 2 months to deliver your creations. This should be enough for an intro.
Please use this thread for questions, discussion and everything else concerning this competition.
THE RULES (same as in 2014, worked very well):
- Has to work on a plain stock C64 (PAL standard) without any extensions.
- Has to be a one-part intro. Fade-ins and fade-outs are OK.
- Has to contain at least one Logo at whatever size you like.
- Has to contain a changing or moving text message (e.g. scrolling text, different lines fading in & out, etc.)
- Has to contain music (not just a humming sound, please).
- Maximum RAM usage is $4000 bytes at one block, at whatever location you like. Screen RAM counts as used memory. Exclusions are system addresses like VIC (inkl. Color RAM), SID, CIA, Stack, Zero-page, IRQ vectors.
- Has to be interruptable any time by pressing SPACE-key (exception are fade-in and fade-out).
- Graphics, charsets and music do not need to be exclusive, but the code should be! So no reuse of existing code with just exchanged graphics and music.
- Intros may not have been used before entering the competition.
- Entries must be handed in as executable format startable with RUN (.prg or embedded in .t64 or .d64).
- Max. 3 entries per participant. Entries might be taken back from the compo until deadline. That means if you want to remove one of your works from the compo to make space for another entry from you, this can be done until deadline.
Deadline for entry submission is January 3rd, 2017 at 23:59:59 (11:59:59 pm) CET.
Voting closes at Sunday January 8th, 2017 at 23:59:59 (11:59:59 pm) CET.
Voting platform is CSDb (with all disadvantages it may have), therefore entries have to be posted here.
Entries will be ranked by weighted average of CSDb votes. Entries with the same weighted average are ranked by their percentages of 10s, 9s, etc.
No prices to win, just the fame. May the best creation win! |
|
... 274 posts hidden. Click here to view all posts....
|
| |
ws
Registered: Apr 2012
Posts: 228 |
Krill, what up? The limitations are the actual fun of it. I find them even pretty flexible because they're not saying like "well you got fixed mem up to $3fff". I find it quite reasonably set. And still, some managed to overstep :-) What i personally find far worse is the voting system. If it was me, i would make anonymous votes optional per production (set by the uploader/author). Hell if i get no public votes, what gives. But Trollvoting anonymously just to avoid revenge, thats just plain cowardish. :-D |
| |
ws
Registered: Apr 2012
Posts: 228 |
And: no one hinders anyone from making a competition where you have to include a very large compressed file that you have to restore and jump into, after pressing space. That would actually be alot more helpful, since i am not sure that i could jump back to a working basic, for instance without requiring more space. |
| |
Krill
Registered: Apr 2002
Posts: 2825 |
Ah, anonymous voting, another pet peeve of mine. :)
But still, the rules are stricter than for actual intros for actual games, with that weird contiguous memory usage without touching the program blob. And the only way to really enforce that is to run an emulator and check all memory writes for illegal access. How sensible. |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Krill: You're right of course, except that it would require that all participants linked the same 48K blob, which would make it harder to do a nice collection of the entries without taking up 4 times as many d64's. And I still like the limitation of 16K in one continuous area, since it means that I'm more impressed when people do something like what ChristopherJam did. |
| |
Krill
Registered: Apr 2002
Posts: 2825 |
ChristopherJam: The only sensible artificial rule is limiting executable size, as in space on disk (or wire, if your prefer). Anything else is pretty much given by Word of God, i.e., the limitations of the machine. Just my 2 cents. :) |
| |
Krill
Registered: Apr 2002
Posts: 2825 |
Quoting Cruzerit would require that all participants linked the same 48K blob Why? 1. Intro starts 2. Intro moves arbitrary program parts to a backup area included in its 16K 3. Intro writes data to original location of backed up program parts 4. Intro runs 5. Space 6. Intro restores program by copying back data from backup area to original locations 7. Program is the same as before intro started 8. Intro runs program.
No reason to actually link anything, not to say the very same blob for every intro. |
| |
Krill
Registered: Apr 2002
Posts: 2825 |
Quoting ScanThat being said, I admire your work on your loader. ;) Thanks, but i hope you're also aware of all those demos (size-constrained or not) and intros i made throughout the years. :) |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
16kb was more of a challenge than I thought, in the very end I was hunting for 16 bytes here 8 bytes there. Had to sacrifice a lot of speed for memory. (bye bye super fast multiply with 2k table)
even with a 4k, or 1k you have the whole 64k to generate code / tables into, and for display. so in a way this is more restrictive. |
| |
Jammer
Registered: Nov 2002
Posts: 1289 |
Damn, have your share of tasty Snickers, sir ;) |
| |
Krill
Registered: Apr 2002
Posts: 2825 |
Quoting Oswald16kb was more of a challenge than I thought [...] so in a way this is more restrictive. It is. I'm still just saying that while limiting to 16 K (or whatever) is all fine and dandy, ALSO limiting to one contiguous chunk of memory is just nonsense. Over-restrictive, so to say. |
| Previous - 1 | ... | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | ... | 29 - Next |
