Benoit,

> I downloaded this VM and unzipped the file and got 2
> executables.  Can anyone tell me what is the
> difference between Squeak-D3D.exe and Squeak-GL.exe  ?

See message below - it's the original announcement of the VM.

> And is there any reason why the zip file and all files
> have a timestamp of May 2001 ?  Weren't they built
> recently?

No, they weren't. Do you have any problem with it?! ;-)

Cheers,
  - Andreas



-----Original Message-----
From: Raab, Andreas [mailto:Andreas.Raab at disney.com]
Sent: Friday, May 18, 2001 7:31 AM
To: squeak at cs.uiuc.edu
Cc: recipient list not shown
Subject: [Win32][VM]: Update to 3.1 Alpha build 6


Folks,

I've just uploaded Alpha build 6 of the 3.1 VM which is in the usual places
at

http://isgwww.cs.uni-magdeburg.de/~raab/squeak/SqueakExe.zip
http://isgwww.cs.uni-magdeburg.de/~raab/squeak/src/Squeak3.1Alpha6Src.zip

This VM has a couple of interesting features so here we go:

[3D Acceleration]
The executables currently come in two forms. One is a build against Direct
3D and one against OpenGL (didn't have the time to integrate the two yet).
If you don't care about acceleration use whichever you want. If you care
about acceleration I recommend the D3D version - it's faster, better
integrated and it's been tested. If you are on NT you will have to use the
OpenGL version - D3D is not supported on NT, only on Win2K.

There are few things that are specific to each version:
* D3D
Requires DirectX 7 or later. If you are on Win95/98 and you do not have DX7
installed (AFAIK, Windows ME and 2K should have it by default) go to
http://www.microsoft.com/directx/homeuser/downloads/default.asp
and grab the latest version from there.

* OpenGL
THIS VERSION IS UNTESTED! My drivers do not work correctly but given that
I've got my share of experience with OpenGL chances are that it will work.
If you have problems, enough experience, and a little time then grab the
sources and fix any remaining bugs.

[LSB display formats]
This VM does support little endian display bits. IF AND ONLY IF you are on
the leading edge of the update stream you may try to do something like:

	Display newDepth: -16. "gimme little endian pixels"
	Display newDepth: 16. "gimme big endian pixels"

Why is this interesting?! Well, here's a little benchmark:

	| msbTime lsbTime |
	Display newDepth: 16.
	msbTime := [1 to: 100 do:[:i| Display forceToScreen]] timeToRun.
	Display newDepth: -16.
	lsbTime := [1 to: 100 do:[:i| Display forceToScreen]] timeToRun.
	^{msbTime. lsbTime}

On my laptop this sums up to 2433 msecs vs. 888 msecs which is roughly a
factor of three in speed [which is not surprising considering that we're
having two passes for reversing the pixels]. Two notes here: #1 The speed
improvement in the above depends on your host display settings. #2 Please do
not expect to see a factor of three in real-live applications (especially in
Morphic). The above is a benchmark showing how much we're paying for having
to do pixel reversal; the actual improvements will be much less than the
benchmark (however, the benchmark is interesting for game-like stuff).

Finally, two warnings:

WARNING #1:
This VM will - if used with an "old" (that is not a 3.1alpha updated to the
very latest) - produce black Wonderlands. If this happens to you and you
want to fix it here's how:

	B3DEngineConstants at: #PrimLightFlags put: 21.

WARNING #2:
Do not even try to use "Display newDepth: -mumble" on some older image.
These lack some necessary support and will just crash on you.

Other than that ... enjoy!

Cheers,
  - Andreas