The download is quite large. However, if you’ve downloaded the previous demo, download this one: myweb.dal.ca/mkiefte/ClampedTextureDemoSmall.zip
and unzip it in the same directory as the previous demo (the map is removed from this archive).
The map should look a lot better now but still have good responsiveness to mouse drags. The mouse wheel should work now, but it might be too fast or too slow.
Mouse dragging works a little differently now, but most people should not notice except for zooming. The map no longer disappears if it’s too small.
I’ve also added some toolbar buttons to simulate what people are going to do 90% of the time (e.g., rotate by a multiple of 90 degrees).
Give it a go, and please let me know if there are any problems. If this works, we’re going to start incorporating these changes into VASSAL.
The black 1 pixel line is still visible - dont know if it is supposed to be gone or not yet.
All buttons worked for me
Mouse wheel zooming is impossible - 1 turn/click of the wheel makes map either disappear altogether or so large as if I cant see anything but 1 color. Test more later on the normal stuff
We’ll want to add a second button to the Zoomer which has controls for
various common angles. Also, we might consider having Shift + Rotate
make some common angles (say, every 15 degrees) be sticky like you have
in image editing programs.
Will we be able to get rid of the seams between tiles?
The only noticeable thing I have is when zooming in / out using the mouse
wheel it is considerably slower than when I press and hold the mouse wheel
(middle button) and drag mouse up/down.
This may be a mouse setting though so going to try on different mouse
shortly at work to see if it’s the same. There could be variance with
different mice as to how quick to respond the mouse wheel is
Tried the mouse wheel zooming again at work (different mouse). Same result as other computer/mouse. This is just slower than holding middle button and dragging - its not a mouse thing but its not a big deal either.
Otherwise everything works good for me
Nvidia Quadro panels have option “Enable conformant OpenGL texture clamp behavior” under it’s OpenGL settings. (Setting is on)
I will look at my Nvidia Geforce cards at lunchtime in a couple hours when I get home, but think they have something similar about clamping control
On May 21, 2008, at 6:29 AM, Michael Kiefte wrote:
OK. I’m at work, so I’m using an Intel Mac.
I’ll have to wait until I’m home to try the PPC.
Works fine with Leopard 10.5.2, Intel HW, Java 1.5
Window initially appears in a couple of seconds. Full load with map
first took a really long time (> 60 seconds), but on subsequent tries
was about 15 seconds. I don’t know if that is because the graphics
card was already loaded, or if it was related to paging behavior on my
Mac.
Performance is smooth and fast.
Buttons work well.
Zooming works with 3rd button and wheel. The wheel seems a bit more
sluggish, but that may be related to differences in the resolution of
mouse position versus wheel clicks. If it is easy, one could try
doubling the zoom factor for each wheel increment.
The image now doesn’t disappear completely at maximum zoom out. It
seems to stop at a single pixel.
On May 21, 2008, at 8:31 AM, Michael Kiefte wrote:
I wonder if that is for possible bug compatibility with some games,
based on earlier behavior for the video card? It’s possible that some
software needs the older, non-conformant behavior.
I have a recently updated nVidia control panel and for option ‘Conformant Texture Clamp’, it has possibly options of ‘Use Hardware’ (current setting), ‘Use OpenGl specification’ or ‘Off’.
I could detect no difference in the demo using the different settings.
Well, I tried this on my PPC Mac at home, but it failed with a link error (again). This time it was the version that has the ppc libraries, so I’m thinking there may be some other problem.
The stack trace is:
./runppc.sh
Exception in thread “main” java.lang.UnsatisfiedLinkError: /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Libraries/libawt.jnilib:
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1751)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1668)
at java.lang.Runtime.loadLibrary0(Runtime.java:822)
at java.lang.System.loadLibrary(System.java:993)
at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:50)
at java.security.AccessController.doPrivileged(Native Method)
at java.awt.Toolkit.loadLibraries(Toolkit.java:1509)
at java.awt.Toolkit.(Toolkit.java:1530)
at java.awt.Dimension.(Dimension.java:68)
at TextureDemo.(TextureDemo.java:65)
at TextureDemo.main(TextureDemo.java:156)
So, I did a bit of searching and found an answer on the Web. Apparently this particular link error is caused by having an environment variable for DYLD_LIBRARY_PATH set. When I unset that environment variable, everything worked fine. I had that variable set to support ImageMagick, but it seems to interfere with this.
Details in next post.
[Edit:] Sorry for the wild goose chase the first time I got this error [End Edit]
So, as long as I make sure DYLD_LIBRARY_PATH is not set as an environment variable, I am able to run the demo code on my Mac.
I was just testing with the following setup:
iMac 1.8GHz G5 (PPC) architecture.
Mac OS X 10.4.11
java version “1.5.0_13”
Java™ 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-241)
Java HotSpot™ Client VM (build 1.5.0_13-121, mixed mode, sharing)
GeForce FX 5200 card, 64MB VRAM
The program loads in about 55s and performs very smoothly once loaded.
Zoom, move and rotate are fast.
Zoom works with mouse button and mouse wheel.
Interestingly, the scroll wheel zooms quicker on this machine than on the Intel laptop I was using at work. They are different brands of mouse (Logitech at home, Macally at work). Perhaps the scroll wheel is implemented a bit differently in the two bits of hardware.
I was also able to confirm that the universal libraries in the runmac.sh (maclib) setup work on both Intel and PPC hardware, so it looks like a separate runppc.sh (ppclib) is NOT needed. (Hooray!)
IIRC, MouseWheelEvent.getUnitIncrement() is platform-dependant, so
what you get from getWheelRotation() can vary quite a bit. The way
to solve this is to use getUnitsToScroll(), which normalizes this
for you.
I think this was in reference to the previous version. Occasionally
the most recent version doesn’t respond quite instantly when panning,
but it might be an issue with the way we’re mapping mouse movement to
map translation. I’ll have to look at that.
On Linux, you might have Driconf. I have the following options:
“Method to limit rendering latency”
Busy waiting for the graphics hardware
Sleep for brief intervals waiting for the graphics hardware
Let the graphics hardware emit a software interrupt and sleep*
“Synchronization with vertical refresh (swap intervals)”
Never synchronize with vertical refresh, ignore application’s choice
Initial swap interval 0, obey application’s choice*
Initial swap interval 1, obey application’s choice
Always synchronize with vertical refresh, application chooses the minimum
swap interval
“Enable S3TC texture compression even if software support is not available?”
Yes
No*
“Support larger textures not guaranteed to fit into graphics memory?”
No
At least 1 texture must fit under worst-case assumptions*
Announce hardware limits
These were the defaults for me—I have no idea what effect I’d see from
altering them.