Messages

1

Archive / Re: High Resolution Backgrounds - New Spin on an Old Idea?

« on: 2009-03-16 08:14:41 »

The problem is the background is made up of a grid of small (32x32?) pictures stitched together.

Oh really? I was suggesting to do that using simple polygons with different textures (as provided in my crappy illustration in prior post)

What we should do is find the function that loads the individual squares and have it load larger squares.

The backgrounds can be re-done very easy. Just trace them out using Sketchup and recast the texture.

Look here

right-ounnnn



Does the game use a simple Z-buffer to pring the field models in front of the texture? if so, then an entirely new 'game engine' could be be used to plug in instead of prerendered textures

2

Completely Unrelated / Re: Degree choices

« on: 2009-03-16 07:00:27 »

I think Mark Twain said it best:

I never let my schooling get in the way of my education.

3

Archive / Editing Ehrgeiz (adding chars/swapping models/etc)

« on: 2009-03-16 06:27:43 »

Has anyone tried it?
Does the game read physical disc addresses like in FF7 or is it file-system based?

4

Archive / Re: Final Fantasy VII - playing w/ controllers

« on: 2009-03-16 04:37:11 »

try autohotkey, it will over-right any software keybinds (even windows)
http://www.autohotkey.com/

but it's a bit more complicated

5

Archive / Re: High Resolution Backgrounds - New Spin on an Old Idea?

« on: 2009-03-16 02:24:48 »

Will this work? 

this way, people may enhance the 2D backgrounds by hand in photoshop/etc, and then easil be ported as segmented tiles, appearing as one hires 2d bg

6

Archive / Re: Final Fantasy VII PSX Replacing models creating new

« on: 2009-03-15 21:09:41 »

When I was playing around with it, nearly a year ago 
i found all models use same compression, but could not be edited due to game reading disc address instead of directories.
...
Please correct me if I'm wrong.

Sorry. I wasn't ignoring you, but now I know what you're saying. You are correct. It is, for the most part, physical disc address referencing. However, it only points to the start of the file. The goal is to take the compressed file, uncompress it, edit it, then re-compress it to be smaller than or equal to the size of the original compressed file, then inject it back into the disc image. This is a working method and has been done with other files that are accessed in this way.
The trick is that the file that the compressed file begins by telling the loading process its own file length so it's not dependent on the FAT to tell how big the file is. So long as it doesn't overwrite the next physical file it can be safely injected.

Why go through the hassle of attempting to fit a highres file into the same amount of space rather than just append the hi-res models unto the end of the disk, and redirect the disc addresses via gameshark? 

7

Archive / Re: Final Fantasy VII PSX Replacing models creating new

« on: 2009-03-07 07:10:15 »

When I was playing around with it, nearly a year ago 
i found all models use same compression, but could not be edited due to game reading disc address instead of directories.

But did anyone try to the demo?
Since the FF7 demo came on over 3 different disks, it could be entirely directory based.

Please correct me if I'm wrong.

8

Archive / Re: Final Fantasy VII - playing w/ controllers

« on: 2009-03-07 07:07:34 »

use jtk374en

9

Archive / Re: Final Fantasy VII PSX Replacing models creating new

« on: 2009-03-04 20:04:41 »

So the goal is to improve model poly count, while keeping it the same size to avoid addressing issues?

Wouldn't it be easier to debug the game with ePSXe and find out the memory codes for in-battle and world models and replace world models with in-battle ones using 'gameshark' ?

10

Archive / Re: PSX FF7 Modding

« on: 2008-05-17 03:14:49 »

you mean like VNC?
that's horribly slow

My goal isnt just to put it on the PSP, I'd like to get it working, even in concept

edit: I can't seem to find the WORLD (field) models only the battle models on the disk 
where are they located

11

Q-Gears / Re: PS1ISO Utility <-- find those pesky files!

« on: 2008-04-29 07:33:02 »

I made an image with alc120% (play station mode, clonecd format, *.img) and it platstaion1ISO hangs when loaded
What other program may I make an image (ISO) with that won't offset the sectors? 

edit: my fault, had to change the 'Files of type' from iso to image' D 'h!!

12

Archive / Re: PSX FF7 Modding

« on: 2008-04-28 14:24:12 »

I'd rather necropost than make a fifth thread about the subject 

I'll look into it, but if they are better, why arent' bg and cgi ported to pc, engine limitations? 

qgear section is of great help.
PS1_ISO_setup.exe looks awesome
i'll test this further by end of the week

ps: great forum, many talents here


Update/question:

using F F 7     P S X     M o d e l     V i e w e r  (found: http://www.ficedula.co.uk/) and a bit of searching,
the Battle Models of the characters are located in
psxdisc1:\ENEMY\
the *.LZS are the models (can be views with the psx viewer)

But I cannot seem to find the world models, are they not LZS files?

13

Archive / Re: PSX FF7 Modding

« on: 2008-04-28 00:00:33 »

• The PS1 version of the game uses the ISO9660 commands in the PS1 bios, and not the file system.  Thus far I've not sat down and scrounged every LBA address of every file then searched for where they might be located on the disk.  An LBA in the ISO file system let's say 0 for example is actually at sector 2:00.00  2 minutes 0 seconds and 0 frames.  Each sector is referenced that way via the CD, I believe in BCD format as well.
• Because of the first problem changing ANY file more than 1 sector (2048 bytes or in an ISO it's 2352 bytes), is likely to crash the game.  File size is determined on ISO accessed files by the begining DWORD having the size of the compressed data. This is used on files in \FIELD \ENEMY* \WORLD <-- maybe well most files that are accessed via absolute address. Files that don't have this size information are access via the normal CDROM system or the MOVIE player. 
• The model formats for the field and battle are different, the textures are stored differently as well.  FIELD.TDB contains all the field model textures.  Animations are somewhere out there (LOL), in the files that is. The number of bones in the models must be the same but I think that's about it.  The PS1 stores the models for the field characters (IE cloud Tifa etc.) in BCX files. These are compressed in LZS format like everything else by the way.  So you would have to take cloud's model extract his data (section 0 of cloud.lzs in ENEMY006 I believe) then repack it and scale it to the field model in clould.bcx.  Don't forget the field models have different looks as well, Cloudette Tifa in a nice dress and Aeris in a red dress etc.  These are all likely contained in the associated BCX file.

Without knowing where the table of LBA's or M:S:F formated index information is on the CD this is mostly just blowing smoke.  The only way to find this is by
making a complete list of files that have a begining that indicates total file size. After this procedure search all the files in directories (that do not have said data files) for both an LBA (little endian seems to be the common method), or BCD encoded M:S:F format (the latter might be very hard to find).  The likely candidates for searching are \INIT \MENU \MINI \MINT  \WORLD and \SCUS_941.63  I doubt KERNEL.BIN has the information in it (it's been looked at a lot).

I suppose this has to be found someday, I'm redoing my methods for extracting RAW data from an ISO image into something more ... elegant.  The ISO file format is quite anoying I've decided.

Cyb

What if you run the game in an emulator and monitor the kernel to what address it reads from, then hex-edit, say the field models to same address as battle models?
it shouldn't effect the file-size, and not offset anything



PS: does FF7 have a MAIN.EXE?