[Hellbender]

Ok, so I spent the weekend fixing up the standard ship textures to run in 1024x768 resolution.  The conversion was easy enough to do, only did a bit of minor cosmetic bluring to smooth out the lines and details at the higher resolution.

When finished, at the 1024x768 resolution the ships are clear, and look pretty much like they do at the lower resolution.  The textures fit the models for a change, and the basic details are not jagged or blurred like they are when using lower resolution textures. The registry change for this works with both retail and the SCP versions as well.  I decided not to do a lot of detail work, especially as this was mainly a test.

Here's the killer part - just the fighters and support ships when compressed are 16+ megs.  For more detailed work the file size would get more massisve still.  There's no alpha channels, they aren't heavily reworked, they are just the basic files.  The full set of models including all ships and weapon shape skins is over 75 megs compressed.

As I explained to Galactic Emperor (all around good guy), I could spend excessive ammounts of time reworking the stock textures for greater detail but at best there would be perhaps a 10% over-all gain in the look of them over the present set I did up.  As previously noted the download size would only go up.  It would not really seem to be worth the trade-off.

I'm posting this here, I do not know if it has been discussed before.  Is it possible to have the game recognise a smaller image format?

And one for laughs, is it possible to get the game to recognise an animated image format for the models? For instance blinking running light textures for the ships (would be something in the realm of the glow maps)...

[FreeTerran]

This threat and this threat is that not the same ?

[Hellbender]

No, they both deal with high resolution textures, but the other deals mainly with how-do-I-use-these-and-where-do-I-get-them.  This thread deals with actual file sizes, and the question if other image file types can be used.

[kasperl]

Originally posted by Free Terran
This threat and this threat is that not the same ?

BTW, it's thread, with a"D".

dunno, this migt be an good idea, but i'm no coder.

[Fry_Day]

1024x768???

Textures must be power-of-two sizes, as I mentioned in some other thread, so that doesn't make sense, since 768 is a sum of two power-of-two numbers (512+256, to the math-lazy, who never wrote programs that use shifts instead of multiplies). 1024x1024 would be good, as would 1024x512, but 1024x768 would have to be stored in a 1024x1024 texture, which is a horrible waste of memory space

[Hellbender]

Um, right...yeah.  Ok, I'll try again:  The textures were resized and blurred to look best with a screen resolution of 1024x768.  A common screen size.  They were not all resized to 1024x768.  The textures themselves vary greatly in actual size.  The game works fine with them when set to this resolution which is what I have most games running at.  

As far as wasteful, well, my system's an 800p3, 512megs ram, GF4ti@64megs.  It doesn't even hiccup on the missions with the most ships in screen.  At 1024x768.  With the afore-mentioned textures.  It's hardly considered mid-ranged for system specs.  

Wasteful or not, and I'm not even sure we are anywhere near the same wavelength on this topic, it works and looks fine.

[Sesquipedalian]

Originally posted by Fry_Day
1024x768???

Textures must be power-of-two sizes, as I mentioned in some other thread, so that doesn't make sense, since 768 is a sum of two power-of-two numbers (512+256, to the math-lazy, who never wrote programs that use shifts instead of multiplies). 1024x1024 would be good, as would 1024x512, but 1024x768 would have to be stored in a 1024x1024 texture, which is a horrible waste of memory space

Actually, "768 is a sum of two power-of-two numbers" is the only true statement in that post, I believe.

[Solatar]

I thought textures had to be square...didn't matter if they were 1234*1234, as long as it was square...

[Sandwich]

Gah, you're all wrong! Textures need to be multiples of the lowest common denominator between the number 849's root, and the amount of whiskers on your neighbor's dog's nose (not the eyebrow whiskers). Take that result, multiply it by 3.156, and that would be the length of the texture side in points. 72 points-per-inch, measure how many pixels per inch your monitor has, and do the math.

 ....what!?

[Hellbender]

But that equals 1024x768...

I need a new abaccus...

But anyhow, back to the questions:

Is it possible to have the game recognise a smaller image format?

And one for laughs, is it possible to get the game to recognise an animated image format for the models? For instance blinking running light textures for the ships (would be something in the realm of the glow maps)...

[LtNarol]

The actual texture maps can be at any resolution, the engine will just resize them to 256*256 for rendering if you don't use the registry hack.  Also, simply resizing the maps and adding a bit of blur doesn't really fix much, you'll get a small improvement but nothing too significant except perhaps file size.  Not worth it if you ask me, unless you actually add detail to the maps

[Hellbender]

Yeah, I think I mentioned something similar to that.  

It gives you the same quality at the higher resolution as you would expect with the standard maps at the unmodified game's highest detail levels.  The blurring (very slight) was simply to smooth out the existing details to avoid the pixel edged look.  For some folks it might be worth doing on their own.  

As for adding more detail, it is tedious, irritating and time consuming using 256 colours.  Just blending in shaded areas is a time consuming keister-ache.  If that were going to be attempted, the suc...uh artist might as well reskin the whole shebang.  Many efforts I've seen to increase details when increasing resolutions often leave the models with a very cartoonish look.  

