Jump to content

Home

Reskinning possible!


Phelon

Recommended Posts

Devanstator:

 

It is able to convert the original into a RAW-RGB-Image, as this was easier for me. Colors were so far off, I was getting a headache. The colors should've been brown tones, but I got only violet tones.

 

Anyhow, I'll be studying how the color changes apply exactly, and maybe figure out the color alteration.

 

BTW, we can use a 32x32 Pixel Image to find out. I've noticed that 32x32 is the exact size the XP gained-Sign, DS-Points gained-Sign (lbl_idside) and the LS-Points gained-Sign (lbl_ilside) are stretched to. And for example the Gizka Skin (C_Gizka01) is exactly 32x32 in size, therefore we can get an image that is not altered in size in the game.

 

Hmm... another guess as well. In all my studies I have never changed the graphic mode, I'm trying to figure it out on 800x600. Maybe when screen size goes up, the image might be stretched more, I haven't tried out yet. So I don't know if the above idea is only applicable under 800x600 or under the other screen modes as well.

Link to comment
Share on other sites

  • Replies 52
  • Created
  • Last Reply

Hmm. The 8-byte encoding definitely sounds like S3TC or something very similar. As for the other, I'm not sure, good luck =)

 

(Edit: I was going to mention this but forgot: in case you were unaware, the extension for these textures is '.tpc' if you want to generate them for your override directory - there might be problems with running out of texture memory if you try using a bunch of TGA textures. Also, at least part of the data after the pixel data (the text part) appears to be the same format as the .txi (texture information) resource type, so you might want to keep that around somewhere as well)

Link to comment
Share on other sites

eiz:

 

Thx for the info. It looks like you've done your homework well. :)

 

You might be right about the S3TC-format... it is very similiar, if not the same. I have not tested yet, but it may very well be that it is handled exactly like that. I'm goin' to try it's color calculation method out. If it works, we've got one of the biggest problems off our hands, thanks to you.

 

That hint on txi-format does make sense. However some of the files do not simply have text at it's end, but an additional number of bytes beforehand, I don't know how to deal with, since the Image ends sooner. Something to research after the color calc. mehtod has been proven right. From looking at the S3TC-format info, it defenitley looks good.

 

BTW, there's also a 16 Byte - Model described in the ST3C-info I found, and it looks like it also matches up.

Link to comment
Share on other sites

So far, so bad...

 

