Guidelines for creating a demo

[SkyWhy]

Hi everybody.

The general yada yada and background:
Me and my mate already have experience in 3D/2D graphics programming and been making games for roughly two years now with languages like C, C++ and C# using API's like Allegro, OpenGL, DirectX, XNA and shading in TRM (cheap adaption from Pixar's Renderman, made by our tutor). Before we were making games we both got roughly three two years of general programming under our belt. I'd say it's four to five years programming experience in total for both of us.

..uhm.. Why the h£ll would YOU care?
we've had a burning interest to jump into the demo scene for some time now and start building our own compos but the problem is that we just simply don't know where to start. There doesn't seem to be that much information available on "how to build a compo".

We don't feel like inventing the wheel AGAIN ( ), since we've done that numerous times already when programming games. Any help concerning the general structure of demo, what it should contain (like what components programming wise) etc. As far as We've understood, the compos are pretty much hard coded from start to the end, for the sole purpose of the demo. So I'm guessing we should stop thinking of trying to build as reusable code as possible and just start chunking stuff together..?

We do have a rough idea what we want to see on the screen. But.. eh.. How? It's so hard to even describe what's the problem, I guess the biggest problem for us is the fact that the task of building a proper components for the demo feels a bit strange and how things should advance. Some sort of "animation" keyframing, or? Should we think of it like a game but instead of reading input from the user we just .. make it do something without the user input?

Does this even make any sense?

Any tutorials, helping topics, helping posts or insight into making demos is appreciated... hell, ANYTHING is appreciated. 


Thanks !

- SkyWhy

[hellfire]

First of all welcome to the forum!

"compo" is the short-term for "competition". You can enter a demo (or two if you've been industrious) to a competition but you rarely do "your own compo".

As you're experienced in building games it should be easy to do a demo. In the classic sense all screenplay in a demo is predefined, objects follow paths (keyframing) and actions occur at certain points in time (timeline) preferably synchronized to the music.

In my opinion it's not a bad idea to include some level of interactivity, though. While traditional art stays completely static, a demo recreates its' output every time it is run and thus allows certain changes comparable to a band performing live and sounding slightly different with every gig. However, you usually want to keep this in certain limits so it doesn't mess up your composition completely.

The way demos predefine screenplay varies from "completely hardcoded" to "playing animation-paths from 3d-studio" over "creating own synchronisation-tools" and "plug your engine into adobe after effects".
Personally I often prefer the hardcoded way as c++ is a pretty good scripting language. Certain tasks require more tailored tools, though.

[SkyWhy]

Thanks for correction on the terms and for the reply. Naturally this atleast gave us some sort of insight on how things might and/or should be done. Everything was as we thought it might be so we were not that much far off... Now it's mainly just creating some sort of keyframing system that allows us to traverse through the "events" and have stuff going nuts on the screen.


Anyone else have any input on the general how to start creating demos matter?

[benny!]

@SkyWhy:
Welcome to the forum. Actually Hellfire described it perfectly. Maybe
some additional thoughts.

Doing a demo can focus on several points. I guess that's why you
throw in the term compo. On demoparties they hold competition,
the so called compos. They are splitted up in certain categories.
That's why the focus could be on different tasks when you want to
start creating a demo. Refer to the different parts of demo types for
more information.

Here is a not complete lists which just came into my mind on what
re-useable routines you might need:

1.) General setup code / skeleton
(Decide between OpenGL, DirectX, Fullscreen- || Windowed mode, Demoloop)

2.) Music replay
(Which format you want to playback ? .MOD, .XM, .MP3 ...)

3.) Some typical demoroutines
(Scroller, Starfield, basic 3D engine etc.)

Well, could be even some more ...

[SkyWhy]

Cool, thanks again for answers. Mighty helpful just to clear up general confusion and to actually give some direction to where to start from.

[Shockwave]

What Hellfire and Benny said, and welcome to the forum SkyWhy .

Please do let us know how you are getting along and ask any questions you like

[SkyWhy]

Two silly questions arised when I was thinking stuff over again with my friend.

We are mainly going to be using spheres and Cubes in our first demo. We are thinking of morphing cubes to spheres at some point of the demo but what I was wondering, does anyone know the name of the algorithm or what is it called when you basically just build REALLY rough sphere of triangles (almost like a cube) and start dividing the triangles into smaller triangles to produce a "high quality" lookking sphere? Or is there some sort of fancy name for this idea we are after already?

