ff9.img directories and files

[Tonberry]

I was able to add some textures to the WM, not like I wanted to but they don't look too bad. Especially considering I like the CAD/technological look.

I posted 3 images to the trash bin provided by mirex (Thank you!), so they'll probably disapear.

In the first one you'll see the landscape near Esto Gaza and Shimmering Island.

http://bin.mypage.sk/FILES/FF9_WM1.GIF


In the second one you'll see the Lifa Tree.

http://bin.mypage.sk/FILES/FF9_WM2.GIF


In the third one, some texture mapping.

http://bin.mypage.sk/FILES/FF9_WM4.JPG

You'll notice it doesn't look right, but look closer at Dali, the Observatory and that landing circle in between and you'll see the mapping is right.

Now, to work on the proper textures, as there are lot of problems.


----------------------------------


Cyberman, besides what halkun sugested (looking for known headers, with which I can't help much and looking for modules which is what I've been trying to do), I'd sugest you take your time to classify things. I'll tell you the way I started with all this in the hope that it may be useful; maybe you did the same and think it's obvious, but I don't know.

1 - Look for files and directories. Didn't work.
2 - Look for TIMs. Found a lot, grouped logically.
3 - Create 1 file for each block of unknown data; that is, the parts that weren't TIMs.
4 - Look for images without header. It's time consuming, but helpful.
5 - Take a look at 4 or 5 files with unknown data that are near a group of TIMs or headerless images and compare. (This was when I noticed the DB NN 00 00s and some of them aligned to 0x800 bytes.)
6 - Take the group of files that seem easier/shorter than the others and study them deeper. (I decided to go with the info near TIMs of weapons, as they wouldn't have animation.)
7 - Look deeper into the DB NN 00 00 stuff for weapons. I found lots of unknowns, but also a lot of similar data.
8 - See if similar data is near pointers in header. This, with the presumption that there weren't overlaping sections was extremelly useful to further subdivide the DB NN 00 00. There I found vertices, triangles, texture mapping and some blocks with the AKAO string. I was able to make sense of the geometry, but not from the AKAO thing.
9 - Look in Internet for AKAO. Not many results on data format, but many about the sound programmer for FF games. Leave for later.
10 - Once with the model for weapons "complete", look near enemies' TIMs. I recognized a lot of the structures as they were the same as the weapons'. (At this moment I found a lot of DB NN 00 00s.)
11 - Dump the first 64/128/whatever number of bytes of the ff9.img starting with DB NN 00 00. I grouped them by the NN and I finally understood them.
12 - Take the previous unordered dump and look for containers.
13 - I found the biggest container for every weapon and enemy, and noticed every container was bound to 0x800.
14 - Look for files and directories with this extra info. Eureka!

The rest is pretty obvious: Separate the files found and do some checking.


The thing is I started trying to reduce things from the whole, but ended up making some "holes" and building from that.
I also started very orderly, but I had to rewrite so many times the code when I discovered something new that I decided it was no use. I was spending more time writing code than looking for things.

For model construction is there a a set of vertexs and bones with seperate animation controls?

I didn't get to find animation data.


I'll start with the classification of images and their respective files and dirs tomorrow.

 

[Cyberman]

There has been a long calm.  :lol:
In any case I've been quietly (noisely is not possible) working on a better UI and processing the data files.
However I've discovered a few things about DIR00 and it's associated files
F<00>000 contains only 1 DWORD in little endian format (00000015) or 21 in decimal First word..
The first DWORD I believe identifies the file (hmm).
F<00>001 begins with 00000005
F<00>002 begins with 00000006 and is followed by 'Disc Cover Open\0'
F<00>003 begins with 00000007 it also has a number of printf format strings in it such as
"Illigal Animation Data" <--- actual data hehehe
"w_movementChange : %d -> %d\xA\0"
"MAP JUMP\xA\0"
"w_frameMapDestructor:\xA\0"
"w_frameSystemDestructor:\xA\0"
"*[ Request from script:Weather:%d ]\xA\0"
"*[ Request from script:Navi Active:%d]\xA\0"
etc.
F<00>004 begins with 00000008 it has a number of words that run together
It contains a load table of locations within the PS1 memory and a series of phrases
"ENEMY CARD SELECT\xA\0"
My guess is this is the card game
F<00>005 begins with 00000009 it also has a long load table of PS1 memory locations.
F<00>006 begins with 0000000A has a short load table and has a few printf format strings in it
"%2d Bankroll\0"
"%ld Wager\0"
"Stand\0"
"Hit\0"
"Double\0"
"Split\0"
F<00>007 begins with 0000000E
F<00>008 begins with 0000000F
F<00>009 begins with 00000011
F<00>010 begins with 00000010
F<00>011 begins with 00000012
F<00>012 begins with 00000013
F<00>013 begins with 00000014
It has words such as
"File00\0"
"/DISC\0"
in the begining
F<00>014 begins with 00000015
has a PS1 memory load table at the begining
(5) locations
F<00>015 begins with 00000016
F<00>016 begins with 00000017
F<00>017 begins with 0000000F
that's all that is contained in it
F<00>018 begins with 0000000D
and looks to have a TIM file in it.

I'm getting false positives reguarding the DB files (mutter) so I may need to work on that a bit more
Current screen caps.
Directory Information (woo?) including those pesky 0xDB encoded files
http://www.geocities.com/cyberman_phillips/Images/DIR04_1.JPG
Hex Dump of first data section of first file on screen.
http://www.geocities.com/cyberman_phillips/Images/DIR04_2.JPG
Note: These are linked because the system killed the images so there was no point in putting them in with \[IMG\] \[\IMG] usage. All Images appear to be restricted to 640 pixels across.

Cyb

 

[Tonberry]

Hi, again! It's nice to see the forums are back.

I haven't done much lately and won't be able to do much for the next couple of weeks as it's crunch time at work. I'll post a little more info then.

Anyway, I'll comment a little bit on your data and our differences.

F<00>000: Has some JPEG tags.
F<00>017: Begins with 00000014. The rest is 00000000.
F<00>020: Begins with 0000000C.

The other numbers match.

Were you able to solve the false positives with the DBs? Where are you having problems?


What I was able to figure out a little after the forums went down:
- Some of the fields I marked as unknown in the WM struct. (I still have to add textures to the ground.)
- Some other WM related data in DIR03. (Model for little Zidane, Chocobo, etc; textures for the ground and text/dialog for the WM.)
- Partial in-game text encoding.
- Some parts of the files in DIR13 that could be used to further subdivide them. (Not complete.)

DIR02 has only text (and some tables to index the text). Each file contains the dialog to a section of the game:
- F<02>000: Intro, theater play (the one about the canary).
- F<02>001: Intro, Vivi in town and Steiner looking for the princess.
- F<02>002: Escape from the forest.
- F<02>003: Ice Cavern and Dali.
- F<02>004: Lindblum.
... etc.

There's a lot of encoded text in other directories, including DIR00.

In the DB structures, text blocks (or files) have "type" 0x06.


I looked at the wiki info on FF9, and I have some comments, as some info is not what I have:
- In the "Root Directory Header", the "Signature" field ends in 0x00, but in the FF9.img I have it is 0x20. (The padding for the Root Dir is the same.)
- In "Sub Directory Information --> File Size information" it says:

The last file is a bit different you need the sector of the next sub directory file list and subtract from that the first sector of the file you wish the size of.

Maybe I'm reading it wrong, but the way to get the size for the last file is quite similar to the previous files, as the last element in the structure has 0xFFFFFFFF in the "Flags" field and the "First Sector" field points to the first sector after the current sub-dir (which is the same as the first sector of the next sub-dir.) I forgot to mention that in my previous posts.

Some other thing I'd change (feel free to ignore this) to the wiki is the description for "Directory Types" 0x03; I wouldn't use the word "Heirarchical", but perhaps "Indexed" or something like that, as there are some blank entries (0xFFFF) that make me think there were effects/summon data left out, but the place was kept to access every file by an index that wasn't easily changed in the application. (I simply don't see the hierarchy.)

 

