kiiali
10th February 2003 08:41 UTC

advsplash:: suggestion
We usually use advsplash:: to do following splash show

SetOutPath $TEMP
File /oname=splash1.bmp ${SPLASH1}
; File /oname=splash2.bmp ${SPLASH2}

advsplash::show 1200 600 400 -1 $TEMP\splash1
advsplash::show 1200 600 400 -1 $TEMP\splash2

Pop $0 ; $0 has '1' if the user closed the splash screen early,
; '0' if everything closed normal, and '-1' if some error occured.

Delete $TEMP\spltmp.exe
Delete $TEMP\splash1.bmp
Delete $TEMP\splash2.bmp


Can it support JPG/GIF format? JPG is more smaller. Same picture (such as acdsee 2.42 splash), if use BMP, 600K, if use JPG, 80K.

Size different is very large.

Sunjammer
10th February 2003 09:14 UTC

It just uses the Windows call LoadImage so it only supports BMP files. Anything else would require the plugin to contain support for JPEG loading which is not trivial.

virtlink
10th February 2003 12:56 UTC

But consider making another plugin that does support JPEG, because .BMP-files are (always) very big, and JPEG aren't. Maybe adding JPEG support doesn't always cost more bytes than the difference in bytes between an BMP and a JP(E)G.

Sunjammer
10th February 2003 13:25 UTC

It's a worthy idea certainly because general compression algorithms know nothing about image data and so are unlikely to achieve the same kinds of compression as something like JPEG or PNG. Also image compression can be lossy, normal compression cannot be lossy to my knowledge.

virtlink
10th February 2003 16:45 UTC

lossy? You mean that you can lose things? For a simple and tight image, GIF is ideal (with no visual loss), and JPEG (photo's) don't have any visible loss eighter (with a compression rate above 70).

But I understand that you understand me :weird:.

Sunjammer
10th February 2003 19:39 UTC

Lossy is a technical term with regard to compression. It is possible to lose data in compression and have this be acceptable. This is because upto a limit we can't tell that the data has been lost. JPEG exploits this I believe to increase the compression ratio. This is why you can choose the compression quality when saving a JPEG image (or it is at least one reason why).

A lossless algorithm will lead to a perfect reproduction of the original after decompression. This is not always necessary so lossy compression techniques "cheat" to gain extra compression.

virtlink
11th February 2003 10:31 UTC

When I zoom in on a GIF-file, I see that there are many small dots on the solid color around a black written word, for example. But you don't see it when you view it at a 100%. Three posts ago, you said:

Originally posted by Sunjammer
It's a worthy idea (...)

Sunjammer
11th February 2003 10:43 UTC

I'd like to, but I have very little time and a lot of commitments already. I work on the Archive when I can, I try to answer posts here, I have a full time job and activities outside work. My next goal is to try and do that flex dll/com object I mentioned in another thread... unless of course you'd prefer jpeg/gif support.

On another note don't forget that gif is a proprietary format. PNGs replaced GIFS and JPEGS.

virtlink
11th February 2003 11:00 UTC

Well, then you should support PNG's as well. :)

But I think that you should go and work on the flex dll/com object. Without it, liquidmotion can't go on. Without GIF, JPEG and PNG-support, it won't make a difference yet. We'll just use BMP as we always did.