Progress !

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

The biggest new feature is the furry editor. It allows you to design your own flurries and easily share them with your friends.

I’ve also added an UI for assigning per-monitor flurries. You can now have a different flurry on each of your monitors.

It has an updated configuration UI that exposes some existing options: an FPS indicator, the possibility to use a "Block Mode" or a "Whiteout Mode" and a way to shrink the flurry window to use only a percentage of the fullscreen window.

Under the hood, there has been quite a few changes with some heavy refactoring to prepare for the flurry editor.

Download from Wincustomize or Download from this site

Full changelog:

Version 1.3.1 Build 41 (07/21/08)
    - Added per-monitor flurries
        * Separated global preset and per-monitor preset
        * Simple UI for assigning flurries to monitors
    - Added flurry editor
        * Presets are saved directly after creation/modification. Deletion is effective when closing the main dialog.
    - Bug fixed
        * Preset names were not stored correctly in registry
        * Fixed deletion of preset (UI was not updated correctly)
        * Crash if Flurry wasn't installed before on the computer

Version 1.3.0 Build 26 (08/10/08)
   - UI Changes
     * Moved credits to About window
     * Added UI for shrink percentage & FPS indicator
       (only in single-buffer mode)
     * Added UI for Block & Whiteout modes
   - Editor
     * Added new/edit/delete buttons
     * Added Editor dialog (not yet functional)
   - Refactoring of code
     * separated settings in a class (preparing for per-monitor flurries)
     * Removed some global variables
     * cleanup/rename: all classes are now in the Flurry namespace
     * Updated Spec class (copy constructor, misc. updates) in preparation
       for editor
   - Bug fixed
     * Preview was not showing the selected preset 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

Here we go: a very crude version of the configuration UI and two screenshots of the dream (with and without a background).

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)

For valentine day, I decided to create a new dynamic dream: it will be an "animated" heart using particles. Time is limited, so I’m doing something simple. You will be able to tweak some settings such as change the color & background, but most things will be hard-coded.

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.

If you have tried to make Dreams in the past, you have been using DreamMaker. This application allows you to take a video file (or several of them in case of a trigger-based Dream) and "compile" it into a .Dream file. This Dream file also contains other information such as the name of the author, a website URL, copyright and permissions info, and a preview image.

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.

I’ve been sitting on that one for quite some time. It’s still not in a good enough state to be called a beta (or even alpha), hence the technical preview. It comes bundled with one logon (by yours truly ). The included logon is still a work in progress: stock buttons, no custom sound, no loading animation, etc.

What’s missing/not working:

• Logon editor (won’t be in 1.0)
• No check for image format when applying a logon (images in the wrong format will break the logon UI, resulting in a black screen)
• Replacing UIFile files is disabled (considering removing support for it as doing it correctly is a lot of work: simply replacing them might be too dangerous)
• No documentation
• a gazillion little and not so little UI bugs

Installation instructions:

1. Extract zip file to a directory of your choice
2. Run LogonSwitcher.exe
3. Drag&Drop Nature.logonswitcher onto the program window or use the import button
4. Click Apply (and pray)

DISCLAIMER:  As ALWAYS, USE WITH CAUTION. BACKUP/CREATE A RESTORE POINT BEFORE INSTALL.

Please leave your feedback (either in the comments or through the contact form) !

TaskManagerEx is a Task Manager add-on I’ve been using for a while. It adds a lot of new functions to the standard task manager. It will allow access to processes modules, opened files and kernel handles lists, as well as memory map & file properties. In addition to those, it also slightly improves the Task Manager UI by adding an icon in front of each running process and by highlighting service processes.

The currently available version runs on Vista but due to changes to the Task Manager, the context menu functionality is broken.

The updated version has the following changes:

• New icons for services, “unknown” processes & main program
• Updated context menu (moved items to a submenu to reduce clutter)
• Removed splash screen & Russian translation
• New image for tooltips
• New toolbar images (WIP)
• Source code cleanup

Currently listening to Mika – Life In Cartoon Motion – Grace Kelly

Volume Control and the DXVolumeControl plugin have been uploaded to Wincustomize. You should be able to get them in a few days. Here are the links: Volume Control and DXVolumeControl (they haven’t been moderated as of today, so you will have to wait a little bit).

After finishing the Vista version of the Volume Control widget, I actually added a XP compatibility layer to the DXVolumeContol plugin, so the only thing the vista version has over the XP one is true synchronization between the volume mixer and the plugin (on XP, the callbacks function are not working). This allows me to only have one version of the plugin running on both operating systems (less work needed on my side, which always is better ).

Work on LogonSwitcher has been slower than I wanted. Version 0.7 should go to my two beta-testers today. Still a lot of work needed on the UI, but the basic functionality is in. I added a bunch of logon using really nice pictures from flickr (under a CC license). I still need to do a full logon with all new graphics (this is going to take a lot of time ) 

 Corrected some problems with the export functionality. Some of those only happen when using multiple file format (that won’t be the case for the first release).

Currently listening to Norah Jones – Somewhere Over the Rainbow/What a Wonderful World

Today I corrected a bunch of remaining issues with LogonSwitcher. The logon preview now shows the password box correctly, the main logon list has better looking borders, etc. I tested a little bit more under VPC to make sure it applies a full logon (not only a new background) I also added some new logons using nice images from Flickr (I’m using images under CC BY or CC BY-NC-SA, so it’s to distribute them).

It still need to be tested thoroughly, and that’s why I recruited two beta testers to get some feedback and to help me refine the UI. The poor ones don’t know what they are getting into

On another matter, I finally updated my project page, adding the remaining pages. I still need to write descriptions for some projects, but at least nobody is going to get a 404 error anymore.