The color calculations of the S3TC-format do not match up with the original colors, though the output is much better than my first bad formula. :(

 

But it seems like they used the S3TC-format for a base on which to build. I'll be playing around with some color variations now, and hope I'll get to the bottom of this.

Link to comment
Share on other sites

I don't believe it's likely that they would use a texture compression format that wasn't supported in hardware directly - it would defeat the purpose of using compression at all.

 

I have written a test program, it only handles the 8byte version but it seems to fairly accurately render those textures. Binary is here, source is here. Give it a .tpc file on the command line.

 

(Edit: err... uh... that will only show the top left 128x128 pixels, BTW. This was mainly for my own use and I didn't really clean up before posting it. If you want to see more, change the BitBlt call)

Link to comment
Share on other sites

Works fine with some Textures, but not with all. I've tried it on "C_Gizka01" and it looked pretty good, but had 2 vertical lines at the right side that were simply not matching up with anything. But not so bad.

 

On the other hand, I've tried to view "lbl_idside", which is the same size, same byte compression, and all I got was blackness, with a few colored dots. That means, something still is going wrong. But you've done well so far... even better than what I am able show.

Link to comment
Share on other sites

Yeah, I don't know what's happening with the lbl_* textures. They were originally 'sort of' rendering, but now I'm just getting junk. I'm sure it's a problem with my implementation of S3TC, however... time for more bug hunting. ;)

 

Edit: Actually, are you sure lbl_* is in the same format? I'm looking at the header and seeing some pretty large differences...

 

Further Edit: Just checked, lbl_* are 16-byte. The Gizka texture shows fine for me, albeit with a black bar on the far right side (although that may be there on purpose). Also, the 1-bit alpha implementation in the version I uploaded is not there, but I have since added it.

Link to comment
Share on other sites

Oops, sorry that was my playing around with the files actually. Exchanged the "lbl_idside" with "C_Gizka01" and played around with it a while. I only had a GFX with BLACK and few colored dots. That's why it ended up displaying garbage. :D

 

About the Gizka Texture... if it really has that black bar, I have not seen it up to now, and I'm positive that it should not be there, unless you've gone outside the image range. Even my litte tool wrongdoing the colors does not show this black bar on the right side.

 

Edit :

 

Is it just my imagination, or do almost all, if not all, 16 byte encoded textures use "00 FF FF FF FF FF FF FF" as pregcognition, before the 8 byte-encoding comes along?

Link to comment
Share on other sites

Yeah, the black bar is definitely a bug, and in addition either I'm getting stairstepping or my interpolation is wrong (likely, I can never remember how to do it) because it's very very blocky and it shouldn't be.

 

Edit: Oops! The black bar was just a trivial arithmetic bug in my call to DrawTileI. I've uploaded a new version. It's still a bit blocky, I think it's because I'm too stupid to figure out the right order to draw the pixels in. =)

 

Edit 2: I believe I have it functioning fairly close to correctly now. At least, it doesn't look as blocky as it did... My eyes aren't too great and I can't tell if it's still got problems.

Link to comment
Share on other sites

i worked at s3 and did some of the original work on that at one point, so just figure i mention a few things:

 

1. although 565 is the most common format, there is also 1555 and 4444 with alpha

 

2. although the most common compression is two endpoints and two mid points (at 1/3 and 2/3), there is also a format with two endpoints and one mid point (at 1/2).

 

3. it might be the simplest way to experiment with this is to use d3d calls to test out the compressions once you have the file loaded. (see msdn dx texture section).

 

4. I did a quick search and manage to find a much modified doc of what i had wrote originally at microsoft at:

http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/directx9_c/directx/graphics/programmingguide/FixedFunction/Textures/compressed/texturewithalphachannels.asp

 

also there is a text version of the attempt to get this into OGL at

http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_compression_s3tc.txt

 

hope that helps

Link to comment
Share on other sites

eiz:

 

Sorry for my late response... I've had a lot of work today, and I'm still not through with it. Will take a few hours... god, I hate a day with more than 12 hours of work. :(

 

If my eyes don't deceive me, you've managed it. From what I can tell, and I don't believe my eyes are far better than yours, it looks very good now. The colors seem to match up exactly, I can't see a diffrence when putting the original and the texture next to each other.

 

aveeare:

 

Thanks for letting us know. Hopefully eiz does find the info more useful than me, since this is pretty much out of my leauge. As anything that has something to do with WIN-Programming, like DX.

Link to comment
Share on other sites

Currently I'm working on a TPC to TGA converter, and I'm having a bit of a problem - the 'encoding type' field in the header seems to have very little to do with the actual encoding type in the file. It handles the DXT1 textures I had been throwing at it fine, and I've written DXT3 support (DXT5 to come - I don't think I will need support for the premultiplied formats DXT2 and DXT4), but, I don't know... look at ip_lightning and lbl_levelup for example. I will continue to look into it.

 

aveeare: Thanks for the information. I've been referring to the MSDN DXTC docs, but I didn't notice any references to a 4444 or 1555 color format.

 

As for testing with D3D, well, I'm more comfortable with GL since I've been a Windows user for a grand total of 2 weeks in this century, but I've definitely been considering it (provided I can get the DX SDK to actually work with MinGW).

 

Edit: Oh yeah, and it also doesn't help that I goofed my pitch calculation... at least I can read those big mainmenu textures now (2048x1024) =)

Link to comment
Share on other sites

eiz:

 

Hmmm... ip-lightning does seem to be in RGBA from a quick look, and givin' the data-length-descriptor (which is zero) would point the same direction like redfill, and the others have done so far. So from the quick glance, I do not see anything wrong, as there's mostly the Alpha Value changed in the beginning.

 

About "lbl_levelup" .... about the center of the file it starts to look somewhat like the Background-Images. What we know is that the second 8 Bytes hold the colors and the pixel bits, I believe it hold true for this one as well. Maybe, I've never said what I've wondered about this format, but I guess it's time.

 

FF 00 00 00 | 00 00 00 00 | FF FF 00 00 | 00 00 00 00

 

did do exactly the same for me as

 

00 00 00 00 | 00 FF FF 00 | FF FF 00 00 | 00 00 00 00

 

and gave me a totally white box. I was trying this one with "800x600back". Any other combination of the first 8 bytes, without the first byte set to FF, has given me black box. It might tell you something it didn't tell me, so I figured I might simply let it off.

 

That's it for me today folks... I'm just done with work and my bed calls out to me. Maybe I can be a little more active again once I've got enough sleep.

Link to comment
Share on other sites

Ahh yes, I had forgotten about the 0 data length = RGBA encoding thing, although I'm still trying to get DXT3 and especially DXT5 which is a creation of the purest evil to function properly. Hopefully I will be able to get it working tonight.

 

As for your experiment, the former 8 bytes of a 16-byte block control the alpha, which should explain your results. Everything else (except the 1-bit alpha mode) is the same as DXT1.

Link to comment
Share on other sites

First off, Hi there. :)

 

