Would 16k be a thing?
category: general [glöplog]
Hello there,
so this release at revision made me think once again about a 16k intro limit.
There is no doubt that the 8k category made some really great intros possible which I believe couldnt have been done this way in just 4k (at least not without shitloads of work), but many of the intros carry the style 4k has coined in the past 10 years or something.
So I am wondering if 16k are enough to make a difference on the technical approach.
I am not a coder and as thus cannot judge exactly what you can all do within that size but I know its not just "4 times a 4k" or "2 times an 8k" but there are a lot of possible usage-scenarios for those bytes instead, not even counting in more effective compression.
So what do you think? Is this a thing worth going on about or would it be more like a poor mans 64k or a really oversized shader-intro?
so this release at revision made me think once again about a 16k intro limit.
There is no doubt that the 8k category made some really great intros possible which I believe couldnt have been done this way in just 4k (at least not without shitloads of work), but many of the intros carry the style 4k has coined in the past 10 years or something.
So I am wondering if 16k are enough to make a difference on the technical approach.
I am not a coder and as thus cannot judge exactly what you can all do within that size but I know its not just "4 times a 4k" or "2 times an 8k" but there are a lot of possible usage-scenarios for those bytes instead, not even counting in more effective compression.
So what do you think? Is this a thing worth going on about or would it be more like a poor mans 64k or a really oversized shader-intro?
Just do it.
I think a 16k would be my choice of "I wanna do a small thing but not spend ages getting it down to 4-8k or getting obliterated by 64k" if I wanted to try out some small stuff. It seems like a nice limit in the sense that it makes non-pure shader based approaches much more viable, as well as multiple separate parts that are not just shaders, or shaders that could carry a lot of offline calculated data.
In practice though, I think it would end up as either as poor man's 64k or "compo I put my 4k in that I didn't feel like optimizing"
In practice though, I think it would end up as either as poor man's 64k or "compo I put my 4k in that I didn't feel like optimizing"
Quote:
but many of the intros carry the style 4k has coined in the past 10 years or something.
Which means we have just barely gotten started, as loonies' excellent winning 8k from Revision just showed.
As Saga Musix says, demoscene just started exploring 8k, so I guess we are not ready yet for 16k.
Personally, I would like to see 128k as an experiment instead ;)
At least Gargaj would be able to go wilder with his doomsday plots.
Personally, I would like to see 128k as an experiment instead ;)
At least Gargaj would be able to go wilder with his doomsday plots.
Quote:
At least Gargaj would be able to go wilder with his doomsday plots.
Is that a Pandora's box we really would want to open?
Huh?
Quote:
existing evidence
There are a lot of good 16k categorized prods indeed but if you look closer you will find almost none of the top ones are really 16k bust just >8 and so this was the next best category for them.
Also I dont want to say 8k should be changed or anything. Its a great format and I think there is indeed much left to explore, but one doesnt have to exclude the other, does it?
I think it's worth noting that the release in question (mine) arguably could have been an 8k if I'd spent time optimizing it down further and learning more of the available tooling (and indeed if I'd targeted windows).
I think we should at least have more than "a newbie's badly-optimized first prod" as the spark for a new size limit ;)
I think we should at least have more than "a newbie's badly-optimized first prod" as the spark for a new size limit ;)
Quote:
Quote:but many of the intros carry the style 4k has coined in the past 10 years or something.
Which means we have just barely gotten started, as loonies' excellent winning 8k from Revision just showed.
This.
What was the reasoning to let 4k become one of the size limit standards?
I think 4k is just about to get really interesting and 8k is just about to slowly develop/show its own traits, introducing "official" 16k seems a bit early.
tl;dr: IMHO 16k is too "easy".
When we (a certain circle of people - you know who you are) discussed whether we should try 8k or 16k, we came to the conclusion to try 8k because it's probably more interesting from certain points of view. It's not like someone woke up and said "uhh let's have an 8k compo". 8k makes sense. 16k does too, but it's waaaaay closer to 64k than we wanted. While it's there for a while now, 8k is still unexplored territory. There's nothing wrong with 16k, but it's just "too much space" if you want something that's subjectively "in the middle".
8k is still very accessible for beginners - just take some random framework, add 4klang, start doing something.
When we (a certain circle of people - you know who you are) discussed whether we should try 8k or 16k, we came to the conclusion to try 8k because it's probably more interesting from certain points of view. It's not like someone woke up and said "uhh let's have an 8k compo". 8k makes sense. 16k does too, but it's waaaaay closer to 64k than we wanted. While it's there for a while now, 8k is still unexplored territory. There's nothing wrong with 16k, but it's just "too much space" if you want something that's subjectively "in the middle".
8k is still very accessible for beginners - just take some random framework, add 4klang, start doing something.
As I see it, 4k is just enough for decent rendering, some interesting content and music. It's a solid challenge to make something good in 4k.
8k doesn't change the basics much, but it gives you enough room to go a little bit wild with what you can do in 4k (the loonies 8k being a great example, I think there's nothing there you can't do in 4k, except all of it at once, and it's all of that at once that makes it so good).
16k doesn't change that much, it just gives you even more room. There's not enough room for any serious data, just much more of similar stuff. Maybe you could start to use some 64k like techniques, but only just.
8k doesn't change the basics much, but it gives you enough room to go a little bit wild with what you can do in 4k (the loonies 8k being a great example, I think there's nothing there you can't do in 4k, except all of it at once, and it's all of that at once that makes it so good).
16k doesn't change that much, it just gives you even more room. There's not enough room for any serious data, just much more of similar stuff. Maybe you could start to use some 64k like techniques, but only just.
I can see 4k changing soon anyway - we're starting to move from raymarching to pathtracing, and that has a different set of things it's good and bad at so the style has to be different to make it work well.
you gotta see it like this:
8K compared to 4K is more like exponential than doubled(multiplied by 2)...why? let´s calc a bit:
0.6k-0.8k Basecode (open a Window, initialize some sort of Framebuffer with used Graphics-API)
+ 1.5k-2.0k Music (Replayer + Songdata)
= 2.1-2.8k used.
In case of 4K there´s about 1.3-2.0k left for effect-code.
In case of 8K there´s about 5.3-6.0k left for effect-code.
Now you see why i said "more like exponential"
4Ks went into a direction where you want all your effects-code in the shaders, simply because it is just ASCII and that crunches away a lot better than normal code (in C,C++ or whatever language).
Many of us coders (including me) still went that route for 8Ks, just because we got used to it i guess. (this is also the explanation for why we say 8K is too much space, i have no idea how to fill all of this and lots of 8Ks end up being 6Ks)
But knowing all that you see that we now can do stuff outside the shader again (in normal code, eventhough it won´t crunch away that well) which ain´t that explored yet naturally!
My opinion about 16K is like:
-too much space to be filled without some sort of Editor (as used in 64ks -> werkkzeug etc.)
(would end up in a lot of procedural-code that would add to the 16Ks filesize again. Also Editors would take away the coders-freedom-of-choice-what-to-code we wanted in <64K-categories)
-too many categories to choose from (and to handle for compo-orgas)
(8K ain´t even got adopted by smaller parties yet because of fear of too few entries, be it in the 4K or 8K-category, because ppl invest their time in just one of them)
8K compared to 4K is more like exponential than doubled(multiplied by 2)...why? let´s calc a bit:
0.6k-0.8k Basecode (open a Window, initialize some sort of Framebuffer with used Graphics-API)
+ 1.5k-2.0k Music (Replayer + Songdata)
= 2.1-2.8k used.
In case of 4K there´s about 1.3-2.0k left for effect-code.
In case of 8K there´s about 5.3-6.0k left for effect-code.
Now you see why i said "more like exponential"
4Ks went into a direction where you want all your effects-code in the shaders, simply because it is just ASCII and that crunches away a lot better than normal code (in C,C++ or whatever language).
Many of us coders (including me) still went that route for 8Ks, just because we got used to it i guess. (this is also the explanation for why we say 8K is too much space, i have no idea how to fill all of this and lots of 8Ks end up being 6Ks)
But knowing all that you see that we now can do stuff outside the shader again (in normal code, eventhough it won´t crunch away that well) which ain´t that explored yet naturally!
My opinion about 16K is like:
-too much space to be filled without some sort of Editor (as used in 64ks -> werkkzeug etc.)
(would end up in a lot of procedural-code that would add to the 16Ks filesize again. Also Editors would take away the coders-freedom-of-choice-what-to-code we wanted in <64K-categories)
-too many categories to choose from (and to handle for compo-orgas)
(8K ain´t even got adopted by smaller parties yet because of fear of too few entries, be it in the 4K or 8K-category, because ppl invest their time in just one of them)
personally i feel there are way, way too many sizecoding-focused compos already on the menu and i'd far rather see new accessible variations on the _demo_ compo added instead. perhaps "30 second demo" or a "realtime graphics" compo where there's only 1 scene and no music allowed. something with a lower barrier to entry than the (probably rather intimidating) main pc democompo that could happily be pulled off in a few days.
smash: Cool ideas! The previous "30 second demos" were really cool, and it makes sense to have a graphic equivalent of the "Executable Music"
i'm not sure there is much of a point. the large majority of punters at a party have a good understanding of size or system restrictions so simply putting it onto your beam slide should be good enough. most parties are nowhere near as big as revision and tend to combine intro and demo compos is varying ways. the size is shown on the beam slide and everyone understands. also looking at the quantity of output for 8k compos is probably quite telling of the situation.
I never understood why there was an 8k compo in the first place. If there's need for an additional compo between 4k and 64k (is there?), then it should be at the (logarithmic) half-way point, i.e. 16k. The existing 8k intros didn't convince me that 8k was a good idea -- they are basically large 4k intros with some additional bells and whistles, not something that really stands on its own feet IMHO.
Smash's suggestions are excellent BTW!
Smash's suggestions are excellent BTW!
There used to be an imprecise category called dentro for smaller stuff.
As a coder I’d like to make tight demos of around 1:30 with everything inside well done.
I believe musicians are going to hate this format though. Not enough time to get the listener immersed in the track. And viewers are probably going to hate it too if it is really good, but too short.
If the music sucks and the effects also suck then it’s great if it is really short.
As a coder I’d like to make tight demos of around 1:30 with everything inside well done.
I believe musicians are going to hate this format though. Not enough time to get the listener immersed in the track. And viewers are probably going to hate it too if it is really good, but too short.
If the music sucks and the effects also suck then it’s great if it is really short.
With 128K I’m sure some of these groups can manage to open a portal to hell with the extra 64K.
Adding more intro categories will just lead to people making their intro in a lazy way, and putting it in to whatever category it fits in to rather than striving to make their intro small. We already see that a little bit with 8k, where it's often the case that the entry is simply a 4k which didn't get small enough. A 16k category will end up accumulating the unfinished 8ks in the same way.
Besides this, I just don't think we need more categories. I agree with what smash said about diversifying the non-size-restricted categories some more though. Interesting restrictions can be created in other ways than just the executable size.
Besides this, I just don't think we need more categories. I agree with what smash said about diversifying the non-size-restricted categories some more though. Interesting restrictions can be created in other ways than just the executable size.