There hasn’t been a lot of visible changes since the last status update, but a couple of small graphic problems have been fixed:

• Alpha transparency drawing is implemented (resulting in correct drawing of ok/cancel buttons)
• Default menu cursors are now shown properly
• Dialog box messages with no message type are displayed properly
• Button highlights are drawn in the correct order (Common::sort is unstable, resulting in an incorrect drawing order when images have the same priority)

Behind the scenes though, a lot has been done: most of the Pompeii game logic is now implemented, along with proper timer handling and there has been some work done on movies, sound and the 360° view.

A new version of Delivery Tracker has just been released. It now supports tracking packages via TNT and includes small fixes for UPS and USPS. You can also start tracking packages by clicking the reference number in the info panel. This is especially useful for Amazon packages if you want to track each package separately.

Note: Auto-update is broken in the previous beta build, so you will have to download the new one manually.

You can read the release notes and download the new version now.

Just a quick update to say that several graphic problems have been fixed since the last status update:

• Most images are no longer drawn at wrong coordinates (for example the dialog boxes or some screen elements in the preferences)
• The first line of images is now being drawn properly (fixing corruption that appeared in some cases)
• Some 32bpp images are now shown properly (it converts them from 32bpp to 16bpp on the fly until we get full support for 32bpp screen surfaces), but with graphics problems when the game is expecting alpha transparency
• Image cursors are shown with the correct coordinates/colors (downsampling from 32bpp to 16bpp here too)
• Highlights now work on menu entries and dialog options
• AND the decompression problem has been fixed (by a single line change…) !

Since the first commit at the end of January 2011, the ring engine has come a long way. Most of the shared engine code for Ring and Faust has been implemented, along with the whole logic for Ring and a sizable chunk of logic for Faust.

The main game view (the 360° view) is not yet implemented, but there is enough display code present to show the game menu in Ring (as well as several submenus). As you can see in the screenshot, there is some image corruption present, due to problems with the image decompression.

And that brings us to the compression algorithms used by the engine: one thing is clear, the original developers loved coming up with new compression types (I’m thinking there was a bet on how many such algorithms they could fit in a single engine). BMP, TGA, WAV (compressed as a whole or streamed), CNM (movies), AQC (360° view data) each use a different variation of the algorithm (with a large amount of duplicated code of course of course, it wouldn’t be fun otherwise!).

And for the next games in the series, they decided to share a single compression format for all images in archives. So in addition to the old compression formats from Ring, Faust introduces a new format, also used for movies…

The new compression code also uses floating point, which makes it quite a bit harder to reverse-engineer. And since most images are inside archives, Faust and the following games are not displaying anything yet.

I’m currently working on implementing the new set of “widgets” used by Pompei and Jerusalem. It includes a dialog selection widget (mostly done) and a hyperlinked encyclopedia (only started reverse-engineering in IDA).

A new version of Delivery Tracker has just been released with lots of fixes and improvements across the board. In addition to the provider updates, the new version adds support for the recent items list on Windows 7, allowing you to open a recently tracked package directly.

You can read the release notes and download the new version now.

I’ve recently spent some time on the asylum engine, implementing the missing logic and display code and fixing problems in the already implemented code.

The logic and actor code is now almost complete and most of the puzzle-specific code has been implemented.

Quite a bit of time has been spent on the drawing code and Max is now drawn with the correct priority. Masked blit has also been implemented, although it is still very buggy (as can be seen on the screenshot). Palette fading is present now (with some small bugs left to fix), making transitions from the menu to a new scene or a movie a lot nicer.

We also tracked down several major bugs, making the text drawing orders of magnitude faster and finally allowing Max to leave his cell. Alexander (midstream) and Alex (alexbevi) contributed quite a bit (implementing almost all the functionality for the missing puzzles and debugging and fixing several problems).

I’m going to be back on Ring for a bit, but the amount of work needed to put the engine in a mergeable state is now a lot less.

DockletX has been updated with support for ObjectDock 2. DockletX is a DesktopX plugin that allows you to use ObjectDock docklets on your desktop.

Full changelog

• Add support for ObjectDock 2
• Blacklist Weather docklet (it doesn’t work outside of ObjectDock as-is)

You can download DockletX from Wincustomize.

Hey all!

For the past few days, I’ve been working on a weather script component. It takes the form of an independent .wsc script file that you reference in your widget script (setting up license info and registering callbacks), calling a few methods and getting weather/location/alert data in the form of a script object with several properties.

