Vega Strike Forums

well, then i would definitely not suggest slowing down loading splash screens by adding the jpeg decompression to the mix just to make it look an infinitesimally little better. You dont see splash screens for more than a couple seconds anyway and it's only at the beginning of a game. I'd much rather save the fractions of a second and load the game faster. Perhaps if it was a single screen that displayed the entire time (but each time it was randomized) then that's a different story.

A couple of seconds not on my rig loading takes minutes not seconds so i get to see the splash screens for about 20-30 seconds each.

Enjoy the Choice

you sure you dont have vsync on ? that would slow it down.... though i suppose an athlon 64 with sata drives and much faster ram does make a good difference.

#1 rule for vegastrike is turn vsync off. otherwise we have to wait for it during load and it slows everything down.

I have vsync forced on on the driver and it still loads quickly. Just thought I'd mention.

Now, let's not argue about splashes... but nobody will argue higher quality on base art, or perhaps even space backgrounds, would be warranted... right?

What's harder than convincing programmers about graphics quality issues?

just to make it look an infinitesimally little better

Safemode, this is something that should be decided by the artists, not by the programmers, really.
The difference is FAR from infinitesimal. VERY far.
We're talking 16-bit versus 24-bit color ***just for starters***; and there's more ways than that to the compromises DDS makes.
JPG is a complete different animal.
Case in point: Just make a smooth gradient in Gimp, save it as jpg and as dds. The DDS will have very noticeable banding artifacts, which jpg won't.

klauss wrote:I have vsync forced on on the driver and it still loads quickly. Just thought I'd mention.

Now, let's not argue about splashes... but nobody will argue higher quality on base art, or perhaps even space backgrounds, would be warranted... right?

On my nvidia driver, it caused load times to go from less than a minute to a little over a minute.

Space backgrounds take up too much memory to be uncompressed.

That's the reason why they were moved to DDS.

at 1024x1024, you have 18MB of vram taken up just to hold the textures off the bat.

The DDS of the system backgrounds would take up 4.1MB. That's another unit you can get in the video card or more planets in the system. It's a big deal.


It seems like we need to setup a system of having 2 texture packs. 1 is performance / size oriented. 1 is simply quality oriented.

The quality oriented one will have textures that will not be compressed.

We'll create a new repository, hq-textures. hq-textures will contain only those textures you are replacing with uncompressed versions, they'll have the same path, same name as if hq-textures was data4.x.

What we'll then do is make a super high quality setting, that we will then use in vsimage.cpp. Everytime a texture is requested, we first check a modified filename with hq-textures inserted, if the texture is not found there, we check the normal filename. hq-textures will likely sit outside data4.x (but in the same parent directory).

As it's an optional download, what gets decided to go in hq-textures is up to the artists.


i think this is the only way to resolve the issue. It's not much trouble at all, it's completely non-intrusive to data4.x and it's extremely easy for end users to pull hq-textures and have it be used without any special installation programs or fudging.

All we need is an extra config parameter, a config check and conditional block in vsimage.cpp, and an update to vssetup to handle the new quality setting (which sets the config option).

I really like that idea.

It's really a win win. Regular data4.x remains at the quality (actually slightly better) that it's always been, only with the benefit of not having to compress on the fly or decompress anything, and those users who have the hardware to handle it, can choose to use select uncompressed textures to provide a level of quality above anything we've ever had.

Talking to yourself?

I like the idea too. I threw together a "space camoflague" overlay for a Gawain, but cannot test it. The DDS tools (DDS Converter 2.1 and also the Nvidia tools) don't convert any image format to DDS on any of my computers. So, I can't put it in-game to see whether the tiger stripes line up properly. If there were a way to selectively bypass the requirement for DDS, I could test artwork without having to find someone to convert it for me.
http://www.willadsenfamily.org/us/don/t ... gawain.png

Turbo

To convert, you'll need to use nvcompress. What's the std output when you start the tool without any options?

You can always test without converting to dds. The final submission to data should be dds or let one of the devs know and they'll convert it appropriately.

nvcompress requires the extension to be correct for the image type. It supports only a few basic formats, usually png or jpeg will do the trick.
Very strange that you cant get it to work on multiple computers.

You can test artwork just fine without making it DDS. The game will still load jpeg and png files (though png wont get compressed on the fly). The requirement was to get all the svn commits to be dds. so that the basic standard was starting from DDS, then we can make exceptions one at a time.

so just setup your artwork in your own pull of data4.x, see how it looks, then if you want to submit for inclusion and you still cant compress it, someone else will.

Either way, you will still have to get someone or find a way to make a dds of it, because textures in the hq-textures repository must have a DDS fallback.

The picture is interlaced, can it have anything to do with that?

not sure, not sure how interlaced png is handled in nvcompress. That would have to be fielded to some nv forum.

I like the idea of an HQ repo, too; except for one detail:

safemode wrote:The quality oriented one will have textures that will not be compressed.

Make that "The quality oriented one will have textures that will be jpeg compressed, rather than DDS-compressed".
Jpeg compression is of MUCH higher quality than DDS compression, and reduces file-size enormously compared to both: PNG and DDS.
What there's almost no place for is PNG format --except very tiny textures, and those that need to have an alpha channel. Other than that, PNG is for the birds. The difference between a PNG and a 90% quality JPG of it, now that is "infinitesimal".

