-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pic.arc weird texture headers #84
Comments
some of the textures have this extra header but it appears to be random (there are files with the same size and color depth with and without the header). |
I just tried this by removing the header from data/pic/sy/sys_title.tex, which is the main menu's SILENT HILL 3 background. This was the result.... It also caused all files stored after data/pic/sy/sys_title.tex to not draw, but I think is because of the difference in arc offsets. Still, this is really strange, I'll have to investigate this. I have no clue as to how they work out which textures have this extra header, perhaps it's for static background images? (Meaning we'll need a ANOTHER class for that as well....) Also, here's what happened when I removed the header from sys_warning.tex (which comes AFTER the title in pic.arc, explaining why that still draws correctly) EDIT: I just did a quick count, out of 301 |
Even if I replace the whole header with ´FF´ it still works fine. Perhaps this header was used in another game on the same engine, or just for the PS2 version? Just to make things work for now we could just check for the presence of the |
Ahh, I neglected to think I was upsetting the offsets in arc.arc... You're right it still draws correctly.
I reckon it's this. You're probably right in saying it's something for the PS2 version. The dev team for the PC version was separate from the PS2 one, so they probably got a whole lot of assets dumped on them and told to make it work.
Yeah I just put this in. I'm redoing the texture class (again), because I managed to find some code where someone had actually worked out how to decode 16 and 8-bit textures.. Turns out the palette comes at the END of the file and is stored in these weird colour blocks.. Super bizarre... Oh, and some of them are compressed and have a weird form of 'encryption'. They must have REALLY not wanted people to try and mod the game..
I'll get on this. I'll write a few tools to dump .arc stuff to actual files (so we don't have to clutter up
Perhaps. I noticed that it seems to exist on all the textures where the image is drawn to the entire screen. Also, it would seem embedded textures (in the Either way, it seems bizarre, as Also note that the file size actually takes this header into account, though this could be because of the tools they used to pack the |
As far as I remember the PC version uses the same exact files as the PS2 one (even the unused stuff is still there). They only added support for loading their raw BMPs and encrypted the videos. |
I noticed this as well and thought it was hilarious seeing _work directories and test.tex files haha. It wouldn't surprise me if this was for some necessity for the PS2 version. Do you know of a way I can view/rip the assets of the PS2 version from my disc? |
In the PS2 version the assets are packed in the mfa files. They're simpler than the arc files from the PC version. |
Cheers I'll try it out later. |
Hi |
Thanks @belek666. We still have a 16-pixel wide column on the left that we do not decode correctly with our implementation. Hopefully this information will shed some light on it. |
Hi @belek666 Interesting, so it's not a form of quasi-encryption, but rather swizzled textures decoded on the GPU (on the PS2 version)? The more and more we dig, the more and more we're seeing how much of a pure port of the PS2 version this actually is. Thanks for the heads up, and as @z33ky said, this should help us with the horizontal 16-pixel shift we currently have with the decoding of the 8-bit paletted textures. |
They used it to speed up uploading textures to ps2 vram. There is source code of gs memory simulator in GSTextureConvert-1.1.zip which can be used to swizzle or unswizzle. I've used it to write converter for textures from silent hill 2 & 3 with those function:
|
Do you plan to use game's fonts? Their compression algorithm is the same as sh2 fonts. I can send you unpacker code adopted to sh3 file format. |
Hi @belek666
Yes we do!! Any information/help you give would be greatly appreciated! Perhaps it would be easier for you to open a Pull Request (if you have time). If not, just send the files through, it'll be a great help! :) As a side note, where exactly are the fonts located in?? I could never seem to find them in any of the .arc sections. |
Fonts are in msg.arc in files:
In each file there are two set of fonts with different height. There is also some data at end but I don't know what it is. Character encoding correspond to text in msg files. |
Thanks very much for the contribution, I'll have a look at this later. |
So is each character/glyph stored as a texture that can be sent to the GPU (from the looks of the pixel is grabbed from the palette when the character is decoded). |
Yes, I'm not sure if pallete is correct because I didn't find it in sh3 files and I took it from sh2. After decoding you get raw rgba32 data. |
Okay cool, when I've got some time that is being consumed by uni I'll have a go implementing this + a shader to draw them. Could I get your full name so I can add it to the file comment (the @ author tag) |
Hi, I'm having a bit of trouble testing the code provided. If I'm correct, Could you possibly elaborate on the format a bit more? |
So its ok now? As for credits, unpacking algorithm was given to me by Dencraft author of "Silent Hill Font Editor" (program for sh2 fonts, never finished). I adopted it to sh3 format. If you want you can credit me by nickname. |
Done
I'm still having issues drawing the raw data. Is there any specific way it needs to be rendered? I can see that it at least has the same amount of colours that a single glyph would have, but it's still all garbage. |
Function "DecodeChar" unpacks single glyph by specific char encoding number in argument. In my code, in main function there is "numChar" which define with char will be decoded. Its set too high and that why you are getting garbage data. For example: for "a" set "int numChar = 'a' - 0x20;" |
Hi, sorry for the late reply. I'm still getting garbage, even with The following image was taken with The following was taken using The main thing I'm surprised about is the character glyph corruption. Are you developing on Windows or Linux? I don't really have much time to debug, but I'll give it a crack on Linux in the next few days. |
I'm using our own code found in SH3/arc/*.cpp... Paging @z33ky , we might have some issues in the arc loading section again.... Anyway, here's the font files and corresponding MD5 Checksum (for good measure) P.S Sorry for using a file sharing site, but apparently ZIPs aren't supported on GitHub, even though they are... rollseyes http://s000.tinyupload.com/index.php?file_id=05835222736118477031 fontdata_j.bin MD5: E14FF96C7AD917A25EF6BB23C5A83A40 |
You have something wrong with arc file management. It looks like it adds extra bytes, even size of file is bigger. |
@Quaker762 Nice work! 👍 |
So I was trying to load a few textures to try and bind onto a quad, when I noticed I was getting strange reads from
sh3_texture
. As it turns out,pic.arc
contains a weird header (I've taken to calling '40-bytes of bullshit') before the actual header, as seen below..It would seem not all textures have this, and the only way to check would be to dump every texture file from pic.arc, which is possible.
How do you suggest we tackle this? I can always e-mail Mike or some other SH3 modders if we get too stuck. I thought it may have been the elusive colour palette for 8-bit textures, but it seems it's the same 40-bytes, even for 24-bit textures...
The text was updated successfully, but these errors were encountered: