Alternate Image Viewer - Current Version 0.5_D

#1
Hello!

About a year ago, I was working on a tool for image viewing and simple effects, it was called Ultimate Image Viewer... A bad name now that I think about it.

I decided to bring my source code back out and do a little work on it, since I found it while I was looking for my ISO of king's field on my HDD.

I opened it up and found that it was rather plain, with only supporting .PNG, .JPG and .BMP completely. I searched for a few hours for some DLL, and came across Image Magick, a conversion command-line program, with c++ source available... I Complied the available source into some .exes, and found a silent dos dll, so I could call the commands in Image Magick without it coming up... Now, we have...

Alternate Image Viewer - [Ver-0.5_D]

An image viewing utility, boasting compatibility with [b]MANY game formats (including From software's .FSTim and Sonys .Tim!)[/b]

Supported File Types:

[table]
[tr]
[td]
--------------------------------TYPE------------------------------------------Yes=Y, No=N, Limited=X
- AAI Dune image(*.AAI) ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  READ[Y] WRITE[N]
- Windows Bitmap(*.BMP) ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  READ[Y] WRITE[Y]
- Dr.Halo Image(*.CUT) ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  READ[Y] WRITE[N]
- Direct Draw Surface(*.DDS) ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  READ[Y] WRITE[Y]
- Graphics Interchange Format(*.GIF) ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  READ[Y] WRITE[Y]
- Radiance Image Format(*.HDR) ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  READ[Y] WRITE[Y]
- Microsoft Icon(*.ICO) ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  READ[Y] WRITE[N]
- Joint Photographic Group(*.JPG) ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  READ[Y] WRITE[Y]
- Multiple-image Network Graphic(*.MNG) ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  READ[Y] WRITE[Y]
- Portable Float Map(*.PFM)|*.PFM ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  READ[Y] WRITE[Y]
- Adobe Photoshop Document(*.PSD) ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  READ[Y] WRITE[Y]
- Truevision Targa(*.TGA) ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  READ[Y] WRITE[Y]
- Alias/Wavefront Image(*.RLA) ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  READ[Y] WRITE[N]
- Seattle File Works(*.SFW) ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  READ[Y] WRITE[N]
- Sony Playstation Image(*.TIM) ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  READ[Y] WRITE[X]
- From Software TIM(*.FSTIM) ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  READ[Y] WRITE[X]
- Sword of Moonlight TXR(*.TXR) ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  ‎  READ[X] WRITE[N]
[/td]
[/tr]
[/table]


Current features:
[table]
[tr]
[td]
- Import, edit and add simple effects to all the supported file formats, including .FSTim!
- Seek .FSTim and .Tim from bigger files, combining usability with multiple tools!
- Convert an entire directory of images to any of the support write formats!

[/td][/tr]
[/table]

Added in latest version:
[table]
[tr]
[td]
- Save as
- Editing files
- Seeking files
- Applying filter effects to images of all different types, and saving them.

[/td][/tr]
[/table]

Planned:
[table]
[tr]
[td]
- Seeking, converting and viewing of many more different game and games console specific formats..

[/td][/tr]
[/table]

WARNING:[/glow]
before downloading, you should know the differences in version...
Release = a build which is the most stable, I fixed all the bugs of the version which I knew about, and it's more polished.
Development = A build which is very rough, I haven't fixed all the bugs and I haven't finished all the features... You can expect crashes etc... Only download if you want the latest updates.

[glow=green,2,300]Release Version:[/glow] Download Release (V0.2) ‎  (3.30MB) [Windows XP-7]
[glow=red,2,300]Development Version:
Download Development (V0.2) ‎  (8.83MB) [Windows XP-7]
Reply

#2
Neat! Will it extract the KFTIMs from the larger files or does it work on the already extracted KFTIMs?

As far as SoM TXR files, it's been a long time since I dealt with them and I don't have much time to refresh my memory right now. Off the top of my head, there are 3 different sub types which are all similar to a BMP but with a changed header, and they are not flipped upside down like BMPs are in their data.

Like a BMP, they come in palleted 256 or less color variety, a non-palleted "true color", and lastly, low color TXR files for map Pieces have some funky data tacked onto their end that is presumably used for shadows. That data can be discarded when converting to a BMP. ‎  ‎  Confused


EDIT: Hee hee I get a crash when I go to import KFTIM and then cancel. My stuff always does that because I forget to tell the program what to do if the "select" box returns empty. I'm glad someone else does the same mistake. Now I don't feel so stupit ‎  Movingeyes ‎ 
Reply

#3
I fixed those crashes by adding some error handling into the program, I also edited the .TIM and .KFTim file importers etc, when you're converting from .TIM to .KFTim.

I used some of the useless bytes which aren't read by the game to hold the tims VRAM tags etc, just so it has more compatibility, same with the reverse (.KFTim - .Tim) , but holding the loader IDs in the TIM's vram slots.

I didn't make a seeker for .KFTim yet, so you need to have the files already extracted, you can extract bulk .tim files in the new version though, with the help of the command-line tool 'TIMMay'.

Quite honestly, I have no idea how to make file seekers, I actually meant to ask you exactly how you did it for the KFtool.

By the way, thanks for that info on TXR... I'll see if I can get something for it, nice to know some of the specifications rather than dive head first into something I'm not very good at...

EDIT -- REMOVED ALL BUILD INFO -- It's now available in the top post, to save time.
Reply

#4
Checking it out now. Smile

(2013-11-15, 12:38 PM)TheStolenBattenberg link Wrote: Quite honestly, I have no idea how to make file seekers, I actually meant to ask you exactly how you did it for the KFtool.
It's a bit difficult with the KFTIMs as I don't think they have a tag, but since data in PSX games is "aligned" in 4 byte chunks. You'll notice KFTIMs repeat bytes 0x0-3 at 0x8-B. So my tool reads the file being scanned into an array of 4 byte chunks, then compares each 4 byte chunk with the chunk that starts 4 bytes later to see if they're the same.
If fileArray[n] = fileArray[n+2] then ...

If that first test came back positive, it checks again if 0x34-7 and 0x3C-F are identical

If fileArray[n+12] = fileArray[n+14] then ...

If those two tests come back positive, there's a fair chance it's a KFTIM. Then the tool just goes back and extracts/computes the info needed to build the TIM. For example the palette would be in fileArray[n+4] through fileArray[n+11] etc.

To scan for a regular TIM would be the same, but a little easier since they have the header tag "10000000". ‎  Drool
Reply

#5
Thanks dude, I used the last 16 bytes before the .FSTim/.KFTim image data to work it out, like so...

Code:
if(checkByte1 = checkByte4) (I read an int for both of these, so it took the entire 4 bytes.) This is that junk data which is on the 4th row...
{
  if(checkByte2 = checkByte5) (These were both shorts ) //Compares the first width value, and tries to compare it with the second...
  {
    if(checkByte3 = checkByte6) (These were both shorts too) //Compares the first height value, and tries to compare it with the second.
    {
       if(checkbyte1 != 0 ... ... ... ) //it checks if all the bytes don't = 0, this stops it seeing the 'padding' bytes as FS/KFTims in the archives... This part isn't needed, but stops junk files...
       {
        //Sets file start: File position - 64
        //sets the file End: fileStart + ((width*4)*height)/2

        //SLOW RIPPING CODE!
       }
    }
  }
}

I used a few loops, quiet a few loops unfortunately, which has made the code a little slow... I could if I wanted use repeat loops, which inside game maker are a lot faster to work with.
(for loop = 150 - 200FPS, repeat loop = 400 - 450 FPS)...

For an example, for me it takes 30 Seconds to rip all the .KF/FSTims from the RTIM.T archive.

It does, how ever rip all BPP and sizes, which means it should work on any KF/FSTim in shadow tower too... I'm gonna have a look at the PS2 games tonight and see what sorta files they have on em.

By the way... Does the USA version of King's Field have any differences from the European version in the way it structures .KF/FSTims?

EDIT: 0.2 Development build now available in the top post, as well as an explanation on the difference on development and release.
Reply

#6
As long as it works I don't think speed will be much issue since people will probably only be scanning a file once. ‎  Have you found any non-4BPP KFTIMs yet?

I have not specifically checked the images in the PAL KF game, but I would expect it to use the exact same format. I wouldn't be surprised if Echo Night and other Fromsoft games from that era use the same custom loader setup, and therefore this ripper might work for them too.

EDIT: Would you mind if I moved this to the "Tools" section? I would hate for it to get buried in "general" and lost.
Reply

#7
I had a look at the .txr format today, from what I can tell so far it looks pretty easy to work with, but I could be mistaken...

I should be able to get the .txr working for now. I won't be making it read monochrome TXRs though, since I can't get a reference for that, and it's only two colors (???) ‎  ‎  , meaning that it wouldn't fit into a single row of bytes on the header... making my time writing the importer and converter a pain in the ass... For notice, once it's done you should be able to import, and save the file as anything -- But you'll have to make the format a .bmp before you can save it as a TXR... I'll look into making that different in the future.


Attached is a document on the .txr file format, in case anyone wants the data.
Just for notice though, I'm kinda new to all this, so it's probably not perfect.


Attached Files
.txt   TXr - INFORMATION.txt (Size: 1.44 KB / Downloads: 175)
Reply

#8
The TXR info is very concise and clear- thank you for that. I should have made such a document when I was working on the format but I didn't, and promptly forgot almost everything ‎  Tongue

I'm quite puzzled at the purpose of the extra data on map Piece TXRs. I can't image a reason to recopy part of the image. Do you know if that bit of repeated image is tacked onto High-Color map Piece TXRs as well?
Reply

#9
Yeah, it is. I've actually started writing the TXR importer with high color.

It was because of working on high color first that I was able to tell it was just a repeat, since high color is 3bytes per pixel - aka R is one byte, and so is B and G... because of that, and comparing it with the regular .txr, you can see that it's the same data, just more of it... just rgb values...

The importer so far scraps that data, since it's really not needed for BMP, and it will be easy to calculate when reversing the process (bmp - txr)...

Pretty much instead of taking the entire file, I've just made it do some simple math before it imports... (width*height)*3... I don't think this will work if a file has a CLUT though. Not looking forward to working on the BMP and TXR style of cluts, they both look really, really messy...

When I have the 256 (16bpp) loader done, I'll release a version update -- It'll mean this one stays on development for a while longer though...

Hopefully when this is all done, it'll provide a more convenient way for people to get textures back from the .txr, than the 'map piece viewer' technique I've seen floating around
Reply

#10
The palettes for TXR and BMP are identical so you shouldn't have to do any processing co convert between those formats at least. I don't know what input format your tool requires to output PNG etc. though. The PRF editor tool in the tools section here has a TXR <-> BMP converter built in, but it doesn't preview the image or convert it to other formats.

Incidentally, the extractor/converter tool works nicely! I wasn't able to see a preview of the images with the Development Build though. Is it supposed to have one?
Reply





Users browsing this thread:
2 Guest(s)