you can select the renderer to use by settting the environment variable
J2D_D3D_RASTERIZER to one of the rasterizer names. (I don’t recall how
to set environment variables in the Windows shell anymore, though.) It
says that if you can’t reproduce the problem with the ‘ref’ reference
rasterizer, then it’s probably a video driver bug.
Give these a shot and see which of them have this problem. (At least one
of them—whichever the default is for you—must.)
The image which has given you trouble is indexed, but I suspect that’s
a red herring, as that shouldn’t affect how it’s stored in memory once
loaded. What I think is triggering the problem is that this image has no
alpha information at all. I’ve converted the image to be RGB, but with no
alpha channel, and it’s attached to this post. Try adding this image to the
test module and check whether it also has the problem. (My hypothesis is
that it will.)
After doing some reading, it sounds like a Video driver bug.
hal and tnl both try to use the full hardware capabilities of the video card.
ref is a reference driver that uses no hardware acceleration at all and should work on any card, but with no harware performance improvements. I would expect this to be equivalent to turning off the d3d pipeline altogether?
Yes, it has a similiar problem - the piece does not appear at all.
Ok, that’s what I thought would happen. So the problem is with opaque
compatible images, not with indexed images.
I have a thought about how to handle this. It might be possible to detect
from the Module Manager whether a D3D driver is going to work if painting
to a BufferedImage goes through the same pipeline—all we’d have to do
is paint a fully opaque test image out to another compatible image at 50%
opacity, and then compare the result with a reference image (the original
image, but saved at 50% opacity). If they differ, then we can’t use that
D3D driver and have to try another one.
I’ll work up a test case for you to try on Tuesday evening.
GeForce 8600GT using Forceware 178.24 on Vista SP1
Google
direct3d hal rasterizer problems
It will be great if we can actually detect this programatically. I assumed it was a problem in the rendering to the card and that we wouldn’t see any difference within Vassal.
If that’s the case, we will probably need to go with a Global preference ‘Disable D3D rendering’ or similiar.
Which reminds me of another issue I hope to handle one day - that the Module Manager has a preference dialog that gives you access to the Global preferences. (Adding a RFE now)
In general this seems to work fine on my iMac G5 (PPC architecture),
Mac OS X 10.4.11
I tried it on just a couple of modules. I did notice some oddities,
but since I hadn’t really tried these with previous versions, I would
guess that they are not new problems.
Silent War Module v0.96 (from compassgames.com/
downloads/SWvassal.zip – yes, it really is a zip file containing the
module and some instructions). The two problems I noted were in the
display of large stacks. The example is the large stack in the top
right corner of the map in the campaign game start.
Problem with mouse-over stack viewer, having units from a large
stack extend off the edge of the window.
Problem with an expanded stack near the map edge having the top
units end up off the map and thus not be individually selectable.
RAF module v1.00 (from Vassalengine).
Problem with an old selection rectangle remaining behind when
moving cards from the card decks at the bottom of the main map onto
separate window name “Scenario Removed Card Holders”. See attached
screen shot (maybe — I’m doing this from mail). The problem can be
created by opening that window (it is opened by the button just to
the right of the die button), and then dragging a card. I continue
to show a green rectangle (of different sizes each time) when I drag
a card to that window.
The image being loaded is ge_1_15_29m_821.png, the one you sent me. It’s
then rendered into a compatible image at 50% transparency, and saved with
the name result.png. What I see when I run it is what_i_get.png. Compare
these two on your machine.
Try this: Add the following line to VASSAL.tools.imageop.ScaleImagePainter
in the draw() method, immediately above the call to Graphics.drawImage():
System.out.println(img);
Then run the test module with it. I want to see what’s printed when you
show the piece with the image (1) at full size, (2) at full size but
with the LOS thread on, (3) at some other size, and (4) at some other
size with the LOS thread on.
The same image is drawn both with and without the LOS thread on. The transparency setting is handled at a higher level at Map.drawPiecesInRegion():1447 where the AlphaComposite is set into the Graphics2D that is then passed down eventually to ScaleImagePainter.
These are what I expected to see. Mainly what I wanted to verify is that
the type of the scaled image is INT_RGB and opaque, which it is.
Could you show me what you get when you load your test module, the one from
which you took the original pictures? Is it possible that the piece image
which is drawn correctly is INT_ARGB?
Could you load the same setup that you had which you took the first
screenshot of? I want to see if the problem piece and the one which is
apparently unaffected have different image types.
Ok, Loaded up a game with that module and pulled 2 pieces. One is a standard piece with the ge-1-15-29m image, the other piece is generated by Game Piece Images. It is the Game Piece Image piece which is unaffected.