pouët.net

100%

as a sizecoder (preferably < 64 bytes) i literally write everything myself, but sometimes i call INTs whose subroutines i didn't write ... is that already cheating? ^^

Well, what about the operating system's executable loader??

Well somewhere among the replies I read that it's okay as long as it doesn't have anything to do with rendering? :)

yeah 100% relied on peippo instead :3

but I kind of dislike the state of intros in that sense. I remember being impressed when I originally learned how small the productions were, but then using crinkler it was something I also did in a day. didn't feel as impressive anymore.

they are sensible limitations, even if everyone is using the same packers. the workflow is very different and there are clearly things you can or can't do and every now and then some new clever trick comes up. it just feels even more arbitrary that you just don't have the size of the code and data as is, but run it through this unrelated transformation by someone else. or spend several months (probs years for crinkler) trying to come even close to their packer or take a serious disadvantage at the competition.

Noby :) :) :) My 2 cents: use whatever you want, but credit where credit is due.

please everybody crediting at least the keyboard brand because you know you are typing on it with your nasty fingers.

Well, historically (going way back to the C64 scene), using packers/crunchers someone else wrote has always been the norm, as well as music replayer routines.
So yeah, writing your own graphical stuff has (and still is to me) what is considered the "demo code".

Anyway, this discussion of 3rd party stuff has been had many times, and not only when it comes to code, I know there was quite a bit of talk about the soundtrack in this demo for example:
http://www.pouet.net/prod.php?which=54603

It seems like today you could potentially create a demo like this:
* Take an existing piece of music, remix it a bit
* Download some 3D meshes from an online repository
* Take some photos and apply some Photoshop filters
* Use an existing, professional 3D engine where you can sit in realtime in a massive UI and tweak rendering and particles and whatever.
* Export the result to exe

It might give a great end result, but I don't get the same feeling from that as I would have if the music was a original composition, the 3D models were created by the graphics guy and the engine was written by the coder.

Perhaps a nice idea for a fun-compo:
Make a demo where nothing in it was created by yourself. :)

I see a lot of this opinion that "use whatever you like but give appropriate credits". I'd like to hear more about what this credit exactly is and how it should be given. Usually crediting or attributing something (i.e. how, where, and to what extent) is mandated by the accompanying license agreement. Usually I think this can be fulfilled by a mention in the readme, or alternatively the software itself might fulfill this by including the attribution into the export themselves (i.e. the free version of Unity).

So what I'm wondering is is this enough? Fulfilling license conditions regarding attribution? Or is it about making it loud and to draw attention to the fact that this production has been made using a 3rd party tool? The latter is not about crediting anyone, it's "engine shaming".

ekspert did a demo about it ;)

the soundtrack in DEMO2 is an original piece though

noby: the "techniques" portion of the compo slides. that's kind of what it's for.

ah, it's just the line between oldschool and newschool .. old farts like me like to handcraft their beer, surly we need some boilers 'n stuff, but it's made with love and we know every pixel by name .. but I like Heineken too :)

I wonder if changing the name from "demoscene" to "graphics programming scene" would reduce the amount of heated discussion on the topic... ;)

so, i'm going to tackle this in several parts.



Yes, of course. When using UE/Notch/Unity/Tooll/Werkzeug/Addict/any tool you did not code yourself, you should credit it.
There is definitely a difference between coding your own engine and using someone elses. It's not to say that making a demo with such tools is easy - anything but - but there are some things which look really cool that can be done almost trivially in say, Notch or Unreal. As we see more demos made in UE/Notch/etc we'll get to know what those things are and recognise them.

It's only fair that people know what was used when watching. But one of the major problems here is audience ignorance. Making a demo in Unity is not easy but people dont understand what is easy about it and what is not - it's very hard to judge the result unless you really understand the process yourself, just like understanding the differences between oldschool platforms etc. The audience can judge whether they like the result but I worry people will see "made in Unreal" and think it was the result of a magic button press.



Notch existed and won democompos before it was publicly released. Today when we make a demo with Notch there is still code written; on Wander for example I coded tons of new stuff for it. When someone uses Unreal, Tim Sweeney is generally not sat in the room developing for the demo. In contrast when making Number One, all 4 of us were sat in the same room all working on it together - code, gfx and music. CNCDFLT demos are always a cooperation between code and design; admittedly a sliding scale where some demos are more designer-led and some more coder-led, but always a cooperation - which is when making demos is at its best imo.

However, is it fair that we are essentially using commercial code to make a demo? Well, no, it isn't. In the purest sense, it's not fair that we can compete with something that was in part developed commercially vs someone who developed in a strictly amateur/hobby environment. But this is a line that's difficult to draw.

Virtually all of your PC demoscene heroes are using code, engines, tools that have been in some way used (and paid for) commercially at some point. Even some of the ones who don't have a tool (or whos theology is the very opposite of using tools) have reused demo code for commercial projects and vice versa. It'd actually be great if everyone came out and was open about that..

Beyond that, what about the 3D artists who made some models for work and then reused them in a demo, or used the software&plugins bought for them by their work? Or the pro musicians that mastered their demo tracks in their work studios? Or the coders who sneak in their democoding into work hours.. :) Let alone the skills and experience that working commercially brings to your demomaking skills. The playing field is very much not level, ever.

I guess ultimately the rules could change to say we aren't allowed to use our own tool when making demos, but that would probably kill the chance of us ever making a demo again. That's up to the scene to decide, but that line is so wide and blurry it would be tough to draw.



Yea.. right. Speaking as one of the relatively few people who have released top-level PC productions in 4k, 64k and demo over the years (I've won Assembly in all 3 categories.. is that a unique claim? :D) ), I can tell you that coding demos at a high level is definitely not easy. It's really hard. There's a whole set of problems (resource management?) that only come when you have enough data and variation of code to hit it. It has a different set of challenges to a 4k but there definitely are as big - if not bigger - challenges.

Now lets be honest about the whole sizecoding superiority bullshit for a second. Making a mid-level 4k nowadays can be, and I suspect sometimes is, achieved by downloading the source for a framework, a 3rd party exe packer, a 3rd party synth, going onto ShaderToy and picking a suitable candidate to steal from, changing the GLSL source a bit, running it through a 3rd party minification tool and putting it together. There's nothing purist or "real" about that process so don't pretend every sizecoding production is somehow wizardry and superior to making demos.

Reuse, tools, shortcuts to results are prevalent in virtually every corner of the scene (and the world). Libraries, stock content, samples, code stolen from shadertoy or elsewhere, some cool sound or 3d model generated easily with a plugin..
The only difference is that many in the audience are ignorant to the particular shortcuts, or because some are more blatant than others.

Following from the commercial issue (because often it's the pros who have the experience to take such shortcuts): it's up to the scene whether this is OK or not and the rules could change; it'd be a nightmare to enforce though.



Gargaj's comment was almost spot on, except for one detail.
From the mid-late 90s until a few years ago, the scene took a strong directional change. A lot of designers/artists left and there was a lurch towards "coder-centric" stuff (e.g. sizecoding). This is imo massively to the detriment of the overall quality and range of releases in the scene and what made it great in the first place.

One of the reasons why is probably that designers just didn't enjoy the process. They were kept removed from the action - left to make models and images and pass them over to a coder to do whatever. It's slow and limited in what can be achieved.
Tools like Unity, Unreal and Notch allow designers to make demos themselves directly in a way that is actually enjoyable for them. Even most demotools so far released are pretty rough and unusable for a designer, but these are different: shit actually works. You can make stuff without the buzzkill of a broken UI getting in the way at every turn. (I know this because of witnessing first hand what a buzzkill a broken UI is for the designer you are working with. :) )
When you have an environment that works creativity becomes possible, it becomes fun again, and that is after all why people make demos - fun. As so many of us approach 40 and have long professional careers already, the chance to dazzle a few computer nerds and the chance to win a few hundred euros in hardware is generally not the major motivating factor to spend hours working on a demo as it was when we were teenagers. People do it because the process itself is fun.
The guys using these tools - e.g. Der Piipo, Jugi, Destop - they aren't choosing to use an editor over working with (sat over the shoulder of) a coder in the traditional way. They are doing it with an editor/engine because its the only way that actually engages them in making demos. They want to be totally hands on. Real-time is a fantastic and fun creative environment if it is presented properly with a directness that offline rendering doesn't have.
It's not an either/or thing - if it wasn't for these new options to make demos we just wouldn't see demos from those guys. And that would be a big loss IMO.

We in Notch are pretty supportive of people who make demos - despite it having virtually no commercial value (it actually costs us money / resources to support it) - simply because we love the scene we came from and want to help keep it alive. I hope to see more and more designers become interested in doing demos because of options like Notch, to make demomaking more accessible to people who could benefit the scene hugely by their involvement, and to see more and better demos result.

This could, in the end, be the kind of outreach that actually.. works.

the invention thing in the demoscene has been smeared out... however, only coders that understand GPU-hardware and programming understand most of the stuff that is invented nowadays on newage PCs. Or if you are a tinytro coder you could invent things that was not done in the past, but only coders know this stuff by technical knowledge.

The detail I "left out" was because I didn't want to presumptuous, and assume that people who make demos with an external tool do it because they want full control of the process.

Basically, what it boils down to is this: before demotools, a coder was necessary to make a demo. Now it's not.

Is that a good thing? I don't know.


Actually let me go on a tangent here, something I've touched on this before. We keep saying "coder" but there's two distinct styles of programming here: there's the sort of code that is not necessarily demo specific - not just boilerplate but keeping structural integrity, loaders, rendering management, tools, and so on. There's another style, of course, which is the creative "shader wizardry" of actual effect writing - in the real world this would mostly fall in a technical artist's scope. Up until demotools, there was space for both - even if you weren't a great effects coder (like me), you had a use because someone had to make sure the demo runs and runs well, and so on. With external demotools, technical artists can ditch "regular" coders and the only chance "regular" coders have to get involved in the process is to make a demotool that competes with Unity / UE / ... - so yeah good luck with that.

This. The scene always has been about competing. Honing your skills. Just like in poker it sometimes feels a bit unfair and I like that. Trying to compete against seasoned proffesionals keeps you sharp. Those without acces to expensive mastering studios just have to make do with whatever VSTs they can buy/warez. Those who couldn't find a job/study in a relevant field soon find out they miss the 10.000 hours which others did put in. It is funny how real life affects your demomaking. Either for good of for worse.

So what smash said, and what Gargaj said.

I guess this is one of the many reasons why people are so defensive on both sides: Designers who use these demotools don't want their new beloved working environments being declared “illegal”, and engine coders see themselves with no place in the demoscene.

PS: There have been implications here that these tools only do jobs that are mundane or triival, which is fairly belittling to coders. There's so much more to a rendering engine than an straightforward .obj loader :-)

Apart from that EVERYONE knows that using samples you got from your own expensive gear in your modules is cheating.

(Minus the speling and grammars mistakes, of course.)

I think Notch marks a pretty good border. It is pro/commercial BUT the tool itself stems in demoscene and is still used for scene prods, moreover, highly endorsed by the creators/leaders of the company to be used for scene. This is something that's not likely to happen for UE/Unity.



^ what he said.

also, if you use an engine, then - echoing myself - credit the engine in the infofile, on the beamer and in the prod and you're good. the audience will most likely know what to make of it.

Lol fuck yes it is. Also, running/owning an opera theater and having the orchestra performing your entry for streamed music compo ;)

Demosceners make demos on obscure hardware that was never meant to display any sort of demo, like calculators. Now, sceners use tools and engines that were never meant to be used for making demos. i.e. Unreal Engine. Big deal? I think not.

Plus many demos nowadays rely much more on artistic input from non-coders than back in the day, ranging from plot writers, drawing artists to musicians and whatnot. If you'd ban these tools, then you'd also ban the creative designers who use them, which would be a loss for everyone, unless you provide alternative tools in the same move. And these tools do exist to some extent. I make executable music with Clinkster because it lets me build executables with it without coding knowledge, it's all about sound design at this point so I can use the tool to my advantage and really shine with the output.

And there are areas in which pure designers can never compete in against coders, they're the size-coding competitions 512b, 4k, 8k etc. So I don't even see how coders would be threatened or left out in any way. I agree that the tools / engines used should always be clearly stated on a compo slide, it'll help the audience to better understand and appreciate your production's creation process.

Bla bla .. you're probably bored of my ramblings now so I'll let others babble on :)