Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Koth on June 09, 2007, 07:47:45 am
-
Topic title says it all.
-
Geo-modding, holographic projection, and a sequel?
Well, in all seriousness, 3.6.9 seems pretty stable (at least to me) so 3.6.10 should have much more than bugfixes if I'm calculating right.
-
Shaders, Normal Mapping, and support for cards without D3D or OGL. :P
-
Shaders,
For ATI cards too I hope?
Normal Mapping,
what will become of all of the hi-poly models? A lot of the details on some of them won't have much use... will they?
and support for cards without D3D or OGL. :P
Say what? :wtf:
-
Here's what I'd like to see...
DX10 and OpenGL 3.0 support
Physics card compatibility (gravity weapons, atmospheric flight, projectile trajectories, genuine flak modeling)
Digital Molecular Matter (basically gives geomodding as a bonus!)
Support for 7.1 Surround sound and EAX up to 4.0
AI that passes the Turing test with an in-built TTS support
Trade system and fleet control in a Total War style 3D-universe, which zooms into battle area either into traditional FS2 mission (1st person control of a single fighter/bomber) or a Fleet Commander style view which doesn't give you control over individual units but instead you get to try how being the GTVA Command feels like
Teeth-whitening feature
...what? I'm dead serious. :lol:
Well it was worth a try.
New multiplayer code, IIRC, will at least be in. Dunno about other stuff, although sound system could use a surround feature IMHO. ANd possibly AI changes. I'm not certain about new pilot code, that might be put into 3.7.
-
http://www.hard-light.net/forums/index.php/topic,47536.0/topicseen.html
DX10?
Shaders?
http://www.hard-light.net/forums/index.php/topic,47536.msg967070/topicseen.html#new
-
:wtf:
It would be nice if someone could post what REALLY will be new in 3.6.10
instead of writng out all your wet dreams.
-
New multiplayer code, AFAIK that at least will be in 3.6.10.
-
:wtf:
It would be nice if someone could post what REALLY will be new in 3.6.10
instead of writng out all your wet dreams.
How? No one really knows, I think...
Just wait for it!
-
I'd say that Taylor or Goober know that is planned for 3.6.10.
C'mon you two it's not that hard to post a few sentences.
-
I'm curious to know if the fix for the infamous red-alert bug is going in 3.6.10, or if that's going to be introduced down the road further.
-
3.6.10 is going to be released next month, so it's not like there is a lot of time to add any really cool, new features. It's just a basic progression from 3.6.9, that's all.
3.6.10 will be:
- new FS2NetD code with cross-platform support and support for modular tables
- bunch of bugs from 3.6.9 fixed
- a few new things for mods to take advantage of
- minor performance optimizations
- changes to the ships lab to make it more useful
- reduced memory footprint (by about half)
- removal of AVI/MPG movie player code (only MVE and OGG Theora are supported)
- now OpenGL only (D3D is no longer functional)
And yes, that red-alert bug should be fixed. But you can test that for sure as soon as the first RC build gets released in another week or two.
-
And yes, that red-alert bug should be fixed. But you can test that for sure as soon as the first RC build gets released in another week or two.
Yay! Now I can play Awakenings!
-
I thought you guys were just trying to get the new Media VPs out?
-
And yes, that red-alert bug should be fixed. But you can test that for sure as soon as the first RC build gets released in another week or two.
Yay! Now I can play Awakenings!
There are actually ways to work around the red alert issues even now, but the missions need to be designed with it in mind. It took a ton of work (and some very ugly hacks), but I got the red alert missions in PI working just before the release.
-
I thought you guys were just trying to get the new Media VPs out?
The new vps will benefit from some of the features of 3.6.10, so they will be released together.
-
What I'd like to see in a near-future release:
Improved wide-screen support.
-
still say it should be 3.7.0
-
the improved tables...they in 3.6.10 or in 3.7.0.?
-
And yes, that red-alert bug should be fixed. But you can test that for sure as soon as the first RC build gets released in another week or two.
If someone has to fix anything to the red-alert code i hope they will also fix the red-alert bug when you launch the red-alert when the player is docked to something, the results are... well, funny, thats cause that any other ship in the next mission whit a "red alert carry status" to become invisible LOL!
The bug of player be able to use afterburners in AI control mode is also horrible :P
Oh come on... DX10 is a joke.... OGL 4ever!.
BTW, what about the FRED ability to modified a table entry by a sexp?
-
- reduced memory footprint (by about half)
how'd you pull that one off?
-
And yes, that red-alert bug should be fixed. But you can test that for sure as soon as the first RC build gets released in another week or two.
Yay! Now I can play Awakenings!
There are actually ways to work around the red alert issues even now, but the missions need to be designed with it in mind. It took a ton of work (and some very ugly hacks), but I got the red alert missions in PI working just before the release.
Oh, I see. Then does that mean that PI will be completely compatible with 3.6.10? (why isn't it 3.7? Are we using hexadecimal?)
Also, are we getting registry independence?
-
Oh come on... DX10 is a joke....
You may not like it, but you have to admit that Shader Modal 4.0 is very impressive. I almost drool at the thought of being able to create geometry with a shader. What does make it a joke is the fact that almost no hardware supports it.
-
The 3.6.x series is still based off of a same stable code tree that 3.6.9 came from. In other words, it's just a basic progression of the code. Nothing big, nothing fancy, just a few neat little things and quite a few bug fixes. There were also some things that were slated for 3.6.9 that didn't make it, and those are going into 3.6.10 instead. There will also be a 3.6.11 at the end of the year, also from the stable tree.
These 3.6.x series of builds is our attempt to bring some stability to the project. This makes it easier for mods to get new features and get bugs fixed, but without having to do a major overhaul of their data to make it all work. 3.6.10 is going to be data compatible with 3.6.9, so mods shouldn't have to change anything to make it work with the new build, unless they want to take advantage of some of the new features.
3.7 is going to be a HUGE break from the norm. It will require some mod changes (for some mods anyway), it will move from the registry to ini files, it will be a new launcher, it will be new input and message handling code, it will be a completely rewritten pilot file core, it will be even more cross-platform friendly, it will a largely restructured graphics back-end ... and much more. That is going to be a big deal and it's going to cause people (both us and you) to make some serious changes. So, although it's going to be a pretty great thing (we hope), don't rush it. Just rely on the relative stability from the 3.6.x builds for the next 8-10 months, then will start with some serious 3.7 builds. :)
- reduced memory footprint (by about half)
how'd you pull that one off?
I'm friggin awesome. Obviously. :D ;)
-
Or there was a gigantic memory leak that shouldn't have been there in the first place.
:nervous:
What?
*ducks under incoming projectile*
-
The bug of player be able to use afterburners in AI control mode is also horrible :P
That one is fixed already. I noticed it just before BtRL shipped so I had to fix it quickly.
-
.. Where were you shipping it? :nervous:
-
Beyond the Red Line of course. :D
-
Oh come on... DX10 is a joke....
You may not like it, but you have to admit that Shader Modal 4.0 is very impressive. I almost drool at the thought of being able to create geometry with a shader. What does make it a joke is the fact that almost no hardware supports it.
Well... SM 4.0 != DX10!
It's also possible with OGL! DX10 is just an API and Microsoft just specifys what features the GFX-Card have to support to be a "DX10" Card.
-
The bug of player be able to use afterburners in AI control mode is also horrible :P
That one is fixed already. I noticed it just before BtRL shipped so I had to fix it quickly.
oh, but i think that my bug report in mantis is still open :O
-
*closed bug*
Hmm. Haven't done that in far too long.
-
I want to hear more about this sudden decrease in memory usage. :wtf: Please?
-
I want to hear more about this sudden decrease in memory usage. :wtf: Please?
Just removing a bunch of crap off of the stack, getting D3D compiled out, cleaning out a couple of structs which had useless data, dealing with textures in OpenGL differently, dealing with various memory fragmentation issues, etc. And it will get even better post-3.6.10 as I start rewriting the old graphics code to work better with modern graphics APIs (which will make graphics faster and more efficient too).
-
Strangely it's these kind of background developments that really get me excited. Needless to say I am very excited right now. ;7
-
I'm friggin awesome. Obviously. :D ;)
I agree. ;)
@Mr_Maniac SM 4.0 means either using lots of different extensions, or waiting OpenGL 2.1
Also I'm wondering... what exactly would you use SM4.0 for?
Look at Eve Online. It's using SM 1.1 and still looks neat.
You're pretty limited with that though...
-
Strangely it's these kind of background developments that really get me excited. Needless to say I am very excited right now. ;7
I'm making changes like those constantly though, so it's nothing new. I run the game through Valgrind every couple of months looking for now memory leaks/errors, and I always compile my own builds with GProf support in order to identify and fix slow parts of the code. I'm also constantly planning changes to increase graphics performance and phasing in the changes in stages to help prevent problems. And now that I don't have to worry about keeping D3D working at the same time, it's a lot easier to make these sorts of changes quickly and efficiently. :)
-
that's why we love you taylor <3
-
I agree. Ditch D3D. I actually have an Intel integrated card that won't support OpenGL, but what the hell. It's about time you guys moved on, there are few FSers who really need D3D support still.
-
I prefer D3D over openGL, mostly because i hate openGL's API (i've used a bit of it before).
That said, there wouldn't be any problems going totally openGL. nVidia just fixed their Vista graphics drivers to fully support openGL, so as a player i wouldn't care.
-
OGL cards aren't that expensive... really. Go check them out. :D
-
Well, of course. For about $100 I could make my computer a vastly superior game machine. It's my parents, jr2.
-
Oh. :nervous: Well, if you save money for awhile, you can buy your own compy for cheap, and get a decent GFX card & RAM for it... unless they'd mind that.
-
I think that even an older 6200TC card whould run in OpenGL just fine...
the same is as for 7300xx series... cheap cards... and remember in from Argentina... the hardware price for me is about x8 than yours... here the price is about 600 dolars for an 8800GTS 640MB card and then the corvercion to our local money 600*3.1=1860$!!! yours may no have an idea of how many is that... well imagine yourselfs having to pay 1860 dolars for an 8800GTS card... :mad: :mad: :mad: So you can imagine that is hard to belive for me that some of yours may having troubles to buy hard...
-
ebay. 'slong as they ship internationally
-
I get rendering errors in OpenGL that i don't get in DX8, such as nebulas not rendering and several particle effects having no alpha blending. On the other hand, DX doesn't seem to support movies. I think continued support of both APIs would be most beneficial, as drivers are often biased toward one or the other and a choice between the two would probably help.
-
@blackhole: what's your GFX card?
-
I'm running vista.
nVidia GeForce 7900 GS
-
I get rendering errors in OpenGL that i don't get in DX8, such as nebulas not rendering and several particle effects having no alpha blending. On the other hand, DX doesn't seem to support movies. I think continued support of both APIs would be most beneficial, as drivers are often biased toward one or the other and a choice between the two would probably help.
Support of both APIs really isn't an option at the present time, as the SCP team currently doesn't have anyone who's a qualified D3D programmer. Taylor's an OpenGL coder, and since he's done the majority of graphics-related work over the past few years, OGL is the only API that's been supported. From everything I've heard, Vista has had some pretty abysmal driver support up until this point in its lifetime, so it's pretty likely that the problem with OGL lies on your end. If someone who knows D3D coding ever joins the SCP, the team will be more than willing to re-institute support, but until that day comes, you'll need to find a way to resolve whatever it is that's wrong.
-
I heard that nVidia just ironed out OGL support for Vista... check and see that you've got the latest drivers...
-
Is SCP going Vista?
Because I won't touch vista with a 10 foot pole :wtf:, no way in hell I'm going to waste $$ on some OS thats less stable then XP (Which im very happy with), just for a crummy DX10 that:
1) Alot of old games don't work on (considering there are alot more old games i prefer over NO new 1's worth getting atm)
2) I would need to get a new PC for since its hardware requirements are rediculasely selective :rolleyes:
So my question is, will SCP go Vista only? Or are alot of people deciding to stay with the stable (and superior) windows XP? :wtf:
-
Whatever gave you idea we were going Vista only?
Hell, if I remember correctly the reason we didn't move to DX9 a couple of years ago was because incompatibilities with Win98! Just because we want to make sure the game works with Vista doesn't mean that we're going to make the game ONLY work with Vista.
-
lol, sorry. With people talking of Vista in here and others on MSN trying to tell me that vista is inevitable, i think i jumped the gun :wtf:
lol, oh well :lol:
-
From what i've seen most of the people who play FS2 have really bad computers, and running vista on any of them would be computer homocide. I run Vista because i've got a computer powerful enough to handle it. And yes, i updated my drivers very recently, after i found out that nVidia fixed their OGL support. I saw results immediately, so i'm fairly certain its not driver related...
But i can't wait to see if someone can test my new DX9 code :nod: If it works i can start optimizing... or rather, restructering the entire damn rendering engine. Then maybe we can have SHADERS! :eek:
-
From what i've seen most of the people who play FS2 have really bad computers
"From what I've seen" means completly nothing.
-
Ok, a sizeable percentage :P
-
The ability to enable FS1 nebulae!
-
The ability to enable FS1 nebulae!
but, there ugly :eek:
-
How about making them pretty? They are sort of pretty in FS1, but I imagine you could improve them whilst keeping their feel.
-
Naw, screw that, how about full 3D volumetric nebulas? Like THIS (http://www.fl-tw.com/Infinity/Media/Videos/Infinity_nebula.avi)! :D :D :D :D :D
-
Naw, screw that, how about full 3D volumetric nebulas? Like THIS (http://www.fl-tw.com/Infinity/Media/Videos/Infinity_nebula.avi)! :D :D :D :D :D
That is very cool.
-
the stars, um you can fly through them?
-
Improved wide-screen support.
I've been busy with university the last few months but I hope to make my foray into FS2 development by doing this. Had a bit of a look at the HUD code and should be doable with a bit of work. Hopefully get started on this this summer or autumn.
-
What's wrong with widescreen currently?
-
If I remember correctly the 3D rendering is all fine. The problem is the HUD and other game artwork is hardcoded to 4:3 resolution so gets distorted/stretched during gameplay.
The gameplay-killing problem is that the targeting boxes are in the wrong place so they don't appear correctly over objects.
-
Both 2D and 3D are set for a 4:3 ratio, not just the interface stuff. It takes fundamental changes to frame rendering and view setup to fix this. Not to mention fixes to FOV and culling.
Getting proper widescreen support is neither an easy nor quick task, which is why it hasn't been fixed yet. I'm already in the process of restructuring the rendering system to actually allow us to fix it, but that's going to take time (ETA is hopefully for 3.6.11, at the end of the year).
-
Fair enough, a bigger problem than I thought. I'd still be interested in helping, what's the best way of communicating? IRC?
From my viewpoint it seemed to at least half work at widescreen resolutions? Will the viewport culling be partially broken when I'm running like that?
-
Fair enough, a bigger problem than I thought. I'd still be interested in helping, what's the best way of communicating? IRC?
I don't really do IM or IRC, never really have the time. PM here is generally the best way to get me, and then something can be setup if needed.
From my viewpoint it seemed to at least half work at widescreen resolutions? Will the viewport culling be partially broken when I'm running like that?
All of the positioning and culling is based on the old software code, which assumed a 4:3 screen ratio. Well, I take that back, it's not the screen ratio itself that's the problem, it is that it's based on an orthographic view. The 3D elements in the game use a projection view, the 2D elements use an orthographic view, and that doesn't work out in the least when you need to get the two separate elements to line up. This is the main problem, and it affects you whether you use a widescreen resolution or not. The real difference is that with a widescreen resolution the problems are just more obvious, but widescreen doesn't actually cause the problem.
It's easy to notice the positioning of the targeting brackets being off, and the culling is the same way since it's all based on the same stuff. If you run a widescreen resolution then the game will either not render things that it should, or render things that it shouldn't. In the first case, it's most obvious with the death screen (even on 4:3), since many ships/weapons just disappear strangely before they hit the edge of the screen. You don't really see the second case, but it causes a performance issue since it wastes time trying to render things that you will never see.
Most people who look at the widescreen issue just think that changing the interface graphics to not stretch out will fix it, but that has absolutely nothing to do with the problem. It can't be done with the HUD anyway, unless you rewrite most of that code.
The basic fix is to restructure the frame rendering code to keep 2D and 3D completely separate, but only when they are not related. The 2D elements on the HUD, for instance, are rendered after the all of the 3D view setup is gone, which means that you will never be able to get the brackets and ships to line up since you can't really figure out where they were on the screen (unless you are REALLY good at math that is). So this not only affects the basic HUD look itself, but it affects performance too since it's constantly switching between 2D and 3D rendering modes during the same frame, and it shouldn't. The HUD needs to be treated as a 3D element just like the rest of the view is, and that takes a bit of work to get situated. Unfortunately that's not even the best/proper fix, but the better fix would basically require rewriting a large portion of the code, which is why I ended up settling for this option instead. :)
-
This is probably not for 3.6.10, maybe not even 3.7, but what are the chances of getting dual screen support. I mean if you could code it in? It could be handy if (and your graphics cards could handle it) you could have one screen for a forward view (HUD etc.) and another for say, an external view or even a rear facing view!
-
This is probably not for 3.6.10, maybe not even 3.7, but what are the chances of getting dual screen support...
-239%, being optimistic about it. ;)
There are no plans to add dual screen support now or at any point in the future. Adding it would require so much work and code complexity that it's really not worth it.
-
Well, if you want to know what people what, look at the Wiki feature request page. Not many people use it, but that's what it's for.
Unless you're already working on all that stuff, and need even MOAR work to do.
-
I want to hear more about this sudden decrease in memory usage. :wtf: Please?
Just removing a bunch of crap off of the stack, getting D3D compiled out, cleaning out a couple of structs which had useless data, dealing with textures in OpenGL differently, dealing with various memory fragmentation issues, etc. And it will get even better post-3.6.10 as I start rewriting the old graphics code to work better with modern graphics APIs (which will make graphics faster and more efficient too).
We're talking about the memory footprint of the binary here, and not memory usage of the whole game, right ?
-
this might be getting a little off topic but if you force the res to the right size (eg. 2560x1024) you can get it to span multiple screens at the moment though youll probably want to fiddle with the fov.
As for multiple different views would it at least be doable and possibly more simple to have the game run a network based server so you can retrieve data about targets, ships and so on from the game so that you can have a seperate target, or radar , weapon display?
does that make the chance of it happening more than -239%? :D
-
We're talking about the memory footprint of the binary here, and not memory usage of the whole game, right ?
Both.
I'm working on both footprint of the binary and overall memory usage as well, since both need a good bit of work. The memory usage as a whole is currently a barrier to adding more features so it's important to start slimming down now in a significant way so that we don't run into more trouble as new capabilities are added to the engine.
-
All of the positioning and culling is based on the old software code, which assumed a 4:3 screen ratio. Well, I take that back, it's not the screen ratio itself that's the problem, it is that it's based on an orthographic view. The 3D elements in the game use a projection view, the 2D elements use an orthographic view, and that doesn't work out in the least when you need to get the two separate elements to line up. This is the main problem, and it affects you whether you use a widescreen resolution or not. The real difference is that with a widescreen resolution the problems are just more obvious, but widescreen doesn't actually cause the problem.
Most people who look at the widescreen issue just think that changing the interface graphics to not stretch out will fix it, but that has absolutely nothing to do with the problem. It can't be done with the HUD anyway, unless you rewrite most of that code.
The basic fix is to restructure the frame rendering code to keep 2D and 3D completely separate, but only when they are not related. The 2D elements on the HUD, for instance, are rendered after the all of the 3D view setup is gone, which means that you will never be able to get the brackets and ships to line up since you can't really figure out where they were on the screen (unless you are REALLY good at math that is). So this not only affects the basic HUD look itself, but it affects performance too since it's constantly switching between 2D and 3D rendering modes during the same frame, and it shouldn't. The HUD needs to be treated as a 3D element just like the rest of the view is, and that takes a bit of work to get situated. Unfortunately that's not even the best/proper fix, but the better fix would basically require rewriting a large portion of the code, which is why I ended up settling for this option instead. :)
Well, I understand very little of this, but I like to think I'm relatively clever, so I'll take a stab at it. I don't understand the terms "orthographic view" and "projection view", but I think I get what you're saying. The targeting brackets exist in a different plane than the 3D graphics, so that it is hard to derive the position of the target precisely and translate that to the 2D plane. Would it be possible to instead add a "postbox view" to the game, so that black bars are added to the sides, and the game is tricked into thinking it's running in 4:3? This is more of a temporary solution, but it would minimize the problems.
-
That might actually work if you took the screen size coordinates that you were feeding the engine and changed them to a 4:3 aspect ratio.
-
Would it be possible to instead add a "postbox view" to the game, so that black bars are added to the sides, and the game is tricked into thinking it's running in 4:3? This is more of a temporary solution, but it would minimize the problems.
Monitors do this automatically -- in fact, that's what happens on my laptop. I think people are lobbying for actual wide-screen support, so that the HUD is properly proportioned across the entire screen. That's a little more difficult.
-
Monitors do this automatically -- in fact, that's what happens on my laptop. I think people are lobbying for actual wide-screen support, so that the HUD is properly proportioned across the entire screen. That's a little more difficult.
Oh. Hewlett-Packard has a lot to answer for. :blah:
-
Actually, most monitors can't do that properly without using an analog connection. Only a few are capable of it. The Nvidia drivers are supposed to be able to do the same thing in software, but it doesn't work on many cards.
-
What I'd like to see in a near-future release:
Improved wide-screen support.
apparently the projection issue that cuases the busted targeting brackets, etc, will probably not be fixed till 3.7
-
apparently the projection issue that cuases the busted targeting brackets, etc, will probably not be fixed till 3.7
Hopefully for 3.6.11 actually, but that just depends on how much time I have available to work on it. It's the same basic bug that screws up the death scene and in-game cutscenes, so it is a pretty major issue overall.
-
HP pavillion runs 1024x768 on widescreen screen and it isn't noticeably distorted - It looks great!
- One thing for 3.6.11/3.7 - Hardwire in smartshaders as a new tab or something. not just HDRish but weird ones like the old TV signal one. It wouldn't add much to gameplay but at least people wouldn't have to go running all over looking for smartshaders. It would be cool, too. :bump:
-
Don't forget to fix the "hull_is_repaired_but_ship_still_spews_smoke" issue
One more thing - don't know where to put this in Mantis or if it even should be there - FRED is giving me trouble.
I do something in it, close it and I can't start half the other programs on my Pc..why? FRED process is still running..So I have to kill it's process...after that everything works normal.
-
That used to be a problem with old FRED builds.. what FRED are you using? 3.6.9? If so, it looks like that problem is back again. :|
-
Yup...3.6.9. ...But I havn't seen this problem before..It started happening about a month ago...
-
apparently the projection issue that cuases the busted targeting brackets, etc, will probably not be fixed till 3.7
Hopefully for 3.6.11 actually, but that just depends on how much time I have available to work on it. It's the same basic bug that screws up the death scene and in-game cutscenes, so it is a pretty major issue overall.
I actually get the culling issue in-game, not just during the death scene. My monitor also doesn't support hardware or software fixed aspect scaling, i've tried it with at least 3 different NVidia cards (6800gt, 7800GTX, 7950GT) i just get total screen corruption. Could I get a command line switch to tweak the culling distance? it actually irritates me more than the bracketting problem (which i get in 4:3 windowed resolutions too, btw)
-
with D3D going bye bye (YAY!) that means we (and i mean we.. i hope to learn how to be a much of an OpenGL wizard as taylor) can implement OpenGL 3.0 when it comes out later in the year :D
-
with D3D going bye bye (YAY!) that means we (and i mean we.. i hope to learn how to be a much of an OpenGL wizard as taylor) can implement OpenGL 3.0 when it comes out later in the year :D
... OpenGL 3.0 is coming out this year? Oh damn. I guess means i'll get more homework this year.
-
... OpenGL 3.0 is coming out this year? Oh damn. I guess means i'll get more homework this year.
:wtf: More homework?
-
OpenGL 3.0 is codename Mount Evans - scheduled for October 2007
it's features will be available via extensions in OpenGL Long's Peak (2.X) [sometime soon - this summer]
Post-3.0 release all previous versions will be deprecated but available - no new functionality will be added to deprecated versions.
3.0 includes geometry instances, geometry shaders, texture buffer objects, and a major shift to the way openGL works (that shift is occuring in Long's Peak but will not be complete until Mount Evans)
-
New in OpenGL. M$ inspired silly code names.
-
MS wasn't the first group to do them, and i'm fairly sure openGL did them before MS existed.. just most people didn't know the code names because the commonite didn't discuss upcoming versions of openGL because there was no reason to - openGL hasn't gone through the level of fundamental change in LP and ME - EVER.
-
Both 2D and 3D are set for a 4:3 ratio, not just the interface stuff. It takes fundamental changes to frame rendering and view setup to fix this. Not to mention fixes to FOV and culling.
Getting proper widescreen support is neither an easy nor quick task, which is why it hasn't been fixed yet. I'm already in the process of restructuring the rendering system to actually allow us to fix it, but that's going to take time (ETA is hopefully for 3.6.11, at the end of the year).
Would it be possible to at least get an option to allow fullscreen on 16:9 and 16:10 monitors by "letterboxing" around a 1024x768 game view? I know it's a kludgey fix, but I haven't been able to play FSO in the six months since I got my widescreen LCD, and I need my fix... :P
-
Both 2D and 3D are set for a 4:3 ratio, not just the interface stuff. It takes fundamental changes to frame rendering and view setup to fix this. Not to mention fixes to FOV and culling.
Getting proper widescreen support is neither an easy nor quick task, which is why it hasn't been fixed yet. I'm already in the process of restructuring the rendering system to actually allow us to fix it, but that's going to take time (ETA is hopefully for 3.6.11, at the end of the year).
Would it be possible to at least get an option to allow fullscreen on 16:9 and 16:10 monitors by "letterboxing" around a 1024x768 game view? I know it's a kludgey fix, but I haven't been able to play FSO in the six months since I got my widescreen LCD, and I need my fix... :P
Just select 1024x768 in the "Video" tab... S'what I do...
... OpenGL 3.0 is coming out this year? Oh damn. I guess means i'll get more homework this year.
:wtf: More homework?
-
I'm in a games programming course, atm, we're cover bone animation in Advanced ComGraph. We're also learning Python. And we're supposed to be learning DX next year, but i've started a bit on my own this year.
-
What should you fix in 3.6.10?
Get rid of all those pointless FRED error messages like "Player ship has no secondaries". Have an option to disable all SCP error messages, as it's annoying to click through 10 error messages only to see that your mission runs fine. Get rid of all those Volition "quality control" features that are no longer needed. For example, you're not allowed to commit to a mission if "player ship has no weapons". This may have been useful to Volition playtesters, but at this point it's unnecessary.
In other words, it'd be helpful if FreeSpace didn't have so many error messages, or at least an option to disable the most common. Sounds like a lot to do, but as far as I can see it's just a matter of deleting extra pieces of code.
-
For example, you're not allowed to commit to a mission if "player ship has no weapons". This may have been useful to Volition playtesters, but at this point it's unnecessary.
:wtf:
-
Why not?
-
Cause sometimes those error messages are needed.
That said I do like the idea of being able to set a warning level like you can with a compiler. If you set it to high warning level you get all the complaints. If you set it to low you only get the "You've ****ed up your mission. Commence ripping out your hair now" type errors.
-
Don't forget to fix the "hull_is_repaired_but_ship_still_spews_smoke" issue
I have to say this again since this bug is there (and I've bene pointing at it) from the first build that had the abiltiy to repair hull...
-
Is the bug in Mantis?
-
Don't know...I pointed at it several time..hanv't put it myself in the Manits...there' only PCS2 category in there, so I wouldn't know under what to report it anyway...
-
Well point at it again. Then I can see what progress has been made and maybe look at it myself. It doesn't sound hard to fix at all. But I'm not stepping on anyone's toes if they're already looking at it.
-
For example, you're not allowed to commit to a mission if "player ship has no weapons". This may have been useful to Volition playtesters, but at this point it's unnecessary.
:wtf:
What if your ship is purposely unarmed? The mission designer might not want you to have weapons.
-
Well in that case an error message is only going to serve to annoy the mission designer seeing as he knows damn well he doesn't want to give you any weapons.
-
Fair enough.
-
... You now know who to blame if ever a mission makes you fly a ship with NO weapons, and plunges you into the middle of a Shivan dogfight.