If you don't believe me, make this experiment in Gimp:
Start with PNG image.
Save a Copy -> samename.jpg ->90% quality.
Load as Layer -> samename.jpg
In layers dialog, select blending mode as Difference.
The screen will be pitch black.
Anchor layer.
New Layer
Bucket fill with dark gray: HEX 0F0F0F
In layers dialog, select blending mode as Divide
This effectively will multiply the brightness of the differences 16 or 17 times.
You might notice a barely visible sprinkle of noise.

No do the same experiment with DDS...

What we need, to go with that, is to curb this policy that JPG's are DDS converted on the fly. JPG should be treated with as much respect as PNG.

personally, i dont care what the format of the files are in hq-textures, on the fly compression will be disabled altogether, so anything not DDS wont be loaded into GL compressed.

But if it's decided that jpeg should be preferrred then that will be written into the rules. But really, I wont stick my nose in what gets in hq-textures or not. I only ask that what gets in gets kept up to date (and us non-interested developers will do that if we end up having to).

so to summarize, with hq-textures, we remove the policy of compressing anything on the fly. The artists can decide on the rules that govern what format hq-textures prefers, and what particular textures are candidates. It'll all get loaded to GL uncompressed.
At first we'll use a blanket config variable to decide to use hq-textures or not, but if hq-textures grows signiificantly in size, we can subdivide them so that everyone without a 600 dollar card isn't alienated from the hq-textures repo.

See the developer focus thread too.

Mostly right now I just want to know how many people who are in the group of people who want to make certain textures not DDS are on board with this plan. I want to make sure this is sufficient to make everyone happy. Then post 0.5, we'll get into implementing it. I can hammer out the code part right after release and get the repo setup. Then when it gets going i'll go back to my original intention of getting the ray collider up post 0.5

Couldn't we just link to the images in masters instead of making a new tree. The masters are supposed to be at a higher quality and non-dds anyway so It seems like that would be an easier approach to solving the same problem/

masters would not be the same. master images may be the wrong resolution for in-game, they may be of excessive quality or wrong format for in-game.

Masters is not meant for use, as such it's not formatted for use.

a new tree will be needed. Both for end users and internal organization.

Fair enough. Thought I saw a chance to kill 2 birds with one stone. But there is indeed non-power of 2 textures etc. That could cause issues.

However, just to be a little friendlier on sourceforge which has hosted our project for so long being waaaay overquota, if the textures in masters do turn out to be fitted for use within the engine in hq-textures, do make an svn copy instead of checking them in again...

BTW: for jpegs to be of such high quality (as chuck mentioned), they have to use YUV444 color space. It's usually configurable, but the default tends to be YUV422, which for some kind of content introduces unacceptable color bleeding artifacts. Many artists don't know this, and thus always find jpeg immensely inferior to PNG (which does not do this).

OT

For the sourceforge quota thing. I would love to see the actual project repository size with all the changesets and everything. It's gotta be massive because all binary updates get completely replaced.

I wonder if it's possible for SF to archive the repository up to say a requested revision so the project doesn't occupy so much live space.

If they have a quota system, they must offer some way to cull old changes that are no longer necessary. then we can back them up locally or SF could etc.

/OT

bgaskey wrote:Couldn't we just link to the images in masters instead of making a new tree. The masters are supposed to be at a higher quality and non-dds anyway so It seems like that would be an easier approach to solving the same problem/

We need to stop thinking as the masters repo as simply holding high quality pictures prior to compression. That's NOT the purpose of having a masters repository. The purpose of it is to keep the ARTWORK masters, --namely, all the layers needed to compose a texture, such as the base material layer, the rust and paint layers, the bump map, the baked ambient occlusion, etceteras.
See this post:
http://vegastrike.sourceforge.net/forum ... 6601#96601

WRT server space: At PU we now got a dedicated server. 160 gigs space. If vegastrike want to, I can set up an svn repo for you there.

It's the project's administrator's responsability AFAIK. And last time I made a snapshot of the WCU repo (alone, and that was with CVS) it was, compressed, about 600MB. Since a clean WCU export wights around 2xxMB, we're talking a 3x overhead. VS sits at 500MB I think, so I'd expect an svn snapshot to be no less than 1.5G. Cool huh?

Basically, the way to cull old versions is to dump the repository and import it again. It's rather quick since it's done all locally using sourceforge's ssh access, but it does obliterate any kind of history you had for the project. I don't know how one would delete only "old" versions.

pyramid wrote:You can always test without converting to dds.

That worked, plus I told Corel Paint to stop interlacing the image. This is more of a novelty than a serious submission. But since I have it 90% done, as far as the texture properly wrapping around corners, here is the updated version:
http://www.willadsenfamily.org/us/don/t ... irefly.png
and here it is in-game:



Of course, to implement it so only my Gawain looks like this, I have to create a unit folder gawain.custom, copy the files, replace the base texture, hack my saved game, etc. Maybe tomorrow.

Turbo

I can't see it

Double post.

I can see it now.