The gain is not really worth the time and filesize - which tends to increase even more as the details do.  That's why I'm interested to see if there is perhaps a way the game engine could be modified to allow a smaller image format for its model skins.

[Fry_Day]

Originally posted by Sesquipedalian

Actually, "768 is a sum of two power-of-two numbers" is the only true statement in that post, I believe.

Okay, I was wrong about hardware limitations and API limitations, to some degree  - You need to look for D3DPTEXTURECAPS_NONPOW2CONDITIONAL to see if your card supports non-power-of-two textures, and hardware older than the Matrox G400 (which includes, I believe, the Riva TNT 2 line, which is popular) most definitely doesn't have that capability, therefore, non power-of-two textures must be either scaled to power-of-two sizes, or stored in the nearest larger power-of-two size with a space-waste.

The origin of the power-of-two limit is of course in the way registers are handled internally, which means that if you force power-of-two sizes, you can do a shift instead of multiply per each pixel drawn, which was a considerable gain, most likely, when decided upon in the original 3D accelerators (though it actually slowed down my software rasterizer on my old Pentium system, since shifts take both pipelines on a Pentium).

Edit: The point is, forcing power-of-two sizes was simply a necessity, for speed and transistor-count purposes, but recent hardware seems to have spared transistors for it. Of course, power-of-two sizes are also cache-friendly, which is good.

Why is the shift used? When a polygon is drawn, the 3D coordinates are transformed into screen-space (2D) coordinates.
Then, a procedure called scan-converting of the polygon occurs, in which, basically, a polygon is dissected into many horizontal lines, by going through the edges of the polygon.


now that you have many horizontal lines (with texture coordinates, lighting, etc. computed for the edges), you have the most critical inner-loop, which draws them basically, it interpolates lighting values, and texture coordinates, reads from the texture, according to the interpolated texture coordinates, modulates with the lighting, and writes to the destination buffer.
The interpolation of texture coordinates is a simple pair of additions, but the resulting texture coordinates are an X,Y pair. A simple point on the texture. That needs to be converted into an offset inside the memory in which the texture is stored (The texture is generally stored as a simple linear array). the conversion is generally OFFSET = (X + Y*TextureWidth)*BytesPerPixel. BytesPerPixel is always a power of two, so that's naturally a shift, and if TextureWidth is a power of two, that's a shift also. Ta Da!

What an essay... Look at what you've done to me, Sesquipedalian, turning me into a nattering nitpicker!

Edit 2: I also forgot to mention that the scan-conversion process is what causes the requirement for triangles to be passed to hardware in general, since convex objects can be scan-converted much faster, and triangles are guaranteed to be convex (Unless there's black magic involved ). That's also why Triangle Strips and Fans exist - Since the hardware can use the same scan-conversion data for more than one triangle (as triangles sare edges), stuff goes a whole lot faster.

[Sandwich]

Originally posted by Fry_Day


Okay, I was wrong about hardware limitations and API limitations, to some degree  - You need to look for D3DPTEXTURECAPS_NONPOW2CONDITIONAL to see if your card supports non-power-of-two textures, and hardware older than the Matrox G400 (which includes, I believe, the Riva TNT 2 line, which is popular) most definitely doesn't have that capability, therefore, non power-of-two textures must be either scaled to power-of-two sizes, or stored in the nearest larger power-of-two size with a space-waste.

The origin of the power-of-two limit is of course in the way registers are handled internally, which means that if you force power-of-two sizes, you can do a shift instead of multiply per each pixel drawn, which was a considerable gain, most likely, when decided upon in the original 3D accelerators (though it actually slowed down my software rasterizer on my old Pentium system, since shifts take both pipelines on a Pentium).

Edit: The point is, forcing power-of-two sizes was simply a necessity, for speed and transistor-count purposes, but recent hardware seems to have spared transistors for it. Of course, power-of-two sizes are also cache-friendly, which is good.

Why is the shift used? When a polygon is drawn, the 3D coordinates are transformed into screen-space (2D) coordinates.
Then, a procedure called scan-converting of the polygon occurs, in which, basically, a polygon is dissected into many horizontal lines, by going through the edges of the polygon.


now that you have many horizontal lines (with texture coordinates, lighting, etc. computed for the edges), you have the most critical inner-loop, which draws them basically, it interpolates lighting values, and texture coordinates, reads from the texture, according to the interpolated texture coordinates, modulates with the lighting, and writes to the destination buffer.
The interpolation of texture coordinates is a simple pair of additions, but the resulting texture coordinates are an X,Y pair. A simple point on the texture. That needs to be converted into an offset inside the memory in which the texture is stored (The texture is generally stored as a simple linear array). the conversion is generally OFFSET = (X + Y*TextureWidth)*BytesPerPixel. BytesPerPixel is always a power of two, so that's naturally a shift, and if TextureWidth is a power of two, that's a shift also. Ta Da!

What an essay... Look at what you've done to me, Sesquipedalian, turning me into a nattering nitpicker!

Balaganist.