Using this new script means rewriting a lot of the existing weather objects script, only keeping the UI handling in the widget scripts and delegating all the weather stuff to the component. It’s not a short term solution for authors that need to update their widgets in the next few days, but I think it’s the easier and more maintainable solution in the long run, as it would finally do away with the duplicated and slightly tweaked weather code in all weather widgets.

The plan is to support several widget providers in the same script, in a mostly transparent way. Right now, I’m planning to have the following providers (in this order):

• wunderground
• weatherbug
• weather.com
• METAR (their xml doesn’t seem too nice to parse and their text only data looks like it’s getting right out of an old mainframe)
• accuweather

Using the script

I’ve tried to make the API as simple as possible, hiding most of the complexity in the script component.

To start using the weather component, you need to create a new instance of the script and register callbacks. Those are functions that will be called when new weather data is available.

Set WeatherController = GetObject("script:" & LIB_FOLDER & "Weather.wsc")

WeatherController.RegisterCallbacks GetRef("OnLocations"), _
                                    GetRef("OnWeather"), _
                                    GetRef("OnAlerts"), _
                                    GetRef("OnForecast"), _
                                    GetRef("OnCameras"), _
                                    GetRef("OnError")

Set WeatherController = GetObject("script:" & LIB_FOLDER & "Weather.wsc") 

WeatherController.RegisterCallbacks GetRef("OnLocations"), _
                                    GetRef("OnWeather"), _
                                    GetRef("OnAlerts"), _
                                    GetRef("OnForecast"), _
                                    GetRef("OnCameras"), _
                                    GetRef("OnError")

You can then get a list of supported providers to let the user choose the one he wants, of simply hardcode the provider you want. If the provider requires a license key, you can also set it at this time, as well as the unit system to use.

WeatherController.SetProvider "WUnderground"

' Default is True
WeatherController.UseMetricSystem = True

' This will be ignored by the WUnderground provider as it does not use a license key
WeatherController.SetLicense "my_id", "my_key"

Contributing

Once the API is stable, I’ll update this post and if you want to help me add support for the other weather site, let me know!

If you want to use the script and there is some functionality that seems to be missing, post here or PM me and we’ll see if it can be added.

Download

I’m still working on the script and the API is still in flux, but you can get a look at it here.

The plan for this plugin is to include all system-related functionality that isn’t already available in the DesktopX System namespace.

Download

You can download a test version here (set to expire on 10/5/2009).

If you have ideas for stuff to add to this plugin, feel free to post them on the DesktopX 4.x request thread.

Plugin Information

Mouse wheel

• SystemEx_OnMouseWheel(rotation)
• SystemEx_OnMButtonDown(x, y)
• SystemEx_OnMButtonUp(x, y, dragged)

Monitor information

• Monitors
• NumberOfMonitors
• GetMonitor(index)

MonitorInfo object:

• IsPrimary
• Left
• Top
• Bottom
• Right

Volume

• Volume
• Mute
• PeakValue (read-only)
• SystemEx_OnVolumeEvent(volume)
• SystemEx_OnMuteEvent(isMuted)

Instance

• CommandLine
• CommandLineArgs
• IsFirstInstance
• SystemEx_OnNewInstance(commandLineArgs)

Misc

• VerifySignature(path, signature, type)

Documentation

Mouse wheel

SystemEx_OnMouseWheel(rotation)

When the mouse is over the object and the mousewheel is used, the SystemExOnMouseWheel
function will be called with the wheel rotation passed as a parameter.

The wheel rotation will be in number of lines.

Default value: 3
Default value for page scrolling: 10

A positive value indicates that the wheel was rotated forward, away from the user;
a negative value indicates that the wheel was rotated backward, toward the user.

SystemEx_OnMButtonDown(x, y) & SystemEx_OnMButtonUp(x, y, dragged)

When you middle click on your object, the SystemEx_OnMButtonDown function will be
called. When you release the button, theSystemEx_OnMButtonUp function will be called.

Both functions will have the mouse coordinates relative to your object passed as
parameters.

Monitor Information

This one was asked by Zubaz to better handle multi-monitor systems. As it turns out, the virtual screen coordinates are not nearly enough to be able to position objects on multi-monitor systems. WMI is exposing monitor information, but it does not seems to work reliably (it only gives information for the first monitor on my system for example).

