|
Pages: [1] 2 3
|
 |
|
Author
|
Topic: Opengl modes don't work in Win98 (Read 10372 times)
|
Yuptar
Frungy champion
 Offline
Posts: 51
|
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.
|
|
|
|
« Last Edit: September 06, 2006, 10:18:40 pm by Yuptar »
|
Logged
|
|
|
|
Novus
Enlightened
Offline
Gender: 
Posts: 1938
Fot or not?
|
OpenGL support is typically provided under Windows by the display driver; grab the latest one for your card from Matrox's driver download page and install it. As far as I can tell, that should fix it.
|
|
|
|
|
Logged
|
|
|
|
Yuptar
Frungy champion
Offline
Posts: 51
|
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!  )
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! 
|
|
|
|
|
Logged
|
|
|
|
meep-eep
Forum Admin
Enlightened
Offline
Posts: 2847
|
(Maybe they can extend the DirectX modes to higher resolutions by the time it reaches the 1.0 release?) 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.
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. Again, upgrade your driver. This is not an UQM problem.
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.
"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."
Lots of little things seem to be unfinished or typoed. Unfinished things are why the project is still in alpha stage.
As for typos, please report those, so we can fix them.
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) 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.
Many, many instances of "Trying to get undefined resource 00000000" (A really 'useful' error message! )
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'" 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.
So I am looking forward to 0.6 and 0.7 and especially 1.0!
|
|
|
|
|
Logged
|
“When Juffo-Wup is complete
when at last there is no Void, no Non
when the Creators return
then we can finally rest.”
|
|
|
Yuptar
Frungy champion
Offline
Posts: 51
|
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.
|
|
|
|
|
Logged
|
|
|
|
|
|
Novus
Enlightened
Offline
Gender:
Posts: 1938
Fot or not?
|
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 (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.
|
|
|
|
|
Logged
|
|
|
|
Yuptar
Frungy champion
Offline
Posts: 51
|
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.
|
|
|
|
« Last Edit: September 08, 2006, 06:15:57 pm by Yuptar »
|
Logged
|
|
|
|
|
|
Yuptar
Frungy champion
Offline
Posts: 51
|
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?)
|
|
|
|
|
Logged
|
|
|
|
Yuptar
Frungy champion
Offline
Posts: 51
|
Ok, here's an attempt to show what is happening:
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.
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.
Third Image: System navigation has the same symptoms
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.
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...
|
|
|
|
|
Logged
|
|
|
|
Novus
Enlightened
Offline
Gender:
Posts: 1938
Fot or not?
|
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.
|
|
|
|
|
Logged
|
|
|
|
Yuptar
Frungy champion
Offline
Posts: 51
|
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.
|
|
|
|
|
Logged
|
|
|
|
Yuptar
Frungy champion
Offline
Posts: 51
|
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.
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.
|
|
|
|
« Last Edit: September 10, 2006, 08:46:23 pm by Yuptar »
|
Logged
|
|
|
|
Novus
Enlightened
Offline
Gender:
Posts: 1938
Fot or not?
|
So that may be why those two functions are being ignored.
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.
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.
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.
|
|
|
|
|
Logged
|
|
|
|
|
Pages: [1] 2 3
|
|
|
|
|
