The Ur-Quan Masters Home Page Welcome, Guest. Please login or register.
Did you miss your activation email?
August 15, 2022, 06:32:46 am
Home Help Search Login Register
News: Paul & Fred have reached a settlement with Stardock!

+  The Ur-Quan Masters Discussion Forum
|-+  The Ur-Quan Masters Re-Release
| |-+  Technical Issues (Moderator: Death 999)
| | |-+  Graphics scaling in combat
« previous next »
Pages: [1] Print
Author Topic: Graphics scaling in combat  (Read 4104 times)
Novus
Enlightened
*****
Offline Offline

Gender: Male
Posts: 1938


Fot or not?


View Profile
Graphics scaling in combat
« on: January 24, 2003, 01:27:36 pm »

I grabbed UQM from CVS a few days ago, and I must say it looks quite impressive already. Most of the time, the game looks great aside from some minor (already reported) graphical glitches, but the scaling of ships in battle does not look very good, with parts of ships (or even entire fighters) disappearing. In the TODO file, trilinear filtering (i.e. linear interpolation between bilinear mipmaps) is mentioned as a possible solution. I'd like to suggest an alternative.

Currently, UQM is drawing (as far as I can tell from the source and appearances) everything to a 320x240 buffer and drawing that to screen, resizing as required to fit the screen resolution. If you're running UQM at a high resolution (e.g. 1280x960), this means that zoomed-out ships and such are shrunk down to fit the low-resolution display buffer and then magnified to fit the screen resolution. Obviously, zoomed-out ships would look a lot better if they were scaled only once.

The problem with this is that it complicates the graphics code somewhat. While there is no real problem with adding objects drawn separately on top of the low-resolution picture currently used, the issue is complicated by the fact that the battle view consists of both stuff that is scaled (e.g. ships, bullets, planets) and stuff that is not (e.g. stars, engine trails). One possible simplification is to assume that all scaled objects should be placed in front of unscaled objects (which is true in at least some of the cases), in which case the scaled objects can be simply drawn onto the back buffer just before swapping the front and back buffers. Alternatively, everything could be drawn directly to screen resolution, but this would require extensive rewriting of graphics code.

As a bonus, with this technique, it would be possible to easily hardware accelerate the drawing of ships et.c. by loading the graphics that are to be scaled as textures and drawing them as quads onto the back buffer (similarly to the way in which bilinear filtering is done now in OpenGL mode).
Logged

RTFM = Read the fine manual.
RTTFAQ = Read the Ur-Quan Masters Technical FAQ.
AngusThermopyle
*Smell* controller
****
Offline Offline

Gender: Male
Posts: 304


A paranoid android.


View Profile
Re: Graphics scaling in combat
« Reply #1 on: April 10, 2007, 02:14:12 pm »

Sorry, to exhume such an old thread, but this was the only relevant topic on these boards I could find.

Anyways, here’s my issue: I recently installed a second hard drive on my machine with Ubuntu as my OS. Got UQM up and running OK. Only problem is that I have the same graphic scaling issue in combat, mentioned above, in resolutions 800x600 and above. Resolutions below 800x600 work fine.

Now when I boot to Windows, UQM runs fine with no scaling problems at all. So what would cause linux to have this problem, but not Windows? As best I can tell, my graphics card driver (ATI) is installed correctly. I am, admittedly, a linux noob, so any help here would be appreciated.
Logged
Novus
Enlightened
*****
Offline Offline

Gender: Male
Posts: 1938


Fot or not?


View Profile
Re: Graphics scaling in combat
« Reply #2 on: April 10, 2007, 05:24:00 pm »

By Dogar and Kazon! I think you've unearthed my first post on this forum! Shocked It only took four years to get a response. Grin