Been lurking a little while, and slowly learning how to do some tinkering with scripting and whatnot as I follow along with various threads and whatnot.. This topic holds considerable interest for me, as I've always enjoyed messing with skins and models for various games, though my knowledge of format conversions and extraction and decompiling and filtering etc of various files is very low.

 

Sooo.. First, the noobish question...

Is there a way to actually extract the models as of yet? (and get them into a format which can be edited by any of the various programs for the purpose?)

 

And now my (probably noobish) attempt at helping with this texture thing.. I see a lot of conversation about formats and headers and the like, and while messing around with various files, I came across this little bit of a 2da. (File is texpacks.2da)

 

2DA V2.0

 

desc texture gui strrefname dynmemratio mem

0 32MB_32BIT swpc_tex_tpc swpc_tex_gui 48003 0.750 31457280

1 64MB_32BIT swpc_tex_tpb swpc_tex_gui 48004 0.750 62900000

2 128MB_32BIT swpc_tex_tpa swpc_tex_gui 48005 0.750 134217728

 

Anyways... wondered if any of that is remotely helpful for you gurus who are/were trying to get these things into TGA format and the like.

 

Keep up the good work in any case. ;)

 

-Kitty

Link to comment
Share on other sites

Yes, the game's textures are stored at 3 resolutions for video cards with different amounts of VRAM. You can choose which one you want in the advanced graphics settings, IIRC.

 

As for models, not as far as I know but I'm getting started on that today, since tpc2tga is largely working =)

Link to comment
Share on other sites

okay, not to sound stupid, though i do quite often and probably will again, but this looks like a dos based program, as everytime i try to run it, a little dos window pops up and goes away almost immediately. so, someone refresh my memory on how to use converter programs like this. because i sure as hell seem to have forgotten. :)

Link to comment
Share on other sites

Put the exe in the same folder as the files you've extracted that you're going to want to convert.

 

Then either write a batch file to do them all one after another, or just open a command prompt (start menu, run, "command") and change to that folder with the CD command (remember that for a folder name longer than 8 characters you have to type the first 6 letters and ~1)

 

So like for me it's like this (enter at the end of each line obviously)

D:

CD Games\LucasA~1\SWKotOR\Override

 

Anyways, then the command line is simply tpc2tga.exe <infile_name> <outfile_name>

 

Wise to name the TGA the exact same name, just with the new extention so you can keep them straight unless you're also going to be doing some custom work in the data to point it to new file names for some reason.

 

Hope it helps.

-Kitty

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...