Rendering QT widgets in Ogre

Problems building or running the engine, queries about how to use features etc.
JeDi
Gnome
Posts: 351
Joined: Thu Oct 21, 2004 1:34 pm
Location: Diepenbeek, Belgium
Contact:

Rendering QT widgets in Ogre

Post by JeDi » Tue Jul 08, 2008 4:47 pm

Hi,

I am not sure if this is the correct forum to post this in, so feel free to move it.

Did anyone try to implement an Ogre renderer for QT 4.4 already? And by that, I don't mean embedding Ogre inside a QT widget, but the other way around!

If I am reading the change list for QT 4.4 correctly, a new feature should make this possible fairly easy. So we could have another nice cross-platform solution for in-game widgets.

Greetz,
JeDi
0 x

User avatar
PolyVox
OGRE Contributor
OGRE Contributor
Posts: 1316
Joined: Tue Nov 21, 2006 11:28 am
Location: Groningen, The Netherlands
Contact:

Post by PolyVox » Tue Jul 08, 2008 5:06 pm

I've been thinking about this for the last week or so, since I saw this demo on TrollTech labs:

http://labs.trolltech.com/blogs/2008/06 ... th-opengl/

Combine this with Qt's ability to customise widgets using StyleSheets and you could have a really cool in game GUI. Plus you get a decent layout editor for it.

It's certainly something I intend to investigate as I bring my project out of the prototype stage, but I think it's still several moths away. If anyone plays with it I'll be very interested in the result!
0 x

User avatar
milliams
Gremlin
Posts: 172
Joined: Fri Feb 16, 2007 1:47 am
Location: Portsmouth, UK
Contact:

Post by milliams » Tue Jul 08, 2008 8:47 pm

PolyVox wrote:...it's still several moths away...
Aah! Moths!!

In answer to the original question though, it should be quite possible to use a QGLWidget and paint over it with whatever canvas you want (a QGraphicsView with WoC (Widget on Canvas) for example would let you place almost an entire Qt application within the window).

However, this would technically still be OGRE running within a Qt widget but you wouldn't really notice that aspect of it.

I can't give you any code right now but there's a number of posts on the forum explaining how to do the first half (putting OGRE into Qt). The second half shouldn't be too much more difficult given the niceness of Qt.
0 x

User avatar
PolyVox
OGRE Contributor
OGRE Contributor
Posts: 1316
Joined: Tue Nov 21, 2006 11:28 am
Location: Groningen, The Netherlands
Contact:

Post by PolyVox » Tue Jul 08, 2008 9:30 pm

milliams wrote:
PolyVox wrote:...it's still several moths away...
Aah! Moths!!
Hmm... well that disproves my hypothesis that it's possible to type accurately with your elbows.
milliams wrote:In answer to the original question though, it should be quite possible to use a QGLWidget and paint over it with whatever canvas you want (a QGraphicsView with WoC (Widget on Canvas) for example would let you place almost an entire Qt application within the window).

However, this would technically still be OGRE running within a Qt widget but you wouldn't really notice that aspect of it.
Right, I'm sure that at the moment it's possible to overlay Qt widgets on an OpenGL background. But one of the nice things about the Qt 4.4 approach is that you should be able to use any OpenGL surface to draw your GUI on. For example, this would mean you can draw to a texture and then use that texture on computer screens in game (like is done for the interactive computers in Doom 3). There are probably speed benefits too.

I really like the idea of combining Qt and Ogre, and I think a framework which combined them properly would be great. As well as rendering into eachother, I can envisage:
  • Using Qt for input handling (no dependany on OIS).
  • Using Qt for the initial configuration dialog.
  • Using Qt to create a log file viewer which is updated in real time.
  • Using Qt to implement texture loading (no dependancy on Devil).
And probably a bunch of other stuff too. It could make a nice alternative to the existing example framework :D
0 x

User avatar
pjcast
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2543
Joined: Fri Oct 24, 2003 2:53 am
Location: San Diego, Ca
Contact:

Post by pjcast » Tue Jul 08, 2008 9:36 pm

PolyVox wrote:
  • Using Qt for input handling (no dependany on OIS).
I noticed you specifically called out OIS ;), so I thought I ask why you would not want to use OIS? Or just you want one less dependency? Also, OIS does more than just Mouse/Keyboard, does Qt offer more for input?
0 x
Have a question about Input? Video? WGE? Come on over... http://www.wreckedgames.com/forum/

