Reviving Vega Strike

Development directions, tasks, and features being actively implemented or pursued by the development team.
Post Reply
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Reviving Vega Strike

Post by chuck_starchaser »

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.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: Reviving Vega Strike

Post by safemode »

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.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Reviving Vega Strike

Post by chuck_starchaser »

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.
Okay, I guess I'll give that a shot.
Are the cubemap dds files replacing the old backgrounds files? or in addition to them?
Replacing.
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.
Wouldn't the (updated) driver for a card without hardware dxt support decompress on the fly on its own?
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 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.
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.
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.
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:
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.
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?
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.
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.
No ideas from me.
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."
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.
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.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: Reviving Vega Strike

Post by safemode »

chuck_starchaser wrote:
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.
Wouldn't the (updated) driver for a card without hardware dxt support decompress on the fly on its own?
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*

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.
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:
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.
sounds good.
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?
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.
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.

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.
No ideas from me.
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."
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.

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.
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.
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.
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.

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.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Reviving Vega Strike

Post by chuck_starchaser »

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*
Okeydoc; I was just asking. (Owners of intel graphic chips should be punished tho :D)
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.
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.
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 :D. 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:
http://wcjunction.com/phpBB2/viewtopic. ... 2329#22329
This is why backwards compatibility is so important. We risk alienating all other mods/games by making leaps in supported datasets.
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.
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.
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.
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.
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.
Ahhhhhhhh... I gottcha now; I had it all wrong, then; I thought HQtextures contained .PNG's and stuff.
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.
Sorry; haven't tried yet; will do so.
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.
Good points.
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.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Reviving Vega Strike

Post by chuck_starchaser »

(Check my last post, first; it got left in the previous page now.)
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.
Ah, I see what you mean now; they look like just a white halo around the planet.
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.
JsnMtth
Bounty Hunter
Bounty Hunter
Posts: 174
Joined: Wed May 27, 2009 6:38 am
Location: Fresno, California - United States of America
Contact:

Re: Reviving Vega Strike

Post by JsnMtth »

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.
The Jump Points are ridiculously slow on my nVidia Corporation G71 [GeForce 7950 GT], it has to be either a bug or bad design.



What proprietary tools are required in developing VS?
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Reviving Vega Strike

Post by chuck_starchaser »

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.
They seem to be using line-drawing functions of the gpu. That's an anti-aliasing nightmare scenario.
What proprietary tools are required in developing VS?
None, I don't think:
  • Gimp for textures
  • Blender for models
  • Gedit for text
  • Open Office for CSV's
and you know more than I do about compilers.
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.
Turbo
ISO Party Member
ISO Party Member
Posts: 423
Joined: Mon Jun 11, 2007 11:54 am
Location: TX, USA
Contact:

Re: Reviving Vega Strike

Post by Turbo »

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.
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.
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.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Reviving Vega Strike

Post by chuck_starchaser »

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:

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$
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,

Code: Select all

password-stores =
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,

Code: Select all

# store-passwords = no
by removing the #...

Code: Select all

store-passwords = no
EDIT3:
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.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: Reviving Vega Strike

Post by safemode »

chuck_starchaser wrote:
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*
Okeydoc; I was just asking. (Owners of intel graphic chips should be punished tho :D
True true.
This is why backwards compatibility is so important. We risk alienating all other mods/games by making leaps in supported datasets.
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.
.image i believe should be 2d targeted images that dont have mipmaps.
.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.
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.
Ahhhhhhhh... I gottcha now; I had it all wrong, then; I thought HQtextures contained .PNG's and stuff.
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.
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.
Good points.
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.
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.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Reviving Vega Strike

Post by chuck_starchaser »

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.
Yeah, this makes a lot of practical sense.
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 ... :oops:
JsnMtth
Bounty Hunter
Bounty Hunter
Posts: 174
Joined: Wed May 27, 2009 6:38 am
Location: Fresno, California - United States of America
Contact:

Re: Reviving Vega Strike

Post by JsnMtth »

chuck_starchaser wrote:
What proprietary tools are required in developing VS?
None, I don't think:
  • Gimp for textures
  • Blender for models
  • Gedit for text
  • Open Office for CSV's
and you know more than I do about compilers.
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.
That is good news. What about xNormal and GenCubeMap?
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Reviving Vega Strike

Post by chuck_starchaser »

JsnMtth wrote:That is good news. What about xNormal...
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.
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.
and GenCubeMap?
FOSS.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Reviving Vega Strike

Post by chuck_starchaser »

@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:

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-
http://msdn.microsoft.com/en-us/library ... 85%29.aspx
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: Reviving Vega Strike

Post by safemode »

chuck_starchaser wrote:
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.
Yeah, this makes a lot of practical sense.
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 ... :oops:
I was thinking not in terms of gates, i used them as an either or example.

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.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Reviving Vega Strike

Post by chuck_starchaser »

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.
  • 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...
JsnMtth
Bounty Hunter
Bounty Hunter
Posts: 174
Joined: Wed May 27, 2009 6:38 am
Location: Fresno, California - United States of America
Contact:

Re: Reviving Vega Strike

Post by JsnMtth »

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)
snow_Cat
Confed Special Operative
Confed Special Operative
Posts: 349
Joined: Thu Jan 05, 2006 12:43 am
Location: /stray/
Contact:

Re: Reviving Vega Strike

Post by snow_Cat »

(off topic)
^- - ^ 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...
^ - -^ (on topic)
I always imagined that the jump effect in WC was similar to Chrenkov radiation.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: Reviving Vega Strike

Post by safemode »

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 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.

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.
[*] 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]
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.

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.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Reviving Vega Strike

Post by chuck_starchaser »

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.
Ahhhh, I didn't know. Good; so no canonical worries.
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.
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...

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.
Jump points aren't visible outside of your ship. That was fixed a while ago. Supposedly.
Great.
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.
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 individual
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.
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.
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.
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).
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...
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.
Perhaps there could be template bit-patterns generated for each faction. One for every AI would require qubit storage.
That's a game changing feature. probably why it hasn't been implemented yet.
For the much better, tho.
snow_Cat
Confed Special Operative
Confed Special Operative
Posts: 349
Joined: Thu Jan 05, 2006 12:43 am
Location: /stray/
Contact:

Re: Reviving Vega Strike

Post by snow_Cat »

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... ^- - ^ or altering the orignal data files, like adventure games did way back in the early 90's to note what player has visited.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Reviving Vega Strike

Post by chuck_starchaser »

Yeah, XML sucks. Didn't know about JSON; looks really good.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Reviving Vega Strike

Post by chuck_starchaser »

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.

Image

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.
JsnMtth
Bounty Hunter
Bounty Hunter
Posts: 174
Joined: Wed May 27, 2009 6:38 am
Location: Fresno, California - United States of America
Contact:

Re: Reviving Vega Strike

Post by JsnMtth »

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."
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.

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.
Post Reply