[Cyberman]

1) JPEG files are unlikely to be in a PS1 game.

2) my computer crashed so I'm waiting to restore my files (sigh).  To be precise the Hard Disk expired mostly.

3) I'm trying to not scream a lot. From frustration with crashing software.  I think my MB is partly to blame.  Life goes on!

4) DIR02 is likely script data.  This means FF9's engines is a bit different in how it organizes it's data compared to FF7.

Since FF9 is a linear progression game it means that it's likely the script and text for each part of the game progression is located in DIR02 in the order they appear.  That also means that you should find the tutorial things that appear during the game in there as well.
If you find there is more data than text then it's script if not the script is hidden elsewhere.  It would be good if you could discover this though

I suppose I need to restore my code ASAP

Hopefully I can cool my dead HD brain a bit to do so

Cyb

 

[Tonberry]

Sorry to hear about your computer crashing. (That reminds me to backup.)

1) JPEG files are unlikely to be in a PS1 game.

Yes, now I think so too, but the tags are there and I wasn't able to decompress any image. Perhaps they were added while translating the game. Anyway I don't mind too much as your file is almost empty and I couldn't find similar tags anywhere else.

4) DIR02 is likely script data.  This means FF9's engines is a bit different in how it organizes it's data compared to FF7.

Since FF9 is a linear progression game it means that it's likely the script and text for each part of the game progression is located in DIR02 in the order they appear.  That also means that you should find the tutorial things that appear during the game in there as well.
If you find there is more data than text then it's script if not the script is hidden elsewhere.  It would be good if you could discover this though Cheesy

