The Ur-Quan Masters Discussion Forum

Yes, I'm still using a creaky old Win98 system. :) I can get the game to run in 640X480 'frame buffer' mode but anything higher (which the docs say requires opengl) will produce a white screen with no visible images. The game seems to be running, because I can hear the menu boops when using the arrow keys. But obviously this is useless when I get no visible feedback. The system is Win98 ('first' edition) with a Matrox G200 video card. This is a few years old, but it does have OpenGL according to the manual. Is it possible that updates to the standard since this was published are causing the problems? Is there possibly some updated DLL that I could get somewhere?

I'd really like to get OpenGL to work for the sake of the hardware acceleration. This system is 'only' a 400 Mhz K6-2 and the game uses just about all available CPU when in play mode.

OpenGL support is typically provided under Windows by the display driver; grab the latest one for your card from Matrox's driver download page (http://matrox.com/mga/support/drivers/latest/home.cfm) and install it. As far as I can tell, that should fix it.

A little research shows that the G200 has always had problems with OpenGL. That seems to be this card's Achilles' heel. I'm using the latest driver that works on my system. The 'really' latest (and last) causes unexplained problems (like hard lockups). But what I've got is from 2001, not 1998, so it's got a reasonably competent OpenGL interface even if it is using a 'wrapper'. I suppose it would not really save much CPU given the cheat of simply redirecting OpenGL calls to DirectX calls. But I would like to be able to use the higher resolutions.  (Maybe they can extend the DirectX modes to higher resolutions by the time it reaches the 1.0 release?)

I have another system with a Matrox G450 card. On this one, the OpenGL mode doesn't go to a flat white screen, but it still has serious problems. Things get redrawn at wrong locations in the window, making it difficult or impossible to follow what is happening in the game. Going back to 'frame buffer' mode fixes this.

The thing is, the 3D screen savers that come with Windows 98 are also OpenGL and they all work perfectly on both systems. So it looks like something is not being done right with the setup or system calls in UQM. It's quite good for version 0.5 but plainly not done yet. :) Lots of little things seem to be unfinished or typoed. The debug log shows lots of unexplained errors:

Many instances of "Warning: Can't open 'lbm/mainmenu.ogg' " (when I've selected PC music and the .ogg files should not be required)

Many, many instances of "Trying to get undefined resource 00000000" (A really 'useful' error message! :P )

And then some ambiguous ones that I'm not sure are errors though they LOOK like errors:

"Thread 'Starcon2Main' blocking on 'DCQ'"
"Thread 'game clock' blocking on mutex 'Graphics'"
"Thread 'game clock' blocking on semaphore 'Clock'"

So I am looking forward to 0.6 and 0.7 and especially 1.0! :D

We're "abusing" OpenGL to scale the screen for us by giving it as a texture for one big 3D object. All DirectX calls go through SDL, and SDL does not have functions for 3D. Unless that changes, it's unlikely that there will be scaling to other resolutions.
It is however possible that some people come up with entirely new graphics, designed for a higher resolution mode, for which not scaling needs to take place.

Again, upgrade your driver. This is not an UQM problem.

Heh. Let me explain by analogy why this remark is so funny:
"The thing is, the toilets in my house also use the same water, and it works perfectly there. So it looks like something is not being done right with the teabag or teaspoon in your cup."

Unfinished things are why the project is still in alpha stage.
As for typos, please report those, so we can fix them.

It doesn't really look for the .ogg file. The main code asks the resource loader "give me lbm/mainmenu.ogg", and the loader gives it "lbm/mainmenu.mod" instead if PC music is selected. This is a stupid hack, and the relevant code will be replaced at some point.
It's a warning, not an error. And you shouldn't get it if you're using a release build.

It is useful to us. And it's also a warning, not an error, which you only get for debug builds.

Debug messages. Not even warnings, just informational. Should only turn up in debug builds. They tell us that one thread of the program is waiting for another one to catch up.

As you should :P

I'm using the latest and last driver on the G450.  I haven't seen any threads on the Matrox support board where anyone is complaining that their OpenGL game doesn't work with their Matrox G450.

And I downloaded this game from the appropriate link on the download page at sourceforge, so if it's not a 'release' version then someone put the wrong thing on that link. I am definitely getting those debug messages.

Hmm... we may have left those warnings on intentionally, to help debugging (after all, it's still alpha). I'm a Linux user myself, so I have little personal experience here.

The white screen is probably a case of the OpenGL implementation failing to accept the 512x256 texture UQM uses as its screen buffer. My good old OpenGL Programming Guide (for version 1.2) says OpenGL doesn't require textures larger than 64x64 (or 66x66 with borders) to work.

One solution that could work in this context is to use 64x64 tiles for the display instead of one big texture. LAB3D/SDL (http://icculus.org/LAB3D/) (an OpenGL port of Ken's Labyrinth) also uses textures as a screen buffer (albeit only for menus, the status bar and suchlike, not the ingame graphics); however, by default (i.e. unless you hack the source code), it uses tiling of small textures instead of one big one.

If LAB3D/SDL works (just grab the latest all-in-one package) and UQM doesn't, some changes to the texturing system may be in order. If LAB3D/SDL doesn't work, I'm inclined to agree that the display driver is broken.

Well, I can't use the full latest drivers, but I extracted the G200icd.dll from the latest driver package and swapped it in. This made the G200/K6-2 system act like the G4500/Duron system. No more white screen, but things get redrawn in the wrong places in OpenGL mode.

This "Labyrinth" game works perfectly, though. Nothing gets put out of place in the graphics area or the menus. But then these menus aren't using a 'light bar' or drawing the menu in a designated place in/on the main display. They popup over the main display. Maybe using a restricted space for the menus makes the difference, or maybe the way it uses the API calls makes the difference.

Interesting. In some cases, transplanting ICDs like that just makes things worse.

My guess is that the problem has to do with UQM using large textures (what's on the screen before the menus are drawn shouldn't really matter), but the G450 behaviour sounds plain buggy. The "white screen" behaviour I can find an excuse for, but putting stuff in the wrong place is just... odd.

Well, that's how I interpret what I am seeing. Perhaps the real problem is some sort of corruption of the textures in memory. Then when they get placed they look scambled, and that 'seems like' misplacement. I'll have to try to capture some images and post them somewhere. (Hmm, where?)

Ok, here's an attempt to show what is happening:

(http://img228.imageshack.us/img228/6537/clipboard01rb2.th.jpg) (http://img228.imageshack.us/my.php?image=clipboard01rb2.jpg)
First image: Even right after switching to OpenGL mode, you can see the 'light bar' in the main menu is malfunctioning. A piece of the screen from elsewhere is transposed on the selected menu item.

(http://img228.imageshack.us/img228/4683/clipboard02fl9.th.jpg) (http://img228.imageshack.us/my.php?image=clipboard02fl9.jpg)
Second image: Here you can see the main problem. The 'frame' seems to get drawn the right way once, then drawn again slightly offset down and to the right a bit.

(http://img208.imageshack.us/img208/2065/clipboard03cj5.th.jpg) (http://img208.imageshack.us/my.php?image=clipboard03cj5.jpg)
Third Image: System navigation has the same symptoms

(http://img228.imageshack.us/img228/750/clipboard04dt5.th.jpg) (http://img228.imageshack.us/my.php?image=clipboard04dt5.jpg)
Fourth image: And in hyperspace you get the same problem. But... in the system navigation mode the menus do still function. In hyperspace if you hit the space bar to replace the local view with the menu it gets scrambled.

(http://img85.imageshack.us/img85/2261/clipboard05bs1.th.jpg) (http://img85.imageshack.us/my.php?image=clipboard05bs1.jpg)
Like this! Since you can see something in the extreme right edge of the images, I presume that the menu gets drawn 'off screen' in hyperspace. Argh...

So there's the result of about an hour's struggle with Imageshack. Whew...

OK, judging from the screenshots, what's happening is that when part of the screen is updated (e.g. the "Setup" entry in the main menu is blinking), the texture being used by the OpenGL implementation is updated with an area from the top-left part of the screen buffer instead of the correct area. Similarly, when the main window is updated, the status bar above it is copied into it and a little around the lower edge lost instead. Looking at the source code, it seems like the settings for GL_UNPACK_SKIP_ROWS and GL_UNPACK_SKIP_PIXELS are being ignored; we could circumvent this by doing the equivalent transformation with pointer arithmetic instead.

This quite clearly seems to be an issue with the OpenGL implementation (i.e. the Matrox ICD), but I may be able to create a patched executable that works for you. As the required changes shouldn't affect any cards that currently work correctly, it may even be prudent to make the corresponding changes to the main code, although I personally dislike circumventing bugs instead of fixing them.

Well, after going to the Matrox support boards and searching on "OpenGL" and these technical terms I find some entries. The scariest of which states "OpenGL only works properly with Intel chipsets, if you have a motherboard with a non-Intel chipset OpenGL will never work properly for you..." Ack!

But weirdly, The G200 system DOES use an Intel chipset. Hmm... but it's only a PCI board, not an AGP board. And the problem seems identical on the two systems, even though one is Intel and the other is not. So hopefully this can be circumvented by the work-around you are considering. That is disappointing if their is no other way, though. Drivers are supposed to handle details like that.

I hope no other weird things would crop up after this fix, though. Obviously it's not going to be worth the trouble to keep making special cases for older cards.

Are those two functions you mention new for the 1.2 version of the OpenGL interface standard? I notice that you say above that your manual is for the 1.2 version. While reading the Matrox forums I saw more than once that they said these cards (all the Milllenium G series apparently) only have the 1.1 standard calls. So that may be why those two functions are being ignored. I hope there is an easy way to inventory what calls are being used and see if any other functions later than the 1.1 standard are used in UQM at present.

If it's only those two calls, as it seems because everything else seems to work, then you could add a compatibility switch to the config file where users could select whether to use the driver functions or the built-in pointer calculations for compatibility.

BTW, I noticed something about the config file(s). The 'bits per pixel' setting is not in the config file actually written by the program even though it is in the two sample 'version' configs that are supplied in the install. And the program barfs when you try to use --bpp on the command line. Is this an obsolete setting? Maybe it needs to be removed from the manual and the two sample configs given with the install.

Nah, they should be in 1.1. Besides, LAB3D/SDL uses these calls too, for the same purpose; without them, the status panel won't update properly, the menus will become a big mess and so on. For some reason, they work in LAB3D/SDL but not in UQM.

Now, the fact that depending on which ICD you use, large textures are supported or not, suggests that the driver is doing some trickery to emulate large textures and getting confused in the process.

The pointer manipulation should produce exactly the same result as the SKIP parameters; they exist solely for the convenience of programmers who dislike pointer arithmetic. Changing the code used in UQM should have no ill effects on other systems.

Either way, I'll see about giving you a modified executable to try out tomorrow. If it works, we can think about putting the change in the standard version.

Well, I'll gladly try out both a 'pointer arithmetic' patch and a 'small textures' patch if you want to prepare both. You did say that LAB-3D is tiling smaller textures rather than using one big one.

OK... Here's (http://koti.mbnet.fi/lonnberg/sc2-opengl-skip-patch-bin.zip) the latest CVS version compiled for Windows with SKIP_PIXELS and SKIP_ROWS changed to pointer arithmetic. I did some cursory testing on this on my machine and basically threw every DLL that looked relevant into the package (I have different versions of the libraries, for various reasons), so the download is a bit big. Unpack to your UQM directory and put the content update (http://uqm.stack.nl/files/snapshots/uqm-0.5.0-~update-20060911.0000.zip) package in your content\packages subdirectory with the other packages.

The bpp setting is indeed removed. As I can't find any references to it in any other file, I suspect that they have already been removed in CVS.

Yes, this seems to fix the scrambled graphics problem. I can now play in 800x600 mode with no problems. Both the original 0.5 and this one though seem to have a problem when Mozilla Seamonkey is also loaded. It keeps crashing with odd errors in the png.dll or jpg.dll -- possibly a conflict with whatever Seamonkey is using to handle these formats?

Anyway, I can report that this works for me. You experienced programmers will now have to decide if you want to go with this or try the 'tiled' method of using smaller textures since LAB-3D also works. I don't know how to figure out which is better in terms of performance (except to run each and look at my CPU monitor? :) )

Is there any explanation available of what other changes have been made in this 0.5.3 version? I see quite a few files in the content update, including dialog text files.

One additional problem: It can't figure what key config it wants. When it starts and finds the old key config, it rewrites it to something else. Then it goes on and plays. But when it starts and finds this new config that it rewrote, it barfs and won't continue. You have to restore the old key config so it can rewrite that again. So whatever it is writing is not what it needs/wants. The rewrite needs to be fixed.

Welcome to DLL hell (http://en.wikipedia.org/wiki/DLL_hell). Seamonkey uses the same libraries for JPEG and PNG loading as UQM. I guess the problem is that Seamonkey is distributed with incompatible versions of these libraries, and Windows is assuming that the libraries are the same and only loading one copy (whichever comes first); after all, that's one of the reasons for using DLLs; you don't need to load separate copies of common libraries for each app.

This is almost certainly a problem with the Windows distribution of UQM and/or Seamonkey; I run Seamonkey and UQM at the same time on Linux all the time without any trouble. Recompiling both UQM and Seamonkey using the same libraries would probably fix this problem. The real question is: what is the difference between the libraries used in Seamonkey and in UQM and why?

Binary-incompatible libraries should properly be given different names to avoid this sort of problem. The fact that this hasn't happened suggests that the libraries were intended to be compatible, but for some reason aren't in practice.

Does starting UQM before Seamonkey (as opposed to vice versa, which I assume is what you done) help? If so, overwriting the DLLs in Seamonkey with those from UQM could help. Of course, the probable result is that Seamonkey crashes instead of UQM. :(

What works well on one machine may not be what works well on another, unfortunately. Anyway, at this point I'll settle for "works correctly". Moving the pointer arithmetic out of the OpenGL implementation and into UQM was a simple change; switching to tiled textures would essentially require a rewrite of the OpenGL code (with associated new bugs). Unless someone actually can find a system that needs that rewrite, I don't think it's worth doing.

Right here (http://sc2.cvs.sourceforge.net/*checkout*/sc2/sc2/ChangeLog?revision=1.518).

Welcome to the CVS version of UQM: all the latest features, all the latest bugs. That would be Michael's new key configuration system. Everything's fine, except the new key configuration system seems to corrupt the key configuration file under Windows (it works under Linux, though). As far as I can tell, some lines in the file are getting cut off; I can fix them manually, but that's no fun at all.

Reported as bug #912 (http://uqm.stack.nl/cgi-bin/bugs/show_bug.cgi?id=912). Fixed binary here (http://koti.mbnet.fi/lonnberg/uqm-debug.zip).

Hmm, I can't find other copies of these DLLs on my system. They must be 'compiled in' to some other part of Seamonkey. This makes things very difficult. Guess I'll just have to remember not to play UQM while surfing the web. :)

The key config fix works fine, so now I've got a fully functional game. When might an 'official' 0.6 be released? I don't think I need all that debug stuff for routine play. :)

As far as the 'tiling' vs. the pointer math, didn't you admit that making one giant texture was 'exceeding the spec' for OpenGL? Wouldn't it be safer for the program to do what ever it does within the spec rather than deliberately exploiting undefined aspects of the standard? The 'work-arounds' might begin to accumulate and be as much trouble as a re-write to stay within spec.  I do notice a difference in CPU usage with the pointer arithmatic version, anyway. I have to wonder if the extra overhead of 'tiling' would be as much as moving a driver function into the main executable like that.

BTW, one more small bug, I think. When I set 'flat' fonts (3DO) the gradient font on the ship outfitting screen that reports things like fuel capacity and combat energy just disappears. Instead of converting this to 'flat' fonts it just doesn't display it. If no one else using Windows can duplicate this then maybe it's another Matrox driver thing. :P

Some versions of Seamonkey seem to have their own built-in versions of libjpeg, libpng et.c.; how they conflict with other programs is beyond me.

I have no idea. When it's ready, maybe?

Sure, that's why I wrote LAB3D/SDL the way I did. :) Seriously, max texture sizes have been 1024x1024 or larger on practically every OpenGL implementation I've ever seen, which sort of justifies the approach the UQM team took. Strangely enough, the minimum maximum texture size is still 64x64 in OpenGL 2.1; I would have expected this to be increased over the years!

The safe approach would be to ask the OpenGL implementation what its maximum texture size is and activate the (new, experimental) tiling code only if the OpenGL implementation doesn't support the required texture size (512x256 without software filtering, 1024x512 with). Alternatively, we could just use the new tiling code all the time (easier to find bugs that way!).

My point was primarily that writing extra code to circumvent limitations in the specification is mostly unnecessary if the OpenGL renderer can be cut out of the loop completely with minimal loss of features (true in UQM, not in LAB3D/SDL 2.x) and most OpenGL implementations provide the required functionality anyway (true for UQM).

Anyhow, writing and testing the code would probably be quicker than arguing about it, so if the coredevs think it's the sort of patch they'd accept, I'll port my tiling code over from LAB3D/SDL.

I think the difference between a optimised release build and an unoptimised debug build is much greater. Seriously, we're talking about about a dozen pointer arithmetic ops per frame (that the driver probably did itself, anyway); there is no way you'd notice a speed difference unless something really freaky is going on. The debug build, however, is probably going to be a lot slower. Also, check for other running programs. I noticed that running Winamp and UQM together on my system (Athlon XP, GeForce4) really slows UQM down.

I'll see if I can reproduce that on Windows.

Yeah, the debug overhead seems more likely to be the reason for the slightly higher CPU usage showing on my CPU monitor. But it's not impossible that moving a function out of the driver could have that effect. The two main functions of a driver are to 1) save many third-party programmers from having to look-up proprietary hardware function calls for using some given piece of hardware, and 2) to centralize and simplify code -- having all the code that operates a given hardware peripheral in one place allows considerable optimization. Rewriting a driver function as an external could result in the "same things" having to be redone many more times than if the code in the driver were used.

BTW, why does the 'official release' open a second debug window but the debug version does not!? ??? ??? ???

I did some quick measurements. Changing nothing else, the debug version is roughly half the speed of the release version (mostly due to turning off optimisation throughout the UQM codebase). Furthermore, changing the compiler may slow things down (Visual C may be faster at some things than GCC and vice versa). Applying/unapplying my graphics patch has no measurable effect on my system at least, and, as I said, the functionality changed involves a few nanoseconds of processing per frame; only if the graphics drivers or something like that is horribly broken can this have any effect!

My debug version is linked to a release version of SDL (I'm assuming SDL works fine), the release seems to be linked to a debug version of SDL (don't ask me why).

It's linked to a debug version of the support library? Now that's annoying. Ok, maybe I'll take the trouble to get all the stuff and be able to compile for myself after all. Then I'll be able to fix goofs like that in the future.

Further investigation shows that SDL has a compile-time option (separate from debug/release) for redirecting standard output and error to files (stdout.txt and stderr.txt) under Windows. This defaults to "on", but is for some reason "off" in the version used by UQM, causing it to open a console window instead. I guess the UQM devs like it that way.

In Unix, connecting standard I/O to something sensible is the responsibility of the caller (command prompt, desktop environment, whatever).

You can use '--logfile' to send stderr to a file.

I've done that. It still opens the window even though there's nothing appearing in it.

Continuing discussion on GL issue as bug 914 (http://uqm.stack.nl/cgi-bin/bugs/show_bug.cgi?id=914).