Alternatively, there are 64-bit builds here: http://www.mediafire.com/file/ndowfov7417s84h/fs2_open_64-bit_GGX_Builds.zip
(especially trough what is for me the night)
I am real nightowl, so I relish the opportunity to stream through the night.
The soon-to-be pre-recorded footage will make it to YouTube after the Stream - unless I decide to not patronize YouTube ... but that's a discussion for another time and place.
Actually both 0rph3u5 and myself were talking about doing that on this thread.
Jup, we did and I have not given up ... just money wasn't always flowing to fix the problems at my end - it's telling that it took until this Friday to get a new headset with a working microphone
FS2 Open Coding - The Source Code Project (SCP) / Re: It's a good time for VR, since one can have HMD for $20+smartphone. I'll show.« Last post by ksotar on December 17, 2017, 04:55:52 pm »
I believed, that graphics subsystem should be constructed like that: Geometry and transformations->Polygon rendering->Post processing->Screen draw.
So, if I'll take my "Plan minimum", that is, to render in 960x1080 resolution, but stretch this image to 1920x1080. That way Reshade+Depth3D could step in, and it will be an already playable result. And that stretching could be easy implemented on the last step, "Screen draw".
But it appeared to be more convoluted than that. My impression is that graphics pipe in FS is quite not like that. There seems to be not enough encapsulation and quite many dependencies on several instances like "max_screen_width", "window_width", "clipping width" etc. (I'm writing by memory and can be wrong with exact naming), some of functions on the other hand, don't use these values but instead query subsystems for current window size. So, it appears not that easy. I was surprised to see the functions based on glViewport to set rendering area there and again in postprocessing etc. (even for single textures, I believe those are used as quasi-buffers). Chains of redefinitions that looks like simple renaming to me, also left me wondering, for example: gr_set_viewport<-gf_set_viewport<-gr_opengl_set_viewport<-glViewport and still using glViewport, but ok. In the end I couldn't find exact "Screen draw" phase, which should be the only place to implement stretching. Which is to my surprise, because in all OpenGL guides I encountered, this viewport transformation is performed just with a single glViewport call, following the logic of this scheme:
So I decided to try to go for all those loosely coupled places where sizes of render region are set.
I went for glViewport calls, halving width, like this: glViewport(0,0,gr_screen.max_w/2,gr_screen.max_h);
I got this:
Here we can see that only HUD rendered to the expected half of the window, but it has wrong AR. And seems like we have "progressive stretching", my guess that "width = width/2" is being passed down the chain. In the leftmost part we have something totally fishy, and I think that is postprocessing with wrong sizes and progressive squeezing. And of course mouse cursor was out of it's place as well.
I thought that it is too much of change points for a task that looked simple enough at start and decided to go the other way, as with window hook that I used. So I started the game in 960x1080 and instead changed the call of window creation:
SDL_Window* window = SDL_CreateWindow(props.title.c_str(),
So I got 1920x1080 window. Video intro, pilots profile menu and main menu appears stretched to full screen size (just what I wanted, and that reveals that some graphic functions are dependent on actual window size, not on stored values). But when I started mission, its loading screen and in-flight screen are 920x1080 again. HUD and all graphics are in perfect sync of course, but it seems that to stretch this screen to the full window is the same difficult task as in previous variant.
I just can't take the thought out of my head, that there should be some screen buffer swap operation or something in which it can be performed easily.
But OK, we have perfect picture at a half of the screen, we may consider to place another viewport for the right eye alongside it, and have true SBS. And here we need second camera, etc. I think that there is something wrong with the idea to set cameras with 30 degrees difference, it should be far less to my expectations. Moreover not only we need cameras to be angled, but we need an asymmetrical frustum. More on this could be found here.
But for now I'm not at this level of understanding of how FSO rendering works (as you can see from my results). Any help would be appreciated.
After letting it settle, I am disappoint. With the entire Disney direction for Star Wars, that is. I wish to God that they had chosen to just do to the Thrawn trilogy what Peter Jackson did for Lord of the Rings; make movies that truly encompassed and portrayed the genius in the books, without sacrificing anything painful (let's face it, it wasn't painful not to have Tom Bombadil). Sure, adjust the books to account for the actors' ages (somehow; I'm no writer), but keep the essential genius that was Thrawn.
But now, instead of a genius tactician waging a war of surgical strikes, masterful maneuvers, and resource balancing vs attrition, we have a petulant boy-man who—no offense to Adam Driver—looks like a wimp.
I've said it before and I'll say it again—stories need quality antagonists to be extraordinary. Heath Ledger in The Dark Knight. Sauron & Gollum in Lord of the Rings. Philip Seymour Hoffman in Mission: Impossible 3. Darth Vader in the OT.
These Star Wars movies, while better in many ways than the prequels, have severe issues that really affect them for the worse.
I just hope I live long enough to see a big-screen (or TV!) adaptation of the Thrawn trilogy.
I think it may come from the launcher (i may try knossos if the newest version works on my system because I had some issues with older ones) because I also have a problem if I don't use the flag "use portable mode" my joystick isn't recognised in game.