You are right, the text follows the script order and there are tutorials, but no, there's no script. Well, I think there is not enough room for a script language there.
The text strings include some control characters (<cr>/<lf> like) and argument placeholders (similar to %s from printf.) There are a lot of characters I haven't looked up, but they appear sparcelly and seem to be punctuation marks or special graphics.

Before the text there is a table with pointers to every string in the file. Each entry has some attributes that as usual I don't know what they mean, and they could reference a script somewhere else; but it seem unlikely as there are a lot of repeated values.

So, the script must be somewhere else. I was thinking the Field directory (DIR04), the World Map 2 (DIR03), DIR01 or DIR00.
The text/dialog should be referenced in the script by a numeric index and assuming the state machine used follows the script, a lot of those consecutive indexes should appear in short distances. That could help automate some search, but I'd prefer to fill-in some easier blanks first.

Rereading this comment I just remembered Zande had mostly all of this figured out long ago. I'll have to check his comments again.

 

[halkun]

You know, you should really start nameing these directories. It will make things a little more standard and easier to read.

I mean it can't be any different than FF7's

INIT
ENEMY
WM
MINI

 

[Cyberman]

You know, you should really start nameing these directories. It will make things a little more standard and easier to read.

I mean it can't be any different than FF7's

INIT
ENEMY
WM
MINI

It's a thought save for the fact the directories are offsets from a table.. and the files are offsets from a table. So there are no names readily available.  Also the index value cannot be directly associated to a name unless one memorizes what the index value of a name is.  My memory is crap of late, so I know I would constantly have to use a little sheet irreguardless of the names.
When we finish hashing out the information contained in each directory I suppose it would be more functional to do it that way. As yet we are acertaining what files are where and such.  It would be nice if the scripting were the similar to FF7 and FF8's format.

Cyb

 

[Tonberry]

I agree with both of you.

Naming dirs and files can help people understand where things are located and such, but as Cyberman pointed out it is too early to do that. I'd suggest to simply create tables mapping the numbers to a short description so people interested can use them and don't get lost. But I'll keep on using numbers until things are a little more clear. (Anyway I wouldn't mind explaining something without the numbers if necessary.)

I think the table Zande provided for the directories is a good start. Now that I can read some of the encoded text, I'm doing a similar table for files in DIR00 in my free time (not much).


For those interested in reading the encoded text I found, I'll post this table:

Code: [Select]

    0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F +---------------------------------------------------0|  0  1  2  3  4  5  6  7  8  9  +  -  =  *  % SPC1|  A  B  C  D  E  F  G  H  I  J  K  L  M  N  O  P2|  Q  R  S  T  U  V  W  X  Y  Z  (  !  ?  "  :  .3|  a  b  c  d  e  f  g  h  i  j  k  l  m  n  o  p4|  q  r  s  t  u  v  w  x  y  z  )  ,  /  º  ~  &5|  6|              á                       Ã­7|  ó           Ãº8|9|A|B|     Â¿C|D|E|F|                       \n

SPC=SPACE (0x20)
\n=New line

It's not complete, as I've added only the bytes I verified, but it should be enough to read some text; especially the dialog, some debug messages, and the text from the menus.

The row number is the most significant nibble in a byte and the column number is the less significant nibble. You'll have to convert that byte to the character inside the cell in those coordinates.

It's not too difficult to get the position for other characters as they can be found in some of the TIM images of fonts.
I already know how to get the image for each individual character from the font image, but I haven't looked too much into it so I'll leave that for when I have more time.

If anyone feels like completing the table I won't mind.

A note: there are probably similar tables for other fonts.


Besides that, I have a description of what I know is inside of F<00>013. It's interesting as I was able to recognize most elements from the first half of the file, but I think I won't be able to know what's inside the other half just by looking at it.

File F<00>013 seems to be the "load/save game" menu. Just to give some bad news to Cyberman ;D, I wasn't able to find a header nicelly describing the components, plus I think it's the same thing for all DIR00 files. My only hope is that those elements are pointed to from a script.

I won't give the offsets of my version, as they'll surelly be different for the English version; or any other language for that matter.

Code: [Select]

(4 bytes) File identifier? (=0x00000014)(4 bytes) Unknown (=0x00003030)(8 bytes) String "/DISCO" padded with 0x00. (Translation: "DISK")(4 bytes) Unknown (0x00)(2 bytes) Unknown (0x7e)(2 bytes) Unknown (0xe0)(4 bytes) Number of pointers to strings that follow. (=0x3a)Pointer to string:  (2 bytes) Number of bytes (relative to offset of first pointer) till the first char of the string.  (2 bytes) Unknown. (Attributes of string?)... (Repeat for every pointer.)Encoded string. (Variable length.)... (Repeat for every string.)(256 bytes)  CLUT for Zidane. (entries=128, 16bpp, size=256 bytes)(1472 bytes) Picture of Zidane's face. (width=32, height=46, size=1472 bytes)(256 bytes)  CLUT for Vivi. (entries=128, 16bpp, size=256 bytes)(1472 bytes) Picture of Vivi's face. (width=32, height=46, size=1472 bytes)(256 bytes)  CLUT for Garnet. (entries=128, 16bpp, size=256 bytes)(1472 bytes) Picture of Garnet's face. (width=32, height=46, size=1472 bytes)(256 bytes)  CLUT for ***. (entries=128, 16bpp, size=256 bytes)(1472 bytes) Picture of ***'s face. (width=32, height=46, size=1472 bytes)(256 bytes)  CLUT for Steiner. (entries=128, 16bpp, size=256 bytes)(1472 bytes) Picture of Steiner's face. (width=32, height=46, size=1472 bytes)(256 bytes)  CLUT for Quina. (entires=128, 16bpp, size=256 bytes)(1472 bytes) Picture of Quina's face. (width=32, height=46, size=1472 bytes)(256 bytes)  CLUT for Eiko. (entries=128, 16bpp, size=256 bytes)(1472 bytes) Picture of Eiko's face. (width=32, height=46, size=1472 bytes)(256 bytes)  CLUT for Freya. (entries=128, 16bpp, size=256 bytes)(1472 bytes) Picture of Freya's face. (width=32, heigth=46, size=1472 bytes)(256 bytes)  CLUT for Amarant. (entires=128, 16bpp, size=256 bytes)(1472 bytes) Picture of Amarant's face. (width=32, height=46, size=1472 bytes)(256 bytes)  CLUT for Marcus. (entires=128, 16bpp, size=256 bytes)(1472 bytes) Picture of Marcus' face. (entries=128, 16bpp, size=1472 bytes)(512 bytes)  CLUT for "passing pages of a book". (entries=256, 16bpp, size=512 bytes)(5808 bytes) Picture of "passign pages of a book". (width=176, height=33, size=5808 bytes)... (Rest is unknown at the moment and is barelly half the file.)

The *** above means I don't remember the name of the protagonist, but if I'm not wrong it's Dagger. I really don't remember if Garnet changed names and the picture of her face changed in the menus as well.

The "passing pages of a book" is, as I mentioned before, the animation of the book that appears when the game is opening a memory card.

After that image I don't know what's in there. That may be a good place to look for some script or compiled code but I don't know machine code nor assembly for the psx and neither do I know ff7 nor ff8 scripting language. So, if anyone could look a little bit into it, please...

It's quite homogeneous and if it was a 8086 architecture I'd go for code, but I might as well be completelly wrong.

 

[Cyberman]

It's not bad news that's good news. I suspected DIR00 of being odd.  I believe this to be splash screens and menu things for the game now. (MENU? )
In summary things are potentially better because of this.
Hmmm I believe there is a font that looks similiar to your matrix coding for text.. I'll have to nose around for it.

The game has a script somewhere, but where is the question, finding the script data is likely going to be troublesome I suspect.

It may be in DIR02 but not with the text... only time will tell.

Erstwhile I am looking at cooling my hard disk and trying to get the data off of it (or at least Hoping too).

Cyb

 

[Tonberry]

It's not bad news that's good news. I suspected DIR00 of being odd.  I believe this to be splash screens and menu things for the game now. (MENU?)

I was just kidding about the bad news, but I'd prefer headers in the files. I agree with the MENU designation but there can be some exception to it.

It may be in DIR02 but not with the text... only time will tell.

All the files in DIR02 have this structure:

Code: [Select]

(4 bytes) DB structure with one sub-element. (Always DB 01 00 00)(3 bytes) Pointer to first (and only) sub-element in DB struct. (Always 0x04)(1 byte)  Type of sub-element. (Always 0x06. Text array?)First sub-element:  (4 bytes) Unknown. (Always 06 01 00 00)  (4 bytes) Unknown. It's incremented by 1 or more units with each file.  (4 bytes) Unknown. (Always 08 00 00 00)  (4 bytes) Pointer to first byte after last string. (Pointer to slack space.)  (4 bytes) Number of string pointers.  Pointer to first string:    (2 bytes) Number of bytes (relative to offset of first pointer) till the first char of the string.    (2 bytes) Unknown. (Attributes of string?)  ... (Repeat for every pointer.)  First encoded string. (Variable length, ends in 0xFF.)  ... (Repeat for every string.)(0x00 padded to complete last sector.)

As you can see they are quite simple. Every file is "text oriented" (meaning they define arrays of strings and not much more.) As I said before, the only relation to a script can be defined in the attributes or by some special character inside the strings, but there aren't many examples where that's possible; and there is no chance to find a complex script there.


---------------------------------------------

Mmmmmm.... Just a correction, as I messed up a bit with the description of F<00>013 (save/load menu). I said I couldn't recognize the second half of the file and thought it could be code, but from a comment by halkun I realized I was missing something. I opened a memory card image and found the first 256 unknown bytes into it. (So much for code.  )

 

[Tonberry]

I think I found assembler code in F<00>013 (load/save game menu), and I mean "valid" assembler code; but it would be great if someone with experience on the psx could tell me if I'm making any mistakes.

I made some quick routines to disassemble the portions of F<00>013 that I couldn't classify and I found something like this at the very begining:

Code: [Select]

* ADDIU  $sp, $sp, 65504  ...  JR     $ra  ADDIU  $sp, $sp, 32* ADDIU  $sp, $sp, 65496  ...  JR     $ra  ADDIU  $sp, $sp, 40* ADDIU  $sp, $sp, 65512  ...  JR     $ra  ADDIU  $sp, $sp, 24* ADDIU  $sp, $sp, 65488  ...  JR     $ra  ADDIU  $sp, $sp, 48* ADDIU  $sp, $sp, 65464  ...  JR     $ra  ADDIU  $sp, $sp, 72* ADDIU  $sp, $sp, 65472  ...  JR     $ra  ADDIU  $sp, $sp, 64* ADDIU  $sp, $sp, 65448...etc.

Now, if I'm not mistaken, those should be typical entry/exit points for functions, as the instructions marked with an asterisk reserve certain amount of memory on the stack and the one after the "JR $ra" frees the same amount of memory.

I tried with other files from DIR00 and got similar results.

 

[scmark15]

I was bored and decided to play with Tile Molester, I found the Change Disc Images & Game over screen...
*Note: I used Zidane_2's ff9_extractor and db_extract programs to tear apart my ff9.img...

I redownload img and db extractors to:
http://zidane_games.webhost.ru/FF9_TOOLS.rar

And upload new version of the "battle scene viewer":
http://zidane_games.webhost.ru/New_viewer.rar

In new version i fix old bug with textures ))

