| |
ChristopherJam
Registered: Aug 2004 Posts: 1370 |
Event id #2655 : 8K Intro Competition 2017
Inspired in part by Didi's past intro creation competitions (many thankings for those!),
have a four week lightning competition to help you survive the holiday season
- single file one part intro (fade in/out acceptable)
- has a logo+changing text+music
- file size of at most 8192 bytes, including load address (so, 8190 bytes of data).
- no more than 5 seconds decrunch/precalculation time.
- once page is running, exits within 5 seconds of pressing space (should be obviously fading out)
- don't trash any RAM from $2800 to $cfff inclusive (unless you restore it on exit).
- entries uploaded to csdb as runnable .prg, optionally embedded in .d64,
- max three per participant, withdrawals allowed, older entries will be displaced if you've too many.
- competition start: 8th December
- entry deadline: 5th of January, 14:00 (2pm) UTC
- voting deadline: 12th of January, 14:00 (2pm) UTC
- entries will be ranked by CSDb rating, including private votes.
- entries with the same weighted average will be ranked by their percentages of 10s, 9s, etc.
No prizes, just fame :)
Thankings to Jeanette, Krill, Groepaz, and various ICC2016 commenters for helping me to crystallise plans.
Any errors in judgement all my own - I've ignored a lot of good advice :D
Questions and discussion below. |
|
... 71 posts hidden. Click here to view all posts.... |
| |
Trasher
Registered: Sep 2009 Posts: 8 |
ChristopherJam: In the case of #2, I think of intros that are a 2-3 blocks long.. or say 10 blocks max.. Including scrolltext. Just as a reference to your crunched 32+ blocks.
The separation of packing/crunching is still valid unless you can separately crunch both intro and game, without the decrunch of the intro destroying the game. I guess this is what you somehow discuss.. Obviously back then it was also a matter of runtime, crunching might take 12-15 hours.
But hey - it's your compo and idea, so do it as you like! I just feel it's not crack-intro style - at all.. And maybe that's not the point. |
| |
ChristopherJam
Registered: Aug 2004 Posts: 1370 |
Quoting TrasherChristopherJam: In the case of #2, I think of intros that are a 2-3 blocks long.. or say 10 blocks max.. Including scrolltext. Just as a reference to your crunched 32+ blocks.
Interesting. I was going for something a bit tighter than last year's 64 blocks, but thought that four weeks might be a bit short a time period to be asking for 16 blocks or smaller.
Quote:The separation of packing/crunching is still valid unless you can separately crunch both intro and game, without the decrunch of the intro destroying the game. I guess this is what you somehow discuss.. Obviously back then it was also a matter of runtime, crunching might take 12-15 hours.
Ah yes - I was thinking the decrunch time between intro and game might be a factor, but I hadn't considered the logistics of running two seperate crunches overnight, one for the intro the other for the game. Challenging times back then!
The idea behind this competition is indeed to decrunch the intro in such a way as to leave the game undisturbed. Perhaps it would help to imagine that the game has decrunched to $2800-$cfff, but has yet to be unpacked...
Quote:But hey - it's your compo and idea, so do it as you like! I just feel it's not crack-intro style - at all.. And maybe that's not the point.
Again, I genuinely appreciate the historical context. While I'll keep the rules for this weird hybrid as they stand, it's definitely something to be kept in mind for a future event. |
| |
Trasher
Registered: Sep 2009 Posts: 8 |
All good CJ! Would be interesting to hear other crackers comments to this. |
| |
Cruzer
Registered: Dec 2001 Posts: 1048 |
These rules are a nightmare. Probably not gonna compete. |
| |
ChristopherJam
Registered: Aug 2004 Posts: 1370 |
Cruzer, I'm curious - would you have been interested if the rules were a straight "don't use any RAM above $2800 aside from interrupt vectors and colour RAM"? |
| |
Tim Account closed
Registered: Mar 2002 Posts: 467 |
hmm,
imho just define max size of code AND sid.
for example not every coder will have access to a musician that can do wonders in tiny memory size due to not having a capable player made for this task. (and I say that with the utmost respect to hero's like GRG or Jeff that do this beautifully) |
| |
chatGPZ
Registered: Dec 2001 Posts: 11092 |
wat |
| |
ChristopherJam
Registered: Aug 2004 Posts: 1370 |
Tim, there are over 30,000 SIDs in HSVC under 4k in size (more than half of them!) That still leaves you with 4k for code and data.
Haven't checked play location but I remember $1000/$1003 being common too; any of those wouldn't even need relocating.
(obviously original music preferred, but I remember reuse being the rule rather than the exception back in the day) |
| |
Hein
Registered: Apr 2004 Posts: 933 |
The rules do allow us to use a wopping 22k. With the old rules (16k) I was having more trouble fitting the provided gfx. Double buffering is also easier now.
Maybe Cruzer had a beautiful one-bank-carpet of interwoven code, music and graphics. |
| |
Dr.Science
Registered: Oct 2011 Posts: 39 |
Ok, just to make sure even I understand it. If I have my music at $1000-$1a00 and some data-tab at $1a00-$1fff - I will crunch the music and the data which will result in maybe $1000-$1600 (just an example). So what I do is have that packed data in my intro, and when intro starts depack the music to eg $e000-$ea00 and the data-tab to $ea00-$efff.
Which gives me $1600-$1fff free for other data and plus I can use $1000-$1600 on the fly...After exit of intro there is NO NEED to clean up $e000-$efff which I messed up? |
Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 - Next |