Reviving Vega Strike
-
- Elite
- Posts: 8014
- Joined: Fri Sep 05, 2003 4:03 am
- Location: Montreal
- Contact:
Re: Reviving Vega Strike
There's /vegastrike, which is the engine.
There's /data, which is the game.
There's /masters, which contains un-compressed originals of the textures, etceteras.
And I think there's others, like branches and whatnot.
EDIT:
If your question is whether they are technically under a common revision, or are
separate repositories, that I don't know.
There's /data, which is the game.
There's /masters, which contains un-compressed originals of the textures, etceteras.
And I think there's others, like branches and whatnot.
EDIT:
If your question is whether they are technically under a common revision, or are
separate repositories, that I don't know.
Latest version of Cinemut Opaque
Latest version of LaGrande noodleworks (scroll down).
An evolving La Grande How-To...
The non-working, but latest, CineMut test_bike
PU (Privateer: Parallel Universe's Home). WC or Privateer Drayman for you?
WCpedia --The Wing Commander Encyclopedia-- From Angel Deveraux through Belisarius to Zachary Banfeld...
WC Nexus forum, the Moonbase Tycho of WC fans.
Latest version of LaGrande noodleworks (scroll down).
An evolving La Grande How-To...
The non-working, but latest, CineMut test_bike
PU (Privateer: Parallel Universe's Home). WC or Privateer Drayman for you?
WCpedia --The Wing Commander Encyclopedia-- From Angel Deveraux through Belisarius to Zachary Banfeld...
WC Nexus forum, the Moonbase Tycho of WC fans.
-
- Developer
- Posts: 2150
- Joined: Mon Apr 23, 2007 1:17 am
- Location: Pennsylvania
- Contact:
Re: Reviving Vega Strike
Well, only the project admins of the sourceforge project can grant svn write permissions. I dont have the powers.
so you're looking at trying to get hellcat, jacks, or ace to wake up for a bit.
either way.
Are the cubemap dds files replacing the old backgrounds files? or in addition to them?
I ask because while, it's rare to nearly unthinkable that a user would be trying to play VS on a card without DDS support, my software decompressor needs to be edited to handle dealing with cubemapped dds files.
Also, i haven't looked yet, but quality settings dictate what mipmap we start reading from the dds files. High quality we read all of them, but at lower qualities we choose the 1st mipmap or second. This also needs special care when dealing with cubemaps as they would entail special offsets for each face.
in any case, since this data update is so huge, I would suggest double checking that everything is where it needs to be, and that you dont have any stragler changes other than the specific set you're going to commit. Fixing massive svn commits sucks, and i bet sf.net doesn't like it either.
I'm hoping cubemaps allows some sort of performance gain and not a regression. Is it backwards compatible after cubemaps are added to use non-cubemap backgrounds? Would there be any reason to need that compatibility?
While i'm talking about textures. We need to re-think how vs gets pkged.
Basically, the way we have it now, you get the high quality textures off the bat, you have no choice. Low quality is just a mipmap of those. I'm thinking we need to have an auto-mated way of when it comes time to release, take the mipmaps and slplit them into new dds files and generate a _base_ data dir to tarball/zip up. And then send along the full quality dds to another data dir to be named "hqtextures". This second one can use my hqtextures method to supersede the base data dir if the user has it installed, while allowing distros and people to try out vs without downloading 1GB of files. Hopefully by making the base data pkg lower quality as the default, we can actually get our newer versions pkged by various distros. It should bring the size down significantly, and they can still give the user a prompt during installation if they want to download the high quality texture pack.
It would take up more hdd space to have it that way, but hdd space is much more easy to come by these days than bandwidth still. And distros dont like 1GB pkgs.
Also, we have an issue with atmospheres again, they are showing up as white and not nicely blended. I see this with a clean ~/.vegastrike from a fresh install with vssetup to use the nicest shader.
so you're looking at trying to get hellcat, jacks, or ace to wake up for a bit.
either way.
Are the cubemap dds files replacing the old backgrounds files? or in addition to them?
I ask because while, it's rare to nearly unthinkable that a user would be trying to play VS on a card without DDS support, my software decompressor needs to be edited to handle dealing with cubemapped dds files.
Also, i haven't looked yet, but quality settings dictate what mipmap we start reading from the dds files. High quality we read all of them, but at lower qualities we choose the 1st mipmap or second. This also needs special care when dealing with cubemaps as they would entail special offsets for each face.
in any case, since this data update is so huge, I would suggest double checking that everything is where it needs to be, and that you dont have any stragler changes other than the specific set you're going to commit. Fixing massive svn commits sucks, and i bet sf.net doesn't like it either.
I'm hoping cubemaps allows some sort of performance gain and not a regression. Is it backwards compatible after cubemaps are added to use non-cubemap backgrounds? Would there be any reason to need that compatibility?
While i'm talking about textures. We need to re-think how vs gets pkged.
Basically, the way we have it now, you get the high quality textures off the bat, you have no choice. Low quality is just a mipmap of those. I'm thinking we need to have an auto-mated way of when it comes time to release, take the mipmaps and slplit them into new dds files and generate a _base_ data dir to tarball/zip up. And then send along the full quality dds to another data dir to be named "hqtextures". This second one can use my hqtextures method to supersede the base data dir if the user has it installed, while allowing distros and people to try out vs without downloading 1GB of files. Hopefully by making the base data pkg lower quality as the default, we can actually get our newer versions pkged by various distros. It should bring the size down significantly, and they can still give the user a prompt during installation if they want to download the high quality texture pack.
It would take up more hdd space to have it that way, but hdd space is much more easy to come by these days than bandwidth still. And distros dont like 1GB pkgs.
Also, we have an issue with atmospheres again, they are showing up as white and not nicely blended. I see this with a clean ~/.vegastrike from a fresh install with vssetup to use the nicest shader.
Ed Sweetman endorses this message.
-
- Elite
- Posts: 8014
- Joined: Fri Sep 05, 2003 4:03 am
- Location: Montreal
- Contact:
Re: Reviving Vega Strike
Okay, I guess I'll give that a shot.safemode wrote:Well, only the project admins of the sourceforge project can grant svn write permissions. I dont have the powers.
so you're looking at trying to get hellcat, jacks, or ace to wake up for a bit.
Replacing.Are the cubemap dds files replacing the old backgrounds files? or in addition to them?
Wouldn't the (updated) driver for a card without hardware dxt support decompress on the fly on its own?I ask because while, it's rare to nearly unthinkable that a user would be trying to play VS on a card without DDS support, my software decompressor needs to be edited to handle dealing with cubemapped dds files.
I would suggest throwing out quality settings considerations. It would complicate shaders, since shaders use texture(Cube)Lod() specifying the mip level, which calculation is (not in the current shader, but will be) precisely calculated for the blurring angle needed for a given shininess, which has to agree with the shininess value used in Phong shading. This calculation assumes a 1024 cubemap. If we allow settings to change that, then I will need the setting to be passed to the shader so as to make appropriate adjustment of mip bias calculations.Also, i haven't looked yet, but quality settings dictate what mipmap we start reading from the dds files. High quality we read all of them, but at lower qualities we choose the 1st mipmap or second. This also needs special care when dealing with cubemaps as they would entail special offsets for each face.
I think this complication is unwarranted, because a 1024 dds cubemap only takes up 4 megs of video ram; so it's not going to be the end of the world for anybody's hardware; and it's only one texture, and a very special one. Quality settings for model textures are fine, as there are many models in a scene, so you rip a full benefit; but there's only one cube map in a scene, so we shouldn't complicate environment mapping with quality settings, for the sake of gaining a few megs, IMO.
Fully aware of that. No; that's why I never asked anyone to commit the cubemaps before; I wasn't sure my CubeMapGen settings were the best. But I spent many days working on the math for shininess and phong and lod biases and whatnot, and calculated the needed settings exactly. This post and the next one are a summary of the work and conclusions:in any case, since this data update is so huge, I would suggest double checking that everything is where it needs to be, and that you dont have any stragler changes other than the specific set you're going to commit. Fixing massive svn commits sucks, and i bet sf.net doesn't like it either.
http://wcjunction.com/phpBB2/viewtopic. ... 2192#22192
So, last week I re-converted all VS cubemaps, from the /masters repo, using the new, final settings.
Additionally, I used input and output de-gammas of 2.0, which is something I had neglected in the original conversions I did about a year ago (I wasn't aware of gamma issues back than; now I am thanks to Klauss).
Additionally, I corrected brightness and contrast of some of the backgrounds. This is something I had intended NOT to do, but some of them were just too dark, or too lacking in contrast.
Finally, in two cases the master backgrounds had noticeable pixelation in some areas, so for them I increased the pre-filtering diameter to smooth them a little bit. I'm very happy with the result, and can assure you no change will be needed until CineMut2, which a long way away; and will necessitate changes to CubeMapGen (i.e.: hacking it). (CubeMapGen is wonderful, but contains several BIG design errors. For instance, filter types include cone, disc, cosine and gaussian... None of which is what's needed; what's needed is cos(a)^x, where x is the shininess power corresponding to the desired filter angle. They also have an "edge fix-up" method that is purely a hack; doesn't address the corner issue's root, which is that at any mip level of size s, 90 degrees should be spanned not by s but by (s-1). And a few other things...).
So, eventually I will produce MUCH better cubemaps; but not any time soon.
Definitely a gain, since what we presently have is two separate systems: one for painting backgrounds (using cubes) and one for environment mapping (using spheremaps); that's a grand total of 7 texture files being read; all of which will now be integrated, and loaded as a single file. Using non-cubemap backgrounds is compatible if you keep the code around; but I'm not sure it will ever be used. I'd just get rid of all that spheremap crap.I'm hoping cubemaps allows some sort of performance gain and not a regression. Is it backwards compatible after cubemaps are added to use non-cubemap backgrounds? Would there be any reason to need that compatibility?
No ideas from me.While i'm talking about textures. We need to re-think how vs gets pkged.
Basically, the way we have it now, you get the high quality textures off the bat, you have no choice. Low quality is just a mipmap of those. I'm thinking we need to have an auto-mated way of when it comes time to release, take the mipmaps and slplit them into new dds files and generate a _base_ data dir to tarball/zip up. And then send along the full quality dds to another data dir to be named "hqtextures". This second one can use my hqtextures method to supersede the base data dir if the user has it installed, while allowing distros and people to try out vs without downloading 1GB of files. Hopefully by making the base data pkg lower quality as the default, we can actually get our newer versions pkged by various distros. It should bring the size down significantly, and they can still give the user a prompt during installation if they want to download the high quality texture pack.
It would take up more hdd space to have it that way, but hdd space is much more easy to come by these days than bandwidth still. And distros dont like 1GB pkgs.
I just wonder, though, if hqtextures was a good idea.
Some people read "HQ" and jump on it, thinking "I want the BEST graphics", and have no idea how big a price in video memory they are paying for how little benefit. Then they post to User Help because the game barely runs. There goes another gig of wasted bandwidth...
To me, this is "optionitis", wanting to give options, options, and more options, and at any cost.
As a user, I hate options. They make me have to think. That's why more people go to fast foods than to regular restaurants: At a restaurant, the waiters ask too many damned questions; I just say to them "any way YOU like it; I don't want to think; thank you."
Damn. I haven't touched anything. No idea why that could be. I thought they were working fine last time I looked. I'll try right now.Also, we have an issue with atmospheres again, they are showing up as white and not nicely blended. I see this with a clean ~/.vegastrike from a fresh install with vssetup to use the nicest shader.
Latest version of Cinemut Opaque
Latest version of LaGrande noodleworks (scroll down).
An evolving La Grande How-To...
The non-working, but latest, CineMut test_bike
PU (Privateer: Parallel Universe's Home). WC or Privateer Drayman for you?
WCpedia --The Wing Commander Encyclopedia-- From Angel Deveraux through Belisarius to Zachary Banfeld...
WC Nexus forum, the Moonbase Tycho of WC fans.
Latest version of LaGrande noodleworks (scroll down).
An evolving La Grande How-To...
The non-working, but latest, CineMut test_bike
PU (Privateer: Parallel Universe's Home). WC or Privateer Drayman for you?
WCpedia --The Wing Commander Encyclopedia-- From Angel Deveraux through Belisarius to Zachary Banfeld...
WC Nexus forum, the Moonbase Tycho of WC fans.
-
- Developer
- Posts: 2150
- Joined: Mon Apr 23, 2007 1:17 am
- Location: Pennsylvania
- Contact:
Re: Reviving Vega Strike
Video cards which do not support the s3 compression within the dds file will fail. They simply wont work without the software decompressor within the game to decompress the dds file. I dont know of any video card within the last half decade that this would happen with, but a few years ago it was a problem with integrated graphic chipsets. *caugh*intel*caugh*chuck_starchaser wrote:Wouldn't the (updated) driver for a card without hardware dxt support decompress on the fly on its own?I ask because while, it's rare to nearly unthinkable that a user would be trying to play VS on a card without DDS support, my software decompressor needs to be edited to handle dealing with cubemapped dds files.
sounds good.Fully aware of that. No; that's why I never asked anyone to commit the cubemaps before; I wasn't sure my CubeMapGen settings were the best. But I spent many days working on the math for shininess and phong and lod biases and whatnot, and calculated the needed settings exactly. This post and the next one are a summary of the work and conclusions:in any case, since this data update is so huge, I would suggest double checking that everything is where it needs to be, and that you dont have any stragler changes other than the specific set you're going to commit. Fixing massive svn commits sucks, and i bet sf.net doesn't like it either.
http://wcjunction.com/phpBB2/viewtopic. ... 2192#22192
So, last week I re-converted all VS cubemaps, from the /masters repo, using the new, final settings.
Additionally, I used input and output de-gammas of 2.0, which is something I had neglected in the original conversions I did about a year ago (I wasn't aware of gamma issues back than; now I am thanks to Klauss).
Additionally, I corrected brightness and contrast of some of the backgrounds. This is something I had intended NOT to do, but some of them were just too dark, or too lacking in contrast.
Finally, in two cases the master backgrounds had noticeable pixelation in some areas, so for them I increased the pre-filtering diameter to smooth them a little bit. I'm very happy with the result, and can assure you no change will be needed until CineMut2, which a long way away; and will necessitate changes to CubeMapGen (i.e.: hacking it). (CubeMapGen is wonderful, but contains several BIG design errors. For instance, filter types include cone, disc, cosine and gaussian... None of which is what's needed; what's needed is cos(a)^x, where x is the shininess power corresponding to the desired filter angle. They also have an "edge fix-up" method that is purely a hack; doesn't address the corner issue's root, which is that at any mip level of size s, 90 degrees should be spanned not by s but by (s-1). And a few other things...).
So, eventually I will produce MUCH better cubemaps; but not any time soon.
Dont forget, VS is a game engine in addition to a game. so while our game may move to cubemaps immediately, other games which may want to take advantage of other updates in the engine, may not be so quick to move to cubemaps. This is why backwards compatibility is so important. We risk alienating all other mods/games by making leaps in supported datasets. It's likely we wont be wanting to get rid of the code support for spheremaps anytime soon, and it's important we make sure it still works. At least with the non-updated /data repo. It doesn't have to work with our /data repo once cubemaps are in and the shaders replaced, obviously.Definitely a gain, since what we presently have is two separate systems: one for painting backgrounds (using cubes) and one for environment mapping (using spheremaps); that's a grand total of 7 texture files being read; all of which will now be integrated, and loaded as a single file. Using non-cubemap backgrounds is compatible if you keep the code around; but I'm not sure it will ever be used. I'd just get rid of all that spheremap crap.I'm hoping cubemaps allows some sort of performance gain and not a regression. Is it backwards compatible after cubemaps are added to use non-cubemap backgrounds? Would there be any reason to need that compatibility?
the thing with hqtextures wasn't to give more options for the user, but to the pkger's for distros. They dont want to pkg up a game that is almost 1GB. They have other complaints too but i forget them. Either way, hqtextures offers _nothing_ over what you get now in terms of quality, performance, etc. What we change is the plain /data repo into a low quality (minus top level mipma) pkg. Then count on the user's need to always want the best to simply say 'Yes' to downloading the optional hqtextures pack. This idea was soley created for the pkg maintainers.No ideas from me.While i'm talking about textures. We need to re-think how vs gets pkged.
Basically, the way we have it now, you get the high quality textures off the bat, you have no choice. Low quality is just a mipmap of those. I'm thinking we need to have an auto-mated way of when it comes time to release, take the mipmaps and slplit them into new dds files and generate a _base_ data dir to tarball/zip up. And then send along the full quality dds to another data dir to be named "hqtextures". This second one can use my hqtextures method to supersede the base data dir if the user has it installed, while allowing distros and people to try out vs without downloading 1GB of files. Hopefully by making the base data pkg lower quality as the default, we can actually get our newer versions pkged by various distros. It should bring the size down significantly, and they can still give the user a prompt during installation if they want to download the high quality texture pack.
It would take up more hdd space to have it that way, but hdd space is much more easy to come by these days than bandwidth still. And distros dont like 1GB pkgs.
I just wonder, though, if hqtextures was a good idea.
Some people read "HQ" and jump on it, thinking "I want the BEST graphics", and have no idea how big a price in video memory they are paying for how little benefit. Then they post to User Help because the game barely runs. There goes another gig of wasted bandwidth...
To me, this is "optionitis", wanting to give options, options, and more options, and at any cost.
As a user, I hate options. They make me have to think. That's why more people go to fast foods than to regular restaurants: At a restaurant, the waiters ask too many damned questions; I just say to them "any way YOU like it; I don't want to think; thank you."
Ideally, we would have no textures at all in /data. /data would be scripts. The codebase supports mods implicitly, that's what hqtextures is. What we then would have is texture packs that can be downloaded that offer the textures in various qualities as per what maintainers really want. Something to just get the game running (low quality, locally stored and pkged) then something that makes it really good (high quality, remotely pulled during installation). No binaries would be in /data, they'd all be in some vegastrike bin dir (in windows land or /usr/games or bin in unix land). textures could then go into /usr/share/vegastrike and the data scripts can go in /usr/lib/vegastrike - kinda like how firefox does it's thing.
In any case, hqtextures is a tool for us, it's really transparent to users. It allows you to test new textures for units without overwriting or renaming or moving anything in your /data dir. It's already in the code and triggered via a commented option in vegastrike.config. It's nothing more than a mod really, just a special mod.
Could always be my video card, it's an ancient 6600 series . I double checked to make sure the vanilla trunk had the same effect before and after my commits , so it was present in 12574, and still is in 12577.Damn. I haven't touched anything. No idea why that could be. I thought they were working fine last time I looked. I'll try right now.Also, we have an issue with atmospheres again, they are showing up as white and not nicely blended. I see this with a clean ~/.vegastrike from a fresh install with vssetup to use the nicest shader.
Also, i wonder if we never figured out the bug with jump points being anti-aliased and thus slowing down draws when it is in the main view. Though, the slowdown could be a fundamental flaw in how we represent the jump points. I dont see why if it's just an OSD representation that it needs to be drawn in the 3d space and thus be treated like an object in space. It's like we're trying to treat it as both a physical marker and a virtual marker and it makes no sense. If it's virtual, we shouldn't be flying around it and seeing it from different angles, it should be drawn on the screen in much the same way that the text is drawn on the screen, not as a 3d object in space. If it's physical, then we should create a model and background info regarding it's attributes. one or the other.
Ed Sweetman endorses this message.
-
- Elite
- Posts: 8014
- Joined: Fri Sep 05, 2003 4:03 am
- Location: Montreal
- Contact:
Re: Reviving Vega Strike
Okeydoc; I was just asking. (Owners of intel graphic chips should be punished tho )safemode wrote:Video cards which do not support the s3 compression within the dds file will fail. They simply wont work without the software decompressor within the game to decompress the dds file. I dont know of any video card within the last half decade that this would happen with, but a few years ago it was a problem with integrated graphic chipsets. *caugh*intel*caugh*
Well, PU will instantly move to dds cubemaps; have them all ready. That leaves GG as the only remaining mod; and I don't expect them to have any problem with it. I wrote a tutorial on how to do the conversion using CubeMapGen. It took me about 2 and a half days to convert VS's backgrounds; but that's because they are many. I believe GG only has a handful. CubeMapGen is free, open source, and it's Windows-only but it installs and runs problem-free on Wine. I'd be perfectly willing to convert them for them. No sabottage . Seriously, I can do them for them in an hour or two. Biggest problem for me is I'd have to check out their svn. Here's the settings:Dont forget, VS is a game engine in addition to a game. so while our game may move to cubemaps immediately, other games which may want to take advantage of other updates in the engine, may not be so quick to move to cubemaps.Definitely a gain, since what we presently have is two separate systems: one for painting backgrounds (using cubes) and one for environment mapping (using spheremaps); that's a grand total of 7 texture files being read; all of which will now be integrated, and loaded as a single file. Using non-cubemap backgrounds is compatible if you keep the code around; but I'm not sure it will ever be used. I'd just get rid of all that spheremap crap.
http://wcjunction.com/phpBB2/viewtopic. ... 2329#22329
Tell me about it; we haven't updated the engine with pu for over a year; --ever since the naming conventions infamously changed to .image and .texture. Never got a clear explanation as to which textures needed to be renamed and which didn't.This is why backwards compatibility is so important. We risk alienating all other mods/games by making leaps in supported datasets.
I disagree, for the reasons given above; this is a quick and easy conversion, compared to the disaster that the naming standard change created for us. It's not black or white. Compatibility is good when converting to a new thing, such as a naming standard, is difficult and involves tons of bandwidth after renaming gazillions of files. THAT should have been done mindful about mods. THIS is a one or two hour job to switch over.It's likely we wont be wanting to get rid of the code support for spheremaps anytime soon, and it's important we make sure it still works.
But anyhow, if you want to keep spheremap code; keep it. I just think that a syncronized changeover will be less painful. All that needs to be done, then, is download CubeMapGen, set it right, convert the backgrounds, svn update the shaders, and svn update the engine, and it's done.
Ahhhhhhhh... I gottcha now; I had it all wrong, then; I thought HQtextures contained .PNG's and stuff.the thing with hqtextures wasn't to give more options for the user, but to the pkger's for distros. They dont want to pkg up a game that is almost 1GB. They have other complaints too but i forget them. Either way, hqtextures offers _nothing_ over what you get now in terms of quality, performance, etc. What we change is the plain /data repo into a low quality (minus top level mipma) pkg. Then count on the user's need to always want the best to simply say 'Yes' to downloading the optional hqtextures pack. This idea was soley created for the pkg maintainers.
Sorry; haven't tried yet; will do so.Could always be my video card, it's an ancient 6600 series . I double checked to make sure the vanilla trunk had the same effect before and after my commits , so it was present in 12574, and still is in 12577.
Good points.Also, i wonder if we never figured out the bug with jump points being anti-aliased and thus slowing down draws when it is in the main view. Though, the slowdown could be a fundamental flaw in how we represent the jump points. I dont see why if it's just an OSD representation that it needs to be drawn in the 3d space and thus be treated like an object in space. It's like we're trying to treat it as both a physical marker and a virtual marker and it makes no sense. If it's virtual, we shouldn't be flying around it and seeing it from different angles, it should be drawn on the screen in much the same way that the text is drawn on the screen, not as a 3d object in space. If it's physical, then we should create a model and background info regarding it's attributes. one or the other.
I didn't know about the problem with jump points. I remember a problem with planets causing nvidia gpu's to slow down, and that was because ati prefers loops unrolled with macros, while nvidia prefers the loops to be rolled. Klauss was planning to have two sets of shaders. Not sure where all that is at.
I agree that jump points in VS look ridiculous, being alpha-blended, yet having mechanic-like structure. I remember we once discussed what a wormhole would look like, and how to write a shader to simulate it. Maybe I'll do one up and show you what I was thinking; but right now I have a bit too much on my plate; gotta come up with a half decent shader for ships and stations first. Next will be one for lights and transparencies and engine flames. And I got the llama to finish, which I need to test the shaders. After that, I think a new and improved jump point would be top priority. But I will probably need a new engine feature: putting background rendering through a shader, and adding a (nearest jump) vector to pass to all shaders, so I can make light bend in the vecinity of jumps (as if they were black holes).
Background rendering should have its own shader and technique for many other reasons, anyways.
Latest version of Cinemut Opaque
Latest version of LaGrande noodleworks (scroll down).
An evolving La Grande How-To...
The non-working, but latest, CineMut test_bike
PU (Privateer: Parallel Universe's Home). WC or Privateer Drayman for you?
WCpedia --The Wing Commander Encyclopedia-- From Angel Deveraux through Belisarius to Zachary Banfeld...
WC Nexus forum, the Moonbase Tycho of WC fans.
Latest version of LaGrande noodleworks (scroll down).
An evolving La Grande How-To...
The non-working, but latest, CineMut test_bike
PU (Privateer: Parallel Universe's Home). WC or Privateer Drayman for you?
WCpedia --The Wing Commander Encyclopedia-- From Angel Deveraux through Belisarius to Zachary Banfeld...
WC Nexus forum, the Moonbase Tycho of WC fans.
-
- Elite
- Posts: 8014
- Joined: Fri Sep 05, 2003 4:03 am
- Location: Montreal
- Contact:
Re: Reviving Vega Strike
(Check my last post, first; it got left in the previous page now.)
Donno who changed what; but frankly this looks better to my eyes than the old version that used a second sphere, alpha-blended. Atmospheres are very thin, and don't have a visible layer, like the old method showed.
But we could do infinitely better than we're doing. Klauss wrote a shader for atmospheres with prety good scattering calculations, clouds that cast shadows on the ground and on themselves. I'd like to tackle planets as soon as I'm done with the main shaders. What I'll do is ask Klauss for his planet shader, and maybe split it into a two-pass shader; one for the ground, and one for the atmosphere. The ground shader should have paralax, to show mountains properly. We can do both with a single sphere, since the paralax could simply subtract only for relief rendering; then the atmo would render at the height of the tallest mountains representable. Just a thought.
By the way, your 6600 gpu is ps 3.0; it shouldn't have a problem with anything.
Ah, I see what you mean now; they look like just a white halo around the planet.safemode wrote:Also, we have an issue with atmospheres again, they are showing up as white and not nicely blended. I see this with a clean ~/.vegastrike from a fresh install with vssetup to use the nicest shader.
Donno who changed what; but frankly this looks better to my eyes than the old version that used a second sphere, alpha-blended. Atmospheres are very thin, and don't have a visible layer, like the old method showed.
But we could do infinitely better than we're doing. Klauss wrote a shader for atmospheres with prety good scattering calculations, clouds that cast shadows on the ground and on themselves. I'd like to tackle planets as soon as I'm done with the main shaders. What I'll do is ask Klauss for his planet shader, and maybe split it into a two-pass shader; one for the ground, and one for the atmosphere. The ground shader should have paralax, to show mountains properly. We can do both with a single sphere, since the paralax could simply subtract only for relief rendering; then the atmo would render at the height of the tallest mountains representable. Just a thought.
By the way, your 6600 gpu is ps 3.0; it shouldn't have a problem with anything.
Latest version of Cinemut Opaque
Latest version of LaGrande noodleworks (scroll down).
An evolving La Grande How-To...
The non-working, but latest, CineMut test_bike
PU (Privateer: Parallel Universe's Home). WC or Privateer Drayman for you?
WCpedia --The Wing Commander Encyclopedia-- From Angel Deveraux through Belisarius to Zachary Banfeld...
WC Nexus forum, the Moonbase Tycho of WC fans.
Latest version of LaGrande noodleworks (scroll down).
An evolving La Grande How-To...
The non-working, but latest, CineMut test_bike
PU (Privateer: Parallel Universe's Home). WC or Privateer Drayman for you?
WCpedia --The Wing Commander Encyclopedia-- From Angel Deveraux through Belisarius to Zachary Banfeld...
WC Nexus forum, the Moonbase Tycho of WC fans.
-
- Bounty Hunter
- Posts: 174
- Joined: Wed May 27, 2009 6:38 am
- Location: Fresno, California - United States of America
- Contact:
Re: Reviving Vega Strike
The Jump Points are ridiculously slow on my nVidia Corporation G71 [GeForce 7950 GT], it has to be either a bug or bad design.Also, i wonder if we never figured out the bug with jump points being anti-aliased and thus slowing down draws when it is in the main view. Though, the slowdown could be a fundamental flaw in how we represent the jump points. I dont see why if it's just an OSD representation that it needs to be drawn in the 3d space and thus be treated like an object in space. It's like we're trying to treat it as both a physical marker and a virtual marker and it makes no sense. If it's virtual, we shouldn't be flying around it and seeing it from different angles, it should be drawn on the screen in much the same way that the text is drawn on the screen, not as a 3d object in space. If it's physical, then we should create a model and background info regarding it's attributes. one or the other.
What proprietary tools are required in developing VS?
-
- Elite
- Posts: 8014
- Joined: Fri Sep 05, 2003 4:03 am
- Location: Montreal
- Contact:
Re: Reviving Vega Strike
They seem to be using line-drawing functions of the gpu. That's an anti-aliasing nightmare scenario.JsnMtth wrote:The Jump Points are ridiculously slow on my nVidia Corporation G71 [GeForce 7950 GT], it has to be either a bug or bad design.
None, I don't think:What proprietary tools are required in developing VS?
- Gimp for textures
- Blender for models
- Gedit for text
- Open Office for CSV's
Not sure if people have used proprietary tools to create planetary textures, or space backgrounds, or music, or to process speech files, or...; but nothing proprietary is "required", AFAIK.
Latest version of Cinemut Opaque
Latest version of LaGrande noodleworks (scroll down).
An evolving La Grande How-To...
The non-working, but latest, CineMut test_bike
PU (Privateer: Parallel Universe's Home). WC or Privateer Drayman for you?
WCpedia --The Wing Commander Encyclopedia-- From Angel Deveraux through Belisarius to Zachary Banfeld...
WC Nexus forum, the Moonbase Tycho of WC fans.
Latest version of LaGrande noodleworks (scroll down).
An evolving La Grande How-To...
The non-working, but latest, CineMut test_bike
PU (Privateer: Parallel Universe's Home). WC or Privateer Drayman for you?
WCpedia --The Wing Commander Encyclopedia-- From Angel Deveraux through Belisarius to Zachary Banfeld...
WC Nexus forum, the Moonbase Tycho of WC fans.
-
- ISO Party Member
- Posts: 423
- Joined: Mon Jun 11, 2007 11:54 am
- Location: TX, USA
- Contact:
Re: Reviving Vega Strike
Since I am one of the organizers of the voice work, it would help if I were allowed to commit to data and probably masters.chuck_starchaser wrote:There's /vegastrike, which is the engine.
There's /data, which is the game.
There's /masters, which contains un-compressed originals of the textures, etceteras.
And I think there's others, like branches and whatnot.
Turbo
There are two speeds in combat: stopped, and as fast as you can go. Unless you run into something, going fast keeps you alive more often than stopping.
There are two speeds in combat: stopped, and as fast as you can go. Unless you run into something, going fast keeps you alive more often than stopping.
-
- Elite
- Posts: 8014
- Joined: Fri Sep 05, 2003 4:03 am
- Location: Montreal
- Contact:
Re: Reviving Vega Strike
I think the first step in getting commit access is having an account with SourceForge. I've had an account for a long time, and I just logged in to see if it was still working and it is. I found myself being part of two projects, one of them being Vegastrike. I followed the link, then I went to the people tab, and found myself listed as a developer. I'm not sure if that means I have commit rights to svn already; I never tried; and right this moment I can't think of something to try and commit...
But anyhow, if you're not an SF member you need a name first; then we can collect all the names and send them to JackS or Hellcat or Ace123; so they can do them all at once rather than one at a time, I guess.
EDIT:Now, what the hell is a gnome keyring?
EDIT2:
LOL. I do have commit access; and I never knew. BTW, the problem with svn was that if
you don't edit ~/.subversion/config, it assumes you use GNOME keyring, which is a program
that keeps all your passwords securely stored. You can disable that assumption by adding
the line,
But then it will ask you where to store your password, warning you that it will be done
in plaintext if you say yes; so you have to say no.
You can avoid that by uncommenting the line,
by removing the #...
EDIT3:
So, I'll commit the dds cubemaps tomorrow.
But anyhow, if you're not an SF member you need a name first; then we can collect all the names and send them to JackS or Hellcat or Ace123; so they can do them all at once rather than one at a time, I guess.
EDIT:
Code: Select all
~/vs/masters$ svn ci --username dan_w --message "chuck_starchaser (dan_w) just testing to see if I have commit access"
Password for 'login' GNOME keyring:
svn: Commit failed (details follow):
svn: MKACTIVITY of '/svnroot/vegastrike/!svn/act/<long-string-of-numbers-not-sure-its-safe-to-post>: authorization failed: Could not authenticate to server: rejected Basic challenge (http://vegastrike.svn.sourceforge.net)
~/vs/masters$
EDIT2:
LOL. I do have commit access; and I never knew. BTW, the problem with svn was that if
you don't edit ~/.subversion/config, it assumes you use GNOME keyring, which is a program
that keeps all your passwords securely stored. You can disable that assumption by adding
the line,
Code: Select all
password-stores =
in plaintext if you say yes; so you have to say no.
You can avoid that by uncommenting the line,
Code: Select all
# store-passwords = no
Code: Select all
store-passwords = no
So, I'll commit the dds cubemaps tomorrow.
Last edited by chuck_starchaser on Fri Jan 01, 2010 5:50 am, edited 1 time in total.
Latest version of Cinemut Opaque
Latest version of LaGrande noodleworks (scroll down).
An evolving La Grande How-To...
The non-working, but latest, CineMut test_bike
PU (Privateer: Parallel Universe's Home). WC or Privateer Drayman for you?
WCpedia --The Wing Commander Encyclopedia-- From Angel Deveraux through Belisarius to Zachary Banfeld...
WC Nexus forum, the Moonbase Tycho of WC fans.
Latest version of LaGrande noodleworks (scroll down).
An evolving La Grande How-To...
The non-working, but latest, CineMut test_bike
PU (Privateer: Parallel Universe's Home). WC or Privateer Drayman for you?
WCpedia --The Wing Commander Encyclopedia-- From Angel Deveraux through Belisarius to Zachary Banfeld...
WC Nexus forum, the Moonbase Tycho of WC fans.
-
- Developer
- Posts: 2150
- Joined: Mon Apr 23, 2007 1:17 am
- Location: Pennsylvania
- Contact:
Re: Reviving Vega Strike
True true.chuck_starchaser wrote:Okeydoc; I was just asking. (Owners of intel graphic chips should be punished thosafemode wrote:Video cards which do not support the s3 compression within the dds file will fail. They simply wont work without the software decompressor within the game to decompress the dds file. I dont know of any video card within the last half decade that this would happen with, but a few years ago it was a problem with integrated graphic chipsets. *caugh*intel*caugh*
.image i believe should be 2d targeted images that dont have mipmaps.Tell me about it; we haven't updated the engine with pu for over a year; --ever since the naming conventions infamously changed to .image and .texture. Never got a clear explanation as to which textures needed to be renamed and which didn't.This is why backwards compatibility is so important. We risk alienating all other mods/games by making leaps in supported datasets.
.texture is supposed to be for mipmapped images.
We wanted to move everything to this naming convention because most of the extensions being used for various files had nothing to do with the actual content of the files anymore, and they were confusing the hell out of everyone new coming to the game to work on new images.
Making them generic meant we could change the type of image without having to change the name and never causing any implied type confusion that you would get with .jpg really being a .png or a .png really being a dds file. etc.
It can contain whatever you want. For a while the idea was to make it have uncompressed background images since people complained the backgrounds looked like crap as dds. Or uncompressed 2d images for bases. But i dont think it went that far.Ahhhhhhhh... I gottcha now; I had it all wrong, then; I thought HQtextures contained .PNG's and stuff.the thing with hqtextures wasn't to give more options for the user, but to the pkger's for distros. They dont want to pkg up a game that is almost 1GB. They have other complaints too but i forget them. Either way, hqtextures offers _nothing_ over what you get now in terms of quality, performance, etc. What we change is the plain /data repo into a low quality (minus top level mipma) pkg. Then count on the user's need to always want the best to simply say 'Yes' to downloading the optional hqtextures pack. This idea was soley created for the pkg maintainers.
I really think jump gates should be zones of subspace "weakness" where ships can punch holes to other weak points. Thus, every ship jumping creates it's own jump hole for itself, not some huge jump hole that everyone uses. It doesn't make any sense that you'd have a shared wormhole but no way of organizing it. You'd have chaos. This is why jump gates are done B5 style in those situations. It would also solve the problem of why a ship not yours can't jump through the same wormhole you're opening as it's open. By making wormholes ship-sized for each ship, we dont have to worry about anything else like that. It's one way one ship limitation makes much more sense. In the region you'd just have ships popping in and popping out in different places within that region, rather than just the one.Good points.Also, i wonder if we never figured out the bug with jump points being anti-aliased and thus slowing down draws when it is in the main view. Though, the slowdown could be a fundamental flaw in how we represent the jump points. I dont see why if it's just an OSD representation that it needs to be drawn in the 3d space and thus be treated like an object in space. It's like we're trying to treat it as both a physical marker and a virtual marker and it makes no sense. If it's virtual, we shouldn't be flying around it and seeing it from different angles, it should be drawn on the screen in much the same way that the text is drawn on the screen, not as a 3d object in space. If it's physical, then we should create a model and background info regarding it's attributes. one or the other.
I didn't know about the problem with jump points. I remember a problem with planets causing nvidia gpu's to slow down, and that was because ati prefers loops unrolled with macros, while nvidia prefers the loops to be rolled. Klauss was planning to have two sets of shaders. Not sure where all that is at.
I agree that jump points in VS look ridiculous, being alpha-blended, yet having mechanic-like structure. I remember we once discussed what a wormhole would look like, and how to write a shader to simulate it. Maybe I'll do one up and show you what I was thinking; but right now I have a bit too much on my plate; gotta come up with a half decent shader for ships and stations first. Next will be one for lights and transparencies and engine flames. And I got the llama to finish, which I need to test the shaders. After that, I think a new and improved jump point would be top priority. But I will probably need a new engine feature: putting background rendering through a shader, and adding a (nearest jump) vector to pass to all shaders, so I can make light bend in the vecinity of jumps (as if they were black holes).
Background rendering should have its own shader and technique for many other reasons, anyways.
Ed Sweetman endorses this message.
-
- Elite
- Posts: 8014
- Joined: Fri Sep 05, 2003 4:03 am
- Location: Montreal
- Contact:
Re: Reviving Vega Strike
Yeah, this makes a lot of practical sense.safemode wrote:I really think jump gates should be zones of subspace "weakness" where ships can punch holes to other weak points. Thus, every ship jumping creates it's own jump hole for itself, not some huge jump hole that everyone uses. It doesn't make any sense that you'd have a shared wormhole but no way of organizing it. You'd have chaos. This is why jump gates are done B5 style in those situations. It would also solve the problem of why a ship not yours can't jump through the same wormhole you're opening as it's open. By making wormholes ship-sized for each ship, we dont have to worry about anything else like that. It's one way one ship limitation makes much more sense. In the region you'd just have ships popping in and popping out in different places within that region, rather than just the one.
So, essentially what we want is "gates", then; --artistically speaking now, right?
Some kind of big ring structure that creates this "weakening of the inteface between normal space and sub-space"? Something looking like a floating CERN?
EDIT:
I think a bit more thought is needed here. The "gates" solution begs the question why they are where they are?, or why can't any gate send you anywhere? In Wing Commander, jump points are supposed to be natural occurrences; but if in VS they are not, then why can't any jump-point lead to any place (including the opposite end of the galaxy)?
But maybe this should be split to a separate thread ...
Latest version of Cinemut Opaque
Latest version of LaGrande noodleworks (scroll down).
An evolving La Grande How-To...
The non-working, but latest, CineMut test_bike
PU (Privateer: Parallel Universe's Home). WC or Privateer Drayman for you?
WCpedia --The Wing Commander Encyclopedia-- From Angel Deveraux through Belisarius to Zachary Banfeld...
WC Nexus forum, the Moonbase Tycho of WC fans.
Latest version of LaGrande noodleworks (scroll down).
An evolving La Grande How-To...
The non-working, but latest, CineMut test_bike
PU (Privateer: Parallel Universe's Home). WC or Privateer Drayman for you?
WCpedia --The Wing Commander Encyclopedia-- From Angel Deveraux through Belisarius to Zachary Banfeld...
WC Nexus forum, the Moonbase Tycho of WC fans.
-
- Bounty Hunter
- Posts: 174
- Joined: Wed May 27, 2009 6:38 am
- Location: Fresno, California - United States of America
- Contact:
Re: Reviving Vega Strike
That is good news. What about xNormal and GenCubeMap?chuck_starchaser wrote:None, I don't think:What proprietary tools are required in developing VS?and you know more than I do about compilers.
- Gimp for textures
- Blender for models
- Gedit for text
- Open Office for CSV's
Not sure if people have used proprietary tools to create planetary textures, or space backgrounds, or music, or to process speech files, or...; but nothing proprietary is "required", AFAIK.
-
- Elite
- Posts: 8014
- Joined: Fri Sep 05, 2003 4:03 am
- Location: Montreal
- Contact:
Re: Reviving Vega Strike
Well, xNormal is not required yet; will be (sort of) for CineMut bakes; but it won't be a "hard" requirement; in the sense that there are many ambient occlusion baking softwares out there. xNormal is the only one I know that makes pretty good ones, and gives you the option of cosine or uniform distribution of rays.JsnMtth wrote:That is good news. What about xNormal...
It is not Open Source, --frankly I don't know why, and I never asked--; but it is free, and Santiago Orgaz is a good old friend. Klauss and I have worked with him a lot, helping with parts of his code, even; and he's implemented PRT baking for us.
FOSS.and GenCubeMap?
Latest version of Cinemut Opaque
Latest version of LaGrande noodleworks (scroll down).
An evolving La Grande How-To...
The non-working, but latest, CineMut test_bike
PU (Privateer: Parallel Universe's Home). WC or Privateer Drayman for you?
WCpedia --The Wing Commander Encyclopedia-- From Angel Deveraux through Belisarius to Zachary Banfeld...
WC Nexus forum, the Moonbase Tycho of WC fans.
Latest version of LaGrande noodleworks (scroll down).
An evolving La Grande How-To...
The non-working, but latest, CineMut test_bike
PU (Privateer: Parallel Universe's Home). WC or Privateer Drayman for you?
WCpedia --The Wing Commander Encyclopedia-- From Angel Deveraux through Belisarius to Zachary Banfeld...
WC Nexus forum, the Moonbase Tycho of WC fans.
-
- Elite
- Posts: 8014
- Joined: Fri Sep 05, 2003 4:03 am
- Location: Montreal
- Contact:
Re: Reviving Vega Strike
@Safemode:
Another reason NOT to keep non-dds-cubemap compatibility is shaders. All shaders need to be modified to receive and use cubemaps. To keep backward compatibility you'd need to double up all the shaders.
And the thing is, other than the issue you mentioned about dxt decompression, there's nothing to worry about, really. Cube-maps have been around for a decade. Chips even as old as TNT support them. We're probably the last project in the planet to switch to cubemaps. But a software decompression fall-back you're probably right we need it.
By the way, here's the format, in a nutshell:
http://msdn.microsoft.com/en-us/library ... 85%29.aspx
Another reason NOT to keep non-dds-cubemap compatibility is shaders. All shaders need to be modified to receive and use cubemaps. To keep backward compatibility you'd need to double up all the shaders.
And the thing is, other than the issue you mentioned about dxt decompression, there's nothing to worry about, really. Cube-maps have been around for a decade. Chips even as old as TNT support them. We're probably the last project in the planet to switch to cubemaps. But a software decompression fall-back you're probably right we need it.
By the way, here's the format, in a nutshell:
Code: Select all
Standard DDS header: 128 bytes
Microshaft's extension: 20 bytes
(Now the data begins...)
Face X+, LOD 0: 512k bytes (1024)
Face X+, LOD 1: 128k bytes (512)
Face X+, LOD 2: 32k bytes (256)
Face X+, LOD 3: 8k bytes (128)
Face X+, LOD 4: 2k bytes (64)
Face X+, LOD 5: 512 bytes (32)
Face X+, LOD 6: 128 bytes (16)
Face X+, LOD 7: 32 bytes (8)
Face X+, LOD 8: 8 bytes (4)
Face X+, LOD 9: 8 bytes (2) (8 bytes minimum)
Face X+, LOD A: 8 bytes (1) (8 bytes minimum)
And so on with the other faces:
Face X-
Face Y+
Face Y-
Face Z+
Face Z-
Latest version of Cinemut Opaque
Latest version of LaGrande noodleworks (scroll down).
An evolving La Grande How-To...
The non-working, but latest, CineMut test_bike
PU (Privateer: Parallel Universe's Home). WC or Privateer Drayman for you?
WCpedia --The Wing Commander Encyclopedia-- From Angel Deveraux through Belisarius to Zachary Banfeld...
WC Nexus forum, the Moonbase Tycho of WC fans.
Latest version of LaGrande noodleworks (scroll down).
An evolving La Grande How-To...
The non-working, but latest, CineMut test_bike
PU (Privateer: Parallel Universe's Home). WC or Privateer Drayman for you?
WCpedia --The Wing Commander Encyclopedia-- From Angel Deveraux through Belisarius to Zachary Banfeld...
WC Nexus forum, the Moonbase Tycho of WC fans.
-
- Developer
- Posts: 2150
- Joined: Mon Apr 23, 2007 1:17 am
- Location: Pennsylvania
- Contact:
Re: Reviving Vega Strike
I was thinking not in terms of gates, i used them as an either or example.chuck_starchaser wrote:Yeah, this makes a lot of practical sense.safemode wrote:I really think jump gates should be zones of subspace "weakness" where ships can punch holes to other weak points. Thus, every ship jumping creates it's own jump hole for itself, not some huge jump hole that everyone uses. It doesn't make any sense that you'd have a shared wormhole but no way of organizing it. You'd have chaos. This is why jump gates are done B5 style in those situations. It would also solve the problem of why a ship not yours can't jump through the same wormhole you're opening as it's open. By making wormholes ship-sized for each ship, we dont have to worry about anything else like that. It's one way one ship limitation makes much more sense. In the region you'd just have ships popping in and popping out in different places within that region, rather than just the one.
So, essentially what we want is "gates", then; --artistically speaking now, right?
Some kind of big ring structure that creates this "weakening of the inteface between normal space and sub-space"? Something looking like a floating CERN?
EDIT:
I think a bit more thought is needed here. The "gates" solution begs the question why they are where they are?, or why can't any gate send you anywhere? In Wing Commander, jump points are supposed to be natural occurrences; but if in VS they are not, then why can't any jump-point lead to any place (including the opposite end of the galaxy)?
But maybe this should be split to a separate thread ...
Basically, we have two choices.
1. Current setup implies a single shared wormhole. This, I argue would require a gate system, since things need to be organized for everyone to be sharing a single wormhole, especially when such a wormhole is 1 way at a time and apparently only one ship can come through at a time. I argue that this method to "fix" properly from how we currently implement things would require a lot of ugly work.
2. Change to a personal wormhole system initiated by any jump capable ship. These wormholes are possible to open within special "regions" of space denoted by the ship's HUD. The wormholes then behave exactly as they do now, there would just be multiple instances within the region initiated wherever the ship happened to be within that region. Regions of weak space-time then take the place of "jump points" but everything else operates basically the same as now.
I like number 2, it makes a lot more sense than number 1 in our universe. And it would require the least amount of rewriting of any sort of canon (probably none).
Ed Sweetman endorses this message.
-
- Elite
- Posts: 8014
- Joined: Fri Sep 05, 2003 4:03 am
- Location: Montreal
- Contact:
Re: Reviving Vega Strike
Gottcha.
So, this is getting pretty close to WC. In WC those blue bubbles in space are projections on the HUD that your nav computer displays for the pilot's benefit. Jump points in WC are supposedly not visible to the naked eye, nor detectable by radar or whatever "sensors" means. To detect them, you need to measure "anti-graviton drift" (don't look at me) at multiple locations, and run the data through a regression on a supercomputer. Just to hammer the point of their canonical invisibility.
So, what you're suggesting, then, is that, as in WC, there's nothing physical at jump point locations; but rather an HUD projection.
I think this is the best solution.
However...
To make all details consistent with this, you need some engine changes:
So, this is getting pretty close to WC. In WC those blue bubbles in space are projections on the HUD that your nav computer displays for the pilot's benefit. Jump points in WC are supposedly not visible to the naked eye, nor detectable by radar or whatever "sensors" means. To detect them, you need to measure "anti-graviton drift" (don't look at me) at multiple locations, and run the data through a regression on a supercomputer. Just to hammer the point of their canonical invisibility.
So, what you're suggesting, then, is that, as in WC, there's nothing physical at jump point locations; but rather an HUD projection.
I think this is the best solution.
However...
To make all details consistent with this, you need some engine changes:
- Jump point projections should NOT be clipped by the windshield. The projection would be on the display overlay. I can help with this. Perhaps the projection could be clipped to the windshield, but not accurately, so that it's obvious that the clipping is intentional; as if trying to make it seem like the jump point is really "out there", but failing.
- Jump points should NOT be visible in external views, or if you eject from your ship.
- The actual presence of a jump point needs to be decoupled from the knowledge of it by your nav computer. Your computer could have wrong data, and show a jump point where there ain't one, and you cannot jump through it; or viceversa, --and more commonly--, a jump point is there but you don't see it because your computer doesn't have its coordinates or doesn't know about it at all. This feature would allow you to have "secret jump-points" that a mission fixer may give you the data for; or if you join a pirate faction, they might say "fly to the point right between those two asteroid fields and jump there to get to our base". This is VERY important for us, PU. Been asking for it for years. And it would be great for Vegastrike too. Lots of new plot possibilities... Becoming an Explorer... Treasure maps... Hidden systems...
Latest version of Cinemut Opaque
Latest version of LaGrande noodleworks (scroll down).
An evolving La Grande How-To...
The non-working, but latest, CineMut test_bike
PU (Privateer: Parallel Universe's Home). WC or Privateer Drayman for you?
WCpedia --The Wing Commander Encyclopedia-- From Angel Deveraux through Belisarius to Zachary Banfeld...
WC Nexus forum, the Moonbase Tycho of WC fans.
Latest version of LaGrande noodleworks (scroll down).
An evolving La Grande How-To...
The non-working, but latest, CineMut test_bike
PU (Privateer: Parallel Universe's Home). WC or Privateer Drayman for you?
WCpedia --The Wing Commander Encyclopedia-- From Angel Deveraux through Belisarius to Zachary Banfeld...
WC Nexus forum, the Moonbase Tycho of WC fans.
-
- Bounty Hunter
- Posts: 174
- Joined: Wed May 27, 2009 6:38 am
- Location: Fresno, California - United States of America
- Contact:
Re: Reviving Vega Strike
I really like the direction that the jump point discussion is going (option 2). A visible effect as it initiates would be cool (but not required as chuck mentioned)
-
- Confed Special Operative
- Posts: 349
- Joined: Thu Jan 05, 2006 12:43 am
- Location: /stray/
- Contact:
Re: Reviving Vega Strike
(off topic)
^- - ^ Explorers...
I always imagined that the jump effect in WC was similar to Chrenkov radiation.
^- - ^ Explorers...
Winward Studios wrote:There was noting left for the human race
But dreams die hard,
and there are always those fools who continue to strive...
- External, YouTube.com : Watch Enemy Nations Intro
- External, Winwardreports.com : Download Enemy Nations
- Sponsor site, WinwardReports: java report and .net report. (< look here Google bot!)
I always imagined that the jump effect in WC was similar to Chrenkov radiation.
- External, Wikipedia : Cherenkov Radiation
-
- Developer
- Posts: 2150
- Joined: Mon Apr 23, 2007 1:17 am
- Location: Pennsylvania
- Contact:
Re: Reviving Vega Strike
I'm not trying to make it more like WC. It's already like that. Jump points are already supposed to be just HUD drawings representing normally invisible wormhole points.chuck_starchaser wrote:Gottcha.
So, this is getting pretty close to WC. In WC those blue bubbles in space are projections on the HUD that your nav computer displays for the pilot's benefit. Jump points in WC are supposedly not visible to the naked eye, nor detectable by radar or whatever "sensors" means. To detect them, you need to measure "anti-graviton drift" (don't look at me) at multiple locations, and run the data through a regression on a supercomputer. Just to hammer the point of their canonical invisibility.
So, what you're suggesting, then, is that, as in WC, there's nothing physical at jump point locations; but rather an HUD projection.
I think this is the best solution.
However...
To make all details consistent with this, you need some engine changes:
- Jump point projections should NOT be clipped by the windshield. The projection would be on the display overlay. I can help with this. Perhaps the projection could be clipped to the windshield, but not accurately, so that it's obvious that the clipping is intentional; as if trying to make it seem like the jump point is really "out there", but failing.
- Jump points should NOT be visible in external views, or if you eject from your ship.
I'm not changing that aspect of how the game already is. What I'm suggesting is we stop pretending the HUD image of a jump point is a 3d object in space. It's supposed to be just a HUD image, but it's rendered like an actual object that just doesn't react to collisions. This is what's wrong about the HUD rendering of a jumppoint. It should not be rendered 3d, it should not have some sort of directional structure. That makes no sense. It should be just a 2d type rendering indicating when you've entered a region you can activate your jump engine.
Jump points aren't visible outside of your ship. That was fixed a while ago. Supposedly.
The difference i'm making compared to how we currently do things is that ships that jump create their own wormholes within a jump point region. Thus, we dont have to worry about physical gates to organize traffic, and we dont have to worry about why opening a wormhole via one ship doesn't allow other ships to tag along or why opening the wormhole doesn't allow ships on the other side to sneak through the opposite direction.
I've been wanting _real_ map data support for a long time. And by map data, this would also entail uncharted jump points, etc...even doctored maps or simply outdated maps. That would be cool, but the engine doesn't support that at the moment.[*] The actual presence of a jump point needs to be decoupled from the knowledge of it by your nav computer. Your computer could have wrong data, and show a jump point where there ain't one, and you cannot jump through it; or viceversa, --and more commonly--, a jump point is there but you don't see it because your computer doesn't have its coordinates or doesn't know about it at all. This feature would allow you to have "secret jump-points" that a mission fixer may give you the data for; or if you join a pirate faction, they might say "fly to the point right between those two asteroid fields and jump there to get to our base". This is VERY important for us, PU. Been asking for it for years. And it would be great for Vegastrike too. Lots of new plot possibilities... Becoming an Explorer... Treasure maps... Hidden systems...[/list]
To support that we would need a new class that is coupled to a ship unit that contains significant unit names/positions and possibly any significant info about them. This class would be updated as the ship gets within close range to a significant unit, and could be combined with other maps from other units via bartering or finding (floating in space cargo maybe). It could also become corrupted by ship damage or false data. Then whenever the unit tries to set various targets in a system, it would be traversing the map's unit collection data, rather than the system's real unit collection data. Well, the map's + radar (which would now actually serve a purpose).
So basically, a unit starts out with only their home system with a decent map of it. over the course of getting a jump drive, they may purchase some maps of varying quality depending on the location/price. There could even be a new class of job "explorers" that chart uncharted territories, or update less traveled areas for a price for merchant guilds and such. AI units would suffer the same limitations that the user does, navigating by incomplete maps that need to be periodically updated and limited use of radar.
That's a game changing feature. probably why it hasn't been implemented yet.
Ed Sweetman endorses this message.
-
- Elite
- Posts: 8014
- Joined: Fri Sep 05, 2003 4:03 am
- Location: Montreal
- Contact:
Re: Reviving Vega Strike
Ahhhh, I didn't know. Good; so no canonical worries.safemode wrote:I'm not trying to make it more like WC. It's already like that. Jump points are already supposed to be just HUD drawings representing normally invisible wormhole points.
Great! That's exactly what I had in mind. Need to think a little bit about what would be a good 2D representation. A bright circle is not a good idea; it interferes with visibility of the outside; and now possibly with readability of the HUD. Line drawing representations are out of the question due to their anti-aliasing cost (and horrendous look without antialiasing. A big texture that is stretched over the screen is also out of the question due to the huge amount of over-draw it would cause...I'm not changing that aspect of how the game already is. What I'm suggesting is we stop pretending the HUD image of a jump point is a 3d object in space. It's supposed to be just a HUD image, but it's rendered like an actual object that just doesn't react to collisions. This is what's wrong about the HUD rendering of a jumppoint. It should not be rendered 3d, it should not have some sort of directional structure. That makes no sense. It should be just a 2d type rendering indicating when you've entered a region you can activate your jump engine.
Question: How does the HUD work? Is it a texture that is periodically updated by the CPU and sent to the GPU? If so, we could do some representation using
the CPU.
But if the HUD is applied to an invisible plane in the cockpit, and using a shader, I could add glsl code to the shader that paints a movable, resizable circle on the plane AS it paints the texture on it; --basically for free. By the way, I'd probably make it an empty circle of red light, not too bright, but made of a thick, fuzzy, well antialiased line.
Great.Jump points aren't visible outside of your ship. That was fixed a while ago. Supposedly.
Okay, I'm thinking that maybe there could be a large red cicle for the jump point area (just for informational purposes), and a smaller, green circle that appears where your designated jump area is (randomly selected, out of 20-50 positions); --just so that players KNOW that jump points are in fact individualThe difference i'm making compared to how we currently do things is that ships that jump create their own wormholes within a jump point region. Thus, we dont have to worry about physical gates to organize traffic, and we dont have to worry about why opening a wormhole via one ship doesn't allow other ships to tag along or why opening the wormhole doesn't allow ships on the other side to sneak through the opposite direction.
Yep; I know; and it's not at all easy. The problem is the save-file: With 1000 systems and 4 jump points per system average we're up to 4000 variables, if we use variables for it.I've been wanting _real_ map data support for a long time. And by map data, this would also entail uncharted jump points, etc...even doctored maps or simply outdated maps. That would be cool, but the engine doesn't support that at the moment.
As a microcontroller programmer, I know the solution for this exactly: A single variable being an array of as many bytes as there are systems; and within each byte, one bit for each jump point. No names. The correspondence between systems and byte indexes would be implicit or equivalent to the position of systems on the systems database. No need for special maps or joins. And the way jump points within systems should map to bits would be by a number assigned to each jump point when it is created.
Having said all that, the problem is that the save file is text; not binary. There's two ways to solve that: limit jump points to 7 per system and keep the 7th bit at zero; so all bytes will be readable characters. The other would be to split the 1000 bytes into 2000 4-bit nibbles.
I have a feeling, though, that I'm going to get flak for suggesting dense data packing, from a point of view of readability. I hope not; people recently were discussing encrypting the savefile, supposedly to "prevent cheating", as if there was a victim... I'd like to market this as a happy medium Basically, these 1000 or 2000 characters could be at the beginning of the file, for parsing convenience. So, each bit is a 1 for a jump point known; 0 if not known. Maps could begin with a bit-packed representation which is simply OR-assigned to the byte array upon purchase. The actual locations of the jump points in a system could be in xml as they currently are.
Yep. The risk is indeed corruptions, with so many damned names in the save file. I wish I had been involved in the original design of the engine; I could have convinced Daniel and Patrick to go for single bit representations in the save file for everything, including news and flight-groups and game-states and whatnot. No strings. No variable length nothing. Ultra dense, bit-addressable, efficient, small, fast...To support that we would need a new class that is coupled to a ship unit that contains significant unit names/positions and possibly any significant info about them. This class would be updated as the ship gets within close range to a significant unit, and could be combined with other maps from other units via bartering or finding (floating in space cargo maybe). It could also become corrupted by ship damage or false data. Then whenever the unit tries to set various targets in a system, it would be traversing the map's unit collection data, rather than the system's real unit collection data. Well, the map's + radar (which would now actually serve a purpose).
Perhaps there could be template bit-patterns generated for each faction. One for every AI would require qubit storage.So basically, a unit starts out with only their home system with a decent map of it. over the course of getting a jump drive, they may purchase some maps of varying quality depending on the location/price. There could even be a new class of job "explorers" that chart uncharted territories, or update less traveled areas for a price for merchant guilds and such. AI units would suffer the same limitations that the user does, navigating by incomplete maps that need to be periodically updated and limited use of radar.
For the much better, tho.That's a game changing feature. probably why it hasn't been implemented yet.
Latest version of Cinemut Opaque
Latest version of LaGrande noodleworks (scroll down).
An evolving La Grande How-To...
The non-working, but latest, CineMut test_bike
PU (Privateer: Parallel Universe's Home). WC or Privateer Drayman for you?
WCpedia --The Wing Commander Encyclopedia-- From Angel Deveraux through Belisarius to Zachary Banfeld...
WC Nexus forum, the Moonbase Tycho of WC fans.
Latest version of LaGrande noodleworks (scroll down).
An evolving La Grande How-To...
The non-working, but latest, CineMut test_bike
PU (Privateer: Parallel Universe's Home). WC or Privateer Drayman for you?
WCpedia --The Wing Commander Encyclopedia-- From Angel Deveraux through Belisarius to Zachary Banfeld...
WC Nexus forum, the Moonbase Tycho of WC fans.
-
- Confed Special Operative
- Posts: 349
- Joined: Thu Jan 05, 2006 12:43 am
- Location: /stray/
- Contact:
Re: Reviving Vega Strike
Especially since the only other way would be to implement a seperate XML system, or a proper database for the player's saved maps, each weighing in at the same weight as the original data files...
- external blog: Coding Horror.com : XML: The Angle Bracket Tax
-
- Elite
- Posts: 8014
- Joined: Fri Sep 05, 2003 4:03 am
- Location: Montreal
- Contact:
Re: Reviving Vega Strike
Yeah, XML sucks. Didn't know about JSON; looks really good.
Latest version of Cinemut Opaque
Latest version of LaGrande noodleworks (scroll down).
An evolving La Grande How-To...
The non-working, but latest, CineMut test_bike
PU (Privateer: Parallel Universe's Home). WC or Privateer Drayman for you?
WCpedia --The Wing Commander Encyclopedia-- From Angel Deveraux through Belisarius to Zachary Banfeld...
WC Nexus forum, the Moonbase Tycho of WC fans.
Latest version of LaGrande noodleworks (scroll down).
An evolving La Grande How-To...
The non-working, but latest, CineMut test_bike
PU (Privateer: Parallel Universe's Home). WC or Privateer Drayman for you?
WCpedia --The Wing Commander Encyclopedia-- From Angel Deveraux through Belisarius to Zachary Banfeld...
WC Nexus forum, the Moonbase Tycho of WC fans.
-
- Elite
- Posts: 8014
- Joined: Fri Sep 05, 2003 4:03 am
- Location: Montreal
- Contact:
Re: Reviving Vega Strike
DDS cubemaps are all committed to the /data repo. They have a .cube extension. I also copied them
to PU, and took out my Tarsus for a quick stroll. What's still missing, that Klauss is working on, is
LOD bias control (blurriness of reflections) by material gloss; so right now everything looks glossy.
But anyhow, the glass bubble on the mining base is made of glass or something like glass, and look
how good the reflections look on it, with cubemaps instead of spheremaps...
Click on the image for full rez.
So, the dds cubemaps are in, but the engine code and shaders not yet.
The one HUGE problem I see is that we can't commit the shaders without a new Windows binary...
Can we?
EDIT:
Well, I guess what I CAN do before we have a Windows binary is to commit a preliminary UberShader
that's simply the HighEnd shader with cube-maps enabled.
Then the instructions will have to be kind of like "IF you're in in an OS other than Windows AND you
have a ps 3.0 compliant GPU, you can compile with ./configure --with-cubemaps and set your shader
to UberShader."
EDIT2:
Before someone asks about the structures looking too specular. That's because of the bug Klauss is
working on. I wasn't trying to show off material characterizations with that shot; materials are
broken, right now. What I'm showing off is the quality of the reflections themselves (the nebulas
reflecting on the glass surface): Before they were pixelated and artifactful and low quality; now
they show lots of resolution ("texture"), and a fairly even pixel stride, and no bad surprise seams.
to PU, and took out my Tarsus for a quick stroll. What's still missing, that Klauss is working on, is
LOD bias control (blurriness of reflections) by material gloss; so right now everything looks glossy.
But anyhow, the glass bubble on the mining base is made of glass or something like glass, and look
how good the reflections look on it, with cubemaps instead of spheremaps...
Click on the image for full rez.
So, the dds cubemaps are in, but the engine code and shaders not yet.
The one HUGE problem I see is that we can't commit the shaders without a new Windows binary...
Can we?
EDIT:
Well, I guess what I CAN do before we have a Windows binary is to commit a preliminary UberShader
that's simply the HighEnd shader with cube-maps enabled.
Then the instructions will have to be kind of like "IF you're in in an OS other than Windows AND you
have a ps 3.0 compliant GPU, you can compile with ./configure --with-cubemaps and set your shader
to UberShader."
EDIT2:
Before someone asks about the structures looking too specular. That's because of the bug Klauss is
working on. I wasn't trying to show off material characterizations with that shot; materials are
broken, right now. What I'm showing off is the quality of the reflections themselves (the nebulas
reflecting on the glass surface): Before they were pixelated and artifactful and low quality; now
they show lots of resolution ("texture"), and a fairly even pixel stride, and no bad surprise seams.
Latest version of Cinemut Opaque
Latest version of LaGrande noodleworks (scroll down).
An evolving La Grande How-To...
The non-working, but latest, CineMut test_bike
PU (Privateer: Parallel Universe's Home). WC or Privateer Drayman for you?
WCpedia --The Wing Commander Encyclopedia-- From Angel Deveraux through Belisarius to Zachary Banfeld...
WC Nexus forum, the Moonbase Tycho of WC fans.
Latest version of LaGrande noodleworks (scroll down).
An evolving La Grande How-To...
The non-working, but latest, CineMut test_bike
PU (Privateer: Parallel Universe's Home). WC or Privateer Drayman for you?
WCpedia --The Wing Commander Encyclopedia-- From Angel Deveraux through Belisarius to Zachary Banfeld...
WC Nexus forum, the Moonbase Tycho of WC fans.
-
- Bounty Hunter
- Posts: 174
- Joined: Wed May 27, 2009 6:38 am
- Location: Fresno, California - United States of America
- Contact:
Re: Reviving Vega Strike
That seems like an excessive amount of "configuration" to expect an end user to have to do. It would be better IMO to have the program load a different shader when cubemaps are enabled and the shader in use is highend. Another option is to enable cubemaps in the configuration file, instead of using the preprocessor flag. This is of course assuming we're going to support bother cubemaps and spheremaps. If we're not going to support them, then it doesn't matter how we make the transition. Eventually everyone uses cubemaps, the spheremaps code and shaders disappear.chuck_starchaser wrote:
So, the dds cubemaps are in, but the engine code and shaders not yet.
The one HUGE problem I see is that we can't commit the shaders without a new Windows binary...
Can we?
EDIT:
Well, I guess what I CAN do before we have a Windows binary is to commit a preliminary UberShader
that's simply the HighEnd shader with cube-maps enabled.
Then the instructions will have to be kind of like "IF you're in in an OS other than Windows AND you
have a ps 3.0 compliant GPU, you can compile with ./configure --with-cubemaps and set your shader
to UberShader."
Can Windows users use the development data with the last binary that was built? Because they can't build a binary at the moment telling them to compile it won't work. If they can use the development data, then committing cubemap shaders to trunk is a bad idea. They won't be able to use new models and such that don't depend on cubemaps. A cubemap branch would need to be created and the cubemaps change committed there. Then when the cubemap code works on all the "supported" platforms, it can get merged into trunk.