| |
Didi
Registered: Nov 2011
Posts: 488 |
Event id #2757 : Intro Creation Competition 2018
Preface: Please use this thread for questions, discussion and everything else concerning this competition.
After ChristopherJam had the chance to run a similar compo last year, this year I am back with the known ruleset, with only slight change.
Runnning the competition after X party turned out to be a great timeframe, so I stay there.
Competition runs from November 5th, 2018, until January 6th, 2019. So you have a full 2 months to deliver your creations. This should be enough for an intro.
THE RULES:
Your intro...
- has to work on a plain stock C64 (PAL standard) without any extensions.
- has to be a one-part intro. Short 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).
- has a maximum RAM footprint of $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. This means RAM besides chosen $4000 bytes area and exceptions has to be the same before and after running the intro. What happens during runtime is up to you.
- has to be interruptable any time by pressing SPACE-key (exception are short fade-in and fade-out).
- does not need to have exclusive graphics, charsets or music. But the code should be exclusive, so reuse of existing code with just exchanged graphics and music is not allowed.
- has not been publicly used before entering the competition.
- has to be handed in as executable format startable with RUN (.prg or embedded in .t64 or .d64).
Maximum 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 Sunday January 6th, 2019 at 23:59:59 (11:59:59 pm) CET.
Voting closes at Sunday January 13th, 2019 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! |
|
... 155 posts hidden. Click here to view all posts....
|
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Just checking my understanding of the memory restriction:
I gather *post decrunch* anything you touch anything outside
- $0000-$01ff
- your chosen 16k block
- $fffc-$ffff
- the IO area (VIC, SID, CIA 1&2, colour RAM)
must be be restored upon exit.
Is that correct? |
| |
Krill
Registered: Apr 2002
Posts: 2982 |
Quoting ChristopherJam- $fffc-$ffff
Plus $fffa/b, i hope? :) |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Quoting ChristopherJam[...]must be be restored upon exit. As I understood it from earlier years, you couldn't touch anything outside these areas, regardless of whether it was restored. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
From the rules:
Quote:RAM besides chosen $4000 bytes area and exceptions has to be the same before and after running the intro. What happens during runtime is up to you. |
| |
Didi
Registered: Nov 2011
Posts: 488 |
That's the new part of the rules. You may use RAM outside the chosen $4000 but you have to restore it to its previous content on exit. I mean really restore it, so e.g. clearing the normal screen RAM at $0400-$07ff does not mean "restore". ;)
I took that inspiration from the discussion thread of ICC 2016, hoping it opens new possibilities for some people. |
| |
Krill
Registered: Apr 2002
Posts: 2982 |
Oh, so having sparse memory layouts for certain VIC effects is legal? As in, e.g., a few bytes at every $0400 bytes block boundary throughout the entire address range? Cool as long as they're restored to their original contents after intro? |
| |
Didi
Registered: Nov 2011
Posts: 488 |
Yep. It's an experiment. Let's see what comes along.
That's why I called it "has a maximum RAM footprint of $4000 bytes at one block" this time. |
| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
Isn't most of the memory just zeros or some pattern alternating 00 ff ? If i can generate lots of speedcode to some upper memory and the zero it out or fill it with the default memory pattern it would be perhaps too easy ?
I'm trying to make my intro only use $4000 - $7fff, maybe i'll use more if others do to. |
| |
Krill
Registered: Apr 2002
Posts: 2982 |
Quoting DidiThat's why I called it "has a maximum RAM footprint of $4000 bytes at one block" this time. That's not exactly unambiguous. So, in other words, "Payload is $xxxx* bytes in one contiguous chunk of memory before running the intro and is expected to be the same after running the intro, but may be changed at will while running the intro."?
* $xxxx would be something slightly smaller than $c000, maybe $bdfa = $c000 - $0200 - 6, so 64k minus intro minus zeropage minus stack minus vectors? |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Quoting GolaraIsn't most of the memory just zeros or some pattern alternating 00 ff ? If i can generate lots of speedcode to some upper memory and the zero it out or fill it with the default memory pattern it would be perhaps too easy?
It's an intro competition, so my understanding is that we are to imagine that most of memory is filled with a compressed copy of the game it is introducing.
Hence, we can copy it to somewhere within our 16k block for later copying back, but even assuming it to be compressible would be on very shaky ground, never mind assuming it contains a specific pattern. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | ... | 17 - Next |
