You can set the window size (default is 800×600), chose an output file and FourCC code for the output video.

It currently only runs unprotected dreams: the dreams that come with DeskScapes will work, but any dynamic dream that you bought won’t.

See the readme file for command line switches.

Download test build here.

Update: Added preliminary support for protected Dreams (you will have to activate them first through DeskScapes).

Still some bugs with the Bouncing Box sample, but it’s getting there. Now let’s proxy some dlls

Changes from the previous version:

• New "Heart" particle texture
• Blur is disabled by default (only for first time install)
• Toned down the blurring   
• Fixed configuration window (no more reloading of the Dream on configuration change)
• Fixed reloading of textures
• Fixed behavior on higher quality settings
• Fixed crash in update when the dream was not starting correctly

Since the last update, most of the work has been directed towards the configuration UI. Loading and saving settings is now fully implemented. I also added a slider to modify the size of the particles.

What’s not working correctly yet:

• Applying a new configuration is causing the dream to reset.
• The colorize shader still needs some work to make it use the particle color (the color is hard-coded right now).
• More particle textures are needed
• The colors need to be tweaked
• The "scaling" code (to adapt to the different quality settings) is not working properly.
• A few potential bugs in the config code

You can download a zip file containing the dll files and the resources, as well as a test program named TestDream that will load the dream inside it’s own window. Simply open a command prompt and launch it with "TestDream.exe Valentine32.dll".

There is also a .Dream file inside, but remember that it hasn’t be tested extensively, so use it with caution (make sure to take a look at the readme file).

Download: Valentine Dream Test Build

The configuration is loaded from the registry at startup (and initialized if the dream is started for the first time). You can tweak it by changing the registry keys as the UI is not functional at the moment.

Once I have the config UI working I will make a test build available (probably not a .Dream at first) so that you can play with it a little

(Background picture is Valentine Favorites by craftilyeverafter – Particle tutorial by Almar Joling was a great help)

It will use some particle system to create the heart itself. You will be able to change the color and texture used for the particles. The background will be chosen among a few different pictures, with a shader applied for blur & coloration.

Things to do:

• load/save configuration
• configuration UI
• Particle "engine"
• Background, with pixel shader for color & blur

The plan is to get a first test build as soon as possible to get some feedback, with a pre-release build on February 8 for final tweaking. I expect to make a final release on February 12.

I need to find a few nice backgrounds (flick is my friend here ). Color selection for the heart will probably be limited to magenta and blue, with 2/3 different particle textures.

As you can see from the two pictures, I’m not really good at sketching I will try to get some screenshots of the real UI soon, so you can get a better idea of how it will look like.

BTW, for people wanting to create dynamic dreams, I can’t really release any source code right now, but you can start by downloading the December 2006 Microsoft DirectX SDK (the version is important!). Creating dynamic dreams is a lot like creating screensavers: get the CD3DScreensaver class that is part of DXUtil and start hacking on it. Converting that work to a dynamic dream should be relatively straightforward once the Dream SDK is released.

The most visible thing lacking is a proper configuration UI. Most of the settings are currently either hard-coded or read from a XML file (instead of the registry).

Those dreams are ports of XboxMediaCenter screensavers. Those are licensed under the GPL, so all source code will be available with the public release.

There are other screensavers in the collection, but they are not yet ready for testing. I will probably not release all of them (some do not make good dreams or are too hard to port).

Here is a description of the Dreams:

• Asteroids: a simple asteroids game simulation (note: the IA is not really good at the game…).
• BioGenesis: this dream implements a ‘game of life’ simulation. Not spectacular, but kind of mesmerizing to look at
• MatrixTrails: the famous matrix letter effect. Really nice one!
• PingPong: the pong game (without score)
• PlaneState: this one is an adaptation of the PlaneState Screensaver. The different configurations are hard-coded and chosen randomly on startup.
• Stars: moving through a star field. A great demo, but probably not recommended for everyday use.

Don’t hold you breath though, they probably won’t be released publicly until Stardock makes the Dream SDK available.

One of the current limitations of DreamMaker is the lack of a save/load mechanism, requiring you to retype everything each time you want to create a new Dream (or update an existing one). While this might not be a big deal with video and trigger-based Dreams, it begins to be a real pain the moment you start creating dynamic Dreams (even more so when you have 8 or 10 of them in development/testing at the same time).

Enter DreamBuilder: a command line tool to build Dreams. It uses a simple XML configuration file to load the info needed to build a Dream file. No more re-typing ! Now you can have the Dream creation cleanly integrated into you build process.

DreamBuilder is using the DreamMaker.dll file (part of the DreamMaker distribution) under the hood to create the Dream file, so the Dream files created will be the same that DreamMaker would have created. Error messages that DreamMaker normally shows are redirected to the console.

Pre-requisites:

