[Lightspeed]

And they get rendered in full 32-bit as soon as they are used in your game. Point?

[KARMA]

*sigh*

Originally posted by Bobboau
if you want to know how much space a texture is going to take up in memory, simply multiply it's hight by it's width by it's color depth (if you don't know it's 16 bit, that would be the old PCX textures, TGA aand JPG are both 32 bit) the only exeption would be the dds compressed textures.
so a 1024X1024 32bit picture would be 33,554,432 bits
divide that by 8 any that's how many bytes you have, 4,194,304, so about 4.2 megabytes

and since it wasn't posted 5 years ago but about 2 months ago, then (again) my question:

Originally posted by KARMA
I thought...that the colour depth ... affect the weight (I suppose in term of memory usage) of an image used in game.

and to me more memory usage=not good and something to avoid if possible;
now, is it still true or something which I don't know changed in that period of time (I've been almost out in that period for real life, so it could be..)?
Because I feel like I'm missing something here, or maybe I'm just stupid and I continue to miss the point
and, this is WHY I keep asking the same thing, it really doesn't cost too much to me to open my old psd files and save em as 24/32 bit instead of 8, if it cost nothing in term of perforamce

[Bobboau]

oh, yeah, the PCX are still being loaded into a 16 bit texture, it probly wouldn't cost you too much, but it wouldn't gain you anything either.

[Lightspeed]

not is you use -pcx32, anyway.

[KARMA]

ahh ok then, tell me if I'm wrong now:
pcx 256 colours (8bit) will use the same memory of a pcx 16 bit (so I can save as 16 bit and have the same performance of an 8 bit pcx)
all the other formats will take up the memory of a 32 bit image, no matter if it is a 8 bit or a 16 bit image or whatever.
If I use the command line -pcx32 any pcx will use the same memory of a 32bit image, no matter if it is a 8 bit or a 16 bit image or whatever.
Then I have mostly this choice: pcx 16bit (which I think is what I'll go for when saving textures) or tga 32bit.
Any other  file saved with a lower colour depth will give no performance gain at all, the only gain will be a smaller file size when downloading them from internet.
am I right finally?

[Lightspeed]

not 100% yet

FS2open can load only 8-bit PCX files. Any higher colour depth PCX files can NOT be loaded.

If you want more colours you need to use TGA, JPG or DDS.

[JarC]

Originally posted by Lightspeed
not 100% yet

FS2open can load only 8-bit PCX files. Any higher colour depth PCX files can NOT be loaded.

Ok, now I am lost again....so what is the -pcx32 flag then for if fs2open can't load them anyways?

[Lightspeed]

see... normally FS2 loads all PCX files and uses a compromised 16-bit palette to display them.

When -pcx32 is activated each PCX will be allowed to have *its own* 256 colour palette.

[Bobboau]

um, no, PCX files are loaded into a 16 bit texture (unless you use the comand line pcx32 thingy), everything else is loaded into a 32 bit texture, no compression (with exeption for dds), no pallets, you have x*y(both of these rounded up to the nearest power of 2)*colordepth (16 (2 bytes) or 32 (4 bytes)) this is how much space is being taken up.

[übermetroid]

Originally posted by Omniscaper

:nod:

Holly flying cows this looks great!

[Bobboau]

becase noone seemed to see this in the other thread

"I spent the last hour or two, reintegrateing decals trueform and environment mapping, I also have a few other small tweaks that are native to my codebase

use the following comandline options;
-max_subdivide 2.10 (trueform, may cause instability, the 2.10 is part of it, use higher number for more subdivision, doesn't effect geometry at this point (only lighting, yo will see a big diference))
 -bobshield (new shield rendering effect, initaly for capship shields, but I think its better all around)

http://freespace.volitionwatch.com/blackwater/fs2_open_r_future_demo.zip

to get decals working, you will need to alter weapons table

Code: [Select]


$decal:
+texture: bullethole01_A
+radius: 2.0

goes at the end of an entry"

this is integrated into a better version of the code so there shouldn't be as many problems

[Ypoknons]

Much happiness, Bobboau.

[Wes]

That file crashes for me when starting up.

[Turambar]

so pretty

[Taristin]

Still using the old backgrounds, eh?

I need to DL this.


Where can we get the bullethole graphics?

[Turambar]

if it looks good with old stuff, i can't wait till Lighspeed's nebulae are put into the campaign

[Lightspeed]

Originally posted by Bobboau
becase noone seemed to see this in the other thread

"I spent the last hour or two, reintegrateing decals trueform and environment mapping, I also have a few other small tweaks that are native to my codebase

use the following comandline options;
-max_subdivide 2.10 (trueform, may cause instability, the 2.10 is part of it, use higher number for more subdivision, doesn't effect geometry at this point (only lighting, yo will see a big diference))
 -bobshield (new shield rendering effect, initaly for capship shields, but I think its better all around)
 

Okay, finally tested your future build

There still seem to be issues with the features. I havent tested decals yet (will have to do some testing later), but from what I see it's draining a lot more performance than it should be.

Where I get constant 85 FPS with a normal build, with Trueform and env mapping I get about 28 FPS (or less, in some cases) - the specular lighting flickers on and off wildly. If I turn off TrueForm, I get 85 FPS again and the specular lighting works again, but as soon as theres a bit of action it drops down to 42 FPS (and stays there).

Also, there seem to be some 'edges' on the reflected backgrounds on the models - it looks like if the texture would end there, and after that it's just black. When I die, the screen seems to be resized so the horizontal size is halved (the models look really squashed together left-right).

The most important thing to fix in the near future would be the performance drain, which is a lot higher than it should actually be.

[Turambar]

ive noticed that too

[DaBrain]

The subspace model is moving super-fast


And it looks like the whole tunnel is envmapped on the ships.

[Bobboau]

"Also, there seem to be some 'edges' on the reflected backgrounds "
I've seen the oddness with the environment map, I'm not sure exactly what's causeing it, but it's either I'm setting the fov wrong or I'm orienting the camera wrong when I make the texture

"And it looks like the whole tunnel is envmapped on the ships."
as it should be...