flipcode - The Art of Demomaking

The Art of Demomaking - Issue 16 - The Final Product
by (08 December 1999)

Introduction

Well, this is the last issue of this column. And what's so special about it? It's a whole day late!! I'm terribly sorry about that, there's no good excuse for a column being late, but I've had the busiest weekend so far this term. Hope you can forgive me. You'll realise how much work went into this issue when you take a look at the code ;)

Anyway, this week, I'll quickly explain the importance of transitions, and how they make the whole demo look better. Ironically, I'll also tell you about deadlines. And we'll finish off with a few hints of what to put into a demo.

Transitions

The ideal demo in my mind would be composed of various different scenes, in which you can't pick out each separate effect. The whole screen would be so full of detail, and each separate components would be blended together so well that you wouldn't notice a thing. Just like the intros of the two latest James Bond Films. Now you can't really afford that computationally, so most demos end up as a succession of effects, as you probably noticed if you took a look at scene.org. Therefore, to make the demo feel a bit smoother to watch, you have to make sure the transitions between each effect is worked on.

If you take a look at this week's demo, you'll notice the serious lack of originality for the transitions. They're just simple flashes: fade to white, change effect, and fade back. The hard part with transitions is making them quick. Usually, you have to run the algorithm of the previous effect, the transition algorithm, and the next effect's algorithm, which can be extremely computationally intensive. But in most cases you can have a transition to a black screen, or a static image, and then another transition to the next effect, which reduces the computation drastically. The other secret for good transitions is making them original. I'll give you a few ideas, most of them have already been done before, but it's good exersice:

simple fade in / out
split screen up into many polies, and make them fly apart
move 3d objects out of the screen
zoom in really close and fade out
integrate a static image of current effect as part of the next effect (then burn it, draw ripples over the top)

If you can't find any ideas of transitions yourself, just download a couple of good demos and see how they did it.

Deadlines

I suppose it's a bit ironic for me to be talking to you about the importance of deadlines, when this week's column was a whole day late... I suppose the appropriate saying is "Do as I say and not as I do." No matter how much you plan ahead, there is always something that will make you work all the way up to the deadline. It's good practice to try and finish the product before 3/4 of your time is up. For example, if you have a week, try to finish in 5 days. If you have a month, give yourself 4 weeks. The weird thing is you still end up working all the way up to the deadline, but the product you end up with is usually more polished, and more stable.

Another good piece of advice is to make your code as clean as possible to start with, so that when you start hacking it desperately 2 hours before the deadline, it won't turn out too badly. This week's demo is also hacked together quickly, but basically, anything that works is acceptable. Another ironic thing is that people end up doing things completely different because of the deadlines. Ask a demomaker how he'd do something theoretically, and compare it with what he did, chances are there is no similarity... For example, this is what I'd do to handle the wide variety of effect in my demo. I'd define a polymorphic class and derive each separate effect from that.


	class EFFECT
	{

	      EFFECT();
	      ~EFFECT();
	      virtual Precalc()=0;
	      virtual SetParams( TIMER & )=0;
	      virtual Render()=0;

	};

You may also want to define a rendering buffer, so that you can render to different locations, to make combining effects that much easier.

Fast Portable Graphics For Demos

I was debating for a while whether to make all the effects use OpenPTC for the graphical output. That way each effect would have been fully portable, making them accessible to everyone, whatever their compiler. But in the end, I opted for the low level VGA code, and it served it's purpose: teaching the principles. So I gave up the portability idea and chose the easy way out. Then Michael Malsbury contacted me and told me he was willing to port all the effects to SDL, another good portable graphics library. That saved me quite a bit of work ;) Thanks a lot to Michael. You can download the archive here (332k). The programs should work on most gcc based compilers. A bit of work may be needed to make the timer code portable, but using MIDAS should solve that problem.

The Contents Of A Demo

All along this series, apart from trying to teach you generic coding techniques to create realtime graphics, I've shown you some pretty much standard effects you expect to see in demos. If you limited yourself to those, your demo would be fairly boring. But don't let that put you off, it's still good practice. As I mentioned in the first tutorial, demomaking is all about impressing people. There's a higher chance of impressing people if you come up with original effects. So in my opinion, you can basically put anything you consider impressive in a demo. This could be a physics engine, voxel engine, some AI routines, and so on. Why limit yourself to what people expect? Don't imitate, innovate!! That line is more appropriate here than in that stupid advert :)

Special Thanks

First, a very big thanks to those of you that emailed me with feedback. Thanks to Des and Adam for their ideas and moral support. And an especially big thanks to Kurt for doing such a great job with flipCode, providing useful ideas about each issue, and putting the column up every week.

Final words

Well, thanks to this column you basically learned in a few weeks what took me over two years. Hope you appreciate how lucky you are. The only difference between you and me right now is practice. I got a lot of that since i learned by trial and error. And there's no other secret to becoming good at coding effects, it's all practice. On the other hand, coming up with original ideas for effects is not something you can work on easily...

As for me, I learned how to stick to a deadline every week (except the last one), and got the satisfaction of helping trillions of potential demomakers now, and for the next few years... Writing tutorials is fun, especially when people actually bother reading them. Needless to say i'll be writing more of them, right here on flipCode, so keep an eye out!

Download the final demo with the whole source code right here (964k)

Best of luck,
Alex

(06/16/2003) An SDL port of all of the demos is available thanks to Paulo Pinto. Download: demomaking.tar.gz (2mb)

Article Series:

The Art of Demomaking - Issue 01 - Prologue
The Art of Demomaking - Issue 02 - Introduction To Computer Graphics
The Art of Demomaking - Issue 03 - Timer Related Issues
The Art of Demomaking - Issue 04 - Per Pixel Control
The Art of Demomaking - Issue 05 - Filters
The Art of Demomaking - Issue 06 - Bitmap Distortion
The Art of Demomaking - Issue 07 - Bump Mapping
The Art of Demomaking - Issue 08 - Fractal Zooming
The Art of Demomaking - Issue 09 - Static Texture Mapping
The Art of Demomaking - Issue 10 - Roto-Zooming
The Art of Demomaking - Issue 11 - Particle Systems
The Art of Demomaking - Issue 12 - Span Based Rendering
The Art of Demomaking - Issue 13 - Polygon Engines
The Art of Demomaking - Issue 14 - Perspective Correct Texture Mapping
The Art of Demomaking - Issue 15 - Music And Synchronization
The Art of Demomaking - Issue 16 - The Final Product