Left button moves the map.
Middle button zooms.
Right button rotates.
Textures must have power-of-2 dimensions, which is why the image is square. There is also a platform-dependent upper limit and the next power of 2 is too big for my computer. My next step is to reimplement this with several smaller squares, each with its own texture.
The code is a little chaotic. Everything is being done in display() because that’s the only place I seem to be able to get a valid GL object. Trying to find where the mouse is relative to the map for dragging is challenging. There is a better way if you assume the map is orthogonal to the viewer (which it is right now), but I haven’t done that yet.
I think the next thing to do, before putting to much more work into
this, is to verify that it works on everybody else’s. Could you
package up the demo for testing on Windows and Macs? (I think this
would involve just getting the appropriate JOGL libraries for each
platform, writing a batch or shell script to start the demo, and
rolling it into an archive.)
Ok. Download the following archive: http://myweb.dal.ca/mkiefte/TextureDemo.zip
create a new folder and unzip the contents into that.
If you’re a Linux user, type ./run.sh in the directory.
If you’re a Windows user, double click on run.bat in the folder.
If you’re a Mac user, type ./runmac.sh in the directory.
Left button pans the map.
Middle button zooms.
Right button rotates.
I’ve updated it to include the 64-bit libraries so you can try it now. For 64-bit linux, you’ll have to type ./run64.sh . Each computer will have to have a different script depending on operating system and processor. There are 10 platform-dependent versions of the libraries and I’ve only included four. If VASSAL goes this route, we’ll need a more convoluted download procedure.
–
Michael Kiefte, Ph.D.
Associate Professor
School of Human Communication Disorders
Dalhousie University
Halifax, Nova Scotia, Canada
tel: +1 902 494 5150
fax: +1 902 494 5151
For each of Linux and Windows, there’s a 32-bit and a 64-bit library.
It looks like there’s a univeral one for Macs, so I guess that’s the
only one we’d need (?) there. Since the libraries are tiny, there
wouldn’t be any problem with distributing, e.g., both the 32- and 64-
bit ones with the Windows build. I was planning eventually on packaging
an RPM (and maybe a .deb?) for linux, and could do the same there. (It
will be trivial, comparatively, to do packaging for a system I actually
use myself!) Does anyone actually use Solaris?
This is no problem so long as it’s possible for something to detect
which libs should be loaded at runtime.
That doesn’t really bother me, although there’s no other reason it could not work. OpenGL is particularly well suited for network protocols, but if they haven’t implemented it, then…
Unless they’re running PPC? Why do they get a separate version?
I met someone once in 1993 who did. To be fair, it has the most versions, so it’s not that bad really if we ditched support for Solaris entirely. If I added the 64-bit Windows libs, we’d be fine.
I’d be happy to support Solaris, so long as we had someone who was willing
to do testing there.
This is not an insurmountable obstacle. There’s probably some ugly
hack on Windows by which you can find out whether you’re running 64-bit,
like ‘uname -a’ on a UNIX.
Are you looking at a virtual Windows desktop or Linux desktop? I’m assuming Windows, as for X you could just set your display to a remote machine. That would work with OpenGL.
–
Michael Kiefte, Ph.D.
Associate Professor
School of Human Communication Disorders
Dalhousie University
Halifax, Nova Scotia, Canada
tel: +1 902 494 5150
fax: +1 902 494 5151
I was looking at the code just now; is there any better texture filter
available than GL_LINEAR? Bilinear interpolation is pretty crappy for
downscaling. If not, I wonder whether we could start calculating a
better interpolation and paint that when the user stops panning/zooming/
rotating?
(I think the “Eye of Gnome” image viewer does this. If you zoom and
then stop, you’ll see what looks like nearest neighbor or bilinear
interpolation, followed by something much smoother a half-second later.
We could do that programatically—the mipmaps are just a scaling pyramid,
right? So you can apply any scaling algorithm you want that way. Maybe
all that time I spent on my Lanczos scaler won’t be for nothing, then.
This is relatively easy to do. However, I didn’t think the linear interpolation was that bad and it’s still going to use linear interplation for rotations (unless we stick with orthogonal rotations).
That’s my mistake. I have the new ZIP-file on my laptop and I mustn’t have uploaded it. However, I don’t have access to my laptop at the moment. I’ll upload the Mac version later this evening.
This might have been a bit before you joined us, but there were howls
of protest when, without realizing I’d done it, I disabled the old
averaging downsampler in one of the 3.0.x releases, which left the
default scaling as bilinear.
It’s also possible that we could write a (simple?) pixel shader to
get some smoothing.
Some people have more sensitive retinas than I. Do you have a sense of what ZunTzu is doing just by looking at it?
That’s doable but perhaps somewhat complicated. I’m also not sure that fragment shaders are available on all hardware and I have no idea if you can do it through JOGL.
The reason that GL_LINEAR is the most complex resampling function is because it’s blazingly fast and it’s treatment of texture edges is completely uniform. Fragment shaders is really the only way to do what you describe without some serious pain.
2008/5/6 Michael Kiefte <mkiefte@dal.ca (mkiefte@dal.ca)>:
–
Michael Kiefte, Ph.D.
Associate Professor
School of Human Communication Disorders
Dalhousie University
Halifax, Nova Scotia, Canada
tel: +1 902 494 5150
fax: +1 902 494 5151