Anyhow, since then, trilinear scaling has been implemented in UQM and works like a charm most of the time. However, I did experience problems similar to those you describe a while back, and I find now that turning the resolution up again makes them reappear. Further examination shows that the graphics work fine in pure SDL mode but large parts (I've seen Eluders missing two or three spheres!) go missing in OpenGL mode; this is on openSUSE 10.2 with an NVIDIA Ti4200 and driver version 9631. In any case, since I can duplicate this, I can investigate further and report bugs as applicable.

As my current monitor (like most LCD monitors) does bilinear scaling (or something that looks very much like it) from 640x480 to its native 1280x1024 just fine, I've been running UQM in SDL framebuffer mode at 640x480 for quite a while (which appears to speed things up slightly); no sense in having UQM duplicate monitor functionality. Smiley

Anyhow, the current workaround is: don't use resolutions other than 320x240 and 640x480. I'll keep you posted whenever I discover more.

My suggestion about rewriting the graphics system still stands, although the current trilinear scaling works well enough as it is when it does. This is only worth doing if you introduce high resolution graphics at the same time.

Edit: Looks like the edges of ships are being cut off in the rescaled graphics. Maybe an alpha channel that's being misused?
Edit 2: Confirmed on Intel 855GM chipset, stock openSUSE 10.2 drivers. Looks like a bug in UQM.
Edit 3: OK, the zoom code is generating alpha data that seems to be getting copied into the framebuffer, messing things up for the OpenGL code which for some reason is treating it like RGBA where the alpha component should really be ignored.
« Last Edit: April 10, 2007, 06:07:09 pm by Novus » 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: Graphics scaling in combat
« Reply #3 on: April 10, 2007, 06:06:52 pm »

LCD monitors have a fixed resolution. If you use a resolution different from the monitor's native resolution (or a divisor thereof), you'll get artifacts.
To make sure this isn't what is causing your problems, try running UQM in your monitor's native resolution (if running fullscreen), or running with the desktop on your monitor's native resolution (if running in a window).
Logged

“When Juffo-Wup is complete
when at last there is no Void, no Non
when the Creators return
then we can finally rest.”
Novus
Enlightened
*****
Offline Offline

Gender: Male
Posts: 1938


Fot or not?


View Profile
Re: Graphics scaling in combat
« Reply #4 on: April 10, 2007, 06:42:13 pm »

LCD monitors have a fixed resolution. If you use a resolution different from the monitor's native resolution (or a divisor thereof), you'll get artifacts.
To make sure this isn't what is causing your problems, try running UQM in your monitor's native resolution (if running fullscreen), or running with the desktop on your monitor's native resolution (if running in a window).
Thanks, Meep, but those were the first things I ruled out. My current guess at what seems to be happening is that the OpenGL implementation is using RGBA instead of RGB for textures (which may be legal) and getting confused by the alpha values from the zoom code.
Logged

RTFM = Read the fine manual.
RTTFAQ = Read the Ur-Quan Masters Technical FAQ.
AngusThermopyle
*Smell* controller
****
Offline Offline

Gender: Male
Posts: 304


A paranoid android.


View Profile
Re: Graphics scaling in combat
« Reply #5 on: April 10, 2007, 07:04:50 pm »

Anyhow, the current workaround is: don't use resolutions other than 320x240 and 640x480.

That's exactly what I'm doing now. Not the most desirable scenario though, since I like to run UQM in windowed mode.

I’ve tried the trilinear filtering with no luck. In fact, all of the filters seem to produce the same disappearing effect on resolutions of 800x600 and above in OpenGL mode.

The only thing I can think of is the ATI OpenGL implementation behaves differently in Windows than it does in linux. When I have time later, I may look around some linux forums (which I’ve grown accustomed to doing so lately) and see if I can find any other examples of similar behavior in other applications.

Thanks for looking into this, btw! Hopefully we can get to the bottom of this.
Logged
Novus
Enlightened
*****
Offline Offline

Gender: Male
Posts: 1938


Fot or not?


View Profile
Re: Graphics scaling in combat
« Reply #6 on: April 10, 2007, 07:23:38 pm »

Overriding the alpha value sent to OpenGL doesn't help; it seems that whatever's going wrong is going wrong before the graphics reach OpenGL. Maybe SDL is treating alpha differently with the graphics format used by the UQM OpenGL code?

In any case, I think this merits a bug report (I can't find a graphics card or resolution where the problem does not occur under Linux); I'll put one in Bugzilla tomorrow.
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: Graphics scaling in combat
« Reply #7 on: April 11, 2007, 07:59:44 pm »

WTF? Huh Changing the format of format_conv_surf from RGBA to BGRA (which, incidentally, matches what pure SDL uses on my system) fixes it. I'm starting to suspect an SDL bug; that would go some way to explaining why it works on Windows but not Linux. Just switching the red and blue channel masks (R_MASK and B_MASK) around is enough to fix it.

In case you're wondering, this in on openSUSE 10.2 with SDL version 1.2.11.

Edit: Possible reason; will investigate further.
« Last Edit: April 11, 2007, 08:58:31 pm by Novus » Logged

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

Gender: Male
Posts: 94



View Profile
Re: Graphics scaling in combat
« Reply #8 on: April 12, 2007, 01:10:52 am »

WTF? Huh Changing the format of format_conv_surf from RGBA to BGRA (which, incidentally, matches what pure SDL uses on my system) fixes it. I'm starting to suspect an SDL bug;
Possible reason; will investigate further.

Yes, this is exactly the SDL issue in question - SDL bug 390. Good catch, Novus! I also have to admit, the SDL issue was my fault -- a problem in my rewrite of SDL gcc alpha blitters. Ryan Gordon has committed the fix to SDL subversion repository, so you can build your own fixed SDL version for Linux.
Logged
Novus
Enlightened
*****
Offline Offline

Gender: Male
Posts: 1938


Fot or not?


View Profile
Re: Graphics scaling in combat
« Reply #9 on: April 12, 2007, 08:51:10 am »

Thanks for confirming the issue, fossil.

OK, that means a proper fix will appear in the next release of SDL (whenever that is), so you'll probably have to compile your own until then (either apply the patch yourself or grab the latest version from SVN; you probably want the stable 1.2 branch, not the 1.3 development version). Switching colour format (as documented above) seems to work around the problem, but may affect performance.
Logged

RTFM = Read the fine manual.
RTTFAQ = Read the Ur-Quan Masters Technical FAQ.
Pages: [1] 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!