Author
|
Topic: Removing loading times in Final Fantasy Anthology (Read 1 times)
|
Bregalad
Guest
|
 |
« on: June 29, 2011, 07:58:36 am » |
|
Is there someone experienced enough in PS1 hacking to be able to tell how hard this would be to do ?
I'm pretty sure it would be hard but in fact I have no idea.
Final Fantasy 5 is 2 MB large, the size of the PS1's RAM, and Final Fantasy 6 is 4 MB.
I don't know how much RAM does the "emulator" take, but it certainly should be possible to have a really good part of FF5 or FF6 loaded into RAM, therefore it would be theorically possible to do very minimal loading. (If for example the emulator code is 512k, you can load 75% of FF5 and 37% of FF6 at a time).
However they apparently implemented it in a way so that the battle code/graphics are loaded at the start of every battle, menu code/graphics is loaded every time you enter the menu, field code/graphics are loaded every time you exit battle or menu etc...
This should probably have been the easiest way for them to code it, but it is slow as hell !
If FF7, 8 and 9 can do all this with few apparent loading times while having modern graphics, it SHOULD be possible to emulate old 2D games without so much loading times.
The question is how hard is to hack the game to take advantage of this theoretical possibility. Is there any way clever ASM hacking can chance when what file is loaded where, in order to make the games more optimal ?
|
|
|
|
|
Jorpho
Guest
|
|
« Reply #1 on: June 29, 2011, 11:16:52 am » |
|
If FF7, 8 and 9 can do all this with few apparent loading times while having modern graphics, it SHOULD be possible to emulate old 2D games without so much loading times. If I am not mistaken, FF7, 8, and 9 just disguised the loading with lots of dramatic zooming. |
|
|
|
|
I.S.T.
Guest
|
|
« Reply #2 on: June 29, 2011, 11:53:02 am » |
|
Correct.
|
|
|
|
|
KingMike
Guest
|
|
« Reply #3 on: June 29, 2011, 02:12:53 pm » |
|
So, I'd guess the radial blur effect in FF5 on Anthology was also disguised loading time? (and maybe the FF6-like gradient fade effect, which wasn't in the SFC FF5)
|
|
|
|
|
Lenophis
Guest
|
|
« Reply #4 on: June 29, 2011, 03:57:22 pm » |
|
If I am not mistaken, FF7, 8, and 9 just disguised the loading with lots of dramatic zooming. Not really. FF7 was so simplistic in nature, that it barely had any loading time at all. That .6 seconds between battles was the worst one, though town transitions could take a bit at times. Playing it on the PS2 nullfified the loads completely. FF8 was the worst offender, because the graphics were awesome. Everything took at least 5 seconds, except for the menu. FF9 was inbetween the two, but still took a bit of time for town and battle loads. They finally starting buffering stuff to help minimize it. Go SO2 for starting it. As for Anthology, the way to remove the load times would be to not emulate the 6502 65816 and go with native code for all instructions. Or you can bug Gemini and see if he'll release his WIP hack for FF6.  |
|
|
|
|
gadesx
Guest
|
|
« Reply #5 on: June 30, 2011, 02:33:35 am » |
|
I remember that in FF6 in the destroyed world, if I removed the disc from psx, the game continue running, but the
battles don't started lol
|
|
|
|
|
Bregalad
Guest
|
|
« Reply #6 on: June 30, 2011, 02:40:21 am » |
|
Not really. FF7 was so simplistic in nature, that it barely had any loading time at all. That .6 seconds between battles was the worst one, though town transitions could take a bit at times. Playing it on the PS2 nullfified the loads completely. Yes, in fact it does loading but I'm pretty sure the game was written intelligently, by Square's programmers, so that the game anticipate what is going to have to be loaded and load it before the data is actually needed. However FFA was written poorly by Tose's programmers, so they just made the game load the data just when it needs it and did not anticipate anything. For FF5, I'd bet the game loads the whole "MNU" folder every time you enter the menu, the whole "BTL" folder everytime you are in battle, and the whole "NAR" folder otherwise. But this is not intelligent. You'd rather want to load only the needed data at appropriate time. As for Anthology, the way to remove the load times would be to not emulate the 6502 65816 and go with native code for all instructions. Unless the emulator uses almost all of the 2MB memory (which I doubt it's the case), it should be quite possible (theorically). You could load about 1/3 of FF6 and 2/3 of FF5 in memory + the emulator !! It should be quite possible to load all maps, dialogue, graphics, ennemies and all battle graphics for a given area in the 2MB of RAM that the playstation have (and then restrict the loading only when going from/to the world map). As a proof, FF4, which is only 1MB, apparently loads at boot and then never loads anything again. Or you can bug Gemini and see if he'll release his WIP hack for FF6. I'm not sure what you are talking about. I searched for a hack called "whip" on RHDN, no result. Tried on google, no result. I would REALLY appreciate if someone would point me to some debugging tools that would allow me to trace when the game loads what data. I know assembly (although I never messed with the CPU of the Playstation but it's probably similar to all others CPUs) and I know how to hack simple ROM based games, but I'm unfamiliar with PS emulators and ISOs. So it'd be something interesting to spot. |
|
|
|
« Last Edit: June 30, 2011, 03:05:36 am by Bregalad »
|
|
|
|
KC
Guest
|
|
« Reply #7 on: June 30, 2011, 03:09:33 am » |
|
These games aren't really emulated. It would be way, way too slow. Also because loading half a ROM wouldn't exactly lead to pleasent results... The games can access the whole ROM with pretty much no load times. But loading big chunks of data takes forever on the PSX. It would be even slower.
At least FF4-6 and CT are a weird mix of simulating the SNES hardware (like hardware registers) and recompiling the SNES code. FF4, for example, more or less replaces every 65816 opcode with a MIPS function call (that then implements the behavior of that opcode).
That of course bloats the code a lot, and as a result it eats up a lot of the 2mb of RAM. I assume they use similarly big overlays for different parts of the game.
It's reasonable to assume that they load way too much data. Gemini said that, for example, CT loads a file containing every single enemy at the beginning of every battle... just to get the bit of information it needs for the current 1 or 2 enemies. It adds enormous delays for stupid reasons.
The best way to cut load times would be to add compression where there is none at the moment. The less data you load from the disc, the better.
|
|
|
|
|
danke
Guest
|
|
« Reply #8 on: June 30, 2011, 03:11:37 am » |
|
I'm not sure what you are talking about. I searched for a hack called "whip" on RHDN, no result. Tried on google, no result.
lol... Are you serious? WIP = Work in Progress, as in a hack that is in the process of being created/completed. |
|
|
|
|
Bregalad
Guest
|
|
« Reply #9 on: June 30, 2011, 05:12:01 am » |
|
These games aren't really emulated. It would be way, way too slow. Also because loading half a ROM wouldn't exactly lead to pleasent results... The games can access the whole ROM with pretty much no load times. But loading big chunks of data takes forever on the PSX. It would be even slower.
At least FF4-6 and CT are a weird mix of simulating the SNES hardware (like hardware registers) and recompiling the SNES code. FF4, for example, more or less replaces every 65816 opcode with a MIPS function call (that then implements the behavior of that opcode).
That of course bloats the code a lot, and as a result it eats up a lot of the 2mb of RAM. I assume they use similarly big overlays for different parts of the game. Oh it's great to see research about this WAS done. So if they replaced every opcode by some call, I guess this is called emultion  It's reasonable to assume that they load way too much data. Gemini said that, for example, CT loads a file containing every single enemy at the beginning of every battle... just to get the bit of information it needs for the current 1 or 2 enemies. It adds enormous delays for stupid reasons.
The best way to cut load times would be to add compression where there is none at the moment. The less data you load from the disc, the better. Yeah but it would be equally better to have the game load information for all enemies in some area when you enter in the area, and not loading info for all other enemies of the game. (I'll assume FFA works the same as CT). Of course it should not be really easy to implement it as a hack but maybe it's possible by hacking all routines related to loading data ? (Rewriting the entire game and porting all the code from 65816 to R3000 is out of the question of course.) To know is such a hack could be possible, one should first understand mostly how the game and it's internal "emulator" works, and more importantly how it manages memory. This requires debugging tools. Any advice ? WIP = Work in Progress, as in a hack that is in the process of being created/completed. Thank you. (how could I possibly GUESS that ?) |
|
|
|
« Last Edit: June 30, 2011, 05:26:52 am by Bregalad »
|
|
|
|
Lenophis
Guest
|
|
« Reply #10 on: June 30, 2011, 10:05:36 am » |
|
You could load about 1/3 of FF6 and 2/3 of FF5 in memory + the emulator !! Do you propose swapping in the FF5 disc at random points while playing FF6? (You are, by the way.) :angel: As a proof, FF4, which is only 1MB, apparently loads at boot and then never loads anything again. The music is XA (or some streamed equivalent), so it must load that. If you open the cover, eventually the game crawls to a halt, and will wait until the music is going again. The best way to cut load times would be to add compression where there is none at the moment. The less data you load from the disc, the better. Would the time gained from not loading be lost to decompressing it? |
|
|
|
|
Deathlike2
Guest
|
|
« Reply #11 on: June 30, 2011, 11:48:39 am » |
|
Would the time gained from not loading be lost to decompressing it?
Unless the CPU is inadequate for handling the decompression (you may not necessarily need a complicated compression scheme), the optical drive tends to be the slowest point of access. |
|
|
|
|
syntax error
Guest
|
|
« Reply #12 on: July 01, 2011, 02:34:57 pm » |
|
I heard that they simply used assembler macros for most parts.
|
|
|
|
|
|
RHDN Forum Archive
