1426
Archive / Help on the commonly known bug....COSMO CANYON :(
« on: 2005-08-02 22:13:57 »
I've just send it back.
------------------
Edit:
No problem
------------------
Edit:
No problem
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
1427
Archive / Help on the commonly known bug....COSMO CANYON :(
« on: 2005-08-02 15:06:44 »
Heh...
I got it... but there is no attachment
Are you sure you've send me your save-game?
-------------
Edit:
OK, now you can check your mail.
I got it... but there is no attachment
Are you sure you've send me your save-game?-------------
Edit:
OK, now you can check your mail.
1428
Archive / Help on the commonly known bug....COSMO CANYON :(
« on: 2005-08-02 14:44:55 »
Well...
You can upload your save-game on some server and post it here, so someone would "Watch it for you" (you can send it to me btw, see profile details for e-mail). That problem is well know, but there is no always-working solution. Search this forum for "cosmo canyon crash" (+eidos) if you want to know more.
You can upload your save-game on some server and post it here, so someone would "Watch it for you" (you can send it to me btw, see profile details for e-mail). That problem is well know, but there is no always-working solution. Search this forum for "cosmo canyon crash" (+eidos) if you want to know more.
1429
Archive / Help on the commonly known bug....COSMO CANYON :(
« on: 2005-08-02 06:28:16 »
Heh...
Neither mine nor yours mail-box don't like to work on Mondays
<I've already tried to use 2 e-mail addresses which usually work, so...>
Neither mine nor yours mail-box don't like to work on Mondays
Code: [Select]
[email protected]
connect to mailin-04.mx.aol.com[205.188.157.25]: server refused mail service<I've already tried to use 2 e-mail addresses which usually work, so...>
1430
Archive / Difference?
« on: 2005-08-01 18:01:52 »
AFAIK, PSX version have better sound quality, but the sound itself is generated in real-time (MIDI, not an MP3). If you have good MIDI-device on your PC, it could sounds nearly as good, as on PSX (if...).
As for the second question... dunno
As for the second question... dunno
1431
Archive / Movement Problems
« on: 2005-08-01 12:05:16 »
Well...
IMHO PS2 controller is good for all (IF it's small-size isn't a problem - my bro for example prefers bigger joy-pads). Also it's known as a high-durability product (of course an original one). I was thinking of buying PS2->PC converter and using the DualShockII, but i've given a shot to that SpeedLink thingy
Also... a Logitech's controller is a good choice (precise and long-living).
If you're going to use it in mash-all-the-keys-as-quickly-as-possible-type-games, don't waste your money on cheap replacements... buy a good one, that will last longer than your enemies...
IMHO PS2 controller is good for all (IF it's small-size isn't a problem - my bro for example prefers bigger joy-pads). Also it's known as a high-durability product (of course an original one). I was thinking of buying PS2->PC converter and using the DualShockII, but i've given a shot to that SpeedLink thingy
Also... a Logitech's controller is a good choice (precise and long-living
).If you're going to use it in mash-all-the-keys-as-quickly-as-possible-type-games, don't waste your money on cheap replacements... buy a good one, that will last longer than your enemies
...
1432
Archive / Help on the commonly known bug....COSMO CANYON :(
« on: 2005-08-01 11:54:59 »Code: [Select]
[email protected]
host mx2.hotmail.com[65.54.166.230] said: 550 Requested action not taken: mailbox unavailable (in reply to RCPT TO command) Sorry, can't help you.---------------------
Edit:
Check your e-mail-box.
1433
Archive / Movement Problems
« on: 2005-08-01 09:47:58 »
Well...
brand... SpeedLink...
It's not a brand-gamepad after-all. It's a clone of the DualShockII but has a USB-connection (that's why i bought it). It's not a good idea to buy some made-in-china products which are SONY's replacements, because these won't last as long as the original one will. But well... It works now and if it gets broken i'll buy a new one
brand... SpeedLink...
It's not a brand-gamepad after-all. It's a clone of the DualShockII but has a USB-connection (that's why i bought it). It's not a good idea to buy some made-in-china products which are SONY's replacements, because these won't last as long as the original one will. But well... It works now and if it gets broken i'll buy a new one
1434
Archive / Movement Problems
« on: 2005-07-31 23:14:56 »
The best solution is to buy a gamepad (really there's a huge difference between using a keyboard and a good joypad).
Anyway... just checked it... I could run diagonally. Changed the keys to use up-down-left-right arrows to move and now I have that problem too. The solution? Change your movement keys...
Basically it's because the keys you've chosen fill the keyboard buffer with 2 bytes (per key) when pressed. Your kebyoard just don't see the [CANCEL] key pressed when you're also pressing two "arrows".
Hope that helps...
there's a huge difference between using a keyboard and a good joypad).Anyway... just checked it... I could run diagonally. Changed the keys to use up-down-left-right arrows to move and now I have that problem too
. The solution? Change your movement keys...Basically it's because the keys you've chosen fill the keyboard buffer with 2 bytes (per key) when pressed. Your kebyoard just don't see the [CANCEL] key pressed when you're also pressing two "arrows".
Hope that helps...
1435
Troubleshooting / Can Someone....
« on: 2005-07-31 23:05:59 » Why don't you just search for it? Duh...
http://www.dll-files.com/dllindex/dll-files.shtml?msvcrtd
(i typed msvcrtd.dll in google.com - in case you were wondering...)
1436
Scripting and Reverse Engineering / TEX format and WINDOW.BIN file update...
« on: 2005-07-31 19:51:03 »
Oh...
I know that my english is a bit crappy but... I said that I've discovered how this thing works (yesterday), and I'm willing to make a new topic about that... After that Ficedula said it is already known. Then I asked, if he could update his docs (on his home-page) or do whatever, just to let people know that it's already worked-out. You know... so they wouldn't reinvent a wheel (as I did ).
I know that my english is a bit crappy but... I said that I've discovered how this thing works (yesterday
), and I'm willing to make a new topic about that... After that Ficedula said it is already known. Then I asked, if he could update his docs (on his home-page) or do whatever, just to let people know that it's already worked-out. You know... so they wouldn't reinvent a wheel (as I did ).
1437
Troubleshooting / cosmo canyon crash help!~!~!~!
« on: 2005-07-31 13:18:16 »
Just gimme your e-mail.
1438
Scripting and Reverse Engineering / TEX format and WINDOW.BIN file update...
« on: 2005-07-31 11:28:15 »Quote from: ficedula
Not sure if there's already a topic on it in the forums, although I think Qhimm was the original source of the information.
There could be a topic... if there is one, then I just don't know how to find it. Also i haven't found that in the gears so... maybe you could update your docs with that info? Guess there are a "few" people interested in ff7-tech-related-stuff that know this forum and your site, so whenever they would need that info, it would be there...
1439
Scripting and Reverse Engineering / TEX format and WINDOW.BIN file update...
« on: 2005-07-31 09:53:58 »
Hello, and thx for the reply (gee Mirex answered to my post )
Ficedula's programs were usually a great help, but this one... Yeah... that's a program which i tried first, but it simply didn't work with those files (maybe 'coz I'm using Win2003 - NT family - always some access violation). So I debugged the ff7, and found out how it deals with these files.
You can read the results of my work above. As I had never seen those information elsewhere, thought it could be useful. Guess it's not... maybe that's why no1 posted it before...
Anyway, I had also done some discovering about (as Ficedula says) "CRC code" in lgp files. I know how it works, and how to make your own "CRC code". I'll make some new topic (or maybe i shouldn't? I didn't find it in this forum, but just tell if I shouldn't post it).
)Ficedula's programs were usually a great help, but this one... Yeah... that's a program which i tried first, but it simply didn't work with those files (maybe 'coz I'm using Win2003 - NT family - always some access violation). So I debugged the ff7, and found out how it deals with these files.
You can read the results of my work above. As I had never seen those information elsewhere, thought it could be useful. Guess it's not... maybe that's why no1 posted it before...
Anyway, I had also done some discovering about (as Ficedula says) "CRC code" in lgp files. I know how it works, and how to make your own "CRC code". I'll make some new topic (or maybe i shouldn't? I didn't find it in this forum, but just tell if I shouldn't post it).
1440
Scripting and Reverse Engineering / TEX format and WINDOW.BIN file update...
« on: 2005-07-30 17:45:57 »
Hello there
"Intro - ...duction..."
I was debugging ff7.exe to find some information useful when trying to change font used in-game. Why would i do that for? Because a team from Poland - FF7-PL, is making a polish version of FF7 (which is my favourite game... again). You know who M4v3r is, so I think I don't need to say anything else. The polish font in their release occupies some in-my-humble-opinion-very-important characters, so I started to make my own font. I don't know that for sure, but i think I found out some info, which wasn't posted here, on Qhimm's forum. So... that's what I've found out. Listen up...
"First chapter - Why mine is bigger than yours?"
FF7 uses an array to see how much pixels each letter has. The address in memory (after loading ff7.exe EN v1.0):
- 0x0098F458
In that array, each byte corresponds to a single character. To decode the data stored, all you have to do is get the byte for a character, and look for the corresponding data in the array. After that:
- to get a character's width, AND a just-found-byte with 0x1F (00011111b)
- to get a character's padding (well I don't know if that's what it's called, but it's just a number of pixels before the character), SHR just-found-byte by 5
Example:
To get a quotation mark "values", we:
- get the byte for that character - it's stored in address 0x0098F458 (base address) + 0x1F (the hex value for quotation mark). It should be 0x27 (or 00100111b or 39);
- AND it with 1F, or modulo it by 0x20 (32) - we get 7
- SHR it (the byte read 0x27) by 5 (or divide by 32) - we get 1
And... that's it. Remeber that these values are in 320x240 resolution mode (not really sure about that), to get the size in the 640x480 mode multiply the results by 1.666667, and truncate the non-integer part (even if it's 4.9998, we get 4).
OK... We do know, how to get the character size. But how to change it? There are some methods. We can do it by changing the data stored in the memory for example. We get the immediate effect. To those who don't want it to be a temporary change, we have to change data in the file. Which file? Oh... that's the 3rd file of WINDOW.BIN pack-file. We have to unpack it, change it and repack it (the worst part). It wasn't me who discovered, that the data is stored in that particular file (i just knew that it's in WINDOW.BIN, then I came here to see if it has already be decoded, and found out that I've just reinvented the wheel), so don't call me a leecher
"Second chapter - Oh mummie, that dog after some paintings looks cool"
We all know, that the font itself is in menu_us.lgp file, but do we know how to change it? Well... You do I didn't. Used Mirex's Biturn (omg, that's a good piece of work, THX Mirex for writing it), and just changed the font. Then i started to wonder... maybe i can write a program for quick replacing the font graphics and widths. I have a program to repack the modified file which contains the "width-data", I know the TEX format good enough... wait a minute... I didn't
After some debugging work, that's what i found out (i know, that some bytes where know for long, but that's what i have found out about reading TEX files by ff7):
TEX_FILE_HEADER is 0xEC long, and contains of 59 int-s. Some of them listed below (by offset):
0x00 - TEX file "version", if it's not 0x00000001, the game will not load it.
0x04 - zero... always... i think
0x2C - zero?
0x30 - MYSTERIOUS_DATA_NUM_OF_ENTRIES
0x3C - RES_X (already known...)
0x40 - RES_Y
0x44 - zero?
0x48 - zero?
0x4C - PALLETTE_ACTIVE (if it's set, then there is a pallete data right after the header, if it says zero, the pallette-data is missing from the file)
0x58 - PALLETE_NUM_OF_ENTRIES (to get pallete data width, multiply by 4)
0x60 - PALLETTE_PTR (Doesn't really matter. It's always zero-ed when loading the header, after reading pallette data here is where the pointer to that data is stored)
0x68 - BYTES_PER_PIXEL for the bitmap data (bitmap data comes in the file after the header and the pallette data)
(here some unknown data)
0xBC - MYSTERIOUS_DATA_ACTIVE (if it's set, then there should be some data after the bitmap part of the file)
0xC0 - MYSTERIOUS_DATA_PTR (same as PALLETTE_PTR, it could be 0 as well...)
0xC4 - It's set after loading the header (always with 0xFF... i think)
0xC8 - Set after loading the header (when debugging it was 0x04, mostly)
0xD4 - BITMAP_PTR (it's set after the memory allocation and reading the bitmap data, so... who cares)
0xD8 - don't know (hmm... it's zero-ed like the pointers, but i didn't see it containing any data after loading the pallette... weird)
"Third chapter - Can you tell me HOW you DO IT?"
How the game reads the TEX file?
- Allocates a memory (on the heap... or maybe not... forgot) for a header and reads it into the memory.
- if 0x00 DWORD says 0x00000001 then keeps loading, otherwise stops reading that file
- if 0x4C DWORD is set, reads the pallette (4*0x58 DWORD) and stores the data pointer in the 0x60; if the pointer is NULL, ff7 stops reading that tex-file
- reads the bitmap data (0x3C DWORD * 0x40 DWORD * 0x68, or RES_X*RES_Y*BYTES_PER_PIXEL) and stores the pointer in 0xD4 DWORD; again, if the pointer is NULL, stops reading that file
- if the mysterious data is present (0xBC DWORD is set) reads the data (0x30 DWORD * 1) and stores it's pointer; if it's NULL... blah
After that, it does some mysterious and not really interesting things...
"Epilogue - Stupid talk..."
Well... that's it for now I hope it's gonna help someone (hmm... if you are good enough to decode my post, you ain't gonna need it, 'coz you're a super-human with abnormal abilities). When i get any other data which is somehow connected with ff7, I'll post it (or not... if I got banned before that). Have a nice life
"Intro - ...duction..."
I was debugging ff7.exe to find some information useful when trying to change font used in-game. Why would i do that for? Because a team from Poland - FF7-PL, is making a polish version of FF7 (which is my favourite game... again
). You know who M4v3r is, so I think I don't need to say anything else. The polish font in their release occupies some in-my-humble-opinion-very-important characters, so I started to make my own font. I don't know that for sure, but i think I found out some info, which wasn't posted here, on Qhimm's forum. So... that's what I've found out. Listen up..."First chapter - Why mine is bigger than yours?"
FF7 uses an array to see how much pixels each letter has. The address in memory (after loading ff7.exe EN v1.0):
- 0x0098F458
In that array, each byte corresponds to a single character. To decode the data stored, all you have to do is get the byte for a character, and look for the corresponding data in the array. After that:
- to get a character's width, AND a just-found-byte with 0x1F (00011111b)
- to get a character's padding (well I don't know if that's what it's called, but it's just a number of pixels before the character), SHR just-found-byte by 5
Example:
To get a quotation mark "values", we:
- get the byte for that character - it's stored in address 0x0098F458 (base address) + 0x1F (the hex value for quotation mark). It should be 0x27 (or 00100111b or 39);
- AND it with 1F, or modulo it by 0x20 (32) - we get 7
- SHR it (the byte read 0x27) by 5 (or divide by 32) - we get 1
And... that's it. Remeber that these values are in 320x240 resolution mode (not really sure about that), to get the size in the 640x480 mode multiply the results by 1.666667, and truncate the non-integer part (even if it's 4.9998, we get 4).
OK... We do know, how to get the character size. But how to change it? There are some methods. We can do it by changing the data stored in the memory for example. We get the immediate effect. To those who don't want it to be a temporary change, we have to change data in the file. Which file? Oh... that's the 3rd file of WINDOW.BIN pack-file. We have to unpack it, change it and repack it (the worst part
). It wasn't me who discovered, that the data is stored in that particular file (i just knew that it's in WINDOW.BIN, then I came here to see if it has already be decoded, and found out that I've just reinvented the wheel), so don't call me a leecher "Second chapter - Oh mummie, that dog after some paintings looks cool"
We all know, that the font itself is in menu_us.lgp file, but do we know how to change it? Well... You do
I didn't. Used Mirex's Biturn (omg, that's a good piece of work, THX Mirex for writing it), and just changed the font. Then i started to wonder... maybe i can write a program for quick replacing the font graphics and widths. I have a program to repack the modified file which contains the "width-data", I know the TEX format good enough... wait a minute... I didn't After some debugging work, that's what i found out (i know, that some bytes where know for long, but that's what i have found out about reading TEX files by ff7):
TEX_FILE_HEADER is 0xEC long, and contains of 59 int-s. Some of them listed below (by offset):
0x00 - TEX file "version", if it's not 0x00000001, the game will not load it.
0x04 - zero... always... i think
0x2C - zero?
0x30 - MYSTERIOUS_DATA_NUM_OF_ENTRIES
0x3C - RES_X (already known...)
0x40 - RES_Y
0x44 - zero?
0x48 - zero?
0x4C - PALLETTE_ACTIVE (if it's set, then there is a pallete data right after the header, if it says zero, the pallette-data is missing from the file)
0x58 - PALLETE_NUM_OF_ENTRIES (to get pallete data width, multiply by 4)
0x60 - PALLETTE_PTR (Doesn't really matter. It's always zero-ed when loading the header, after reading pallette data here is where the pointer to that data is stored)
0x68 - BYTES_PER_PIXEL for the bitmap data (bitmap data comes in the file after the header and the pallette data)
(here some unknown data)
0xBC - MYSTERIOUS_DATA_ACTIVE (if it's set, then there should be some data after the bitmap part of the file)
0xC0 - MYSTERIOUS_DATA_PTR (same as PALLETTE_PTR, it could be 0 as well...)
0xC4 - It's set after loading the header (always with 0xFF... i think)
0xC8 - Set after loading the header (when debugging it was 0x04, mostly)
0xD4 - BITMAP_PTR (it's set after the memory allocation and reading the bitmap data, so... who cares)
0xD8 - don't know
(hmm... it's zero-ed like the pointers, but i didn't see it containing any data after loading the pallette... weird)"Third chapter - Can you tell me HOW you DO IT?"
How the game reads the TEX file?
- Allocates a memory (on the heap... or maybe not... forgot
) for a header and reads it into the memory.- if 0x00 DWORD says 0x00000001 then keeps loading, otherwise stops reading that file
- if 0x4C DWORD is set, reads the pallette (4*0x58 DWORD) and stores the data pointer in the 0x60; if the pointer is NULL, ff7 stops reading that tex-file
- reads the bitmap data (0x3C DWORD * 0x40 DWORD * 0x68, or RES_X*RES_Y*BYTES_PER_PIXEL) and stores the pointer in 0xD4 DWORD; again, if the pointer is NULL, stops reading that file
- if the mysterious data is present (0xBC DWORD is set) reads the data (0x30 DWORD * 1) and stores it's pointer; if it's NULL... blah
After that, it does some mysterious and not really interesting things...
"Epilogue - Stupid talk..."
Well... that's it for now
I hope it's gonna help someone (hmm... if you are good enough to decode my post, you ain't gonna need it, 'coz you're a super-human with abnormal abilities). When i get any other data which is somehow connected with ff7, I'll post it (or not... if I got banned before that). Have a nice life