|
Pages: [1]
|
 |
|
Author
|
Topic: Graphics scaling in combat (Read 4347 times)
|
Novus
Enlightened
 Offline
Gender: 
Posts: 1938
Fot or not?
|
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
|
|
|
|
AngusThermopyle
*Smell* controller
Offline
Gender:
Posts: 304
A paranoid android.
|
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
Gender:
Posts: 1938
Fot or not?
|
By Dogar and Kazon! I think you've unearthed my first post on this forum!  It only took four years to get a response. 
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. 
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
|
|
|
|
|
|
|
|
|
|
Novus
Enlightened
Offline
Gender:
Posts: 1938
Fot or not?
|
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
|
|
|
|
Novus
Enlightened
Offline
Gender:
Posts: 1938
Fot or not?
|
WTF?  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
|
|
|
|
|
|
Novus
Enlightened
Offline
Gender:
Posts: 1938
Fot or not?
|
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
|
|
|
|
|
Pages: [1]
|
|
|
|
|
