|
Pages: 1 [2] 3
|
 |
|
Author
|
Topic: Opengl modes don't work in Win98 (Read 10371 times)
|
Yuptar
Frungy champion
 Offline
Posts: 51
|
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
Gender: 
Posts: 1938
Fot or not?
|
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
|
|
|
|
|
|
|
|
Yuptar
Frungy champion
Offline
Posts: 51
|
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
Gender:
Posts: 1938
Fot or not?
|
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. 
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.
Right here.
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
|
|
|
|
|
|
Yuptar
Frungy champion
Offline
Posts: 51
|
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. 
|
|
|
|
« Last Edit: September 12, 2006, 05:41:42 pm by Yuptar »
|
Logged
|
|
|
|
Novus
Enlightened
Offline
Gender:
Posts: 1938
Fot or not?
|
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?
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 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.
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. |
|
|
|
|
Logged
|
|
|
|
Yuptar
Frungy champion
Offline
Posts: 51
|
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!? 
|
|
|
|
|
Logged
|
|
|
|
|
|
Yuptar
Frungy champion
Offline
Posts: 51
|
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
Gender:
Posts: 1938
Fot or not?
|
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
|
|
|
|
|
|
Yuptar
Frungy champion
Offline
Posts: 51
|
I've done that. It still opens the window even though there's nothing appearing in it.
|
|
|
|
|
Logged
|
|
|
|
|
Pages: 1 [2] 3
|
|
|
|
|
