Hard Light Productions Forums
Community Projects => The FreeSpace Upgrade Project => Topic started by: neoterran on May 08, 2006, 12:43:07 pm
-
The SCP is looking mighty fine.
Has anyone ever given a thought to upgrading the Heads up display to look more modern, IE, have glows, transparencies, etc.
This would obviously be optional because the purist will freak out when it's even spoken of, but we need new HUD anyway in order to support new and widescreen resolutions (widescreen is the future for gaming, no reason why SCP can't join that club)
I'm not suggesting that the order of the HUD or its basic elements be changed much, just upgraded to look nicer and more modern. Look at games like Ghost Recon : Advanced Warfighter. The HUD in the game looks very nice, especially the use of transparencies in the right places.
I think an upgraded HUD for Freespace SCP would make a huge impact on new players. After all, it's something that you see every time you play, and having it look more modern would have a large psychological effect, I think.
Discuss.
-
I seem to remember there was a discussion about this somewhere sometime ago. Perhaps in one of the hosted projects... Use teh serchzomgh!!11!!1
-
Heh, I'm sure someone has "given a thought" :p. I think there's some stuff being worked on, probably some stuff in limbo, and other things are now possible through the new scripting system.
But really, it's easy to say "look more modern", "have glows, transparencies"... what specifically do you mean? I look at screenshots of Ghost Recon: Advanced Warfighter, and I see a lot of really useful context-specific indicators and displays (more to discuss on that topic, some other time), and I see that there are many different colors and the indicators are semi-transparent. Ok. Now I look at FreeSpace 2, and I see that we can change colors of each indicator, and they're already transparent (even retail!). I don't have the other game so maybe I'm missing what you're getting at.
"New HUD"... complete redesigns are hard but possible someday. For now, sure, some new shapes would be nice. Mostly all we need is someone to make them, you any good at such art? Look at TBP, they've already changed a few things...
Widescreen support is a good idea, but actually it mostly works already. Everything but some of the non-static things like target brackets (but this is a bug involving FOV I think, and already reported).
-
I don't personally think the HUD looks old fashioned; I think we're simply just used to it. That given, a completely new HUD would be useful as a sort of general library for people wanting to make TCs etc, but it's not really needed IMO for FSU. And, of course, it's a hell of a lot of work which there aren't many people perhaps willing to do.
-
What we need to do is to make them look a bit more holographic IMO.
HUD is a very good system but the trouble is, the HUD in FS doesn't really look lika a HUD even. A HUD normally is best comprised of thin lines as indicators, made more clear by text and numbers. I think the FS HUD is not really a HUD at all but rather more like the holographic panels in, say, HALO. Though a tad bit more transparent, that is.
What I think would give a nice touch would be to have some bleeding from the very edges of the indicators. Not that the HUD would be blurred or anything. No, what I mean is to have the edges of indicators as sharp as they currently are, but give an impression that the image is created by light and some of that light makes the air softly glow in immediate vicinity of the indicator. Another thing is that perhaps the indicators really should be a little bit more transparent.
Of course the indicators could use some redesigning. Everything always does. :D
-
It's not a hologram, though. It's most definately a HUD, even if it's an odd one from a current-day perspective.
-
3D cockpits with specially named textures tied into the game engine are the way to go.
-
I'm the black sheep here.
A prettier HUD would be really nice, but I do prefer that modders and coders spend their time in more useful tasks:
+ Fixing reported bugs.
+ Adding new features (functional decays, env mapping, enhacing multitargeting, dynamic laser convergence, new SEXPs, WhatEverYouThinkOf, ...)
+ Making HTL ships (I prefer better looking ships than better looking HUD).
+ Making new campaigns, voice acting older ones.
Of course, this is a free and open community so everyone can do whatever he or she likes. But I think HUD is not so awful to need an urgent remake. I just fell it should have low priority, and maybe, the required effort isn't worth.
-
What we need to do is to make them look a bit more holographic IMO.
HUD is a very good system but the trouble is, the HUD in FS doesn't really look lika a HUD even. A HUD normally is best comprised of thin lines as indicators, made more clear by text and numbers. I think the FS HUD is not really a HUD at all but rather more like the holographic panels in, say, HALO. Though a tad bit more transparent, that is.
What I think would give a nice touch would be to have some bleeding from the very edges of the indicators. Not that the HUD would be blurred or anything. No, what I mean is to have the edges of indicators as sharp as they currently are, but give an impression that the image is created by light and some of that light makes the air softly glow in immediate vicinity of the indicator. Another thing is that perhaps the indicators really should be a little bit more transparent.
Of course the indicators could use some redesigning. Everything always does. :D
This is exactly what I mean ! The HUD looks a little dated, But i love the general layout of it, I'd like it just to be a little more "enhanced", maybe sharper, and cleaner, things that couldn't be done in 1999. Also the loading screens in between the game looks a little dated too... why can't that have transparency ? Look at the menus GUI in F3 mode in the Main Hall.. stuff like that ! That looks really kick ass... Why can't all the game menus be retooled to be like that ? Keep the general idea, but make all the background menus and loading bars etc, semi-transparent, it would just bring the game more respect from people taking a general look at it. It's obvious they wanted to do some transparency, because they've got that weird matrix bitmap they're using in the menus for the backgrounds, but that was when most computers/cards couldn't easily support that kind of thing. That's not the case now... and in a year or two, this project will still be around, and AGP cards like the 7800 GS will have fallen to less than 200 dollars, so many legacy systems still have a path to get an amazing graphics card for freespace SCP.
Anyway, the HUD is the most important thing to change out of all these things because you stare at it and it's supposed to give you the immersion of really being in a cockpit. We already have quite a few high poly models, and for those of use with fast graphics cards and tweaked mediavp sets, it's already possible to run the game at modes like 8xS AA and 16X AF where it looks gorgeous, I'm sure volition had no idea it would ever run this long.
I'm not an artist. There seems to be a general trend around here that you can't suggest or put forward ideas unless you do them yourself, i don't know why that is.
-
Also the loading screens in between the game looks a little dated too... why can't that have transparency ?
They can. But someone actually has to make them. The loading bar animation can be an EFF so you can have any sort of transparency that you want, and even make it TGA without worry since it doesn't stay in memory.
Look at the menus GUI in F3 mode in the Main Hall.. stuff like that ! That looks really kick ass... Why can't all the game menus be retooled to be like that ?
Umm, because that GUI doesn't work very well?? The code still needs to be finished (scroll bars, keeping things on screen, taking keyboard input, properly dealing with lower resolutions, etc.) before it's even remotely suitable for use as the main interface. Plans are already in the works to totally rewrite the main interface code anyway, taking what it is now and moving it to a whole other level. The lab GUI may be ok for some, you people don't take full advantage of the existing interface capabilities now anyway, but it could be so much better.
Anyway, the HUD is the most important thing to change out of all these things because you stare at it and it's supposed to give you the immersion of really being in a cockpit.
[rant:target="Thread"]
Well, lets see...
People wanted a way to customize the HUD. WMCoolmon did a lot of work on hud_guages.tbl so that they could make changes to graphics, positions, etc. Future work was planned to make it better as the community used it. BUT NO ONE USED IT!
Nope, people wanted more. WMCoolmon did a LOT of work on the scripting support so that you could build a custom, interactive and feature rich HUD via scripting. You can even mix scripted elements with non-scripted elements to just enhance the existing look of the HUD. NO ONE IS USING IT!
Sorry, but you can want a better HUD all you want. You can even be given a way to make it happen. But apparently that isn't quite good enough. Coder time is already maxed out. It will be a miracle if you get a third coder push for the same damn feature, simply hoping that, maybe this time, it will actually be worth the coding effort they will have expended. Take advange of what you already have, and shut the hell up.
[/rant]
Ahhh, I feel so much better now. :D
-
Where's the documentation for the likes of hud_gauges.tbl?
-
Well, it would be nice if information like what taylor suggested was actually KNOWN... it's not in the wiki, short of asking WMCoolmon or Taylor himself, how are we supposed to know ? I guess now we finally have had a search for a week, but i did search for HUD and Better HUD and didn't find a thread exposing this info....
Plans are already in the works to totally rewrite the main interface code anyway
Well, that's great. Hopefully when it's done it'll actually be documented so newbies to the project like myself will actually know what can be changed and what can't.
-
Hud_gauges.tbl (http://www.hard-light.net/wiki/index.php/Hud_gauges.tbl) in FSwiki
Scripting.tbl (http://www.hard-light.net/wiki/index.php/Scripting.tbl) in FSwiki
And atleast some mods/TCs are trying to use will use scripting..
-
WMCoolmon did a lot of work on hud_guages.tbl so that they could make changes to graphics, positions, etc. Future work was planned to make it better as the community used it. BUT NO ONE USED IT! WMCoolmon did a LOT of work on the scripting support so that you could build a custom, interactive and feature rich HUD via scripting. NO ONE IS USING IT!
It's a fair point, well made. Given the opportunity to customize guage positionings and such is only half the battle. Someone still needs to sit down and draw up the graphics for all these fancy new HUD guages. In the case of the scripting though, the truth may be that particular case may be that nobody knows how to use it.
Take advange of what you already have, and shut the hell up.
Game, set, match. I will shut up, along with everyone else ;).
-
Hud_gauges.tbl (http://www.hard-light.net/wiki/index.php/Hud_gauges.tbl) in FSwiki
Scripting.tbl (http://www.hard-light.net/wiki/index.php/Scripting.tbl) in FSwiki
And atleast some mods/TCs are trying to use will use scripting..
Ah, okay, i guess i didn't look very hard. Well, um hopefully someone like aldo will do the graphics... :drevil:
-
In the case of the scripting though, the truth may be that particular case may be that nobody knows how to use it.
I agree. The scripting route does require more coding knowledge than many people may be willing to learn. I know for sure that some are/will use scripting for custom HUDs, but those custom HUDs are pretty complex. For those who need/want basic changes hud_gauges.tbl is the only other way to go.
And though hud_gauges.tbl is closer to a normal table and is easier to use, the fact that no one has really made use of it and that scripting can do the same thing, hud_gauges.tbl is on the feature chopping block. If more people start making use of it then there is cause to not only keep it but also expand on it. I think it would be good to keep since it allows you to customize the HUD in a relatively basic way, but you don't have to get so complex with it like scripting would give you. So the problem here is that we have to code features which can do the same basic thing, if one doesn't get used then we dump it. That hurts people who want a custom hud, but not to the extent that scripting does it, though removing it does clean up the code and reduce bloat. Hopefully enough of the modders can make use of both features so there is enough reason to actually keep both.
-
Hud_gauges.tbl (http://www.hard-light.net/wiki/index.php/Hud_gauges.tbl) in FSwiki
That one is my "fault" :p and not a very good 'excuse' for documentation for the hud_gauges.tbl -- I made it last week, getting the information from Google's cache of the old FSDoc site. :nervous: Besides that, I can't find any other documentation. A few mentions in the forums archives, but lots of dead links to example hud_gauges.tbl files.
And though hud_gauges.tbl is closer to a normal table and is easier to use, the fact that no one has really made use of it and that scripting can do the same thing, hud_gauges.tbl is on the feature chopping block. If more people start making use of it then there is cause to not only keep it but also expand on it. I think it would be good to keep since it allows you to customize the HUD in a relatively basic way, but you don't have to get so complex with it like scripting would give you.
I agree, it would be nice to keep and expand. I'll do some of it if there are people that want such things. So far I see, doing a forum search, it supports moving things like the middle shield icon, the two hull/shield status indicators on the bottom, the escort list, and the afterburner/weapons gauges. That's a good start for stuff to mess with. I found an example and will shove it in the wiki, but I dunno how out-of-date it is.
So uh... Whether or not there was enough information in the past for people to use it, it's gone (or hard to find) now so we need to start again. If WMCoolmon and anyone else who knows about it would help me update the wiki entry, it would be great.
-
Besides that, I can't find any other documentation.
That has long been the problem with SCP features. They're great and uber powerful, but no one knows how to use them.
-
Another problem is that most of us that are knowledgable enough to start getting involved and learning these features, are also incredibly busy with RL(tm) so it's gonna take some time. I really want to get this HUD updated, I'm looking into it, problem is it really requires an artist more than a coder, someone with vision and who understands we want to keep the spirit of the HUD intact, so it doesn't get rejected out of hand etc.
-
Actually, I wrote the original hud_gauges.tbl page, but the sorely-needed scripting.tbl page I never got around to working on. Thanks Wanderer.
I've (repeatedly in the priv forum) asked for a feature-of-the-day system, so you could fill out a few fields per feature., and a little box on the SCP would pop up one of the submitted features (picking a new one each time the page is refreshed). Done right you could also have an indexing system, to index features by type.
also what would be nice are more people who add stuff to the wiki. It's really annoying to spend literally hours writing about a feature on the forums, making examples, etc etc and then have people complain because it's not in the wiki. Which nobody can really see new changes in very easily.I imagine if coders did simply write stuff in the wiki instead, people would complain that the information wasn't organized or formatted very well. And if coders spent the time to document, organize, and format everything in the wiki, plus announce new features on the forum, while trying to fix bugs, then people would complain that features weren't being added fast enough!
There are literally pages of discussion on hud_gauges.tbl...however you will have to do a search, because most of the discussion is not in the wiki.
-
also what would be nice are more people who add stuff to the wiki.
I was thinking the same thing. There really just needs to be a person, or persons, who are part of SCP for the purpose of writing documentation. Expecting a coder to write docs is not the sanest thing in the world. Although we can do it, the docs may not be comprehensible, and it takes away from doing other things, like you say. There are, or have been, SCP members who will test things and then those who code. We just don't have anyone dedicated to the job of actually keeping up with all of the new features and document them. I guess we need to try and create a "DocMaker" position for the project, and then trick someone into volunteering for the job. :)
-
The thing about making a new hud idea is very cool. But, as opposed to cosmetic changes, you can already flexibly customize the hud in the game. Color whatever you want, remove what you don't want on there, and i think even control transparency to preference(if i remember right). The real potential for changing the hud would be within making custom hud for different fighters. That would be sweet as hell. Something interesting for an interceptor hud would be a bomb tracking display that automatically locks onto the nearest bombs while having a standard display for locking onto everything else, even possibly another radar specifically for tracking bombs along with the standard radar(tracking everything on the single radar does get a little hectic with a big engagement). Another thing that would be cool for custom huds is something like secondary laser target reticles, for something that has offset gunpoints like the ursa per say.
But the great thing about the standard fs hud is that it's very flexible, and really comes with everything you absolutely need for everything you fly in fs. I don't see why the hud is outdated in any way, so far the only recommendations for the hud so far have been what seem to be minor cosmetic alterations. Another thing for customized huds is that yes it takes a lot of time that people don't have time for, and that what happens when someone makes a new fighter for a campaign? You'd have to make a new hud for pretty much every class of ship specifying where target reticles go and so forth, or what other capabilities you'd want. That'd be a hellstorm for a campaign that has tons of new ships like inferno. That's the nice thing you can forget about when making a campaign, you can forget about the hud layout, the aspect you need worry about is a good escort list. The fs hud is so far universal for fs combat, and flexible for different ships in the game.
-
There's so much possibility with what's already implemented, though. What's in there isn't much more advanced than what 90% of what the lab GUI uses. Or in other words, I believe that you could remake the GUI to a checkbox level, possibly even add in scrollbars and such. The current lack of keyboard input is a pain, restricting you to true/false values and spinners, and it's hardly the most optimized way to do things...but it's still very doable.
Most of the reason that these features don't get used isn't because they are poorly documented, it's because very few people are sitting down to do them. Things like "There's no documentation (http://www.hard-light.net/wiki/index.php/FS2_Open_Lua_Scripting)" or "There's no list (http://www.hard-light.net/wiki/index.php/Command-Line_Reference#-output_scripting) of functions (http://fs2source.warpcore.org/temp/scripting.html)" are simply wrong in the case of scripting. There's now even the list of hooks (http://www.hard-light.net/wiki/index.php/Scripting.tbl) that Wanderer put in, so you don't have to look that up on the forums. No, the one on the website is not necessarily up to date.
Short of copy-pasting in the 3-4 examples that I've posted, linking in the example HUD (http://www.game-warden.com/forum/showpost.php?p=29809&postcount=13), and rewriting to the nth power, I'm not sure that there's much that could be done to make the documentation better, short of people actually reading it and trying to follow it and having problems with it, that are then addressed.
With hud_gauges.tbl, the most difficult thing to understand are the custom gauges, I think. You have to define those in the hud_gauges.tbl, then you can set preset values in the table, but will generally want to set the values using the SEXPs.
-
People wanted a way to customize the HUD. WMCoolmon did a lot of work on hud_guages.tbl so that they could make changes to graphics, positions, etc. Future work was planned to make it better as the community used it. BUT NO ONE USED IT!
Really? You should know better. :drevil: ;7
-
Really? You should know better.
Yeah, but we do know that now. That's why we don't work more in many types of features. I mean take the envmap code for OpenGL for instance. At some point I may start working on it again, but even when it eventually gets into public hands there will be something found for everyone to complain about. Either it's going to be too slow, or not look right, or everyone will get mad that I've never been able to figure out how to get -alpha_env to work properly, or it doesn't look exactly like the D3D version. Someone will probably complain about documentation on that too. It's just not worth the effort.
I'd rather just work on bug fixes instead. Even though some do manage to complain about that for one random reason or another, it's a lot less stress on me. :sigh:
(no one caught that particular feature reference, right? i'd put a :wink: face here or something, but it would be too easy to notice.)
-
Uhmmm I think 99% will love you for addin env mapping support again... the other people can just disable it. ;)
Seriously. And I think it doesn't have to look exactly like the D3D env mappig. It just has to look good. ;7
About the scripting: Well, even if the mods don't go public with their ideas for a scripted HUD, the scripting is still getting used. If the first mods release something with scripted stuff and people get the chance to see it in action and get some (more) samples, it should get more and more popular. It's only a matter of time.
-
Communication has to occur, though. :p If nobody talks about a feature, and I don't know of any mods/campaigns that use that feature, I'm going to assume that no one is using or particularly interested in that feature, and probably move on to something else. Or simply not code, if I don't want to do anything besides that feature. No reason to code something if no one is going to use it.
Of course, on the flip side, having people request features but then not use them is just as annoying, because then I feel somewhat deceived, and have also wasted my time.
Good communication FTW.
-
Personally, I don't care what the D3D evironment mapping looks like anymore, or what the OGL version will look like in comparison because I no longer play FS2O in Winduhs anyway. And I think I can speak for my fellow Linux users, and probably the Mac users who play this game as well that we would just like the feature there and working already. And DaBrain is right. It doesn't have to match D3D. It just needs to look good.
-
Personally, I don't care what the D3D evironment mapping looks like anymore, or what the OGL version will look like in comparison because I no longer play FS2O in Winduhs anyway. And I think I can speak for my fellow Linux users, and probably the Mac users who play this game as well that we would just like the feature there and working already. And DaBrain is right. It doesn't have to match D3D. It just needs to look good.
I was just screwing with everyone. Envmap support for OpenGL will hit CVS this weekend. ;)
The code has been in final testing for a little over a week. DaBrain knows all of this, he's just playing along. :)
This is the only announcement there will be of the code though, I'm going to sleep for a week after it's in CVS. The reason I'm telling you now is that if HLP goes down for maintenance this weekend then you might not hear about it. Also, I just finished the last missing part of the code (which I didn't think I would code in so fast) so the only thing to hold it up now is two more days of private testing. And as you probably use CVS I figure you would like to know as soon as it hits. Envmap for D3D will be disabled at the same time though, I don't care to update it to be in line with all of the new general envmap code upgrades.
-
Of course, on the flip side, having people request features but then not use them is just as annoying, because then I feel somewhat deceived, and have also wasted my time.
Good communication FTW.
Agreed, and I hope we can do this better, have a fresh start now that there's the (knock on wood :nervous:) working domain, forums (with search!), and wiki. There's been a lot of miscommunication, and quite a bit of forgetting or info getting lost or something. Nobody's fault, it happens. I wasn't there, but I'm guessing part of the problem involves some of the downtimes in the past, or something... for example, hud_gauges.tbl had lots of discussions in 2004 and then suddenly went silent...
One thing about this: it's not too late! Whether or not the requested feature hasn't been used yet, it still can be! For example, I'm pushing the hud_gauges.tbl to the WCSaga team. (and considering taking up your Coding Opportunity (http://www.hard-light.net/forums/index.php/topic,29349.0.html) :D)
And all it really takes is one cool implementation, because then some other mod group will go "Whoa, how did they do that" and copy the example and then tweak it from there.
I was just screwing with everyone. Envmap support for OpenGL will hit CVS this weekend. ;)
The code has been in final testing for a little over a week. DaBrain knows all of this, he's just playing along. :)
Very looking forward to trying it out. Yikes you guys scared me there for a bit! Man, taylor if you gave up just because of the stupid people, I would have to go and hunt down Every Single One. And that would take a while. Don't make me do that. :p
-
I hope you realize that if you did set about hunting down all the stupid people, you'd mostly depopulate the planet.
-
Envmap support for OpenGL will hit CVS this weekend. ;)
This is great news. Thanks Taylor.
-
WHAT !!! OMG I'm going insane, thank you taylor. Taylor is my hero. :eek: :nod:
I sure hope someone does a build....
So um, Taylor, can you tell us what it looks like ? Or better yet can you take a screenshot to tease us while we wait these interminable hours ?
-
So um, Taylor, can you tell us what it looks like ? Or better yet can you take a screenshot to tease us while we wait these interminable hours ?
Screenshots don't really do it justice unfortunately. The effect is a bit more subtle and blended in with the model than the D3D was (I think, never really saw the D3D version in action). It does look really good, occording to the testers (and myself ;)), but the look may change a little when it does actually hit CVS. Right now I have cmdline options in the test builds so that testers can adjust the intensity of the effect, but the defaults seem to make everyone happy so far and those cmdline options won't go into CVS. Still, the defaults might change between now and when it hits CVS. But at this point the defaults look best on the widest variety of mods and models.
Here is some (very) basic info on the changes though:
- Both -env and -alpha_env work as advertised.
- Testers report little to no speed difference between using -env and not
- Works equally well in static and dynamic env modes
- DDS loader and OpenGL texture code updated to properly handle cubemaps
- Added mission option for modders to include pre-made, mission specific, envmaps
- Added cmdline option to save static render targets to file after they are rendered, so that you can distribute them
Not everyone will be able to actually make the env maps themselves since it requires the GL_EXT_framebuffer_object extension, which not everyone will have support for. Most everyone will be able to actually use envmaps though, which is why I added to ability to use them from a file. This way mod makers can just include copies of the static envmaps for each mission if they wish. There is also a default envmap, "cubemap.dds", which will be loaded (if it exists) and used as the default envmap in the case that the user's video drivers don't support creating envmaps and the mission doesn't specify one. And a good reason for using files is that the render-target versions can't be compressed in-game. This means that the two default envmaps, when they have mipmaps, will use over 6meg of video ram each. But, since you can save those to file, a mod maker can compress them into DXT1 making the files need only about 1meg of memory instead and distribute those files with his/her mod.
Of course, what you should really be asking is not for screenshots, but why I let the secret out. I can keep a secret till death, even keep it so well you wouldn't even know there was a secret, if I chose to do so. For me to let you know all of this before the code actually hit CVS can mean only one thing...
I've got a better secret. :drevil:
-
The effect is a bit more subtle and blended in with the model than the D3D was
That's really good to hear, because it looked utterly ridiculous in D3D (but still cool, and i'd still turn it on) so it's really good to hear it's a bit toned down because that's exactly what was needed.
I've got a better secret. :drevil:
The new launcher ?!
This is going to be the BEST WEEKEND EVAR !!!! TAYLOR FTW !!!
-
I've got a better secret. :drevil:
The new launcher ?!
This is going to be the BEST WEEKEND EVAR !!!! TAYLOR FTW !!!
Nope, not the launcher. :) Everyone already knows that I'm working on the new launcher, so what kind of secret would that be? (the launcher is a major upgrade to game code so it's not close yet)
The real secret thing, possibly a feature of some sort, will probably go unnoticed by just about everyone. It's just that it's such a minor thing, something I whipped up one afternoon. It happens to be one of those things that I like, but no one has ever complained about that thing or had issue with it. I'm really only doing it for the one or two people who might actually enjoy it. Since I like it it's something that I can get excited about but whether anyone else likes it doesn't really matter. I'd compare it to a computer upgrade, it would be awesome to me (for a little while at least) but nobody else would care that I got an extra gig of RAM or something like that. This secret is that type of thing.
;)
-
Completly redone engine?
Redone AI?
Better handling of RAM?
-
What ! What could it be ? :confused: Damn, I can't wait for the weekend to get here. You've already improved my freespace experience a thousand fold, looks like you'll be doing it again...
*edit*
So uh, since the forum will be down this weekend for upgrading or whatever, what day can we realistically expect a new build if everything goes well with the testing ? Monday ?
-
Well there will always be speed improvements and better memory usage. Lots of little things have been fixed in the course of this. For instance, I found one bug where compressed DDS images loaded from disk/VP, when they have mipmaps, will use 30-35% more memory than they actually needed. I cleaned up a few redundant math and state changes per frame. The envmap squishing bug where the generated envmaps look freaky should be fixed (hopefully, as reported in Mantis with the D3D code). Just various little things like that.
But, like I already said, the new feature (or whatever it actually could be) is rather minor. The few people who notice it will enjoy the novelty, for about 5 seconds. Then it will fade away and everyone can go back to criticising all the various little issues that don't really matter. There are really only two things to know: 1) DaBrain may need medical assistance, chronic laughter and rolling around on the floor like that can't be good for you, and 2) I'm an evil, evil bastard. :D
EDIT:
So uh, since the forum will be down this weekend for upgrading or whatever, what day can we realistically expect a new build if everything goes well with the testing ? Monday ?
I was thinking about that too. There will be one more private test build. If it goes well then I'll just move it to a public location (such as http://icculus.org/~taylor/fso/nightly) over the weekend. Whether I remember to actually do that is another question, but it may not hurt to look there Saturday afternoon or so.
-
Okay, that would really be neat because the weekend is about the only time i get to sit down at my home theatre set up and play.
Let's hope all goes well, I'm interested to see how env / env alpha works on OpenGL and if I can figure out what the "secret" addition is.
-
If I got an extra gig of memory it wouldn't be minor, but oh well...
-
I was thinking about that too. There will be one more private test build. If it goes well then I'll just move it to a public location (such as http://icculus.org/~taylor/fso/nightly) over the weekend. Whether I remember to actually do that is another question, but it may not hurt to look there Saturday afternoon or so.
Isn't the "nightly" folder more where you put non-Windows builds? Wouldn't the "testing" or "willrobinson" folders be better for that? Yes, I am a snoop junkie. :drevil:
-
Isn't the "nightly" folder more where you put non-Windows builds? Wouldn't the "testing" or "willrobinson" folders be better for that? Yes, I am a snoop junkie. :drevil:
I just haven't released any builds that were "nightly" worthy since I made that directory. The Linux and OS X builds are the only thing in there only because I haven't had the Windows builds to add in yet. How I run down what goes where:
- "nightly" is those builds which are current CVS. In this particular build case it's basically current CVS, just two days early. I'll update and rebuild if needed before this weekend. Anything in here will not contain any experimental code and either is current CVS, or soon will be.
- "testing" is for things that are not yet ready for CVS. Mainly ideas or theories, but nothing that should cause any major issues. These will typically be CVS ready code mixed with some personal-use type code.
- "willrobinson", well.. I picked that name for a reason. :) Use builds from there at your own risk as those will be things that change options, init stuff, memory freakiness, io code, pilot code, etc. Those builds are just as likely to not start up as they are to work fine, but make it impossible for you to run older builds.
-
Hey, I'm leaving till next wednesday. But I really can't WAIT to see env-mapping... (although I will have to ... :hopping:)
OTOH, to SCP crew and modders, as I have posted 3 billion times, DO NOT PAY ANY ATTENTION TO PEOPLE SAYING YOUR WORK IS RUBBISH OR WORTHLESS. You make a great FREE job. So what other people, (just like me), can do is just POLITE SUGGESTIONS. If someone is so clever to say Taylor, WMCoolmon or any other one, are wasting their time or making a bad work, what he/she has to do IS MAKING IT BETTER. Less talk and more actions.
-
Hey, I'm leaving till next wednesday. But I really can't WAIT to see env-mapping... (although I will have to ... :hopping:)
OTOH, to SCP crew and modders, as I have posted 3 billion times, DO NOT PAY ANY ATTENTION TO PEOPLE SAYING YOUR WORK IS RUBBISH OR WORTHLESS. You make a great FREE job. So what other people, (just like me), can do is just POLITE SUGGESTIONS. If someone is so clever to say Taylor, WMCoolmon or any other one, are wasting their time or making a bad work, what he/she has to do IS MAKING IT BETTER. Less talk and more actions.
In my opinion this just goes with the territory when you do any kind of development work of this nature whatsoever, you have to get a thick skin and abide by your own principles. You're going to get some criticism, and sometimes you have to be honest with yourself and ask yourself, is this criticism valid ? Most of the time it won't be, but sometimes..
And for all the people that are all talk and no action, then that becomes obvious. It's the people who add stuff to the community that will be valued, and it's fairly obvious who those people are.
Hey, has this thread gone far enough off topic or what ?!
-
I would like to remind taylor that today is saturday and we are anxiously awaiting the holy grail of builds, that with env_map and env_map_alpha enabled in openGL.... :shaking:
-
I would like to remind taylor that today is saturday and we are anxiously awaiting the holy grail of builds, that with env_map and env_map_alpha enabled in openGL.... :shaking:
Don't I at least get a little time to sleep?? ;)
Builds are going now, check in about an hour or so and you should find it. :)
EDIT: There, happy now?
-
Taylor,
you should know there is no rest for the wicked. ;7
/me bows down before Taylor
WOOT ! This is just as I had hoped ! The effect is subtle, but Oh so nice. Thanks so much for toiling to get this working, your efforts are appreciated !
And it's a hell of a lot different than the Direct3D version (which looked...WRONG.. it was like all the ships were hyper chrome-y and just absolutely unreal, at least, the leviathan was) Much more realistic and just the right amount of reflectivity. Adds alot IMO. I managed to mess up my mod.ini just prior to this and got a shock loading the game expecting env maps and seeing retail ships and textures (I've forgotten just how much you guys have improved the game... amazing)
My weekend, and my freespace 2 installation, is now complete. I assume this has hit CVS as of today right ? All that remains is for Redmenace to build some CPU instruction set optimized versions and test to see if there is any difference between them. I'm psyched. Freespace SCP OpenGL FTW !
Oh, and Freespace SCP is working without any performance issues in Windows Vista while it is running aero glass. Which is good, because they almost considered crippling OpenGL for a while there, and I'm glad it didnt' happen.
*edit* and I assume that 'cubemap.vp' goes in the mediavps right ? Or is it supposed to reside in the root directory ?
-
*edit* and I assume that 'cubemap.vp' goes in the mediavps right ? Or is it supposed to reside in the root directory ?
Doesn't really matter. That VP just provides a default envmap, in case your video card can't create them (which will be an issue for some). I hope that the default envmap will be included in the next MediaVPs (even if it's not the particular one in that VP) so that the extra VP isn't needed. The VP isn't even required, but since without it you have to actually play a mission before envmaps show up in the techroom, I decided to distribute the VP.
EDIT: Oh and the hyper reflective ships can still be a problem here but it's not the code, it's the texture maps. When you use -alpha_env it uses the alpha of the map to decide how reflective the ship is. I check for this and if the map doesn't have an alpha channel then it uses non-alpha_env to render. The problem is that some maps are still DXT5, which has an alpha channel, but the map doesn't actually have alpha. These maps will have the hyper-chrome effect to them. You have my MediaVPs which already have all fixed maps, but if you used the official ones then you would still get issues with some ships.
-
Ah, okay then. that explains quite a bit.
-
When are we going to find out what this bigger better secret is?
-
When are we going to find out what this bigger better secret is?
As soon as you find it. :)
And it's not difficult to find actually. Depending on the cmdline options in use you will see it within the first 5 minutes of starting the game.
-
umm, is it something to do with the engine flares... they look different somehow, better... ?
-
umm, is it something to do with the engine flares... they look different somehow, better... ?
Nope. By the time you get in mission you've missed your first opportunity to view it.
I said it was minor and that most people wouldn't even notice it. That would mean that it's something you don't normally pay much attention to, and may turn it off.
-
ummmmmmmmmmm......................... can you give us a hint ? :drevil:
-
@Taylor
i guess you want some feedback on the env-mapping, aren´t you?
First of all. Thx man, i´ve waited long for this. After Bob implemented env-mapping in D3D, i´d never wanted to miss it again. But OGL is much faster and the lighting is also much better. Now there´s really no reason to stick to D3D. The effect in OGL is more subtle than in D3D. I don´t use the alpha env-mapping, ´cause it looks weird in some situations.
I suggest to make it a bit less subtle, ´cause sometimes it is really hard to notice (and that´s really a shame after all this hard work you put in this feature).
I would also suggest to implement the "popcorn"-effect, mentioned in this thread:
http://www.hard-light.net/forums/index.php/topic,39221.0.html
That would create the PERFECT BUILD.
Keep it on. Thank you!!! :yes:
-
No, leave the effect the way it is. It should be subtle, you don't want the ships reflecting all over the place, it would only be noticable in certain angles/lighting situations anyway.
Also the alpha env mapping makes the ships with the old black style cockpits look great, by making their cockpits shine.
Still trying to figure out what the super secret add on is...
-
.......... it would only be noticable in certain angles/lighting situations anyway.
Right, that´s why i wrote "a bit less subtle". It´s too nice to be hardly noticed. ;)
-
I too think the effect should be toned up.
-
lol, well taylor, you knew this would happen. This is why perhaps you should have left parameter passing for this feature in so that people could tweak it.
-
People ask that it be more pronounced so that they can say "oh look, environment mapping" but then get used to it and expect it to be that way. It should be very subtile, especially given the way most of the FS ships are beaten to hell and back. And then there's the fact that this isn't even tweaked in the game code, but is actually a media issue entirely. Lower or raise the intensity of the alpha channel on a map and presto, you've changed the reflectivity.
-
People ask that it be more pronounced so that they can say "oh look, environment mapping" but then get used to it and expect it to be that way. It should be very subtile, especially given the way most of the FS ships are beaten to hell and back. And then there's the fact that this isn't even tweaked in the game code, but is actually a media issue entirely. Lower or raise the intensity of the alpha channel on a map and presto, you've changed the reflectivity.
QFT
-
...especially given the way most of the FS ships are beaten to hell and back.
Hadn't thoght of that, your right, it is about right.
-
Env mapping = Sexy. Great job on it!
-
lol, well taylor, you knew this would happen. This is why perhaps you should have left parameter passing for this feature in so that people could tweak it.
I did keep a copy of the cmdline.cpp file which has the options in it, just in case. The problem is that the intensity of the effect depends on the textures. Maps that aren't as good will look too intense, ones that were trying to fix the D3D version will be too dull. I tested every mod/model/texture I could get my hands on before settling on the current levels and that just worked the best. Everyone who has tested it so far has liked where it is now, though I didn't actually expect that, so I'm resistant to chaning the values now.
It may turn out that putting the scale cmdline options back in is a good idea but I didn't want to do that until after it had been in use for a little while. I'm not going to change the defaults, but I may add the options back sometime next week.
Still trying to figure out what the super secret add on is...
Ok, one more hint: What act is closely tied to a food item, that when properly prepared, is consumed from a small bucket?
If you can't get it now, I give up.
-
This thread has gone seriously off topic (thinking it needs a new name: Taylor's Env Mapping Build, (Was : Updated HUD))
Your build has also provided me with some performance improvements, Taylor. Not in FPS, but there is no more pausing / hitching behavior AT ALL for me any longer on my abused 5600 Ultra. It had already been seriously mitigated by the DDS mediavps_t, but now it is really completely gone. Although this card is a 4 x 1 card that has terrible DX9 and Shader performance due to Nvidia's royal cock-up, it actually performs extremely well in OpenGL, where it doesn't suffer anywhere near as serious problems as it does in Direct X. In fact I'm able to run playable frame rates with 8xS AA and 8x AF which is pretty outrageous, (but it looks great)
-
lol, well taylor, you knew this would happen. This is why perhaps you should have left parameter passing for this feature in so that people could tweak it.
Yeah, thats the reason for feedback. And thats also the way things work in an community. Just in case you forgot this, neo.
-
I think I figured out what the super secret addition is:
Save Render Targets to File? (under Dev Tools, of the launcher flags)
-
I think I figured out what the super secret addition is:
Save Render Targets to File? (under Dev Tools, of the launcher flags)
Nope. That's just a standard part of the envmapping support that I added. This is for modders to save the envmaps generated by the game to file. Then they can enhance/compress them and distribute the files as part of the mod/mission data. There is a new mission flag ("$Environment Map:") which lets them specify a file to use for the envmap.
When you enable that option (-save_render_target) then it will save the generated envmaps, and other static render-targets, to data/cache/ so that you can pick over them later. So when the ship/weapon select screens are modified to use the render-to-texture support to turn 3D models into icons, the mod maker can save those images and use them as the icons for the ship/weapon. And since the OpenGL extension required to make envmaps in-game isn't going to be supported for everyone, this lets them still get to use envmaps since they already exist.
As an added benefit of this, it can save a ton of memory. When an envmap is created by the game it's uncompressed. With the default settings that means that the envmap is using about 6megs of memory. But if the mission maker was kind enough to distribute an envmap which was already created, and compress it with DXT1, then it would need only 1meg of memory. Plus the saved envmap could be enhanced to highlight certain portions or some parts even removed. Hell, you could make a totally new envmap from scratch, or from images downloaded from NASA, and use that instead of relying on the game to do it for you.
-
so i could also put in say, a large static ship, or meshes that otherwise wouldnt be put in by the game, but that would only look right if said mesh didn't move and was a good distance away, and i'd just have to draw it in right.
sounds good.
-
Found the feature. Very nice :)
-
Taylor, I hate to jump right to the bad, but your FRED build isn't displaying backgrounds.
-
Taylor, I hate to jump right to the bad, but your FRED build isn't displaying backgrounds.
Hmm, I never even tested it. Mainly just included it to make sure I didn't break building for anyone else. If you are using -env with FRED2 then try removing that and see if it makes a difference. Since -env never worked with FRED2 before I did kind of question whether it was safe or not. The other change that could be causing the problem (and is more likely) is that I removed all of the view/projection matrix setups from the starfield code. It's a serious performance drain to set and unset that stuff so many different times per frame.
FRED2 likely just doesn't have the base view/projection matrix setup before calling stars_draw() and that would cause it to render incorrectly. Phreak would probably know that better than me, but the fix should be simple enough. I think that a couple of HTL functions were added for FRED2 (fred_enable_htl() and fred_disable_htl()) so any calls to stars_draw() just need to be wrapped in that. If neither Phreak nor karajorma do that before I get the chance I'll take care of it in a couple of days. Feel free to file a Mantis bug on it though, I bet that karajorma is planning to release a new FRED2 build soon anyway.
-
Its not the stars. If I adjust the star number slider, I can see it having an effect. It will also display any suns in the mission, it will however refuse to display any nebulae or skyboxes. You can sometimes see a very thin crescent at the edge of the viewing window, which may be a distorted render of the background. This occurs whether -env is enabled in the shortcut or not. Also, the debug build (FRED) is giving me some weird errors for missions I've been working on for TBP:
Assert: GL_modelview_matrix_depth == 2
File: c:\documents and settings\taylor richards\desktop\fs2_open.pre\code\graphics\gropengltnl.cpp
Line: 1092
Assert: GL_htl_projection_matrix_set
File: c:\documents and settings\taylor richards\desktop\fs2_open.pre\code\graphics\gropengltnl.cpp
Line: 975
In fact, even if I start from scratch, and attempt to place a nebulae (in debug FRED), I'll get the first error message.
Can you translate these?
-
Isn't that an old FRED bug that was there for months and got knocked out not long ago? :shaking:
-
Its not the stars. If I adjust the star number slider, I can see it having an effect.
The stars themselves aren't HTL which is why they work fine. But stars_draw() will draw the skyboxes, background nebula, subspace, suns, and the stars. It's only the parts that are rendered using HTL that will break. Those Assert() messages are just confirming the problem, that the view and projection matrix isn't set.
-
Isn't that an old FRED bug that was there for months and got knocked out not long ago? :shaking:
I don't think so. FRED is asserting with this message when I try to open some earlier missions I made for SoR with this error.
Assert: GL_htl_projection_matrix_set
File: d:\c++\freespace\fs2_open\code\graphics\gropengltnl.cpp
Line: 975
and it didn't do that last time I tried the mission (which must be a couple of weeks back). I'll probably take a look-see what's causing that at some point but I've not poked around in the graphics code at all yet so I probably won't have a clue what's going on there.
-
I'll probably take a look-see what's causing that at some point but I've not poked around in the graphics code at all yet so I probably won't have a clue what's going on there.
... I think that a couple of HTL functions were added for FRED2 (fred_enable_htl() and fred_disable_htl()) so any calls to stars_draw() just need to be wrapped in that. ...
-
Didn't help. I'm not really any the wiser about what the code is doing after looking at it and I'm really loathe to alter code when I don't have a clue what it's doing.
-
Didn't help. I'm not really any the wiser about what the code is doing after looking at it and I'm really loathe to alter code when I don't have a clue what it's doing.
Hmm. I thought that just changing:
if ( Bg_bitmap_dialog ) {
stars_draw( Show_stars, 1, Show_stars, 0, 0 );
} else {
stars_draw( Show_stars, Show_stars, Show_stars, 0, 0 );
}to:
fred_enable_htl();
if ( Bg_bitmap_dialog ) {
stars_draw( Show_stars, 1, Show_stars, 0, 0 );
} else {
stars_draw( Show_stars, Show_stars, Show_stars, 0, 0 );
}
fred_disable_htl();in fredrender.cpp:1777 should fix it. If that's not what you did then try it and see what happens. I don't want to make that change in CVS until I can actually test it, and that isn't likely to happen until tomorrow night sometime. If that turns out not to help any then I'm not really sure what the issue is. I don't remember changing anything else that could have caused this particular error.
-
Doing that brings back the backgrounds when the background editor is open but stars_draw is also called several times from starfield.cpp and I wasn't certain if those calls also needed patching or if the problem lies elsewhere.
-
Doing that brings back the backgrounds when the background editor is open but stars_draw is also called several times from starfield.cpp and I wasn't certain if those calls also needed patching or if the problem lies elsewhere.
It only needs to be around the stars_draw() call itself and never in starfield.cpp. That's what was wrong with it in the first place (the calls were in starfield.cpp). And stars_draw() is never called in starfield.cpp so that's not even an issue. It's basically a call-all, that one function will call the other stars_draw_*() functions based on what you actually intend to draw. The individual stars_draw_*() calls shouldn't be used outside of starfield.cpp except in the rarest of instances.
We only ever need to be setting the view/projection martix once per frame if at all possible. It's a rather large performance hit to call it more times than you need. Previously is was called around 8 times per frame in the regular game, now it's 3, and that's just because it's a pain to get it lower than that. At one time stars_draw() did have to be called outside of a view/projection matrix setup, but that bug was fixed 9 or 10 months ago so there was no longer a reason to keep it a performance drain.
-
Yeah. I double checked and you're right about that. I hadn't looked too carefully at what grep was turning up. :)
Oh well what I've got at least lets people see the background when editing it and gets rid of the assertions so at least it's an improvement on the current situation.
-
Oh well what I've got at least lets people see the background when editing it and gets rid of the assertions so at least it's an improvement on the current situation.
I didn't think you were too clear about when the backgrounds show up, otherwise I had an extra paragraph on my last post about that. I took it out to avoid making myself look too stupid, the FRED code isn't exactly something I like to fiddle with. :)
It really shouldn't matter whether you are editing or not as to whether the backgrounds work. The only real difference between the two is that if you are editing then the backgrounds always show. When you aren't editing then it's hooked into the "Show backgrounds" (or whatever the menu item is) as to whether it shows them or not. Try to toggle that option just in case it's off, or thinks that it is anyway. As far as I know that one thing is all that's different for how the starfield draws in FRED, but I haven't looked that closely at the code in a while so I could be off on that. I'm just going from memory when I upgraded the starfield bitmap code a while ago.
-
Yeah. It turned out that was the problem. At some point backgrounds had been switched off on my debug copy of FRED. I suppose I didn't spot that cause I don't have backgrounds on the test missions I usually make. Oh well I'll submit the changes to CVS then and build a copy of FRED later today.
-
Still trying to figure out what the super secret add on is...
Ok, one more hint: What act is closely tied to a food item, that when properly prepared, is consumed from a small bucket?
Um...
The only thing I can think of is a popsicle... you know, those little homemade ones where you pour juice into a cup and stick it in the freezer. And you suck on popsicles... so are you saying your code sucks? :wtf:
If you can't get it now, I give up.
No you don't. Eventually, you'll make it easier to guess (or just give it away via email). Coders can't bear, for very long, to have their cool stuff go unnoticed. ;)
-
My PMs have'nt turned up anything so far, except for a cryptic message regarding the age of the feature.
-
I have no clue what it was...
-
The only thing I could possibly think of that even remotely fits that clue would be something involving "Vasudanswuvfishes," but that makes absolutely no sense...
...or does it make so much sense that it could drive us mad? :p
-
No, i will drive you mad, when i rave about hdrish combined with this new feature, and taking screenshots, and starting a massive new thread :drevil:
Oh god, i'm one happy hdrish accolite, with hull reflections :lol:
-
Still trying to figure out what the super secret add on is...
Ok, one more hint: What act is closely tied to a food item, that when properly prepared, is consumed from a small bucket?
Um...
The only thing I can think of is a popsicle... you know, those little homemade ones where you pour juice into a cup and stick it in the freezer. And you suck on popsicles... so are you saying your code sucks? :wtf:
If you can't get it now, I give up.
No you don't. Eventually, you'll make it easier to guess (or just give it away via email). Coders can't bear, for very long, to have their cool stuff go unnoticed. ;)
Wings? (as in, Chicken)
-
The only thing I can think of is a popsicle...
Popcorn actually, like you eat when you go to ... ;)
I'm assuming that many people have actually seen it, and just not realized that it's different. Now that makes me a happy, happy man (as it was the intent to go largely unnoticed). :D
-
Ha! And here I was scouring the particle code, and trying creative ways of running away ('popcorn' and 'chicken' respectively). :lol: Very cool feature, now that I figured it out. Though it is particularly easy to miss if the files in question have been deleted, or replaced ;)
-
The clue wasn't actually about popcorn, but one of things that you tend to be doing when you eat it. I phrased the clue that way to keep everyone from easily guessing, and I think it was successful. :)
Oh, and I do have some particle code changes coming up real soon. It's faster, dynamic, less error prone, and, well, a couple of "things" are fixed now. ;)
-
Yeah. I had figured that people might guess it from that to be honest. Then again I was in on the secret.
It's not like I haven't blatantly stated the answer the one place it does matter though. I can edit it back the way it was if you want but I figured there was no point in letting people who are actually affected by the change suffer :)
-
The only thing I can think of is a popsicle...
Popcorn actually, like you eat when you go to ... ;)
I'm assuming that many people have actually seen it, and just not realized that it's different. Now that makes me a happy, happy man (as it was the intent to go largely unnoticed). :D
I've not played FS2 for that long I didn't realise it was the new addition to this build. I just saw it and thought 'lovely'. Because it is lovely.
And then it crashed. I think, though, because I had the high-memory effects on and blew up an Orion in an asteroid field. Or because (hope not) my new fighter model was borked.
-
MVEs? :nervous:
What... popcorn as in partical effects, what the hell?
-
Oh crap. And I was in on it, too. Guess I have trouble connecting the dots. Or maybe I was hoping for yet another feature taylor hasn't told us about yet. :D
-
Oh crap. And I was in on it, too.
:lol:
Or maybe I was hoping for yet another feature taylor hasn't told us about yet. :D
There are, perhaps, a couple new things in the works. :drevil:
-
the suspense is killing me. seriously, i've got suspense-cancer
need... cylon fetal blood...... *collapses*
-
the suspense is killing me. seriously, i've got suspense-cancer
need... cylon fetal blood...... *collapses*
Well, he's gone. Anyone want to give me a hand rifling through his wallet?
-
i'm a college student
there's nothing there
-
I just got this image of a dead body lifting its head up and saying that.
-
You too? :wakka: