This can cause transparency colours to be wrong if there are slight variations in the way that bitmaps are rendered by GDI.
This is because the transparency colours are obtained using GDI functions which are not device independent. This problem was initially seen when a configuration file generated on Windows 98 was used on Windows NT but it is conceivable that tweaking Gamma settings on advanced video cards on a single operating system installation could also cause this problem.
Why not fixed?
This would be a major rework affecting colour fetching routines, transparency,
rotation, displaying and possibly the AVI writer. It's all down to the way
that the VB picture control works. It's sufficient at the moment.
Workaround
Use a graphics resolution that has at least as many colours as your input
picture. Save environment specific .ini files for Windows 9x and NT if you
need.
Example:
Start time=12:00:00, Duration=5s
Effect:
Animation shows 12:00:01, 12:00:02, 12:00:03, 12:00:04, 12:00:05.
Starting at 12:00:00 and setting to 60s will end at 12:01:00.
Cause:
This is correct behaviour.
Remedy:
Set the time to 12:00:00, duration to 1s, FPS to 6, second hand smooth
movement enabled. The clock moves smoothly showing that the time is
indeed inclusive of the first second.
Resolution:
If you want to to be inclusive without second hand smooth movement set the
start time to one second before.
This was an initial design decision. It will not change now.
2. Skewing shown at 30s for any hand for high resolution clock.
Example:
radius 183, hand length > 85%
Effect:
At 6 o'clock the hand is not completely straight. The x coordinate is 1
pixel out from the x coordinate of the centre point.
Cause:
The x position from the centre to the outer point is out by 1 pixel because
the points are spread slightly because of the large radius. This is
potentially noticable at 12, 3, 6 and 9 on the clock face.
Remedy:
The straigtening feature copies the centre x coordinate to the x points at
0\360 and 180 degrees and the centre y coordinate to the y points at 90 and
270 degrees for all calculated circles. This solves the problem.
Resolution:
Fixed in 0.9. Use the straightening feature on the advanced form.
3. Saving uncompressed AVIs causes colours to be displayed wrongly in AVIEdit and Real Producer. The files were displayed correctly in VirtualDub and Windows Media Player, and compressed files were always displayed correctly in AVIEdit and Real Producer.
Cause:
This was down to the way that the picture structure was declared in COMGDIAVI.DLL
Remedy:
Fixed in 1.0 by using Comgdiavi.dll version 0.4.
4. Minute hand running, changing to the hour, one second out with minute smooth movement.
Example:
Start at 3:59:37 and run for 30 seconds.
Effect:
Rolls onto hour when second hand is at 50s. Should be on the hour.
Cause:
Only fine when smooth movement is off. Despite initial thoughts of this being a precision
problem the calculation has been modified to adjust the offset for the minute hand smooth movement start
position in both 10 and 15 second minute hand increment modes. Looks OK now.
Remedy:
Fixed in 1.0.
5. Hex encoding of selected point colour was displayed wrongly.
Example:
Select pure blue "0xFF0000 -> (0,0,255)" was displayed.
Cause:
Hex$(val) was perfomed on a colour, because of endian differences this was reversed from
the logical RGB values. Decimal display used correct method. Each RGB colour is split and
Hex$ is performed on each RGB unit. Also 0 extended now.
Effect:
None, this was for display purposes only. The decimal version was correct.
Remedy:
Fixed in 1.0.
Back to index.