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

Return to The Archives

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.


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 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.


    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,

    (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

    Copyright 1999-2008 (C) FLIPCODE.COM and/or the original content author(s). All rights reserved.
    Please read our Terms, Conditions, and Privacy information.