Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Murleen on February 14, 2008, 12:24:41 pm
-
Hi all,
I've been poking around in the code looking at the 2d/3d misalignment problem, and I think I've worked up a fix. There were two basic issues - the aspect scaling code was broken - it looks like it was intended to increase the horizontal fov when the width was greater than the height, and decrease the vertical fov otherwise. Unfortunately the if condition was wrong, so the vertical fov decrease was always being applied. Since the OpenGL projection fixes the vertical fov, I've changed the aspect scaling code to match. The second problem was the View_zoom being improperly applied - the 2d code was treating it as a linear zoom factor, while the 3d code multiplied it by an 80 degree vertical fov angle. Here's the patch:
Index: code/render/3dsetup.cpp
===================================================================
RCS file: /home/fs2source/cvsroot/fs2_open/code/render/3dsetup.cpp,v
retrieving revision 2.22.2.1
diff -u -r2.22.2.1 3dsetup.cpp
--- code/render/3dsetup.cpp 1 Oct 2006 19:31:19 -0000 2.22.2.1
+++ code/render/3dsetup.cpp 14 Feb 2008 17:58:32 -0000
@@ -284,15 +284,8 @@
s = aspect*(float)Canvas_height/(float)Canvas_width;
- if (s <= 0) { //scale x
- Window_scale.xyz.x = s;
- Window_scale.xyz.y = 1.0f;
- }
- else {
- Window_scale.xyz.y = 1.0f / s;
- Window_scale.xyz.x = 1.0f;
- }
-
+ Window_scale.xyz.x = s;
+ Window_scale.xyz.y = 1.0f;
Window_scale.xyz.z = 1.0f; //always 1
init_free_points();
@@ -371,17 +364,10 @@
Matrix_scale = Window_scale;
- if (View_zoom <= 1.0) //zoom in by scaling z
-
- Matrix_scale.xyz.z = Matrix_scale.xyz.z*View_zoom;
+ float f = 1.0 / tan((double) Proj_fov / 2.0);
- else { //zoom out by scaling x&y
-
- float s = (float)1.0 / View_zoom;
-
- Matrix_scale.xyz.x = Matrix_scale.xyz.x*s;
- Matrix_scale.xyz.y = Matrix_scale.xyz.y*s;
- }
+ Matrix_scale.xyz.x = Matrix_scale.xyz.x*f;
+ Matrix_scale.xyz.y = Matrix_scale.xyz.y*f;
//now scale matrix elements
It's more than possible that I've missed something here, but it seems to be pretty solid for me with wacky fov and aspect settings...
-
I always get a warm feeling when someone's first post is a code fix. :D
-
I always get a warm feeling when someone's first post is a code fix. :D
Yeah, that is always pretty nice. :)
I need to test this out when I get back home before I can give it my official thumbs up, but this is easily the best best idea I've seen so far to address the problem. This patch doesn't really touch on the root of the problem, it's a bit more complicated than that, but it certainly appears to come damn close to making the proper fix a wasted effort (which is would do if the proper fix didn't offer performance improvements). I'll test it out in a few hours, and if everything appears to work fine then I'll go ahead and commit it. :)
And I'm sure that you could end up getting a cookie out this, or a carrot, or a beer, or a pizza, or whatever it may be that turns you on in a congratulatory-gift sort of way. :D
EDIT: Works great for me. Fantastic work Murleen, I'll commit this later tonight! :)
-
And I'm sure that you could end up getting a cookie out this, or a carrot, or a beer, or a pizza, or whatever it may be that turns you on in a congratulatory-gift sort of way. :D
If this works, I recommend a proper custom title. As a laptop user, I'd also be happy if a widescreen fix was to be implemented.
-
He's got Perspective.
-
Title'd. :D
Will this work for FRED too? :)
-
Will this work for FRED too? :)
Not sure yet, I'll be testing that a bit later today before I commit. There are already a couple of issue with the fix that required some minor changes so that it works better, but that wasn't a big deal. But after the necessary changes I haven't found any test case that doesn't work so far. :)
-
Hi all,
I've been poking around in the code looking at the 2d/3d misalignment problem, and I think I've worked up a fix. There were two basic issues - the aspect scaling code was broken - it looks like it was intended to increase the horizontal fov when the width was greater than the height, and decrease the vertical fov otherwise. Unfortunately the if condition was wrong, so the vertical fov decrease was always being applied. Since the OpenGL projection fixes the vertical fov, I've changed the aspect scaling code to match. The second problem was the View_zoom being improperly applied - the 2d code was treating it as a linear zoom factor, while the 3d code multiplied it by an 80 degree vertical fov angle. Here's the patch:
Index: code/render/3dsetup.cpp
===================================================================
RCS file: /home/fs2source/cvsroot/fs2_open/code/render/3dsetup.cpp,v
retrieving revision 2.22.2.1
diff -u -r2.22.2.1 3dsetup.cpp
--- code/render/3dsetup.cpp 1 Oct 2006 19:31:19 -0000 2.22.2.1
+++ code/render/3dsetup.cpp 14 Feb 2008 17:58:32 -0000
@@ -284,15 +284,8 @@
s = aspect*(float)Canvas_height/(float)Canvas_width;
- if (s <= 0) { //scale x
- Window_scale.xyz.x = s;
- Window_scale.xyz.y = 1.0f;
- }
- else {
- Window_scale.xyz.y = 1.0f / s;
- Window_scale.xyz.x = 1.0f;
- }
-
+ Window_scale.xyz.x = s;
+ Window_scale.xyz.y = 1.0f;
Window_scale.xyz.z = 1.0f; //always 1
init_free_points();
@@ -371,17 +364,10 @@
Matrix_scale = Window_scale;
- if (View_zoom <= 1.0) //zoom in by scaling z
-
- Matrix_scale.xyz.z = Matrix_scale.xyz.z*View_zoom;
+ float f = 1.0 / tan((double) Proj_fov / 2.0);
- else { //zoom out by scaling x&y
-
- float s = (float)1.0 / View_zoom;
-
- Matrix_scale.xyz.x = Matrix_scale.xyz.x*s;
- Matrix_scale.xyz.y = Matrix_scale.xyz.y*s;
- }
+ Matrix_scale.xyz.x = Matrix_scale.xyz.x*f;
+ Matrix_scale.xyz.y = Matrix_scale.xyz.y*f;
//now scale matrix elements
It's more than possible that I've missed something here, but it seems to be pretty solid for me with wacky fov and aspect settings...
I think I love you. In a completely platonic way of course. :D
-
Great job !!!
-
(http://members.cox.net/wmcoolmon/images/welcome.gif)
-
(http://members.cox.net/wmcoolmon/images/welcome.gif)
All this success, and we forgot the most sacred of welcomes :)
And he gets a custom title with his first post!
(in a completely freindly way) CONGRAGU-****ING-LATIONS! WE FINALLY HAVE THE DAMNED WIDESCREEN FOV FIX! :D
Now...um...how do i use it? :confused:
-
Wait for a build. Has anyone, besides the Hammer of 0wnage or
Thunder Kalfireth Thunder, got a title on their first post or before posting?
-
Kind of like finding a hundred dollar bill on the street.
-
beautiful!
no more black bars or misleading lead indicators for me!
-
Will this work properly for 5:4 aspect ratio as well as 16:9 and 16:10?
-
what kind of screen uses 5:4 anyway?
-
1280x1024...
Rather common resolution, I daresay. :p
-
yeah, but do common CRT monitors support that? what would you need that ratio for anyway?
-
They support it and a lot of people use it, but it's the wrong ratio for them and makes things look squished. 5:4 LCDs were made as such because this resolution was so common on CRTs.
-
That's a great news!
Just need to wait opengl version of softh and i ll be able to play fs2 with my 3screens :yes:
That fix , the track ir suppport and virtual cockpit that are coming both, scp engine open his way to simulator's immersion feeling!
:nod:
-
Thanks! Glad to help :)
Now if only there were a simple way to get aspect-correct scaling on the HUD...
Will this work properly for 5:4 aspect ratio as well as 16:9 and 16:10?
Should work with pretty much any ratio - though I noticed a couple of areas not fixed by my patch (probably what Taylor had mentioned) - the skybox seems to zoom in the wider the screen gets, and the indicators around the reticle that point at targets seem to point the wrong way now.
That's a great news!
Just need to wait opengl version of softh and i ll be able to play fs2 with my 3screens :yes:
That fix , the track ir suppport and virtual cockpit that are coming both, scp engine open his way to simulator's immersion feeling!
I had a go running over three screens - just run in windowed mode, and set the resolution in the registry. It's not very playable however, since the UI and HUD are stretched across three screens (the reticle ends up about one screen wide). I've been poking about with the dirtiest of dirty hacks to get the UI/HUD to only display on the centre monitor, but it's kinda nasty at the moment...
-
Doesn't fov command correct that ?
Did you try with softh?
anyway softh is not the perfect solution as long as it do not support opengl yet, but it's on it's way!
I wonder if there is any possibility to modify fso to handle triple screen by it's own?
'cause with softh, the perfomance were quite horrible... maybe because it use direct x mode :confused:
-
yeah, but do common CRT monitors support that? what would you need that ratio for anyway?
I've not seen a brand new CRT in over a decade that doesn't support it. Most CRT's (17" especially) run highest at 1280x1024. Anyways--as far as I know, the GUI and in-mission indicators and boxes always wants to stretch over the entire available screen area. Unfortunate--it would be nice if you could change that so you can dock certain elements to different parts of the screen.
-
By support, i meant if you get a distorted or stretched picture when running at 1280X1024.
-
Thanks a lot Murleen!
I really need a second monitor at home too. And now it might just be a widescreen. :)
-
Just another note to say thank you for this fix. This will help me a great deal! :yes:
-
/me uses a widescreen too...this will come in handy.
-
I use one too, got a 1280x800 lappy.
Itching for the build.
-
just compiled my MacOS X build with the patch... works!!
:yes:
-
My eyes thank you Murleen. :yes:
-
Actually, nobody's commented on the best part of this fix -
It works in FRED too. :D
I'll have a windows build posted shortly.
-
http://fs2source.warpcore.org/exes/latest/C02182008.zip (7.76 MB)
-
That seems to work marvellously... the retail stars and suns are no longer wandering around the skybox/nebula background! Huzzah!
But I want MOAR. Would it be possible to make a normal map enabled build with this fix included? I've kinda grown attached to them... Too much of a good thing I guess. :p
-
Dear sweet baby jesus it's beautiful.
However with this build I have a weird pausing problem. My framerates are fine but the first thing anything loads I have horrible stuttering. I didn't have this problem using the fs2_open_3_6_10-20071007T build with the -no_glsl flag, however this build doesn't recognise that flag.
My specs:
Core 2 Duo T5450
2Gb RAM
Geforce 8600M GS using 169.09 drivers
Vista Home Premium
Also I can't see engine glows on larger ships in this build.
My command line is D:\Games\FreeSpace 2\fs2_open_C02182008.exe -mod mediavps -spec -glow -env -mipmap -no_vsync -cache_bitmaps -dualscanlines -orbradar -rearm_timer -ballistic_gauge -3dwarp -warp_flash -snd_preload -ambient_factor 90
I installed using Turey's installer, and I have the latest media vps except adveffects as provided by the installer.
-
Does this fix the 16:10 ship pop-in/out at the edges?
-
The build I released isn't based on Taylor's Xt builds, so that's almost certainly the reason for the bugs and lagging.
Does this fix the 16:10 ship pop-in/out at the edges?
It seems to, but I didn't look too carefully. I did, however, also try it at 1050x1680, and that worked fine, too. :p
-
good to hear, since i use this res :)
-
1280x1024 has actually been around for a long time. The reason it exists has to do with how a frame is stored in the framebuffer. It's more memory efficient than 1280x960, even though the latter is a proper 4:3 resolution. 1280x1024 goes back to CAD days, with big CRTs in offices and old school graphics adapters. So it's just kind of been around since then, and considered the more standard 1280 resolution. Using 1280x960 actually wastes memory apparently, so they figured they would just increase it. Bugs me too, but it took a college professor's explanation to at least help me understand why it even exists. And yeah, not only do LCDs support it, but it's been the native res for a huge chunk of LCDs made over the last 5 years or so. I really like my Sun CRT though, 20" of any-res goodness. It even actually shows a few 16:9 resolutions, and you can fiddle with the scaling enough to make them actually look right on the monitor, like watching a widescreen movie on a boobtube. I'll have to pull it out and thoroughly test this on it.
The only builds that are going to have normal map/shader/GLSL/-no_glsl support, etc are going to be builds directly from Taylor until he commits his code or shares it with someone else directly. Without it, you're basically getting builds from a codebase that hasn't had a lot of graphics changes since before September I think. I hope a lot of the recent enhancements can make it into 3.6.10, since it seems there'll probably be another huge round of bug hunting anyway. Mmm...FOV fix, GLSL, multi updates, new scripting...this could be a very good release indeed.
Not to mention a bunch of Bob's stuff that Taylor's been adding back in :)
Hmm, on second thought, taylor's build with -no_glsl should basically be using the same rendering path as this, so that does actually seem a bit interesting to me that they would behave so differently. I wonder what's changed in that path between October and now, besides this fix.
-
The changes in my Xt tree are massive, with considerable effort put into not only cleanup but also performance optimization. Some of the features are dependent on other new features which aren't complete yet, which is why it's taking so long to get the code in SVN. Another problem has just been the bugs in the new code. I don't like to add bugs to SVN, so I try very hard to work out as many of those as I can find before I ever commit new code. I actually had to drop almost half of the new code that I wrote for the Xt tree just so there was less work to do in order to get the rest into SVN quicker.
Both the programmable and fixed rendering paths have changed considerably over last year so it shouldn't come as a surprise that things likely work differently. I also work closely with some testers who not only help me work out new features for general use but also help track down and identify various slowdowns and other performance issues. Through that collaboration I decided to completely rip out and rewrite all of the GLSL code that was in the 10/28 build, so it's 100% new and improved now. Many other things were changed as well, such as state changes, reducing calls and many wasted CPU cycles, as well as a reworking of the fixed rendering pipeline to better streamline it.
Oh, and the other devs do have my code. I have even released it publicly several times (even the 10/28 build had a source code release for Linux users to build from). The devs that ask for it get it, as Bobboau and WMCoolmon have done. But having it and being able to deal with the considerable amount of changes (upwards of 70,000+ lines last time I looked) are two very different things. With that amount of changed code it's generally easier for other devs to simply not deal with a code tree like that and focus only on whats in SVN. I've had a year to slowly get used to the differences, but others don't really have that luxury, so you can't blame anyone else for not releasing builds based on my code.
And so this doesn't keep to the off-topic content...
The FOV isn't in SVN just yet, as has surely been noticed. While testing I discovered several issues that I attributed to the FOV changes, but they turned out not to be related at all. I actually haven't found one single issue that can seriously be attributed to the FOV patch in any way, just old issues that didn't really get noticed before. As a result I removed those non-FOV changes so as not to screw up other stuff with a freaky bug hunt. The only change that I've made to the original patch, other than an extremely minor performance related change, was to put it with proper Cmdline_nohtl checks so as not to mess up cases where we don't actually run with projection (it's just easier to stay with retail in that area for now, even if the FOV patch doesn't appear to hurt anything).
I missed by time window for doing the commit though, and have been working on other bugs. I will get it committed at some point in the near future however, so sorry about the delay Murleen. :)
-
Great to hear Taylor, I'm glad to hear so much care is going into making the next release the Best Ever. I'm sure I can wait a while longer if it's going to be as awesome as it sounds. And thanks again Murleen, this is awesome all around.