I seem to experience reproducable crashes on some machines when castmembers
of 8 Bit color depth appear in a 16 bit color depth environment.
This only happens from a projector. NT 4.0, DfW 6.02, screen is set to
15 or 16 bit color depth. It only happens on some machines, the graphic
card is an ELSA Winner 1000 with 2MB. The crash occurs right before an 8 bit
member appears on the stage amidst members of 16 bit colordepth.
This is not a problem of an individual 8 bit member, whichever happens to be
the first triggers the show. With the runmode = "Author" everything is fine.
The effect can be suppressed by transforming the bitmap(s) to 16 bit color depth.
However, with several thousand bitmaps in 200+ internal and external castlibs
finding, selecting and transforming the #bitmap members with a depth of
member = 8 is a bit unpractical since, although i can set the selection
of castlib aLib to a list of culprits, transform bitmap is still greyed
out in the menue.
And I found no way to transform a bitmaps color depth via lingo.
So, I have two questions:
First, is this a known problem, is using 8 bit graphics in a 16 bit
context unsafe behaviour?
Second, does anyone have ideas how to automate the transformation of
some member x of castlib y from 8 bit to 16 bit so I can roll a handler
not only to list the culprits ( I have that already) but fix them?
Thank you for your attention,
best regards
Daniel Plaenitz
The error messages:
The OS error message claims an illegal instruction 0xC000001d at 0x00d42da4.
(Actually the message reads "Ungültige Anweisung" since this is a German
localized NT 4.0 Sp3)
Under w95b on the same machine the message reads:
Modul DIRMMX.X32 bei 0137:00e02da4 aus.
Register:
EAX=000002a0 CS=0137 EIP=00e02da4 EFLGS=00010202
EBX=009f1c48 SS=013f ESP=0077f2d8 EBP=0077f2e4
ECX=00000054 DS=013f ESI=02e4a619 FS=19e7
EDX=009f1480 ES=013f EDI=005815c0 GS=0000
Bytes bei CS:EIP:
0f 6f 03 0f db 05 50 ad e0 00 33 db 8a 1e 66 c1
Stapelwerte:
00000000 0052b9a4 02e4a618 0077f374 004cfe61 005815c0 02e4a618 009f1480 00000000 00000000 00a11810 00650162 00000000 00000000 00e01082 00e01019
---------------------------------
First of all, I want to thank Terry Graham, P!M, minty, Jim Bell and
all other contributors for the valuable input I received.
To make it short, there are a lot of ways to answer the 2nd question.
I received only one feedback relating to question #1, stating mixing
8bit and 16bit graphics never made problems there.
Transforming bitmaps to higher bitdepths can be done either via an extra
or by utilizing the director default of creating a new bitmap at the
current color depth of the stage.
The xtra, according to P!M: Penworks' CastEffects which has a "Transform
bitmap" function. Downside: The tremendous* memory leak in this function,
so you can't really
use it (on Mac that is). You can use CFX freely in authortime, so you
don't have to buy it.
The lingo based way requires to set the monitor to the desired color depth
(16 bit for me) as the first step. Next you basically save the old bitmap,
erase that member and recreate it and director will create it using the
current color depth by its own. Using the clipboard functions as P!M and
Jim Bell recommended seems a very elegant solution.
I actually used and tested the first proposed method (from Terry Graham)
I received the same day I posted my question. Although Terry warned to
keep in mind that changes to cast members have to be remembered I had no
problems with memory, but I added some lines to restore the name and the
regpoint of converted bitmaps.
on changeDepth
-- transform all #bitmap of 8 bit color depth
-- to the current color depth
set templateMember = new(#bitmap)
set ini = 1
set end = the number of castlibs
repeat with i = ini to end
set lastMbr = the number of members of castLib i
repeat with j = 1 to lastMbr
set dMember = member j of castlib i
if the number of dMember > 0 then
if the type of dMember = #bitmap then
if the depth of dMember = 8 then
set tempPic = the picture of dMember
set tempName = the name of dMember
set tempReg = the regpoint of dMember
duplicate templateMember, dMember
set the picture of dMember = tempPic
set the name of dMember = tempName
set the regpoint of dMember = tempReg
end if
end if
end if
end repeat
end repeat
end
N.B.: this is a fine example on the difference between the picture of
member x and the media of member x. The above handler did *not* work
when I used the media instead of the picture. Apparently the media
includes the color depth while the picture does not.
As to my first question, I 'm not any wiser now. I've seen the crashes
on 2 pc boxes and nowhere else. One of those has both w95 and nt4, it
crashes on both of them. The hardware of those boxes is not at all similar,
about the only thing they have in common is: none of them has an intel
processor. w95 on both of them is fresh with almost no software installed...
- it remains a riddle, may be a freak effect, however, I choose not to risk
that any other machine performs the same trick and rather transform the bitmaps.
If anyone experiences a similar problem I'll be eager to learn about the details.
-----------------------------------
At 12:30 07.10.98 EDT, jd wrote:
>Daniel Plaenitz wrote on Oct 7, in part, "Summary: on 1.10.98 I wrote about
>regular crashes on some machines under w95/NT when 8 bit graphics appear in a
>16 bit environment..."
>
>I've been reading the recent threads, but can't tell the critical parts...
>just in case, D501/Win32 Projectors *did* have a crashing failure when trying
>to create graphics at runtime that were at a different colordepth than the
>monitor.
>
Thanks for your input, John, it did help me isolate the problem, though
rather in a indirect way. When playing around with stub projectors from
different versions I discovered, more or less by accident, that there were
no more crashes when the projector started w/o xtras. 5 minutes later I
knew that in fact I had all the data already but just had not seen the
connection: w95 's error message actually mentioned dirmmx.32 as the
culprit, both machines I had the crashes were non-intel processors and
deleting dirmmx.32 from the xtras folder did help. Afterwards I even found
techNote ID: 12103 and now, reading that techNote, I just wonder how an
AMD 486DX cpu manages to signal mmx capability...
Are there any data to the possible performance gain dirMMX.32 offers on
intel cpu 's?
Will it work if I keep that xtra in another folder and only activate it
with new() after I made sure that indeed an intel cpu is present?
D. Plänitz