And for the music, well, more like how to go about using it. Should we actually go as far as start doing beat detection algorithms or just use a simple wave editor and get the general timing of the wanted beat going on and hard code it in? Seems a bit hardcore for a demo to start analyzing the signals

All though I guess that could be an option in a proper big demo but when it comes to really "low level" stuff like 64k to 1k demos I'm guessing there's absolutely no room for beat detection? Nothing that causes brain meltdown but just general stuff I'd like to get answers to. 

We are going to try and push out some sort of small demo even though we got our work loaded currently on us with the games we are working on. Also, any recommendations for a first demo, in way, how long / what kind of should be? Since it's like.. no matter what I do I instantly pull of the coolest lookking demo I can from youtube and don't really feel like showing the crappy demo we made to anyone since it cannot be even compaired to the coolness you find off the scene.

[Jim]

Splitting triangles into smaller ones is either called Subdivision or Tesselation.
1Kb demos are extremely difficult to anything with, but you should check out Pouet for some amazing 64Kb demos - you can do almost anything in 64Kb, but you'll need lots of compression.

Jim

[SkyWhy]

Hmmm... Yes, it's tesselation but basically there was this nifty algorithm to actually use tesselation with some additional magic to increase the so called approximation of a sphere to actually make it look better. Currently just can't get my head around the name, I'll pop the name here if I ran into it. Since it's bother me like there's no tomorrow.

I have to dig through the DBF resources if I can find something cool to use since it seems to contain loads of interesting libs/addons to use.

[Jim]

In terms of spheres, then Geodesic Sphere is one name.
Create a unit Icosahedron (this is a Platonic Solid), subdivide any face, get the xyz, renormalize it and there you have a better geodesic sphere approximation.

JJim

[Clyde]

There arent really any strict guidelines as such; there is math out there to help you out, and you will find the usage of sin and cos practically everywhere.

And your most certainly correct, there isnt a busting lot of information on how to make effects; you will probably have to reinvent the wheel a bit.

This place is dynamite for usefull tit bits. tutorials are planned too.
O, and a warm welcome to the Forums

When your over at pouet.net which Jim suggested, a few of my suggestions to checkout are the likes of 64ks by the groups Farbrausch and Conspiracy. The demo called Heaven Seven by Exceed, and also And's 64ker Squish.

If you like retro, then checkout stuff from around 1992. Some of it you'll need to use emulation, unless you have the original computers to run them on.

Btw, Where can I find some of you guys games?
And great to see a new Demo Group

Wishing you every success,
Clyde^Gravity

[Clyde]

Please let us ( the community ) know about your progress dudes!

[ferris]

The sphere/cube thing can be done by defining the two models, sphere and cube. Make the cube have tons more vert's, probably through tesselation, then just crossfade the vertex coords.

As far as what you'd really need for a demo, Benny covered it very well. I'll just be a bit more specific:

1. Main engine. This includes which graphics API you'll be using, along with a scene manager and timer system. These are used to run certain scenes between certain time intervals and can also pass a timing value to the scene function (0 = start of scene, 1 = end of scene). This may also include API wrapper functions, texture/model loaders, etc. The simpler the better, but make sure you have everything you need to code comfortably...but essentially, all you're doing with this is setting up a window and calling your audio & effect functions.

2. Music generation/playback. There are tons of lib's lying around for this, like FMod[Ex], BASS, MiniFMOD, V2, or go the hard route and write your own synth (which you're pretty much forced to do for anything 4k and under, due to the low quality of most released synths). For demos, though, at least starting out, stick to playing a .mp3, .ogg, .xm, or other easy-to-load resource.

3. Effects. These will probably be more simple as you start out, but eventually will become huge layered masses of code! You can do anything here, but just make sure they are easy to implement into your timer code. Youth Uprising's demo engine calls each effect function with the 0-1 timer as mentioned above, which makes effects very easy to do as functions of time and also this keeps the demo looking consistent from machine to machine, no matter how fast/slow.

4. Demoscene nuances. I personally feel you can't start making demos without first starting to code oldschool effects Scrollers, logo wavers, starfields, keftales, rotozoomers - tons of them. But if you really don't wanna reinvent the wheel, and you just wanna jump into newschool coding, that's cool too. Just always try to include things like greetings - who do you like? Who's helped you along the way? Name them! Try to fit the greets into your demo/intro, but if you can't, include them in the readme for sure.

And along with Clyde, we wanna see your progress!!!

Hope this helps