Archive contain old and new versions and 2 files for example.

Code: [Select]

Dir 01 file 2 (Standard 16bpp TIM File):Game Over ScreenHeight: 224pxWidth: 320px

Code: [Select]

Dir 01 files 7-10:Change Disc 1-4...after a little cut and paste...Height: 224pxWidth: 320px

...One thing I noticed is that the right half is missing 19 (8x8pixel) tiles from the bottom right of all of them...

*Edit .... Searched through the original ff9.img file (too big to open with tile molester) using my hex editor and
cut out about 1400 bytes and pasted it at the end of the 7th file in the 01 directory saved it as a new file and
tried to view it again and the missing tiles are there now. I have no idea why it got cut off, maybe a problem with
Zande_2's ff9_extractor, I don't know C++ so I can't tell ^_^ (my original ripped 7th file is 143, 360 bytes).

Best viewed settings for change disc images...
Codec: 16bpp ABGR (1555) *Corrected*
Mode: 2-Dimensional
Zoom: 100%
Width: 20 (8x8 pixel) tiles
Height: ?????? (don't feel like counting)

The image will be cut in half with the right half of the image below the left half.

I know a little hex but I really gotta learn Visual C++ so I write my own custom TIM/file viewers.
Any recommendations on books/commented source (I like the cut, delete, paste method of learning also) that would help, I'd greatly appreciate it!

Thanks,
scmark15

 

[Cyberman]

I'm afraid not much source code exists for TIM file reading.
I have header information for the file type however.
I believe the TIM images on FF9's change disk screens are 320x224.
Since most of the TIM images that are directly readable are 16bit (this includes background images). They are very easy to decode, save the back ground images although 16 bit TIM's include palettes. I suspect they did this to make things easier programming wise.

Code: [Select]

#define  _PSX_STRUCT_H_//typedef  long           INT32;//typedef  unsigned long  UINT32;typedef  short int      INT16;typedef  unsigned short UINT16;typedef  char           INT8;typedef  unsigned char  UINT8;typedef struct{   UINT32   Magic;   UINT32   Type;} base_tim_hdr;typedef struct{   UINT32   WCount;   UINT16   IMGX, IMGY; // origin of image   UINT16   Pitch;   // in 16 bit words per horizontal line   UINT16   Height;  // number of lines;} base_tim_img;typedef  struct{   base_tim_hdr   INFO;   UINT32   Bytes;   UINT16   PALX, PALY;   UINT16   ZZ01;   UINT16   CLUT_CNT;} tim_4bpp;typedef  struct{   base_tim_hdr   INFO;   UINT32   Bytes;   UINT16   PALX, PALY;   UINT16   ZZ01;   UINT16   CLUT_CNT;} tim_8bpp;typedef  struct{   base_tim_hdr   INFO;   base_tim_img   IMAGEDAT;}  tim_16bpp;typedef  struct{   base_tim_hdr   INFO;   base_tim_img   IMAGEDAT;}  tim_24bpp;#define  TIM_4BPP    8#define  TIM_8BPP    9#define  TIM_16BPP   2#define  TIM_24BPP   3#define  TIM_MAGIC   0x10// Pallette/Color Look Up Tables for TIM filestypedef  UINT16 CLUT_4bpp[16];typedef  UINT16 CLUT_8bpp[256];

The code I have simply will not work for whatever you are using it for (It is VCL specific).
The best method is to convert the BGR16 (note it IS 16 bit data not 15 bit don't forget this EVER as that could really mess things up if you do).
The data in all tim's other than 24bpp is 16 bit WORD sized ALWAYS and more importantly it is NOT BGR15 data EVER. I repeat it WILL be a big mistake if you assume that.  Why? Bit 16 is the ALPHA bit or mask bit.  IF it is set be VERY wary of the data that's associated with it.  It can indicate any of 4 modes of transparency and this IS used in FF9 background data. FF9's background data is 16 bit TIM information, however they use a custom method to decode the data in the TIM (IE it's internally not 16bit data ). 
My suggestion is start with the data you have the header information I've included should be enough to get you started and look at the wiki for further details on TIM images.

 

[scmark15]

Thanks Cyb!

I was just messing around with Tile Molester and found them accidently, they weren't found
with any TIM viewer/scanner (Yuri 0.99e, Tim Viewer, PSXMC, etc...) that I had.

I realized that they were actually 16bpp after when I viewed them the second time after reading
qhimms wiki on TIM files with the extra 1400 (approx) bytes pasted at the end (to see if the
missing tiles would appear). I just found them by accident with the 15bpp BGR (555) codec setting
first, they display the same (or there is an un-noticable difference). In Tile Molester they are not
colored correctly  at 16bpp BGRA (5551) or any other display codec but at 16bpp ABGR (1555)....
I'm not including the 15bpp (555) setting ^_^.

Just thought that others may wish to view them ^_^.

---------------------------------------------------------------------------------------------------------------------------------------

I have Visual Studio (6 & 2008 .Net) as well as Borlands C++ & Delphi (My old mans a
programer/systems analyst). I have very little programming experience (I know HTML, PHP and a
little hex) but want to learn C++, I've played with MS Visual C# .Net and Visual Basic as well as
Borlands Delphi but have no idea where to start with C++, like should I start with Borland C++ or
MS Visual C++, what is the difference. Any recommendations on language and/or books for
beginners would be greatly appreciated.

!!Thanks again!!,
scmark15

---------------------------------------------------------------------------------------------------------------------------------------
PS Cyb,

Thanks for the code! I'll save it for later.

 

[Cyberman]

A few Things VCL (BC++) makes things very easy. However MS created C# to countermand this concept (IE that coding for there SDK is a pain in the arse).  It's now 6 of this half dozen of the other.  It may or may not be easier.  the important thing is to use what you have examples of that you can make work.  BCB was what worked for me.  (It really is Rapid Application Development) If your father (petrarch), can help you with it that's even better. 

I used VCL because I have little patients to build wheels over and over again (VC++). C# is a bit easier ... a bit. It does have a large learning curve. Also it is not C++.  My opinion on it aside, it is what it is.  Don't be worried I guess I'm getting old and inflexible

Anyhow try one thing and stick with it, don't use Visual Basic.. too many limitations, it's for business oriented applications not something that would require some pretty precarious methods of getting at data.  C++ or C# is a better bet.

Cyb

 

[scmark15]

Thanks Cyb! I picked up some books that my father recommended, he also recommended some webpages that show examples and source. Unfortunently though he's grown accustomed to working with Microsoft Products (the company he works for has deals with microsoft, one of the CEO works for MS also) but he told me to start with Borland C++ and then give Visual C++ a try a little later down the road, and he also recommended a while back to learn C# (that's why I dabbled with it).

Anyways...Time to crack open some books

Thanks again Cyb!
Scmark15

 

[Zidane_2]

Some info:

Dir 0:
File "1" - Field Module
File "2" - Battle Module
File "3" - WORLDMAP Module
File "4" - TetraMaster module
File "5" - ???? module.
File "6" - ???? module.
File "9" - ???? module.
File "14" - ???? module.