| |
Didi
Registered: Nov 2011
Posts: 487 |
Event id #2889 : Intro Creation Competition 2019
Preface: Please use this thread for questions, discussion and everything else concerning this competition.
Many people were asking about the competition being held this year. It turned out to be a good place to have it after the big X party each second year. But why not give it a try in between?
This time I decided to add a second category to the well known rules: 4kB intro! It is different to the 4kB intro category you know from demo parties. There the executable file has the limit of 4096 bytes and may allocate as much as you like during runtime. Rules here only allow to use 4kB overall for a different challenge. Please check the rules for more details. Result will show if that was a good idea.
Here you go...
Competition runs from November 4th, 2019, until January 5th, 2020. So you have a full 2 months to deliver your creations. This should be enough for an intro.
RULES for both categories:
Your intro entry...
- 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 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).
Your 16kB intro...
- 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 contain music (not just a humming sound, please).
- is linked to this competition as "C64 Demo" entry (sorry, no other fitting entry exists).
Your 4kB intro...
- has a maximum RAM footprint of $1000 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 $1000 bytes area and exceptions has to be the same before and after running the intro. What happens during runtime is up to you.
- does not have to contain any sound, but feel free to add some.
- is linked to this competition as "C64 4k Intro" entry.
You are allowed to enter maximum 3 entries per participant and category, so you are can enter 6 entries at best. 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 5th, 2020 at 23:59:59 (11:59:59 pm) CET.
Voting closes at Sunday January 12th, 2020 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! |
|
... 173 posts hidden. Click here to view all posts....
|
| |
Smasher
Registered: Feb 2003
Posts: 520 |
Quote: I don't know about you, but I never made any effect with the aim to fit into 4 or 16kb. I was just writing something and then it turns out it's small or could be smaller without much effort.. I guess I'll use it for 4/16kb intro then. Then you add music, graphics, "design" and it's over the limit by 500 bytes and rest few weeks is just triming the fat everywhere. I like it honestly
I quote you 100% :) |
| |
TheRyk
Registered: Mar 2009
Posts: 2240 |
If you do sth with various extremely polished sprite fonts over a fancy bitmap gfx with some huge .SID, there might be stuff where a full VIC Bank of RAM comes quite handy and makes sense, agreed. I didn't want to bash 16K competitors, though I'm happy if some of you lazy bastards feel a little provoked/challenged, hehe.
All I'm saying is 16K frequently doesn't require any optimizing/half-smart coding. Maybe it's just me (who doesn't know any bitmap gfxians that ain't lazy bastards so I rather use ROM or coder gfx anyway so I never need much RAM for visuals), but 16K (=no) limit often made me go lazy and think "why bother optimizing stuff like unrolled loops, e.g. by a code generator or self-modifying routine - when exomizer can do all the work more efficiently anyway with regard to crunched file." That's why I like the 8K hosted by CJ better and this 4K even more. Looking 4wd to doing 2K and 1K ;) |
| |
Krill
Registered: Apr 2002
Posts: 2979 |
Quoting TheRyk"why bother optimizing stuff like unrolled loops, e.g. by a code generator or self-modifying routine - when exomizer can do all the work more efficiently anyway with regard to crunched file." Because if you can generate code at run-time, you can squeeze in more variations and possibly more effects, too. =)
Really, any given set of platform limitations allows for a continuum of information density. Meaning if you can easily pull off an effect, it probably means there are more impressive things possible within the same limitations. :D |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Perhaps a silly question, but what is the state the intro is supposed to start from? Stock C64 after a cold start without any cart/custom ROM? In other words: can I rely on a 'default' VICII, $01, CIA state? |
| |
Didi
Registered: Nov 2011
Posts: 487 |
I smell dirty tricks. :-)
4kb should give enough space for proper initialisation of e.g. needed zero pages IMO. CIA and VIC values should be default post-reset state. |
| |
TheRyk
Registered: Mar 2009
Posts: 2240 |
Compyx: Feel free to check KERNAL ROM listing for initialised RAM, afair SOME values can be relied on :) Though I think compatibility is clearly desirable (and I even cared about old KERNAL revs), imho "working on stock KERNAL V3" must count as valid entry even if it fucks up with old rev or $hankypanky ROM/CRT |
| |
Danzig
Registered: Jun 2002
Posts: 440 |
Quote: I smell dirty tricks. :-)
4kb should give enough space for proper initialisation of e.g. needed zero pages IMO. CIA and VIC values should be default post-reset state.
you can initialize with like sta $d000,x by the way. that was a well used pattern in the 80ies :-) so a little math here:
10 bytes lda#/sta$ for 8 x&y sprites results in 80 bytes.
lda$/sta$ to d000, with loop makes ~11 bytes + 16 for x&y is like 27 bytes or alike. setting $d010 makes + 1 byte or + 5 for lda#/sta$
and this is a naive approach, taking no optimizations into account. And it's not limited to sprites initalization, just taken as a proper example.
@Didi: please cancel 16k and start it after the 4k ;-) |
| |
Smasher
Registered: Feb 2003
Posts: 520 |
Quote:@Didi: please cancel 16k and start it after the 4k ;-)
no |
| |
Didi
Registered: Nov 2011
Posts: 487 |
Running 4k and 16k together is an experiment. Maybe the 16k entries just take a bit more time to think what to do with that lot of RAM. ;) |
| |
Dwangi
Registered: Dec 2001
Posts: 130 |
No there are people who used to release intros in the last minute.
Remember last year Cruzer had the lead until the last day I think.
then Jammer came .. |
| Previous - 1 | ... | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | ... | 19 - Next |
