Expanding the Iso Space?

[Darkholme]

I've heard people mentioning the limited amount of space available in the files, and people are trying to make use of that space conservatively so as to not run out.

I have to ask: Why does the file size limit still matter?

If you're not going to run it on an actual playstation, shouldn't you be able to expand the file without too much trouble? Is this an issue of the emulator emulating the hardware, and not being able to read/handle a larger file?

I'm just curious.

~DH

[Xifanie]

Files that are worth expanding: spritesheets, maps, and video files (but we can hardly edit those).
FFT uses many file sizes that have a determined size in the RAM, so it's pointless to try expanding them.
Then we have stuff like the ENTD and TEST.EVT which have plenty of slots to start with, so whatever.

And it's not -that- easy to expand a file. You have to move it somewhere else on the image, expand, and relink all the game's code to load the file at THAT new sector. It's hardly ever been done, as it is rarely required, other than shishi doing it automatically while restructuring.

[Darkholme]

I see.

I was thinking filesize was part of the reason we don't see people trying out things like upping the number of playable jobs to 50, or copying all of the job and event data from WotL into the PSX version of the game, or having tiered jobs like in Disgaea.

Hmm.
So the problem isn't the filesizes, it's the memory limits? If you're running it on a PC, don't you have access to a couple gigs of ram?

[formerdeathcorps]

The reason why I don't want 50 jobs is because a game does not have 50 balanced roles to fill unless each job only has 2 skills and 1 R/S/M (but then they wouldn't be very distinctive or interesting).  In practice, FFT's base mechanics supports around 15 balanced jobs unless you start restricting abilities (by compressing canonical abilities like Cure / Cure 2 / Fire / Fire 2).  I had to add mechanics like weight and remake the entire faith and CT system to extend that to 20. 
Of course, if you believe in a tiered system where certain jobs upgrade into better variants of themselves (like Pokemon evolutions), then you can certainly have as many jobs as you want.  However, you run into three related but distinct technical problems:

1) If I want the game to still work on emulator / PS1 / on PSP's popstation, then I must respect the 2MB RAM limit.  If I don't, then I would either have to code / hack the emulator to accept an arbitrary amount of RAM or code my own computer / PSP game.

2) If I accept 1), then I must either remake the unit RAM table or add to it as well as all dependent routines.  From a performance perspective, it is better to merge your additions to the existing RAM table (because memory is finite and only 32 registers exist; one table means only one register holding the starting address while two tables mean either two registers holding both addresses and duplicated code or five registers to create a proper while loop to account for the two different cases, run twice).  But that then means I need to fix unit RAM loading to accept a table that is +X longer than the previous amount.  Once that is fixed, all the dependent routines (pretty much all of BATTLE.BIN after 0x110000) needs to then be fixed because they reference either bytes in the unit RAM table or its size.  In short, it's so massive a task it's about as hard as half-coding a game. 

3) As a result, most people choose the less efficient option of making their own table (as to not disturb existing code) or to consolidate the existing table by making sure each byte (or if you're SA, each bit) is in one-to-one correspondence with your list of features.  Because I create fairly watertight mechanics (where many combinations simply cannot exist), my coding process has many patch-specific simplifying assumptions, but I know many other coders prefer to have their imaginations run wild, regardless of the coding costs.  In any case, you just need to then find the appropriate routines that call the "job skills learned" routine (it's in SCUS), create the table for all 16 (potentially) units in battle, and have both the player and AI reference the existing table (be it in WORLD or BATTLE.BIN RAM) through all the load / learn routines.  Nor is C/Ping WotL code a solution; WotL was coded in MIPS IV, which has commands MIPS I does not support.

However, I do agree with you that a larger TEST.EVT paired with an expansion of the ATTACK.OUT / BATTLE.BIN / WORLD.BIN conditionals would be nice.