The Ur-Quan Masters Home Page Welcome, Guest. Please login or register.
Did you miss your activation email?
October 14, 2024, 12:15:31 am
Home Help Search Login Register
News: Celebrating 30 years of Star Control 2 - The Ur-Quan Masters

+  The Ur-Quan Masters Discussion Forum
|-+  The Ur-Quan Masters Re-Release
| |-+  Technical Issues (Moderator: Death 999)
| | |-+  Opengl modes don't work in Win98
« previous next »
Pages: 1 [2] 3 Print
Author Topic: Opengl modes don't work in Win98  (Read 10369 times)
Yuptar
Frungy champion
**
Offline Offline

Posts: 51



View Profile
Re: Opengl modes don't work in Win98
« Reply #15 on: September 11, 2006, 12:20:29 am »

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.
Logged
Novus
Enlightened
*****
Offline Offline

Gender: Male
Posts: 1938


Fot or not?


View Profile
Re: Opengl modes don't work in Win98
« Reply #16 on: September 11, 2006, 10:50:05 pm »

OK... Here's 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 package in your content\packages subdirectory with the other packages.
Logged

RTFM = Read the fine manual.
RTTFAQ = Read the Ur-Quan Masters Technical FAQ.
meep-eep
Forum Admin
Enlightened
*****
Offline Offline

Posts: 2847



View Profile
Re: Opengl modes don't work in Win98
« Reply #17 on: September 11, 2006, 10:57:56 pm »

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.
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.
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 Offline

Posts: 51



View Profile
Re: Opengl modes don't work in Win98
« Reply #18 on: September 12, 2006, 02:03:38 am »

OK... Here's 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 package in your content\packages subdirectory with the other packages.

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? Smiley )

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.
« Last Edit: September 12, 2006, 03:18:59 am by Yuptar » Logged
Yuptar
Frungy champion
**
Offline Offline

Posts: 51



View Profile
Re: Opengl modes don't work in Win98
« Reply #19 on: September 12, 2006, 05:15:39 am »

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.
Logged
Novus
Enlightened
*****
Offline Offline

Gender: Male
Posts: 1938


Fot or not?


View Profile
Re: Opengl modes don't work in Win98
« Reply #20 on: September 12, 2006, 09:36:07 am »

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?
Welcome to 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. Sad

Quote
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? Smiley )
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.

Quote
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.
Right here.

Quote
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 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.
Logged

RTFM = Read the fine manual.
RTTFAQ = Read the Ur-Quan Masters Technical FAQ.
Novus
Enlightened
*****
Offline Offline

Gender: Male
Posts: 1938


Fot or not?


View Profile
Re: Opengl modes don't work in Win98
« Reply #21 on: September 12, 2006, 01:51:28 pm »

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.
Reported as bug #912. Fixed binary here.
Logged

RTFM = Read the fine manual.
RTTFAQ = Read the Ur-Quan Masters Technical FAQ.
Yuptar
Frungy champion
**
Offline Offline

Posts: 51



View Profile
Re: Opengl modes don't work in Win98
« Reply #22 on: September 12, 2006, 05:39:33 pm »

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. Smiley

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. Smiley

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. Tongue
« Last Edit: September 12, 2006, 05:41:42 pm by Yuptar » Logged
Novus
Enlightened
*****
Offline Offline

Gender: Male
Posts: 1938


Fot or not?


View Profile
Re: Opengl modes don't work in Win98
« Reply #23 on: September 13, 2006, 09:45:56 am »

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. Smiley
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.

Quote
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. Smiley
I have no idea. When it's ready, maybe?

Quote
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?
Sure, that's why I wrote LAB3D/SDL the way I did. Smiley 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.

Quote
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. I do notice a difference in CPU usage with the pointer arithmatic version, anyway.
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.

Quote
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. Tongue
I'll see if I can reproduce that on Windows.
Logged

RTFM = Read the fine manual.
RTTFAQ = Read the Ur-Quan Masters Technical FAQ.
Yuptar
Frungy champion
**
Offline Offline

Posts: 51



View Profile
Re: Opengl modes don't work in Win98
« Reply #24 on: September 13, 2006, 07:40:24 pm »

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!? Huh Huh Huh
Logged
Novus
Enlightened
*****
Offline Offline

Gender: Male
Posts: 1938


Fot or not?


View Profile
Re: Opengl modes don't work in Win98
« Reply #25 on: September 14, 2006, 02:56:57 pm »

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.
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!

Quote
BTW, why does the 'official release' open a second debug window but the debug version does not!? Huh Huh Huh
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).
Logged

RTFM = Read the fine manual.
RTTFAQ = Read the Ur-Quan Masters Technical FAQ.
Yuptar
Frungy champion
**
Offline Offline

Posts: 51



View Profile
Re: Opengl modes don't work in Win98
« Reply #26 on: September 14, 2006, 09:41:53 pm »

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.
Logged
Novus
Enlightened
*****
Offline Offline

Gender: Male
Posts: 1938


Fot or not?


View Profile
Re: Opengl modes don't work in Win98
« Reply #27 on: September 15, 2006, 10:11:34 am »

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).
Logged

RTFM = Read the fine manual.
RTTFAQ = Read the Ur-Quan Masters Technical FAQ.
meep-eep
Forum Admin
Enlightened
*****
Offline Offline

Posts: 2847



View Profile
Re: Opengl modes don't work in Win98
« Reply #28 on: September 15, 2006, 06:03:24 pm »

You can use '--logfile' to send stderr to a file.
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 Offline

Posts: 51



View Profile
Re: Opengl modes don't work in Win98
« Reply #29 on: September 16, 2006, 12:27:06 am »

I've done that. It still opens the window even though there's nothing appearing in it.
Logged
Pages: 1 [2] 3 Print 
« previous next »
Jump to:  


Login with username, password and session length

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!