pouët.net

Maximum file size for demo (esp. @Assembly)

category: general [glöplog]
That's a bit of a strawman, isn't it? My argument wasn't that capacity is a problem (I explicitly said so that it isn't), but that capacity also made us care less about size, and by proxy, elegant solutions. (Which btw is no means unique to the scene, but hey.)
added on the 2017-11-06 10:21:38 by Gargaj Gargaj
Which goes back to communicating the size i guess. I can see 512MB as something very reasonable with enough high quality assets.

Sucks that communicating cant be done too easily like i explained before :(
Maybe auto insert to slides what the latest entry filesize is? Assuming that everything goes through intra.
added on the 2017-11-06 10:32:11 by oasiz oasiz
Gargaj: I'm not quite sure how my own opinion can be a strawman argument but nonetheless wish you the best of luck in promoting "elegant solutions" by means of arbitrary size restrictions.
added on the 2017-11-06 10:49:48 by havoc havoc
Quote:
Most of us are getting drunk together in 2 weeks to hash out ASM details, if there are wishes regarding this then we can of course check those out!


Like Oasiz said, we are having get together with compo orgas in few weeks and will discuss compo rules for the next year among other stuff. So good timing for reminding us on this! I will give you update on this when we have had the meeting.

It's interesting to hear your views on the issue and also if you have any other concerns about Assembly compo rules, now is a good time to give us feedback on those (e.g. by pinging me on irc).
added on the 2017-11-06 11:11:29 by rimina rimina
When it comes to elegance in demos, I'd rather see people making the effort on the visual/aural/conceptual side than spending time trying to optimize away relatively meaningless technical details to fit under an arbitrary size limit.
added on the 2017-11-06 11:14:34 by Preacher Preacher
Well, it's a little bit disheartening when a 5mn demo takes half an hour to download from a sluggish server...
added on the 2017-11-06 11:22:18 by Zavie Zavie
Quote:
...capacity also made us care less about size, and by proxy, elegant solutions.

But is that really a problem?
Making a solid data packer (because that is what we're talking about here, procedural generation in size coding disciplines is something entirely else) is cool, but where is the achievement in using a library to unpack your RAR file?

I've started wondering if it's about time to just stop compressing my music for demos. I just do it out of habit, because I've always done it. But I don't really see any point anymore in compressing to MP3 and degrading the sound quality for no real benefit.
I don't see why graphics data should be degraded similarly "just because".
added on the 2017-11-06 11:36:53 by lug00ber lug00ber
Quote:
Well, it's a little bit disheartening when a 5mn demo takes half an hour to download from a sluggish server...

Downloading a few megabyte demo back in the modem days wasn't any faster ;)
added on the 2017-11-06 11:47:11 by britelite britelite
To give you and example,
A demo lasts 6 minutes. It is 30-40mbytes, including music and textures, which is not bad.
Now comes a single scene with a single resource that is 200mbytes zipped. It is painstakingly crafted from real data+offline processing and only possible to use this in an effect (with good framerate) in very recent times. It is technically not possible to compress by, say, 1:50 but rather 1:3. This scene may last 1 min, but is very interesting and memorable. What do you do? Keep it or lose it (as it would harm your 256 limit, or worst still your 64!).
added on the 2017-11-06 12:18:51 by Navis Navis
Drop the resolution and interpolate in realtime.
added on the 2017-11-06 12:27:49 by visy visy
Quote:
When it comes to elegance in demos, I'd rather see people making the effort on the visual/aural/conceptual side than spending time trying to optimize away relatively meaningless technical details to fit under an arbitrary size limit.

word!
added on the 2017-11-06 12:40:37 by v3nom v3nom
Totally agree with Lug00ber about sound compression. There's no point in degrading the sound quality when producing high end demos nowdays.
added on the 2017-11-06 13:04:26 by Frequent Frequent
Quote:
When it comes to elegance in demos, I'd rather see people making the effort on the visual/aural/conceptual side than spending time trying to optimize away relatively meaningless technical details to fit under an arbitrary size limit.


This!
added on the 2017-11-06 13:06:28 by okkie okkie
well, it's not just elegance or file size awareness. data inflation due to bigger and more textures, good sounding audio compression (<128kbps is pretty no-no these days), more polygons and shit XML based data storage... the latter two can pack relatively well but still.. it probably also is part of the demoscene glam that a demo unpacks 1GB of point cloud animation miraculously packed into 200MB :P
added on the 2017-11-06 13:16:00 by maali maali
Quote:
Well, it's a little bit disheartening when a 5mn demo takes half an hour to download from a sluggish server...


More the reason to stream it from youtube.
added on the 2017-11-06 13:16:25 by xTr1m xTr1m
Time to see how the NYRC demos would look if textures were compressed enough to fit the demo in 16mb :thinking:
added on the 2017-11-06 14:22:30 by msqrt msqrt
or do a break-even point analysis with youtube... so, you have to stay just under 60MB/minute! :D
added on the 2017-11-06 14:32:59 by maali maali
Quote:
More the reason to stream it from youtube.


This would be the next logical step in that whole "let's lift the filesize limitiation" train of thought. Just upload shitloads of data to the cloud and have a small client exe stream it (and optionally cache it locally for next time).

But then it would only be fair to allow the same for Amiga demos :)

If any of this was really going to happen, i think personally i'd quit coding demos.

Bad enough that we allow Unity/UE4 stuff already imho.
added on the 2017-11-06 14:40:03 by arm1n arm1n
spike: a french 64k already did that trick in the early 2000s ;)
added on the 2017-11-06 14:54:29 by maali maali
Why are there arbitrary computing power limitations? Or the meaningless arbitrary limitation that it has to "run" on a computer. I'd rather see something creative.
added on the 2017-11-06 16:41:01 by yzi yzi
yeah, are you sure it's a great idea to completely change what the demoscene is all about?

If "anything goes", and there are no more "borders" - then nobody knows anymore what the demoscene differentiates from other artsy fartsy stuff.
added on the 2017-11-06 16:46:00 by arm1n arm1n
BB Image
added on the 2017-11-06 16:50:38 by maali maali
Quote:
Quote:
...capacity also made us care less about size, and by proxy, elegant solutions.

But is that really a problem?
Making a solid data packer (because that is what we're talking about here, procedural generation in size coding disciplines is something entirely else) is cool, but where is the achievement in using a library to unpack your RAR file?

Demo sizes are counted when compressed though - you already ZIP/RAR your demos.

My argument is that everytime I see a 40MB QT.DLL next to a demo, something inside of me dies.
added on the 2017-11-06 16:59:36 by Gargaj Gargaj
Quote:
When it comes to elegance in demos, I'd rather see people making the effort on the visual/aural/conceptual side than spending time trying to optimize away relatively meaningless technical details to fit under an arbitrary size limit.

So why realtime then?
added on the 2017-11-06 17:00:04 by Gargaj Gargaj
Quote:
So why realtime then?


Why does being realtime have to come with a size restriction?
added on the 2017-11-06 17:29:40 by okkie okkie

login