User avatar
nullsquared
Old One
Posts: 3245
Joined: Tue Apr 24, 2007 8:23 pm
Location: NY, NY, USA

Post by nullsquared » Tue Jul 08, 2008 9:50 pm

PolyVox wrote:For example, this would mean you can draw to a texture and then use that texture on computer screens in game (like is done for the interactive computers in Doom 3).
OT: This is what I especially like about QuickGUI, something that most other GUI's for Ogre are definitely missing ;)
0 x

User avatar
PolyVox
OGRE Contributor
OGRE Contributor
Posts: 1316
Joined: Tue Nov 21, 2006 11:28 am
Location: Groningen, The Netherlands
Contact:

Post by PolyVox » Tue Jul 08, 2008 10:08 pm

pjcast wrote:I noticed you specifically called out OIS ;), so I thought I ask why you would not want to use OIS? Or just you want one less dependency? Also, OIS does more than just Mouse/Keyboard, does Qt offer more for input?
Nope, no offense meant! And I singled out Devil too :wink: Actually, with a full game Qt can remove many dependancies including network, XML parsing, sound (limited), containers, signal slots for messaging. Of course, the implementation is not specifically designed for games so depending on your application you might want lower level networking for example. Or if you want joystick support you probably still want OIS.

In my particular application, I could get rid of a lot of dependencies (hence it's desirable). However, when talking about a smaller Ogre example framework it only gets rid of a couple of dependencies which is why I mentioned OIS.

And no, it's probably not as good as OIS for input. And there are a lot of great open source game libraries out there. But Qt is just a nice as an all-in-one solution.
0 x

User avatar
milliams
Gremlin
Posts: 172
Joined: Fri Feb 16, 2007 1:47 am
Location: Portsmouth, UK
Contact:

Post by milliams » Sat Jul 12, 2008 2:21 pm

PolyVox wrote:...sound (limited)...
Well, as of Qt 4.4, Trolltech (now Nokia technically I guess) incorporated KDE's Phonon library directly into Qt. This gives an easy to use completely cross-platform sound API. I think that point is one of the main plus-points for using Qt, the ability to develop using it on one OS and be able to compile it on any other without having to change one line of code.

Even if you don't want to use it for the GUI aspects you can simply use just the QtCore part as a very full featured utility library. I think that's the thing many people don't realise about Qt - that it's really much more than a GUI library, it's a full-blown toolkit. It's even got a built-in scripting language (ECMAScript based) which is useful for many games. See the module list to get an idea of the scope.

Sorry if I sound like I'm doing marketing for Qt but having used it extensively within KDE it's truly made application development a breeze.
0 x

mikademus
Halfling
Posts: 54
Joined: Wed Jun 25, 2008 6:38 pm

Post by mikademus » Sat Jul 12, 2008 4:08 pm

PolyVox wrote:with a full game Qt can remove many dependancies including network, XML parsing, sound (limited), containers, signal slots for messaging. Of course, the implementation is not specifically designed for games so depending on your application you might want lower level networking for example. Or if you want joystick support you probably still want OIS. ... it's probably not as good as OIS for input. And there are a lot of great open source game libraries out there. But Qt is just a nice as an all-in-one solution.
I for one am fully in favour of this. Qt4 is a very competent package, and removing dependencies, gaining a fabulous GUI system (or more native support for wxWidgets for those that that since it uses Qt4), native KDE-integration for those that wish, and making Linux/*BSD-development more "native" are extremely good arguments.
0 x

User avatar
PolyVox
OGRE Contributor
OGRE Contributor
Posts: 1316
Joined: Tue Nov 21, 2006 11:28 am
Location: Groningen, The Netherlands
Contact:

Post by PolyVox » Sat Jul 12, 2008 4:39 pm

Before I cause too much controversy, I should point out that I'm not suggesting changing anything in Ogre, or replacing the current Ogre example framework. Of course I know that not everyone wants to drag a full toolkit along with their application, and those who do may have reasons for choosing another one (wxWidgets, etc).

This would simply be an addon project which aimed to combine the best bits of Qt and Ogre to produce an alternative framework. A search on the forums shows several people are already using Qt with Ogre, so any further work to integrate them would probably be useful :-)

And I didn't know about Phonon - do you know how advanced it is? For example, does it handle 3D sounds? So you can give a sound a location and it will attenuate it based on distance to the player, for example?
0 x

User avatar
milliams
Gremlin
Posts: 172
Joined: Fri Feb 16, 2007 1:47 am
Location: Portsmouth, UK
Contact:

Post by milliams » Thu Jul 24, 2008 7:51 pm

I'd like to draw everyone's attention to something my fellow KDEer Rivo Laks has been working on. Take a look at his latest blog entry, How to easily mix QWidgets and OpenGL. Now, this solution is a little KDE-centric as far as I'm aware but it should be very easy indeed to filter out what is and to make it pure Qt and more general.

Go ahead and try it out and if you have any questions, head over to [url]irc://irc.kde.org/kdegames[/url] where Rivo can be found.
0 x

User avatar
PolyVox
OGRE Contributor
OGRE Contributor
Posts: 1316
Joined: Tue Nov 21, 2006 11:28 am
Location: Groningen, The Netherlands
Contact:

Post by PolyVox » Sat Jul 26, 2008 9:55 am

Interesting... I definitely think there is some interesting work to be done here and that code is worth looking at. I built Qt 4.4 from source last week and one other thing I noticed was it now has support for Direct3D. So hopefully it can support both Ogre's render systems.
0 x

pmax
Gnoblar
Posts: 16
Joined: Sun Aug 17, 2008 8:29 pm

Post by pmax » Sun Aug 17, 2008 8:49 pm

This is very cool stuff, and I am desperate for a solution as well.

First I thought, I could use Qt/Embedded (used for PDAs and such) and implement a custom QScreen driver to render to a texture and overlay that on top of the whole screen. Unused space would be transparent, so you could still see what's going on. Unfortunately, it seems Qt/Embedded is only available for Linux and I'd really like it all to work on my Mac. A version that works on Windows would also be nice, I guess :).

So, after reading that same blog post on TT's labs, I thought this would be great. After googling a bit, I found this on qtcentre.org:

http://www.qtcentre.org/forum/f-qt-prog ... 40679.html

Apparently, this does paint an OGRE window in the background of a QGraphicsView, but only in X11. I've tried to integrate code from

http://www.ogre3d.org/phpBB2/viewtopic.php?p=258064

but that somehow doesn't work. Switching between AGL contexts seems to be more difficult than between GLX contexts. I've got the above code working on top of a normal QWidget, but not for a QGLWidget, which is kind of required for this usecase of QGraphicsView.

I can upload my changes to the qtcentre code if anyone is interested. Any help on doing the OpenGL context switching between OGRE and the QGLWidget properly such that they render on the same window, one after the other, would be much appreciated.
Also, is there any way to give OGRE a parent OpenGL context at renderwindow creation? It doesn't seem so given the current code of the GL Render System. There is no way to set the main context which is queried by the platform specific render window implementations. Maybe that would be a nice feature.

Cheers,
max
0 x

User avatar
PolyVox
OGRE Contributor
OGRE Contributor
Posts: 1316
Joined: Tue Nov 21, 2006 11:28 am
Location: Groningen, The Netherlands
Contact:

Post by PolyVox » Sun Aug 17, 2008 9:20 pm

Well, I am now working on this. I only started this weekend so I haven't got very far - I'm mostly just looking at examples and trying to work out my options (and I'm no Qt expert at the moment). I do, however, have a basic OgreWidget working so I'll give you the source in case it is useful:

http://www.david-williams.info/linked_f ... -0.0.1.zip

However, it doesn't do any of the embedding qt in Ogre stuff which we really want to get to, but it does work in both Linux and Windows.

Regarding that QtCenter post, well I only skim read it but I thought it was redundant since the TT blog post? Or is there some reason you still need it?
pmax wrote:Also, is there any way to give OGRE a parent OpenGL context at renderwindow creation? It doesn't seem so given the current code of the GL Render System. There is no way to set the main context which is queried by the platform specific render window implementations. Maybe that would be a nice feature.
From the docs here:

http://www.ogre3d.org/docs/api/html/cla ... 1_1Roota34

It seems there are flags "externalGLControl" and "externalGLContext" which might do what you want, but they are flagged as Win32 only.

I hope I can be more use in a couple of weeks once I have had a chance to get my head round Qt. I've never looked at it in this level of detail...
0 x

pmax
Gnoblar
Posts: 16
Joined: Sun Aug 17, 2008 8:29 pm

Post by pmax » Sun Aug 17, 2008 10:12 pm

Hi, thanks for the quick reply.
PolyVox wrote: Regarding that QtCenter post, well I only skim read it but I thought it was redundant since the TT blog post? Or is there some reason you still need it?
Well, for once, they claim to have it working front to back with ogre instead of plain OpenGL. The last post of that thread has code attached which seems to work for X11. I'd say that's an important step.
PolyVox wrote: It seems there are flags "externalGLControl" and "externalGLContext" which might do what you want, but they are flagged as Win32 only.
I was thinking along the same lines, but I have no idea how to encode this context into a string. Also, I checked the Mac implementation of GL Render System and it doesn't check for a user supplied context.

Cheers,
max
0 x

User avatar
PolyVox
OGRE Contributor
OGRE Contributor
Posts: 1316
Joined: Tue Nov 21, 2006 11:28 am
Location: Groningen, The Netherlands
Contact:

Post by PolyVox » Sat Aug 23, 2008 12:38 am

Hi Guys,

Well it's hard work but I'm finally making progress with this :) See below:

Image

As you can see it is possible to embed a Qt window in an Ogre scene and get the transparency effects (the transparency and antialiasing are not possible if you simply overlay a QWidget on an Ogre/OpenGL background). So, we have a proof of concept but I am struggling a lot and could really use everyone's help.

The problem is that most of the time I do not see an image like the one above, but instead I get an image like the one below:

Image

As you can see, the QWidget has somehow become corrupted. I suspect this is somehow related to the OpenGL format which being used (for example, Ogre is using a different format from Qt) but I lack the low level knowledge to really address this. There is also a chance it's a driver bug, which is why I'd like interested people to try it out. In an attempt to find out what was going on I downloaded and used GL Intercept which provides a replacement OpenGL32.dll with logging capabilities. This gave me a whole bunch of error messages but - most interestinly - the corruption went away and it all worked perfectly. That is how I was able to obtain the first of the two screenshots above.

Anyway, I have prepared a sample (with source code) which I would like to use to identify the problem. I know there are many people who like to use Qt with Ogre so I hope this can be useful for everyone. You can get the sample from here:

Download QtOgre Sample

You can try running both the release and debug versions. If you get corruption like I showed above then please try renaming the files 'OpenGL32.dll.temp' and 'gliConfig.ini.temp' by removing the '.temp' extension. This will enable GL Intercept to run and may produce different results as I mentioned.

If you want to build from source I provided a .sln file. Remember to replace my Ogre .dll's with your own or versioning issues could cause more problems than we are solving. You will need to build from source if you want to experiment with what I have done, or if you have trouble running the provided .exe's (for example I couldn't run them at work).

Let me know how you get on! I think Qt in Ogre could be a really cool GUI solution so let's hope we can get this working.

p.s. A couple of points - no Linux version yet. I make use of the 'externalGLControl' flag to createRenderWindow() which is not supported on Linux. However, from reading around the forums it seems this flag could be implemented - it's just no one has done it yet. I'm trying to focus on one problem at a time :) Also, there is no Direct3D support. I will be working on a fallback (slower) approach which will read the rendered image back from the framebuffer in order to allow Qt to perform the transparency effects.
0 x

pmax
Gnoblar
Posts: 16
Joined: Sun Aug 17, 2008 8:29 pm

Post by pmax » Sat Aug 23, 2008 8:39 am

Very cool! I've been playing around with it as well, but didn't get anywhere. I tried to reuse the context from Qt (in RenderSystems/src/OSX/OgreOSXCarbonWindow.cpp:168 by passing aglGetCurrentContext() as the second arg to aglCreateContext()), but that somehow caused an error in Qt which I can't trace because I can't figure out how to link against the debug version of Qt... Seems to be a common problem on OSX.

In the meantime, I've thought about using the idea from
http://www.ogre3d.org/phpBB2/viewtopic.php?t=2750
and implementing a separate GLSupport using Qt. The only obstacle is that I would like it to be a plugin (no reason to make Qt a dependency), but choosing a GLSupport is done in at compile time of Ogre.

The cool thing would be that the RenderWindow would be a QGLWidget to start with, so no problem using it as a widget directly instead of hacking so it shows it in the same screen coordinates. Somehow, this seems cleaner to me. The only thing is that there has to be a way to set the GLSupport instance in GLRenderSystem, which shouldn't be too hard to do. After that, implementing a Plugin to replace the GLSupport should be easy. What do you think?
0 x

pmax
Gnoblar
Posts: 16
Joined: Sun Aug 17, 2008 8:29 pm

Post by pmax » Sat Aug 23, 2008 2:31 pm

Hmm, I'm almost done with a GL Support Plugin with Qt. However, I have a problem with linking it properly.

The thing is that it obviously depends on symbols defined in the RenderSystem_GL plugin. I can compile and link it fine with "-undefined dynamic_lookup" which tells the linker that undefined symbols are ok and should be looked up when the library is loaded at runtime.

The thing is, it doesn't do it properly. Once I load the RenderSystem_GL plugin, those symbols don't seem to be part of the main program. So, once I dynamically load QtGLSupport, the dynamic library loader complains about missing symbols. Proper error message:

Code: Select all

*-*-* OGRE Initialising
*-*-* Version 1.4.9 (Eihort)
Loading library RenderSystem_GL
Installing plugin: GL RenderSystem
OpenGL Rendering Subsystem created.
Plugin successfully installed
Loading library QtGLPlugin
2008-08-23 15:20:22.428 demo[3951] CFLog (21): Error loading /Library/Frameworks/Ogre.framework/Resources/QtGLPlugin.bundle/Contents/MacOS/QtGLPlugin:  error code 4, error number 0 (Symbol not found: __ZN4Ogre9GLSupport20initialiseExtensionsEv
  Referenced from: /Library/Frameworks/Ogre.framework/Resources/QtGLPlugin.bundle/Contents/MacOS/QtGLPlugin
  Expected in: dynamic lookup
)
terminate called after throwing an instance of 'Ogre::InternalErrorException'
  what():  OGRE EXCEPTION(7:InternalErrorException): Could not load dynamic library QtGLPlugin.  System Error: Unknown Error in DynLib::load at /Users/max/Desktop/ogre/Mac/Ogre/../../OgreMain/src/OgreDynLib.cpp (line 80)
Abort trap
I'm not sure what to do. Is it possible at all to have plugins depend on other plugins?
0 x

pmax
Gnoblar
Posts: 16
Joined: Sun Aug 17, 2008 8:29 pm

Post by pmax » Sat Aug 23, 2008 9:29 pm

Okay, I figured out what the problem was.
Of course there are some more issues I need to look into...

Cheers.
0 x

User avatar
PolyVox
OGRE Contributor
OGRE Contributor
Posts: 1316
Joined: Tue Nov 21, 2006 11:28 am
Location: Groningen, The Netherlands
Contact:

Post by PolyVox » Sun Aug 24, 2008 11:47 am

Argh, sorry, not getting enough time to post...
pmax wrote:In the meantime, I've thought about using the idea from
http://www.ogre3d.org/phpBB2/viewtopic.php?t=2750
and implementing a separate GLSupport using Qt. The only obstacle is that I would like it to be a plugin (no reason to make Qt a dependency), but choosing a GLSupport is done in at compile time of Ogre.
That's very interesting - I'd seen that thread but I didn't get all the way to the end where the source code was released! I will have a look at it to get some ideas.

Ok, to get my ideas straight I'm going to summarise the various approaches I have found to combining Ogre and Qt:
  1. Create a window (not necessarily a QGLWidget) using Qt and pass its window handle to Ogre using the 'externalWindowHandle' flag. Ogre then creates a context and is fully responsible for it. This is basically what I did for the first demo I made. It has the advantage that it should support both OpenGL and Direct3D, and also should work accross all platforms. The big drawback is that Qt widgets can only be overlaid (not integrated) so you don't get the nice transparency.
  2. An approach similar to (1) but with the difference that the frame buffer is explicitly read back from Ogre and used as a widget background. This would again work accross all render systems and platforms, and now Qt can perform proper compositing from transparency. However, it is potenially slow doe to the need to read back every frame and copy it to Qt. But this could make a good 'fallback' approach. I haven't tried implementing it yet.
  3. This is the 'proper' approach which we are really considering in this thread. It involves both Ogre and Qt owning OpenGL contexts and both rendering into the same widget. This widget is set as the background of a QGraphicsView/QGraphicsScene and other widgets can be overliad with proper transpaency effects. It only works with OpenGL and is (theorectically) cross platform. There are two variations:
    1. Allow Ogre to create it's own OpenGL context (passing the flag 'externalGLControl') and then retieve the context once createRenderWindow() has finished. Under windows there are the wglGetCurrentDC() and wglGetCurrentContext() for this - other platforms should have something similar.
    2. Have Qt create a context on Ogre's behalf and pass that to Ogre using the 'externalGLContext' flag. In this case Ogre basically does nothing except render into the context it it provided with - all the control is with Qt. I haven't quite got this to work yet as I was having crashes in both Qt and Ogre.
Actually I happen to of listed those approaches in order of increasing desirability. However, as far as I can tell they can all be implemented as stand alone widgets without any need to (significantly) modify Qt or Ogre.

Moving on to your current approach of implementing a GL support plugin based on the code in the other thread - I assume it is most similar to Option 3(b) above? I haven't yet had a chance to look at the code but I hope to do so tonight. If it is similar to option 3(b) then what of the advantages of doing it as a GLSupport plugin rather than a simple widget?

From reading that thread you linked it seems that doing it as a GLSupport plugin would allow it to be used in existing Ogre application without changes to the applications source code. Is this the case? Are there any other advantages?
pmax wrote:Okay, I figured out what the problem was.
Of course there are some more issues I need to look into...

Cheers.
Great, I'm glad you fixed it. Sorry I'm not able to help with this - MacOS is outside of my expertise. But sinbad uses it, so he might be interested in what you said in that thread.
0 x

User avatar
sirbabyface
Gnoblar
Posts: 14
Joined: Mon Aug 18, 2008 4:02 pm
Location: Coimbra, Portugal
Contact:

Post by sirbabyface » Mon Aug 25, 2008 10:38 am

Hi,

I've just tried the example from PolyVox.

I run just fine with the DLL I've from Qt (4.4.1). But it doens't show any widget. Only the green and the box with the smile.

On the log there is nothing strange.

I'm using a NVidia card.
0 x

Slan
Halfling
Posts: 49
Joined: Wed Jun 09, 2004 11:13 pm

Post by Slan » Mon Aug 25, 2008 1:07 pm

Try resizing the main window, or add

Code: Select all

	dialog->move(10, 10);
before the addWidget() thing.
0 x

User avatar
sirbabyface
Gnoblar
Posts: 14
Joined: Mon Aug 18, 2008 4:02 pm
Location: Coimbra, Portugal
Contact:

Post by sirbabyface » Mon Aug 25, 2008 2:19 pm

I actually just run the release version. I didn't compile it, since I only I've version 1.4.9, at this application seems to run on vrsion 1.6 or 1.7 of Ogre.
0 x
--
Tiago Correia

User avatar
PolyVox
OGRE Contributor
OGRE Contributor
Posts: 1316
Joined: Tue Nov 21, 2006 11:28 am
Location: Groningen, The Netherlands
Contact:

Post by PolyVox » Mon Aug 25, 2008 6:03 pm

Ok, I've uploaded a new version as I made some mistakes with the original. I previously included the debug build (which couldn't be run), forgot the Qt .dll's, and included the 20Mb Intellisense files. People who failed to run it before, it would be great if you tried again (same link).

@sirbabyface - Please try the new version (with my .dll's though it shouldn't matter?). Also please try the trick I mentioned in the earlier post of renaming the files 'OpenGL32.dll.temp' and 'gliConfig.ini.temp' by removing the '.temp' extension. This causes it to run through GLIntercept which fixes the corruption on my machine.

@slan - So did you try it? Did it work?

I have a busy couple of days, but later in the week I'll look at the code pmax linked and see If I get more ideas.

Also it's incredibly slow for me (just a few FPS) which I'm attributing to the same thing which causes the corruption. Whatever that is :P
0 x

User avatar
triton
Greenskin
Posts: 138
Joined: Thu Mar 13, 2008 10:25 pm
Location: Portugal

Post by triton » Mon Aug 25, 2008 6:17 pm

It works fine here, though it's very slow.

Windows XP SP2 x64 Edition
NVIDIA Geforce 7600GS

Image
0 x

Post Reply