SystemEx.Monitors

Gets an array of MonitorInfo objects

SystemEx.GetMonitor(index)

Returns the MonitorInfo for the given screen

SystemEx.NumberOfMonitors

Gets the number of monitors on the machine

Volume Information

SystemEx_OnVolumeEvent(volume)

When the user change the master volume through the volume mixer or another application
your object callback is called. The volume parameter will contain the current master
volume.

XP Compatibility: never called.

SystemEx_OnMuteEvent(isMuted)

If the volume is muted, your object callback is called.
isMuted will be True if the volume has been muted, false otherwise.

XP Compatibility: never called.

SystemEx.Volume

Sets or gets the master volume.

Usage: 
SystemEx.Volume = <volume>
<volume> = SystemEx.Volume

<volume> should/will be between 0 and 100. Any value outside these bounds will be capped.

SystemEx.Mute

Mute or un-mute the audio stream

Usage:
SystemEx.Mute = True
isMuted = SystemEx.Mute

Mute can take two values: True and False.
If Mute is True the audio stream is muted, otherwise it is not muted.

SystemEx.PeakValue

This is a read-only property. It allows you to get the peak level value for the
currently playing sample.

Usage: 
level = SystemEx.PeakValue
level will be between 0 and 100.

XP Compatibility: might not work with some cards, in which case it will always  returns 100.
It reads from the waveout device, so it won’t work when reading from a CD for example.

Instance Information

SystemEx.CommandLine

Get the full command line (including the path to the executable and DesktopX-specific arguments)

SystemEx.CommandLineArgs

Get an array of command line arguments.
Command line arguments have been cleaned up to remove DesktopX-specific arguments (in the case of single-exe gadgets)

SystemEx.IsFirstInstance

Will be True if this is the first instance to run, False otherwise.
It is preferable to check for it at startup and close the gadget accordingly,
as only the first instance will receive a callback message when a new instance is started.

SystemEx_OnNewInstance(commandLineArgs)

Gets called when another instance is started. The command line arguments are passed in an array.

Misc Information

SystemEx.VerifySignature(path, signature, type)
Check the signature of the file pointed to by path.

The only type of signature supported at this time is SIGNATURE_SHA1

Changelog

1.0 Build 228:

• Renamed to DXSystemEx (plugin namespace is now SystemEx)
• Added SHA1 signature check
• Added MouseWheel and Middle button click callbacks (merged from DXMouseWheel)
• Added Master volume control / Mute / Peak (merged from DXVolumeControl)
• Added instance information (merged from DxInstance)

1.0 Build 205:

• First test version

This is a very small plugin for DesktopX that exposes command line information in your scripts, allowing you to act on certain parameters. It also adds a new callback that is called when another instance is started and gives you its command line arguments.

Use

• associate a gadget to a custom file type and be able to do custom processing when called with the file path as an argument.
• make the "Tasks" category of the jump list in Windows 7 usable (they are shortcuts and supposed to be available even if the application is not running, so they need to be shortcuts to the single exe, not the extracted one).
• handle any other custom command line arguments like a normal application.

Documentation

Remember to select “Allow multiple instances of the application to run” when exporting your gadget!

Here are the new functions/callbacks available to your scripts:

Instance.CommandLine

Get the full command line (including the path to the executable and DesktopX-specific arguments)

Instance.CommandLineArgs

Get an array of command line arguments. Command line arguments have been cleaned up to remove DesktopX-specific arguments (in the case of single-exe gadgets)

Instance.IsFirstInstance

Will be True if this is the first instance to run, False otherwise. It is preferable to check for it at startup and close the gadget accordingly, as only the first instance will receive a callback message when a new instance is started.

Instance_OnNewInstance(commandLineArgs)

Gets called when another instance is started. The command line arguments are passed in an array.

Download

This plugin functionality is now part of the DXSystemEx plugin. You can get more information in this blog post.

Note: This plugin will not work with single-exe gadgets (or widgets)! Due to the way simple deployment gadget’s command line is handled, adding arguments will result in the gadget not even starting (it’s treating almost any command line argument as a path…). I sent a bug report/request to Stardock, but in the meantime, you will have to use custom deployment. I have a binary patch available for DXAppCustom.bin that fixes the command line parsing and allows gadgets to get the original command line (but disables ObjectBar-related code as it’s kind of a hack), so it’s definitely fixable. Let’s hope the next version of DX will have a fix.