Maximum file size for demo (esp. @Assembly)
category: general [glöplog]
Printing the size on the slides sounds like a punishment to me. People will be negative from the first moment after seeing "300 mbytes" on the entry slide, without being able to tell where the data went to. There are many purists who still think in kbytes that would be shocked :-)
It will be good to know if this is going to change or not at assembly or other parties.
It will be good to know if this is going to change or not at assembly or other parties.
Quote:
People will be negative from the first moment after seeing "300 mbytes" on the entry slide, without being able to tell where the data went to
You should see this as an opportunity for adding a bunch of in-your-face DESIGN ARROWS that point out where the storage was spent.
Yeah there should be a pie chart in the compo slide showing where all the space was spent.
Joking aside, a text with the size would be a firmly no from me, on principles (" if we cant catch you with size, we'll redicule you with some text").
I find it a bit hypocritical that some people in this thread generally have the attitude of At Least They Made A Demo, but somehow trying to prevent "laziness" rules over that I guess. If comes down to shipping 100 Mb of QT libraries or the Electron framework along with the demo that enables the demo to be actually made, than do it. It's just a hecking choice of development tools anyway, not an indicator of any laziness. Unless you think they should be required to learn another tool set to be able to directory use Windows' API without the need to ship additional libraries. But what sense does it make to do that if you're already comfortable with another one that does the same thing; just make the damn demo or make it a rule that the demo must be made in Visual Studio (actually please don't).
Another point that seemed to get brought up here a lot is that most people don't need the extra size (for artistic purposes). This is of course true, but are we really going to limit some people's creative and technical possibilities at the expense of some weird democratic majority rule? Similarly to the previous point this is just an example of actively preventing some kinds of demos to be made categorically.
Then there's the whole "just release it in the Wild compo" thing, which just reeks of the "separate but equal" line of thinking. No, wild compos are not equal and you know this. They're almost universally held at worse time slots and don't attract as many viewers and attention as the main demo compos. All it says is that your value system doesn't think demos going over some arbitrary size are allowed to be presented alongside the others. It's just an indirect insult towards the creators that might very well discourage them not to make the demo in the first place.
And that's my point overall. Don't let your own values start limiting the creative output of the demoscene. Leave that for the time you're at the proverbial voting booth after the compo.
Finally something from almost 11 years ago that I think still resonates: http://www.pouet.net/topic.php?post=120604
Another point that seemed to get brought up here a lot is that most people don't need the extra size (for artistic purposes). This is of course true, but are we really going to limit some people's creative and technical possibilities at the expense of some weird democratic majority rule? Similarly to the previous point this is just an example of actively preventing some kinds of demos to be made categorically.
Then there's the whole "just release it in the Wild compo" thing, which just reeks of the "separate but equal" line of thinking. No, wild compos are not equal and you know this. They're almost universally held at worse time slots and don't attract as many viewers and attention as the main demo compos. All it says is that your value system doesn't think demos going over some arbitrary size are allowed to be presented alongside the others. It's just an indirect insult towards the creators that might very well discourage them not to make the demo in the first place.
And that's my point overall. Don't let your own values start limiting the creative output of the demoscene. Leave that for the time you're at the proverbial voting booth after the compo.
Finally something from almost 11 years ago that I think still resonates: http://www.pouet.net/topic.php?post=120604
Quote:
So why realtime then?
To be honest: I don't know. Because it's a fun way to create stuff? Because it's historical? Because it still keeps the technical aspect for those who want it?
Noby wins the thread.
I'm with Noby (and Ryg). Their arguments describes my opinion better than I'm able to myself :)
Regarding the display of file sizes, various other technical information is also shown - and I'm sure that some 15 years ago we would have fought the same thing over "do 3D-accelerated entries have to say so on the slide?" - while these days practically everyone states if they are using OGL/DX/software rendering.
Even if you're not showing the size of a demo on the slide, people will find out, sooner or later. From the filesize shown in Windows Explorer right before the demo is launched, from their buddy in the compoteam, online after the party, etc etc. Reading the discussion so far, it's obvious that filesizes are very much a deciding factor for some folks in making up their minds about voting. So srsly, why even try to hide this information from the crowd?
That little (&totally factual) "493.7MB" (or whatever) scribbled under the name of your entry on a slide is not ridiculing your effort at all, it's just data, like the platform the prod runs on, the name of the group who made it, etc etc.
Quote:
" if we cant catch you with size, we'll redicule you with some text"
That little (&totally factual) "493.7MB" (or whatever) scribbled under the name of your entry on a slide is not ridiculing your effort at all, it's just data, like the platform the prod runs on, the name of the group who made it, etc etc.
Why disclose the compo machine specs at all? It would be more unlimited and therefore artistically interesting if people just pre-rendered the stuff somewhere and submitted a video. Then they wouldn't be limited by an arbitrary choice of a slow compo PC of this year.
Really, I think the rules have allowed rediculously big demo sizes for a long time already, and the results don't feel very impressive or interesting.
Really, I think the rules have allowed rediculously big demo sizes for a long time already, and the results don't feel very impressive or interesting.
Would the results feel more impressive or interesting if the crap demo was smaller?
Yeah, Noby and Ryg voice better what I was saying too.
We'll see when you've released it.
ryg is so badass that he managed to win this thread without even posting in it.
IIRC, Breakpoint 2007 tried displaying file sizes on the info slide. That was the year of Debris - so, in retrospect, the compo organisers probably had a bit of an ulterior motive there... - but I got the distinct impression that the information about Debris's unusually small file size just didn't register with a lot of people during the compo. After all, it was just one data field buried among all the others, not as if they'd stuck up a message saying "180kb, bitches!!!!!1"
(It would be kind of interesting to look back at the post-party discussions from then to see if there was any feedback about showing filesizes, or any hints to why they stopped doing it...)
Anyway - that seems to me like the system working exactly as it should. Give people the information to pay attention to or ignore as they choose. You might get penalised if enough people decide that your demo is too big, but you run that gauntlet with every design decision you make, whether it's using vocal music, or failing to include enough Amiga balls. People will place their votes depending on some mix of rational and irrational, logical and emotional criteria, just like they've always done.
IIRC, Breakpoint 2007 tried displaying file sizes on the info slide. That was the year of Debris - so, in retrospect, the compo organisers probably had a bit of an ulterior motive there... - but I got the distinct impression that the information about Debris's unusually small file size just didn't register with a lot of people during the compo. After all, it was just one data field buried among all the others, not as if they'd stuck up a message saying "180kb, bitches!!!!!1"
(It would be kind of interesting to look back at the post-party discussions from then to see if there was any feedback about showing filesizes, or any hints to why they stopped doing it...)
Anyway - that seems to me like the system working exactly as it should. Give people the information to pay attention to or ignore as they choose. You might get penalised if enough people decide that your demo is too big, but you run that gauntlet with every design decision you make, whether it's using vocal music, or failing to include enough Amiga balls. People will place their votes depending on some mix of rational and irrational, logical and emotional criteria, just like they've always done.
A concrete example from Amiga land:
Some visual elements of Smoke & Mirrors (the 3D objects) are pre-rendered. It's all 680x0 asm, mind you, it's just that some of it is run at build time instead of run time.
I guess I was so used to making intros that I couldn't help but treat the compo as a "20MB intro" compo and see how much I could cram into that. :)
That said, I don't think the demo would have been much different if we had had unlimited space, as we would have hit the platform limitations (namely, 64MB ram) soon enough anyway. Specifically:
- There would have been fewer compression artifacts.
- Some shots would have had more of the 3D object visible.
- The music would have been in stereo instead of mono.
- I wouldn't have had to spend so much time squeezing the demo, which means we would probably have had time to include some of the design elements that were dropped because the compo was about to start.
The subsequent controversy would have been exactly the same. :)
As for Debris, I clearly remember seeing the size on the compo slide beforehand. And it definitely added to the wow factor for me. Then again, I am sure it would have won even if it was 20MB.
Some visual elements of Smoke & Mirrors (the 3D objects) are pre-rendered. It's all 680x0 asm, mind you, it's just that some of it is run at build time instead of run time.
I guess I was so used to making intros that I couldn't help but treat the compo as a "20MB intro" compo and see how much I could cram into that. :)
That said, I don't think the demo would have been much different if we had had unlimited space, as we would have hit the platform limitations (namely, 64MB ram) soon enough anyway. Specifically:
- There would have been fewer compression artifacts.
- Some shots would have had more of the 3D object visible.
- The music would have been in stereo instead of mono.
- I wouldn't have had to spend so much time squeezing the demo, which means we would probably have had time to include some of the design elements that were dropped because the compo was about to start.
The subsequent controversy would have been exactly the same. :)
As for Debris, I clearly remember seeing the size on the compo slide beforehand. And it definitely added to the wow factor for me. Then again, I am sure it would have won even if it was 20MB.
Quote:
As a size coder I don't think seeing the size of demos on the slide would be shocking at a big compo like Assembly where you have 20-30 demos of increasing complexity and level of polish. You clearly see where the data go as the compo progresses.Printing the size on the slides sounds like a punishment to me. People will be negative from the first moment after seeing "300 mbytes" on the entry slide, without being able to tell where the data went to. There are many purists who still think in kbytes that would be shocked :-)
As for the "Debris" case: It is a fantastic demo, with nice direction and interesting audio & visuals, but it is also clearly procedural. That was a design/technology choice. Using X mb of assets could on top of this solid foundation of design, direction and audio would make a(nother) fantastic demo.
In my opinion, i think its good to see the huge-size demos. Huge-size demos with great visuals and so many data will be a good thing like the Cocoon demos. But some demos like this are not good as there size (and yes i know this demo is created with a game engine).
I think maybe some size limitation for normal people are not an important thing. For an example, a party like ASM, which the normal people watch the compos, maybe they some of them will like to present their own demos, next year at the party. But maybe they can't learn demo coding in a year so they use game engines to make demos. So... they will fight for Megabytes of data instead of Bytes :)
Btw, i think creating a super-demo with heavy visuals, hires textures etc is not a common thing on demoscene(in my opinion!). But i think the elite sceners who decide to make these types of demos, like to produce their own demo on main demo compo not on wild compo. So this could be a thing to continue the discussion about it.
And about what Gargaj said about Function's demo compo size limitation and no one reached the limitation in recent years, i think its because the most of demo makers who present their own demo on Function, know that how to make a good demo in different ways. Even the size of demo. But i think even mentioning the size limitation of demo could have effect on the Function's demos. As maybe the coder say that "Maybe i don't use these type of materials and save bytes and Mbytes.".
In technical ways, absolutely ryg win this game about size of demos. But i think this subject is not a just technical subject. I think its more about let people to make things in normal way or even hard way. I'm not coder and i haven't coded anything. So anything i said could turn completely wrong since i just say these things with just according to something that i read in anywhere in demoscene :)
(Some of these things i typed maybe not an necessary things to mention. Sorry for my broken english)
I think maybe some size limitation for normal people are not an important thing. For an example, a party like ASM, which the normal people watch the compos, maybe they some of them will like to present their own demos, next year at the party. But maybe they can't learn demo coding in a year so they use game engines to make demos. So... they will fight for Megabytes of data instead of Bytes :)
Btw, i think creating a super-demo with heavy visuals, hires textures etc is not a common thing on demoscene(in my opinion!). But i think the elite sceners who decide to make these types of demos, like to produce their own demo on main demo compo not on wild compo. So this could be a thing to continue the discussion about it.
And about what Gargaj said about Function's demo compo size limitation and no one reached the limitation in recent years, i think its because the most of demo makers who present their own demo on Function, know that how to make a good demo in different ways. Even the size of demo. But i think even mentioning the size limitation of demo could have effect on the Function's demos. As maybe the coder say that "Maybe i don't use these type of materials and save bytes and Mbytes.".
In technical ways, absolutely ryg win this game about size of demos. But i think this subject is not a just technical subject. I think its more about let people to make things in normal way or even hard way. I'm not coder and i haven't coded anything. So anything i said could turn completely wrong since i just say these things with just according to something that i read in anywhere in demoscene :)
(Some of these things i typed maybe not an necessary things to mention. Sorry for my broken english)
I was always a fan of showing the filesize on the beamslide, maybe even a little more prominent than the rest of the infotext and not optional. If you think further that could not only help in a "unlimited size" democompo to judge the entries but also solve the problem with all the possible intro categories at smaller parties (as most of them, including nordlicht, combine the intro compos anyway).
I get that hard limits are considered a challenge and a 4k coder who spent a lot of effort on cramping down those last 6 bytes finds it unfair to run next to a (better looking) prod in the same compo which is 5kb or something, but as long as the filesize is shown people can make up their own mind if the bytes are well spend.
Once we are used to not think in 1k/4k/8k/64k categories but judge each prods size independently and in relation to its technique and content coders would have a lot more freedom of choice instead of aiming at one of those predefined limits.
Not enforcing a predefined sizelimit makes the productions harder to compare and surely requires more knowledge on the viewers end, but I would say the gained freedom is a win in most cases?
I get that hard limits are considered a challenge and a 4k coder who spent a lot of effort on cramping down those last 6 bytes finds it unfair to run next to a (better looking) prod in the same compo which is 5kb or something, but as long as the filesize is shown people can make up their own mind if the bytes are well spend.
Once we are used to not think in 1k/4k/8k/64k categories but judge each prods size independently and in relation to its technique and content coders would have a lot more freedom of choice instead of aiming at one of those predefined limits.
Not enforcing a predefined sizelimit makes the productions harder to compare and surely requires more knowledge on the viewers end, but I would say the gained freedom is a win in most cases?
On small productions (<1mbyte) it may be true that it can resonate with the audience. In this case it is typically referred to by the makers in the about text. In all other cases it serves no purpose other than, potentially, to confuse or create negative predisposition with the larger demos from the first moment.
If you want open limits, set them and go all the way without mentioning it. If not, set it to,say, 512 and let it to us to decide if we want our prod to come with this info at performance in a competition.
If you want open limits, set them and go all the way without mentioning it. If not, set it to,say, 512 and let it to us to decide if we want our prod to come with this info at performance in a competition.
Well as a gamer I remember being in awe of large games that require several disks or later even CDs. More data is more or higher quality content, right? It never even occured to me that those games were "badly packed" or "badly coded" and could have been done in way less...
Of course in the demoscene things are seen a little bit different but I wouldnt say a "huge" filesize will automatically make people believe the prod is worth less. It all depends on the content and how it is presented, really.
Of course in the demoscene things are seen a little bit different but I wouldnt say a "huge" filesize will automatically make people believe the prod is worth less. It all depends on the content and how it is presented, really.
Hm maybe... But why risk it. Let groups decide if they want or not display this info.
that would probably lead to "we only show the size when its small enough to leave an impression" kind of thinking which in turn would render the whole concept kinda senseless...
Increased content size = increased production time = increased cost.
I'm not against the hard-limit per se, but I'm just curious...
How do you guys find the time to release a killer demo nowadays?
Isn't it a competition first and foremost?
So, maybe the limit should be there just to make the compo more accessible?
I'm not against the hard-limit per se, but I'm just curious...
How do you guys find the time to release a killer demo nowadays?
Isn't it a competition first and foremost?
So, maybe the limit should be there just to make the compo more accessible?
Very patronising idea; that by imposing restrictions to groups that can affort bigger (but not always better) resources, this will create a new kind of level playing field with those that cannot. Its like "lets share a poor vision for new demos" - poor, but at least affortable *to all*.
Good idea for a struggling sport like formula1 - where you desperately need a few teams to spend like 100m every year to just compete, not sure about a hobby with no money to spend or make.
Good idea for a struggling sport like formula1 - where you desperately need a few teams to spend like 100m every year to just compete, not sure about a hobby with no money to spend or make.