• .Net Framework 2.0
• DreamMaker v1.02+ should be installed (http://dream.wincustomize.com)

Usage:

DREAMBUILDER inputFile [/O<outputDirectory>] [/D<variable>=<value>]

    inputFile             Path the dream definition file
    /O<outputDirectory>   Path to the output directory
    /D<variable>=<value>  Defines a variable to be replaced in the XML configuration file.
                          Several such variables can be defined. 

By default, the Dream file will be created in the current directory, but you can specify an output directory (such as the default Dream directory in "My Documents/Stardock/Dreams")

Configuration file:

Here is the example configuration file (included in the distribution).

<?xml version="1.0" encoding="utf-8" ?>
<dream>
    <!-- Dream name - max size: 100 characters -->
    <name></name>
    <!-- Dream description - max size: 600 characters -->
    <description></description>
    <!-- Author name - max size: 100 characters -->
    <author></author>
    <!-- Author url - max size: 200 characters -->
    <url></url>
    <!-- Dream copyright information (optional) - max size: unknown -->
    <copyright></copyright>
    <!-- Dream permissions information (optional) - max size: unknown -->
    <permissions></permissions>

    <!-- full/relative path to preview file - max size: 256x256 - BMP, JPG, JPEG or PNG only -->
    <preview></preview>

    <!-- 3 possibilities: video / trigger / dynamic (if more than one is defined, the first one found is used, others are ignored) -->
    <data>

        <!-- Video dream - full/relative path to video file - max size: 150MB - AVI, MPG, MPEG or WMV only -->
        <video></video>

        <!-- Triggered video dream - type: only "time" is allowed at the moment-->
        <triggers type="time">
            <!-- Trigger definition - at least two different triggers need to be defined -->
            <trigger>
                <!-- Time to trigger the video - in hh:mm:ss format  -->
                <time></time>
                <!-- full/relative path to the file - max size: 150MB - AVI, MPG or WMV only -->
                <path></path>
            </trigger>
        </triggers>

        <!-- Dynamic Dream -->
        <dynamic>
            <!-- Path to 32-bit dynamic dream dll -->
            <dll32></dll32>
            <!-- Path to 64-bit dynamic dream dll -->
            <dll64></dll64>
            <!-- Additional content (optional) - max number of files: 150 -->
            <resources>
                <resource>
                    <!-- full/relative path to the file -->
                    <file></file>
                    <!-- target path (relative to the root dream folder) -->
                    <path></path>
                </resource>
            </resources>
        </dynamic>

    </data>

</dream>

DreamBuilder is checking the XML configuration file against an XML Schema, so it will tell you if there is an error in your configuration (but the message might be a bit cryptic).

DreamBuilder allows you to use relative paths when defining the files to use. By default, it will look for the files relative to the current directory.

This might be a problem if you are executing it from another folder that the one containing the files. This is why I introduced variable replacement: it provides a way to dynamically replace content in the configuration file. I use it for path handling, but you can also use it for other things such as adding a version number to the dream name.

The replacement step is happening before the file is parsed, so you can go crazy if you want, and generate the resource list at compile time for example.

You can have as many variables as you want (simply by adding another variable definition to the command line). To define a variable "name" with the value "Julien", you use the following define: "/Dname=Julien". You can then add a new variable to the XML configuration file: $name$. DreamBuilder will warn you if a variable exists without a substitution.

Example:

As an example, here is the config file I use for the MatrixTrails dynamic Dream:

<?xml version="1.0" encoding="utf-8" ?>
<dream>
    <name>MatrixTrails</name>
    <description>Matrix Trails Dream</description>
    <author>Julien Templier</author>
    <url>http://julien.wincustomize.com/</url>
    <copyright>Copyright (c) 2008, Julien Templier[...]</copyright>
    <permissions>This program is free software; you can redistribute it and/or [...]</permissions>

    <preview>$resdir$/MatrixTrails.png</preview>

    <data>
        <dynamic>
            <dll32>$builddir$/MatrixTrails32.dll</dll32>
            <dll64>$builddir$/MatrixTrails64.dll</dll64>

            <resources>
                <resource>
                    <file>$resdir$/MatrixTrails.tga</file>
                    <path>resources</path>
                </resource>
            </resources>
        </dynamic>
    </data>

</dream>

You can see all the files have a variable at the beginning of the path. Those will be replaced when the Dream is built.

In Visual Studio, I then added a post-build step calling DreamBuilder that takes care of defining the right variables:

DreamBuilder $(ProjectDir)/Resources/$(ProjectName).xml /O$(TargetDir) /Dresdir=$(ProjectDir)/Resources /Dbuilddir=$(TargetDir)

That way, each time a build succeeds, a Dream is generated that can be easily tested & distributed.

Download:

DreamBuilder is currently available as a zipped file (to be extracted to the directory of you choice). You might want to add it to your path to be able to call it from anywhere.

A MSI file is planned that will take care of adding the installation folder to the path.