| |
Raistlin
Registered: Mar 2007
Posts: 627 |
Intro Compos - and Size Coding
I wanted to bring this topic up again.. as I know it was discussed before between TheRyk, Krill, Jammer, GPZ and others.
Size-limited intro compos. WHY are they restricted to limited RAM?
An intro compo, for me, shouldn’t be about pretending that C64 has limited memory. Intros should really just be appropriately sized “hey, we cracked this, we’re awesome, hello to our friends!” things to impress.
A 1k intro would normally be linked to a <4k game.. so if it chose to expand to 48k, but only added 1k or less to the file size, that would be fine. In the real world. The person playing the cracked game really doesn’t care less what the intro’s doing. It’s just an intro.
The argument that “we’re turning an intro compo into a compressed demo compo” seems backward. That’s not it at all. By adding the extra restrictions, you’re actually saying it’s not an intro compo at all - it’s now a size-coding compo.
My 2c.
Ps. Recent discussion on this was here: https://csdb.dk/forums/?roomid=12&topicid=158496&showallposts=1 |
|
... 28 posts hidden. Click here to view all posts....
|
| |
Raistlin
Registered: Mar 2007
Posts: 627 |
Quote: Well, intros used to be _all_ about size. The TRIAD "Mr. Z intro" is a good example.
It could be argued that size doesn't matter so much anymore when there are really fast loaders and alternative storage solutions with more space, but IMO an intro for a crack should try to be below 1k.
...and size coding is fun!
Definitely intros were always about size. I say that in my original post. IMO, an intro shouldn’t add much more than 25% to the size of the initial game it’s linked to.. preferably much less.
But… my point was that if a 1k intro is linked to a 1k game, why not use the other 62k? Outside of compos, proper intros could definitely do that - why wouldn’t they if they allowed them to be somehow cooler? By using the extra 62k, I don’t mean increasing the size of the crack (intro + game), I’m talking about the intro generating code and/or data to somehow improve the intro’s effect.
But I guess intro compos aren’t just about intros.. the added restriction makes it more like a size coding compo with restrictions. Which I can of course understand the interest in. |
| |
tlr
Registered: Sep 2003
Posts: 1762 |
Quoting RaistlinBut… my point was that if a 1k intro is linked to a 1k game, why not use the other 62k? Outside of compos, proper intros could definitely do that - why wouldn’t they if they allowed them to be somehow cooler?
At runtime, sure. But not in binary size, because loading time and space it takes up on a disk.
Quoting RaistlinBut I guess intro compos aren’t just about intros.. the added restriction makes it more like a size coding compo with restrictions. Which I can of course understand the interest in.
You could argue that the whole c64 (and retro computing) scene in general is all about restrictions already. Nothing wrong with a few more to encourage creativity. |
| |
Krill
Registered: Apr 2002
Posts: 2940 |
Quoting RaistlinBut… my point was that if a 1k intro is linked to a 1k game, why not use the other 62k? [...] I’m talking about the intro generating code and/or data to somehow improve the intro’s effect. This boils down to the same "pls provide payload to link with" argument.
Question would be how to properly formalise that for a compo. Either you make the payload so big as to implicitly enforce a memory footprint restriction on the intro, or the payload is smaller and then... require the intro to be no more than a fourth of the payload's size? On disk? After decrunch? Or require crunched intro+payload not to exceed 125% of payload size? Etc. =) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11293 |
Now someone please make a tool that generates a binary containing random uncompressable bitsalad, plus a piece of code that checksums it for validation, so i don't have to do it :) |
| |
tlr
Registered: Sep 2003
Posts: 1762 |
Quote: Now someone please make a tool that generates a binary containing random uncompressable bitsalad, plus a piece of code that checksums it for validation, so i don't have to do it :)
cgen of cbmtools 0.9 does this, but currently only with compressible data. I could add such an option if there is public demand. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11293 |
Do it! (checker code should probably be position independent) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1403 |
So are we talking ~56KiB of random bits to pretend we're doing a trad style "running the intro after decrunch but before unpack," or? |
| |
Raistlin
Registered: Mar 2007
Posts: 627 |
Just to reiterate my original point..
In the OLD days, the really old days, all that we cared about was the size of the file. If a game was 4k, and we linked a 1k intro, so maybe we increased a 16 block game to 17 or 18 blocks, nobody could care less if the cool intro that we slapped on the front used all the spare memory or it just stuck to bank 0. Only the block size mattered, did the game work, were there cool trainers and how good is the intro? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11293 |
You are conveniently ignoring that crack intros were universal things used with dozens, or even hundreds, of different releases :) |
| |
Oswald
Registered: Apr 2002
Posts: 5076 |
I can tell you that with raster plaster I shat bricks to make it fit into working 16k memory. you cant even unroll raster code. |
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
