Final Fantasy Hacktics

Modding => War of the Lions Hacking => Topic started by: formerdeathcorps on February 28, 2011, 03:51:15 pm

Title: Recompilation
Post by: formerdeathcorps on February 28, 2011, 03:51:15 pm
Here's an idea Wasabi got me started on.  I'm just posting here to see how many people would be interested in helping (testing, decompiling/interpretation, ASM hack writing) because it's a massive idea.  Personally, I have my formula/AI hacks to finish first, but I'd still like to gauge the general level of interest and support in this idea.

1) Compare all the primary differences between WoTL's and FFT's code (on the major battle files like WORLD.BIN/SCUS/BATTLE.BIN)  Since most of WoTL's files are smaller than FFT's, the goal is to port WoTL's features into FFT, while simultaneously expanding the free space of each of the three aforementioned files by 2-20 KB in FFT.
2) Figure out how to insert ASM hacks into WoTL (at last) by correctly identifying the Kanji section in BATTLE/WORLD.BIN.
3) Delete the slowdown on PSP by reinserting the recompiled FFT code into the PSP.
4) Delete stupid hard-code features FFT didn't have (Malak/Rafa formulas having a hard-coded max hit of 10, for example).
5) Add in PSP features (not the movies, but the sound novels, extra battles/maps [just find a way to read the PSP's larger TEST.EVT and map folder], minigames [I'm not sure on this one])
6) Bonus feature: Replace Tutorial mode with Debug mode, allowing PvP and PvAI in one game.
7) Bonus feature: Make all maps in both versions selectable (without bugs) in Debug mode, at least.
Title: Re: Recompilation
Post by: Pickle Girl Fanboy on February 28, 2011, 04:54:27 pm
This is insane.  Documenting an entire game in ASM?  You might as well rewrite the whole thing in a high-level programming language and make it open source.  That said, this is still an awesome idea.  Impractical, but awesome.
Title: Re: Recompilation
Post by: formerdeathcorps on February 28, 2011, 05:00:18 pm
Quote from: Pickle Girl Fanboy on February 28, 2011, 04:54:27 pm
This is insane.  Documenting an entire game in ASM?  You might as well rewrite the whole thing in a high-level programming language and make it open source.  That said, this is still an awesome idea.  Impractical, but awesome.


It's only insane if I do all of it.  Hence why I'm gauging interest before I start.
I'm willing to bet most of the sound/sprite/map files are the same, though, so most of the real changes are in WORLD.BIN/SCUS/BATTLE.BIN/ATTACK.OUT/TEST.EVT.  That's only tens of MB put together; if that's split between 3-4 disciplined ASM hackers, that can be done within a year.
Title: Re: Recompilation
Post by: Pickle Girl Fanboy on February 28, 2011, 05:05:01 pm
I'm interested, but can't contribute much.  If you can't garner enough interest, maybe you could interest people in investigating individual files, one at a time?
Title: Re: Recompilation
Post by: formerdeathcorps on February 28, 2011, 05:58:29 pm
All right...FONT.BIN is approximately the same size in both (~0x13000).  Hence, the Kanji table is the same size, just in different places between the PSP ISO and the PSX ISO.

PSX ISO
BATTLE.BIN
0xE7614 is the beginning of FONT.BIN duplicate.
According to the Wiki, 0xE92AC is the start of the Kanji.
0xFA2DC is the end.

PSP ISO
BATTLE.BIN
0xE6CCC is the beginning of FONT.BIN's duplicate.
By extrapolation, 0xE8964 is the start of the Kanji.
0xF998C is the end.

As for why ASM made by Razele/Xif doesn't work in WoTL, it's because offset 0xXXYYZZ in BATTLE.BIN for whatever routine in PSX is probably at 0xXXYYZZ - 0xWWVV on the PSP.
Title: Re: Recompilation
Post by: pokeytax on February 28, 2011, 06:16:49 pm
Not being a WotL player, I just don't see the percentage in it, fdc. All of the hacks ever created still fit in the kanji table, and I can't conceive of a patch so big that it can't cram everything it needs in there. Some SCUS space would be great, but is it worth two years of work?
Title: Re: Recompilation
Post by: formerdeathcorps on February 28, 2011, 07:11:29 pm
Quote from: pokeytax on February 28, 2011, 06:16:49 pm
Not being a WotL player, I just don't see the percentage in it, fdc. All of the hacks ever created still fit in the kanji table, and I can't conceive of a patch so big that it can't cram everything it needs in there. Some SCUS space would be great, but is it worth two years of work?


1) The PSP players (as well as people who play on real PSX machines) are complaining they can't use most ASM hacks.  They also complain of more hard-coding and FPS slowdown.  At the least, the source of this problem should be found, if not resolved.
2) Doing this project would be the first step to learning to how to ROM expand any arbitrary file in FFT.
3) Let's say you wanted to make a whole new class of mechanics (like additional status/weather/terrain effects, generic jobs, or combat paradigm systems).  Similarly, if you want the AI to be smarter, you may need it to store more information about each unit.  Either hack, if made to their full extent, would require many more tables and/or expansion of the unit/AI RAM space (marked as zero in BATTLE.BIN), which would then require the repointing of BATTLE.BIN.  In making it, it would be helpful to at least compare with WoTL, which added more stuff in less space (giving us more space to write PSX hacks in).  Even if we chose instead to save space by making routines more efficient, we'd still need to track down most of BATTLE.BIN to do so (without fear of unintended errors), which doesn't invalidate the argument of having at least having another version to compare with/copy from.
4) Let's say you want a multi-pathed storyline like the kind Tactics Ogre had (or at the least, more units in the formation screen).  If you don't want to compromise, you need to expand TEST.EVT and ATTACK.OUT, which WoTL did.  Learning how to correctly transfer files of different sizes then becomes useful.
5) WoTL's multiplayer had a lot of crude features, but it's still a step up from Debug mode.  If possible, both should be incorporated as one PvP feature (in place of tutorial in FFT and tutorial/co-op in WoTL).
Title: Re: Recompilation
Post by: Pickle Girl Fanboy on February 28, 2011, 07:33:34 pm
It would really help this project is pSX_author would release the source code to pSX.

Remember that guy who wanted to remake FFT using C++ or something?  He asked a lot of questions about AI, and I sent him my idea for subclasses and a bunch of other things.  What FDC proposes will make FFT completely hackable.  I want this to happen, but I doubt it will within the next five years, unless six or seven more ASM hackers pop up, or this project is organized so the casual ASM hacker with a bunch of mods on his hands can contribute.
Title: Re: Recompilation
Post by: formerdeathcorps on February 28, 2011, 08:11:04 pm
Pickle, that would help, but I also intend to teach more people ASM on here, so we can raise more talent.  In fact, given how conversant you and Vanya are at hex-editing, you two probably should try to learn it.

I'm not sure what you mean by
Quotethis project is organized so the casual ASM hacker with a bunch of mods on his hands can contribute.

What would such a project look like?  I suspect the idea is to divide the work on the basis of skill level without giving any one person/type of person "grunt work", but I'm not sure how to do that fairly.

PSP Formula Offset Table (sadly, it's only the first 0x64...the WoTL exclusive ones are elsewhere)
BATTLE.BIN
0x1265E0 - 0x126770

Just for comparison, the PSX Formula Offset Table is at
BATTLE.BIN
0x128614 - 0x1287A4

EDIT: With just the above two bits of information and some routine tracking patience, it should now be possible to make at least 50% of all current ASM hacks (for the PSX) work for WoTL.
Title: Re: Recompilation
Post by: Pride on February 28, 2011, 09:15:45 pm
I really don't support the idea besides figuring out where the Kanji section for wotl players and the last two options. I just don't think the majority of it is worth the time and effort to be honest.
Title: Re: Recompilation
Post by: Mega_Tyrant on February 28, 2011, 10:01:02 pm
I support this idea, if only to increase interest in the PSP version.  So many people have abandoned WOTL simply because there is so little that can be done to it.  It doesn't even have full shishi support.  If it were possible to remove the framerate limit, fix the issue with the spitesheets being joined on multiple characters so that ISO can be expanded to allow for more sprite inserts, and more information were available on the structure of its files so that the ARH, ALMA, and FFTorgASM could be applied, it's multiplayer mode could be made so much better.  WOTL has 2 advantages over basic FFT in having multiplayer and the expanded roster already.  However I do think that this may be more than the current staff of ASMers could handle.

If that post on FuSa SD removing the slowdown on WOTL is true, that might be a lead right there on how the get the framerate back to how it should be.
Title: Re: Recompilation
Post by: Eternal on February 28, 2011, 10:55:36 pm
I have no idea what this is honestly, but I'm always for more documentation. Even if nobody here will really use it, someone else might be interested in it later on.
Title: Re: Recompilation
Post by: RavenOfRazgriz on February 28, 2011, 11:45:58 pm
Quote from: Eternal248 on February 28, 2011, 10:55:36 pm
I have no idea what this is honestly, but I'm always for more documentation. Even if nobody here will really use it, someone else might be interested in it later on.


It means more space to write hacks and the ability to port over as many of the PSP's changes that are compatible with the PSX's hardware / limitations as possible.  This may or may not include more room on the Formation Screen, expanded Equipment tables (possibly more than even the PSP added), the added maps/Event/Attack.Out space, and a synching up of sorts between PSX and PSP to make hacks more easily compatible with both versions, as well as the removal of WotL exclusive hardcoding like the slowdown, Rafa/Malak, and other shit.  It all depends exactly what changes rely on Square using more competent coding methods and which ones rely on upgraded software or use of a better version of MIPs than the PSX used, which is the point of this thread - finding which changes can be ported onto the PSX hardware/copied or otherwise replicated in the MIPs used by the PSX version.  It's just a task only one person can sanely do, but a coordinated group of say 3-5 competent people could handle depending on dedication.  I know I want the extra Formation Screen space and gear slots, don't know about anyone else.

We all know you'd be little help for this T, because it involves knowing how to code.  :p

Same here, really, because I know fuck all when it comes to MIPs.
Title: Re: Recompilation
Post by: Pickle Girl Fanboy on March 01, 2011, 05:26:32 pm
I'm reading some books on Common Lisp.

This language is so painless to learn.  Oh my god, it is, it is.  Compared to C++ (which I tried for two weeks last year), Common Lisp is like a warm shower on a cool spring morning.  This is what Java wishes it was.  Anyone who wants to learn more about it should PM me, and some PDFs will find their way into their inbox.

You should talk to Gemini over at http://www.romhacking.net.  That guy knows his ASM.  He got the SNES Star Ocean to play on PS1 hardware, and he has the source for pSX 1.14, straight from pSX_Author, though he says he won't release it, or a binary, unless pSX_Author tells him to.

Quoteor this project is organized so the casual ASM hacker with a bunch of mods on his hands can contribute.

Organize it so every file you're hacking has it's own topic and wiki page, regularly updated with new discoveries, so if, say, Sentinal Blade is working on something for his mod and it's relevant to your investigations, he can pop into the relevant thread, post it, and go his merry way.  If someone's interested in a particular functionality, they can investigate the relevant file without having to deal with things they're not interested in or equipped to deal with.

Note: If you do make separate wiki pages for PSP and PS1 game files, make sure they're labeled as such.  Ditto on topics/threads.

Why don't you go find DarthPaul and see if he wants to come back?  He might like the way the community is organized now.
Title: Re: Recompilation
Post by: Kourama on March 03, 2011, 12:25:31 am
I would definitely be interested in this being a successful project, but I'm not sure if I could be helpful with this. I know very basic hex editing and don't usually have a lot of time on my hands.
Title: Re: Recompilation
Post by: Wasabi on March 04, 2011, 09:44:40 pm
Thanks fdc for making this topic. I'm part of the majority that has zero coding or hexing experience (aside from simple adjustments and/or allocations from playing around with GameShark codes in the past), but I do truly want to see this project progress towards its optimal course so that more flexiblehacks can be applied for either the PSX or PSP version of FFT (or both). I'm all for a larger formation screen and additional gear slots, and would like to see some ASM hacks applicable for both versions of the game. If the framerate lag could be fixed and an upgraded shishi program could be made for the PSP, I'm all for this project to be realized.

I'm willing to beta test whatever is given to me involving this project, within fdc's or any ASMer's convenience. So far I'm able to run ISOs under ePSXe on my netbook, and play patched PSP ISOs and PSX eboots on my PSP. Just throwing that info out there in case anyone wants feedback on how certain changes appear from this project's progression.
Title: Re: Recompilation
Post by: Celdia on March 05, 2011, 11:14:47 am
Quotelike a warm shower on a cool spring morning.


How poetic, PGF. That said, I support the intent behind this idea. It would be great to have the extra space all tagged out and labeled for use. But potentially years of work (depending on contributers) for fuck-all knows what will come of it? I just don't know if I can get behind the actual project. Feels like a big pile of diminishing returns there.
Title: Re: Recompilation
Post by: Pickle Girl Fanboy on March 07, 2011, 03:15:40 pm
Quote from: Celdia
I support the intent behind this idea. It would be great to have the extra space all tagged out and labeled for use. But potentially years of work (depending on contributers) for fuck-all knows what will come of it? I just don't know if I can get behind the actual project. Feels like a big pile of diminishing returns there.

Right now, two months after one hacker started on formulas in BATTLE.BIN, we are about two months away from fully modifiable formulas.  One hacker, that's all it took.  Now, imagine if we brought the full power of social media to bear on this problem?  A hundred small contributers can be as good as one big contributer, if there is no duplication of effort.

Although I'm busy learning something else, this is still interesting, because someone could use the information discovered to make an open source clone of FFT, which uses the same data formats as FFT (though I'd prefer more detailed sprites).

http://www.purezc.com/index.php?page=home&section=history
^This is a site that features spritesheets for a Legend of Zelda clone.

Anyone know what language FFT was written in?  Are there any patterns common to, say, C programs that are sitting in the game?  Is there any uncompiled code sitting in there somewhere?  Can we research the programmers from the credits of FFT and find out more about them, where they went to school, what they studied, what other games they worked on, what development group they were a part of at Square, where they are now?

@fdc: What tools do you use?  pSX 1.13, a hex editor, and renegade64, I assume.

What tools do you need to make your work easier?

http://en.wikipedia.org/wiki/PlayStation_%28console%29#Technical_specifications

crasm
http://crasm.sourceforge.net/crasm.html
Assemble a microprocessor program and produce output file in Intel HEX or Motorola S Code from source for 6800/6801/6803/6502/65C02/Z80 processors. A program listing and a symbol table are also produced on the standard output.
^Could this help you?

I wonder if it's possible to reverse engineer source code, if we know what implementation of which language it was written in and what it was compiled on?  This sort of reverse engineering is fair use, I believe.
Title: Re: Recompilation
Post by: Atma on March 10, 2011, 04:17:59 am
Hmm, very ambitious undertaking... but the results could be phenomenal!  I've been wanting to make a mod for WotL, but there just isn't nearly the same amount of customization that the PSX version has.  This would definitely be something i'd love to see getting more attention.
Title: Re: Recompilation
Post by: formerdeathcorps on March 14, 2011, 03:46:12 am
PGF:

FFT was written in C.  Release date is 1997 (there was nothing better then) and towards the end of BATTLE.BIN, you see non-ASM ASCII comments detailing files (.C) and folders.  I also found stuff about data heaps (which apparently the coder must explicitly mention in C).  I'm sure stuff like this exists in other files too and I'm sure anyone with a hex editor can do this to find out more about the large-scale file organization of any other important file (WORLD.BIN, SCUS...).

As for code that's never checked in FFT?  We already know that DEBUG mode and Sound Novels are in the English ISO, but not called during normal game procedures.  I strongly suspect there's stuff like this in BATTLE.BIN, especially on some of the longer routines I've seen (like knockback).

I use pSXrel, WinHex or HxD (depending on the computer), as well as the tools downloaded from this site.  I didn't need Renegade up to now, but I might get it to type up the hex for my massive formula hack.
At this point, I'm not exactly sure what other tools I need, though a map of PSX data sections would be nice (e.g. 0x80000000 is ROM, 0xA0000000 is something to do with the system [RNG is called there, as is system time?]...)

Reverse Engineering Source Code...you mean turning Hex back into C?  I know there's commercial programs that do stuff like that (I have some freeware on my laptop that converted EXEs to C#/Java), but it's not 100% and in general, there's no perfect re-engineering software algorithm that can work on any piece of ASM, even for hex code that's simply a compilation of a C program (and even if it did, there's no guarantee the resulting program would be readable or efficient).  Considering also that I intend to ASM hack a lot of the resulting code while under space constraints (and most compilers from any language to ASM use space inefficient algorithms because most of those tend to optimize runtime and minimize the chance for variable misuse/error), it'll be likely that any ASM code I write will yield gibberish when fed through a cheap reverse compiler (because I don't follow conventions that restrict "free" register use).

As for the duplication of effort, that's one of the major barriers in this project (the other being not enough ASM hackers).  I don't know how to split the work that doesn't either result in that or someone doing boring grunt work.
Title: Re: Recompilation
Post by: Darkholme on March 20, 2011, 10:47:30 pm
Doing a decompile of FFT Would be very cool, (decompile it to c/c++ and then recompile to see if it works) but even if the decompile works, the resulting code would be nigh unreadable, and would need to be interpreted (though uncommented c is probably more easily documented than ASM).

I've been experimenting with fftpatcher on my wotl since yesterday; but I'm in my last year of a software design degree.

I don't have alot of ASM experience, and I've only ever done it for a SPARC, but I'd be able to read the ASM (though it might be slow going).

Documented ASM? That's probably harder than documenting some reverse engineered code.

Has anyone considered a different possibility?

We have the battle mechanics guide: What about a new app that can read data from the FFT Files, and *emulates* tactics, based on them? You could write a separate PSP app that reads the datafiles. That app would be able to be ported to other platforms, as you'd just have to compile it for another platform. You'd need to figure out where some of the data is, and what it does, but you wouldn't have to have everything figured out. And much of it could be gleamed from what's already been figured out by other people.
Plus: If you have a custom engine to start from, you can throw together an editor to work with it much easier than hacking or hex editing, and other projects could be made more easily.

Some people have said "Why bother" about WotL stuff; but one reason is portability. I don't have the time to sit down and play videogames on a console or my PC anymore, but on a PSP I can play it on a bus or in the bathroom or whatever. :)
Title: Re: Recompilation
Post by: MysticKnightFF5 on March 20, 2011, 10:53:11 pm
You have my C++! And my Java!! :D
Title: Re: Recompilation
Post by: Darkholme on March 21, 2011, 12:00:10 am
If I wasn't clear in my last post;

While I'm not going to try to take charge of this project, I was trying to say I'm willing to lend an assist. :)
Title: Re: Recompilation
Post by: Atma on March 21, 2011, 04:14:43 am
@Darkholme
a custom engine would be an awesome achievement.  all the limitations and problems that all the people on these forums have been working with could be eliminated.
one problem is that it's a lot of work, and who here is willing to take on such a huge undertaking.  u'd essentially be making a game but coding it in a way that can pretty much whatever u want it to be.
on the flip side, all the work that has already been done on these forums and especially the potential work being suggested in this topic is also a ton of work.  so, in the long run a new engine would probably be the better choice and the fact that u could also improve the quality and customization beyond what is already in place would be fantastic!  (hd sprites ^.^)
Title: Re: Recompilation
Post by: Darkholme on March 21, 2011, 10:35:50 am
Yeah; I guess.

I was suggesting it be written for the original psx architecture/PSP (Though a PC port would not be so so difficult), and for much of it (Maps; Unit stats; Events; Cutscenes, and possibly even graphics) have the program use the data from the psx iso or the psp iso. He have editors and extractors, why not just use the data that's there? Extract it, and just build an engine that reads the data? I think it would be alot less work than re-coding the game from scratch - most of it could be done with the knowledge already available in this community.

The data need not stay in the same format if we want expandable files (http://"http://nwn.bioware.com/developers/"). Bioware gave the specifications out for a few binary files that function alot like xml files; but much much smaller. There are a few editors available on nwvault.com for them, and I believe a few of those are open source.

I'd suggest we stick to paletted sprites, though it wouldn't be hard to move the max from 16 colors to 32.

Though I guess so long as we stuck with c++ we could do it for PC and Port it later. (But keeping in mind the PSP/PSX Screen size when developing the app, and cleanly separating our reliance on libraries, so we can just sub out the libraries for PSP libraries later). - Personally I never game on my PC anymore, and do my gaming almost entirely on the PSP nowadays.

If we want to do this really pro; we could get together a large number of us and start a small on-the-side company, and release our own TBSRPG based on the custom engine (using the official playstation development kits - we could all pitch in and buy one with the software, maybe a couple, and our more prominent coders could have access to the official PSP/PS3 Libraries while we develop). - That would be awesome (though that would be a goal for quite a while from now, if we ever went for it).

Tangent: I come from a java/c#/vb.net background, and most people's c++ is so poorly arranged (disorganized) it makes my head hurt - and some of the base libraries are a nightmare to work with. For me it would be ideal to either be able to make this in c# in visual studio or Java, in Eclipse (but then it's more difficult to port to a console if we later want to). I should note, that C#, AND Eclipse, both support compiling to binary, though it could take some work to do it for PSP Architecture.

These are all possibilities. I guess if we're going to do any of these things we need to figure out some stuff first. (I'll doublepost to break it up)

One thing I have been wondering - Is there a tool to pull out the cinematic cutscenes from WoTL as computer files/has it been done already?
Title: Re: Recompilation
Post by: Darkholme on March 21, 2011, 10:45:48 am
IF any of these things are to be done; we would need to figure out:

1. Interest: Which of these approaches do we want to take? Is there enough interest in any of them? (Main Decision + Teambuilding)
- Figure out the rest of the ASM for the PSP Version.
- Reverse Engineer it and recompile it.
- Custom Engine that could run FFT, or could run something new.

Who would be interested and what could they contribute? Who would be making the decisions, and who would be in charge?

2. Start figuring out the details of HOW we want to approach whichever of the three we decided on. Plan it out, and Plan out who is going to do what.

3. Start Writing it?

I've got some Software Project Management training, though I'm not sure I have the time to commit to this thing to make me managing everything be a fast process.
Title: Re: Recompilation
Post by: formerdeathcorps on March 21, 2011, 12:10:45 pm
All right.  Good to see someone else on-board.

Quote
One thing I have been wondering - Is there a tool to pull out the cinematic cutscenes from WoTL as computer files/has it been done already?


Yes, using UMDGen on the PSP ISO, the movie files, in .pmf format, are in PSP_GAME/USRDIR/movie.

Quote
I was suggesting it be written for the original psx architecture/PSP (Though a PC port would not be so so difficult), and for much of it (Maps; Unit stats; Events; Cutscenes, and possibly even graphics) have the program use the data from the psx iso or the psp iso. He have editors and extractors, why not just use the data that's there? Extract it, and just build an engine that reads the data? I think it would be alot less work than re-coding the game from scratch - most of it could be done with the knowledge already available in this community.

The data need not stay in the same format if we want expandable files. Bioware gave the specifications out for a few binary files that function alot like xml files; but much much smaller. There are a few editors available on nwvault.com for them, and I believe a few of those are open source.


Let me see if I understand your idea:
1) We run this on pSXfin or ePSXe.
2) We extract map/sound/event files and rewrite each file in some new file format and then compile to binary (preserving all non-mechanics data).
3) We rewrite WORLD.BIN, SCUS, and BATTLE.BIN (since those are the primary mechanics files...mostly the latter two) in some higher level programming language and recompile to binary, replacing the existing files.

Essentially, you're saying to do all the real coding work in a higher level language instead of ASM (without even bothering to look at the original) so later if we want to expand the game (by adding 10 new status effects or more unit variables) or port it to PC or another platform, we can more easily adapt that.

Quote
1. Interest: Which of these approaches do we want to take? Is there enough interest in any of them? (Main Decision + Teambuilding)
- Figure out the rest of the ASM for the PSP Version.
- Reverse Engineer it and recompile it.
- Custom Engine that could run FFT, or could run something new.


In any event, I don't see how we can avoid the first option.
1) From experience, we figured out roughly the AI priority on actions, as well as implied formulas on skillsets (which I confirmed when looking through the weapon formulas), some of the changes and hard-coding in the PSP version (like Rafa/Malak have a maximum hit of 10 on their skills), and the BMG by Aerostar certainly has a lot of other useful data (though stuff like "quick is a status" is wrong as we found out when we looked at the ASM).
2) Some things we don't know too well (the binary format of FFT's sound files), but we can work around on a custom engine (by using the equivalent MIDI/MP3 files).
3) However, there probably still exist features/version differences (between pSX/PSP or JP/USA) we never imagined existed.  FFT contains features (like Sound Novels and Debug Maps) that's not referenced or rarely referenced (knockback).  How do I know similar features aren't hiding elsewhere?
4) Furthermore, there exists features that we know must exist (AI, for example) that we don't know the explicit address to or layout of (the recent find by Pokeytax on terrain is one such thing).  Of course, when making an engine, this can be worked around, but the original layout may contain surprises that we don't know about that could easily affect mechanics.  Thus, our knowledge of such "hidden" features in either version needs to be made precise.  This will still require ASM deciphering of the main mechanics files.  Of course, once that occurs, I don't see why we can't do the other two options (or use that rather than copy/paste to insert PSP options into the PSX or vice-versa).

I know...this approach may take longer, but a lot of the PSP ROM's battle mechanics routines will likely be the same or very similar to the FFT ROM's, so the process is more of comparison than total decompilation.

Quote
Who would be interested and what could they contribute? Who would be making the decisions, and who would be in charge?


I can definitely work on ASM either in deciphering or reverse engineering (after I finish hacking formulas), but I'm not too great with higher level languages.  I'd be willing to help make decisions or assign roles, but I don't think one person should be monopolizing that role.
Title: Re: Recompilation
Post by: Darkholme on March 21, 2011, 01:43:50 pm
Quote from: formerdeathcorps on March 21, 2011, 12:10:45 pmEssentially, you're saying to do all the real coding work in a higher level language instead of ASM (without even bothering to look at the original) so later if we want to expand the game (by adding 10 new status effects or more unit variables) or port it to PC or another platform, we can more easily adapt that.
It seems to be the more efficient way to do it; particularly with the Battle Mechanics Guide and the work that's been done here. I don't think we would need to know the exact process they follow to run each thing, so long as the end result is the same.

Quote from: formerdeathcorps on March 21, 2011, 12:10:45 pm
Let me see if I understand your idea:
1) We run this on pSXfin or ePSXe.
2) We extract map/sound/event files and rewrite each file in some new file format and then compile to binary (preserving all non-mechanics data).
3) We rewrite WORLD.BIN, SCUS, and BATTLE.BIN (since those are the primary mechanics files...mostly the latter two) in some higher level programming language and recompile to binary, replacing the existing files.

1) I was going to say we run it on the actual hardware, but yeah, an emulator could work. (Or we design it for PC, but intentionally design it to be fairly easy to Port to the PSX/PSP).
2) We extract the Map/Sound/Event files and rewrite each into an expandable format instead of one with fixed sizes; and maybe also battle.bin (that's where the jobs, characters, and abilities and whatnot are, isn't it?)
3)I don't know really what World.bin and SCUS do though - I'm guess the user interface and the maps and whatnot - and that's easy enough to redo; so yeah.

Quote from: formerdeathcorps on March 21, 2011, 12:10:45 pmIn any event, I don't see how we can avoid the first option.

Why? I think that between what's in the BMG and what's in the Gameshark Guide and what's in the FFTPatcher, We know most of what we'd need (and can make up the rest to fill in the gaps - just section off that area with a comment that that area is a best guess, and if we ever learn more about it we can update it;)

Quote from: formerdeathcorps on March 21, 2011, 12:10:45 pm1) From experience, we figured out roughly the AI priority on actions, as well as implied formulas on skillsets (which I confirmed when looking through the weapon formulas), some of the changes and hard-coding in the PSP version (like Rafa/Malak have a maximum hit of 10 on their skills), and the BMG by Aerostar certainly has a lot of other useful data (though stuff like "quick is a status" is wrong as we found out when we looked at the ASM).
Right. I think we'd have to right a custom AI, but having a general idea how the original works would help us figure it out. The AI would probably be one of the hardest tasks. On the plus side, we could make the NPC fight a little smarter.

Quote from: formerdeathcorps on March 21, 2011, 12:10:45 pm2) Some things we don't know too well (the binary format of FFT's sound files), but we can work around on a custom engine (by using the equivalent MIDI/MP3 files).
A Custom sound engine should be easy enough; we can find a sound library online to handle whatever we need.

Quote from: formerdeathcorps on March 21, 2011, 12:10:45 pm3) However, there probably still exist features/version differences (between pSX/PSP or JP/USA) we never imagined existed.  FFT contains features (like Sound Novels and Debug Maps) that's not referenced or rarely referenced (knockback).  How do I know similar features aren't hiding elsewhere?
You don't necessarily need to. They're hiding. Again, I say we best guess it, and if we turn out to be slightly off, we adjust. I dont think the new engine needs to have all the half-finished, unimplemented aspects of FFT.

Quote from: formerdeathcorps on March 21, 2011, 12:10:45 pm4) Furthermore, there exists features that we know must exist (AI, for example) that we don't know the explicit address to or layout of (the recent find by Pokeytax on terrain is one such thing).  Of course, when making an engine, this can be worked around, but the original layout may contain surprises that we don't know about that could easily affect mechanics.  Thus, our knowledge of such "hidden" features in either version needs to be made precise.  This will still require ASM deciphering of the main mechanics files.  Of course, once that occurs, I don't see why we can't do the other two options (or use that rather than copy/paste to insert PSP options into the PSX or vice-versa).
That's what I was suggesting. This would be the part that mainly gets *written* instead of interpreted from a file. If the original layout contains surprises, they wouldn't likely be in our ripped data or they just wouldn't get used (Examples being the various flags you see in FFTPatcher labelled unknown or left blank - the engine would save them, but ignore them, until we know what they're for).

Quote from: formerdeathcorps on March 21, 2011, 12:10:45 pmI know...this approach may take longer, but a lot of the PSP ROM's battle mechanics routines will likely be the same or very similar to the FFT ROM's, so the process is more of comparison than total decompilation.
Oh; I guess. I was suggesting we use what we have, and update it with things we learn.

Quote from: formerdeathcorps on March 21, 2011, 12:10:45 pmI can definitely work on ASM either in deciphering or reverse engineering (after I finish hacking formulas), but I'm not too great with higher level languages.  I'd be willing to help make decisions or assign roles, but I don't think one person should be monopolizing that role.
Well that works out for me. Frankly, I'm I'm not that great with Assembly, but I can plan out and execute a software project at a higher level.

Though those formulas would be really handy. If you can figure out the formulas for the attacks and whatnot, then we don't need to guess and worry about "how far off" the formulas are from what they're supposed to be.

A) Maybe the two of us can figure out what we have to make the priority for the data ripping. My first priority would be Jobs, Monsters, and Abilities (The same data you see in FFTPatcher).

B) Then I'll build a data ripping app to take what we need, and reencode it into XML/GFF. This way, if we figure out more, we can adjust the extractor, and re-rip the data with the new stuff we need. I think that would be the first step.

C) Then we'd need to start building an engine that simulates the FFT engine, using the ripped data. That's the harder part. Hopefully there would be other programmers to help with part C. - it's a much bigger task.

D) Then we write the AI, Some kindof world map module (with random encounter chances), and something to interpret the ENTD data. Again; other programmers required for any real speed.
Title: Re: Recompilation
Post by: Pickle Girl Fanboy on March 22, 2011, 11:07:35 am
Remember that the battle map portions of FFT are 3D, while the character themselves are 2D sprites.  And getting a working demo up and running is more important at this stage than planning how you will implement job classes and ability data, though it's still good to think about that stuff.  If you can get a simple hardcoded sprite moving on a 2D chess grid, then you can start on the 3D engine, camera angles, and stuff like that.  You can softcode and break everything into modules once the Tactical RPG engine starts to attract more developers; FFT wasn't made by one person, and it's unreasonable to believe that you can do this alone.

I recommend you use a language that has automatic garbage collection and is well supported.  I'm learning Common Lisp - very slowly - but I can find only one open-source GUI toolset.  I hesitate to recommend it to anyone here, but I believe it is an excellent alternative to Java, provided you have the patience to learn about it.  If you don't, then any compiled language with automatic garbage collection should be preferred to Java - this engine can't afford to be slow or big.

http://www.google.com/#sclient=psy&hl=en&site=&source=hp&q=common+lisp+as+an+alternative+to+java&aq=f&aqi=&aql=&oq=&pbx=1&bav=on.2,or.r_gc.r_pw.&fp=ff3e2739446bc197
Title: Re: Recompilation
Post by: Darkholme on March 22, 2011, 12:34:51 pm
Very true;

I don't think I want to use LISP; You're right about java though, it's a tad slow if it's in bytecode. Though if you compile it down to machine code; I'm told it runs just as fast as any other application. And the compilers I've seen can start with bytecode instead of a full source. So if we packaged the free compiler, it could be set up to compile it down during install. I was actually considering using C# for the programming. It has a garbage collector, and it's got a fantastic SDK, and has a more structured and neat flow than c/c++ code. A library called mono for linux allows for C# programs in linux, which would make it portable.

Those are some fair criticisms. It would definitely need an engine to work off of, before it would attract more coders. Implementing the classes now would be starting in the wrong place. However, having a broad, general plan of implementation isn't a bad thing. Planning the project isn't "Making the damn game!" as it were, but some amount of planning saves alot of headaches later. I don't think I've gotten to the point where I'm overplanning. Just laying out some broad ideas, and figuring out what the goals will be.

This idea isn't even to the point where I'd start a thread for it yet though... I've contacted Kivutar (http://ffhacktics.com/smf/index.php?action=profile;u=2596) (He's making Tethical (http://ffhacktics.com/smf/index.php?topic=6809.0), an online PvP FFT Demo Game). We don't quite want to do the *Same* project, but we're talking about resources we could share, or the possibility of combining the two projects, since they are similar.

Can you explain how 3d sprites work? I was under the impression they were regular sprites, with some code that says which sprite to show by camera angle.

~DH
Title: Re: Recompilation
Post by: Pickle Girl Fanboy on March 22, 2011, 01:40:52 pm
Saint Ajora, I'm sorry.  Typo, I meant to say that they're 2D sprites.  C# is probably your best bet.

There's nothing wrong with planning.

One last thing: when you get a google code page set up once you're far along in your project that you need one, please, please include *.zip or *.rar or whatever of all your source codes for every version you release.

http://code.google.com/p/bsnes/downloads/list
^Something like this.
Title: Re: Recompilation
Post by: Pickle Girl Fanboy on March 25, 2011, 05:06:44 pm
http://www.backerstreet.com/rec/rec.htm

Holy crap.
Title: Re: Recompilation
Post by: Darkholme on March 25, 2011, 06:53:04 pm
That's nifty. I've seen the old version.

Decompilers are cool. :)
Title: Re: Recompilation
Post by: MysticKnightFF5 on March 28, 2011, 02:54:34 pm
I enjoy how I was ignored...lol...
well, anyways, I'll help in any way I can.
Title: Re: Recompilation
Post by: Pickle Girl Fanboy on March 29, 2011, 02:19:52 pm
I can compile and do a bit of testing on ubuntu, but my bullshit is free ;)
Title: Re: Recompilation
Post by: Atma on March 30, 2011, 03:07:54 am
don't feel bad, Mystic.  i got ur LotR reference.  :D 
it even made giggle.
Title: Re: Recompilation
Post by: heiir on March 30, 2011, 02:57:24 pm
I really hope you get enough people to do this, that'd be so epic. WotL would be way better if you could use most of the programs on here.
Title: Re: Recompilation
Post by: Gotwald on March 31, 2011, 01:30:04 am
For me, the only way to make WotL better would be to remove the slowdown... whoever figures out how to make it so the FPS doesn't half when spell effects are played have many WotL players in debt to them.
Title: Re: Recompilation
Post by: Darkholme on April 01, 2011, 05:24:34 am
Quote from: MysticKnightFF5 on March 28, 2011, 02:54:34 pm
I enjoy how I was ignored...lol...
well, anyways, I'll help in any way I can.


Sorry about that.

Anyways; my idea is to work on Tethical with Kivutar, and try to design it in such a way as to be port-friendly as much as possible, so that if we decide to port it to another system we dont have to start over. His project is fairly small in scope, compared to what I suggested; but if we combine our effort; we can use his demo as the starting point for the rest of the *Bigger* project, with an already mostly functional game engine that we just need to expand on; and online multiplayer.

I'm dealing with some crap for end of the year finals; and then I'm going to start trying to help him out with more than ideas.

Quote from: Gotwald on March 31, 2011, 01:30:04 am
For me, the only way to make WotL better would be to remove the slowdown... whoever figures out how to make it so the FPS doesn't half when spell effects are played have many WotL players in debt to them.
That's a hack worth investigating, and it's certainly achievable. FUSA does it by accident when you connect your PSP to your TV; though it tends to run things a bit slower overall when connected that way; the spell slowdown doesn't happen. So SOMETHING FUSA does is stopping the spell lag.
Title: Re: Recompilation
Post by: MysticKnightFF5 on April 01, 2011, 10:44:16 am
Well...what does FUSA edit? Only one thing: the display. ....Which means it's probably a PSP problem, not a WotL problem....
Title: Re: Recompilation
Post by: Pickle Girl Fanboy on April 01, 2011, 12:29:58 pm
Maybe forcing the game to run slower prevents the animation slow-down?
Title: Re: Recompilation
Post by: MysticKnightFF5 on April 01, 2011, 01:14:36 pm
Possibly. either way, how easy is that going to be to invoke? research into how this FUSA works is what we need to do to come up with a solution.
Title: Re: Recompilation
Post by: Darkholme on April 02, 2011, 12:20:14 am
It's not a display problem with the console. If you take a psx fft rom and play it on your psp (psp can play psx games) it doesn't have the slowdown. The slowdown only happens in the Official PSP Release.
Title: Re: Recompilation
Post by: MysticKnightFF5 on April 02, 2011, 07:29:26 pm
It wouldn't be surprising if WotL takes up more hardware....
Title: Re: Recompilation
Post by: Darkholme on April 03, 2011, 01:38:15 am
But it's not running the cinematic cutscenes when the slowdown happens, and I dont think the special effects from spells are any different than in psx.

It's not like it's always slower, its just with the spell animations. And its not just specific ones, it's all of them. So the slowdown has something to do with that area of the code.

Well, that, or the unlikely possibility that fft on psp fills up all the systems ram and it therefore has no room left for spell animations, but that seems unlikely, if only based on how long my battery lasts with fft.
Title: Re: Recompilation
Post by: MysticKnightFF5 on April 03, 2011, 09:44:23 am
my battery lasts 6 hours if I have the screen on, and like forever and a half if I have the screen off and I'm just listenbing to music. Unfortunately, it's still any number of possibilities because of all the evidence pointing in different directions, but this FUSA thing fixes it, so we should probably start studying what actually DID help it. :\
Title: Re: Recompilation
Post by: Darkholme on April 04, 2011, 01:02:46 am
I haven't tried FuSa with it, but people keep telling me that it does in fact fix it.
Title: Re: Recompilation
Post by: MysticKnightFF5 on April 04, 2011, 10:29:41 am
Good enough? XD I personally can't research it because I have a research paper to write, a patch to make, a game to make, and a whole myriad of small stupid shit.
Title: Re: Recompilation
Post by: Pickle Girl Fanboy on April 04, 2011, 12:31:30 pm
I know that the slowdown isn't as bad on newer PSPs - ones with more RAM, or clocked faster?  I'm reminded of the appalling slowdown on the PS1 ports of FF4, 5, 6, and Chrono Trigger.  Asking the guys at RHDN about the slowdown on those games could yield some clues, along with finding out if UMDs read slower than CDs.
Title: Re: Recompilation
Post by: MysticKnightFF5 on April 04, 2011, 01:02:11 pm
UMDs definitely run slower--no question on that.
Title: Re: Recompilation
Post by: Kourama on April 04, 2011, 01:25:34 pm
Quote from: Pickle Girl Fanboy on April 04, 2011, 12:31:30 pm
I know that the slowdown isn't as bad on newer PSPs - ones with more RAM, or clocked faster?  I'm reminded of the appalling slowdown on the PS1 ports of FF4, 5, 6, and Chrono Trigger.  Asking the guys at RHDN about the slowdown on those games could yield some clues, along with finding out if UMDs read slower than CDs.


They definitely read slower but even with a PSP running with more RAM and the ISO on the memory card it is still painfully slow compared to converting the PSX version to be PSP compatible. One of the main reasons I don't play the PSP version anymore on my PSP.
Title: Re: Recompilation
Post by: Pickle Girl Fanboy on April 04, 2011, 03:03:46 pm
How fast can you get PSX FFT to play on an emulator on a PSP?
Title: Re: Recompilation
Post by: Darkholme on April 04, 2011, 06:54:59 pm
Quote from: MysticKnightFF5 on April 04, 2011, 01:02:11 pm
UMDs definitely run slower--no question on that.
Oh, if it's a UMD Problem, no wonder I barely noticed it. I have a modded PSP Slim, and about 10 minutes after I bought WotL it was on my memory card. I never play it from the UMD. lol.
Quote from: Pickle Girl Fanboy on April 04, 2011, 03:03:46 pmHow fast can you get PSX FFT to play on an emulator on a PSP?
There's no emulator involved. You need a wrapper of sorts to boot it up, but the PSP processor is a slightly better version of the PS1 processor; that is, it uses the same machine code. FFT from the PSX runs at full speed. The PSP doesn't emulate PSX games, it actually just runs them. (Which is a big part of why I got a PSP, Playing Tales of Phantasia on it is awesome, and I've used FuSa to play that on a big screen. It played at full speed both ways.)

Though I've barely noticed a slowdown in my WotL. It may be a UMD Problem. Once things are less crazy I'll have to try it out all three ways and time some spell animations.
Title: Re: Recompilation
Post by: Pickle Girl Fanboy on April 04, 2011, 07:37:44 pm
Wow, I want my PSP to do that!  Have any good links?

Do you think they could've ported FFT to another language, and that might cause the slowdown?
Title: Re: Recompilation
Post by: Darkholme on April 04, 2011, 09:45:05 pm
Quote from: Pickle Girl Fanboy on April 04, 2011, 07:37:44 pm
Wow, I want my PSP to do that!  Have any good links?
I'll see if I can find them.
First you'll need a modded PSP, with m33 Firmware (might work with others, but that's what I've been using). Older CFW actually uses an emulator, and handles PSX games more crappily.
If you want to be able to use your TV as a screen for standard PSP games and you want it to not suck, you'll need FuSa (and a psp2000 or 3000)
If you want to be able to play PS1 games on your TV using your PSP, you don't even need FuSa, just the adapter cable.
Here's a link to a tutorial that explains the process, and has a bunch of handy links to the apps you'll need! (http://pspslimhacks.com/psp-tutorials/converting-psone-games-to-psp-eboots-psx-to-psp/) :) (They may be outdated though)
And the newest version of Popstation (http://endlessparadigm.com/forum/showthread.php?tid=57).
Newest version of PSX2PSP (http://www.maxconsole.net/showthread.php?40946-PSX2PSP-v1.4-Popstation-GUI)
And here's some technical stuff (http://www.maxconsole.net/showthread.php?101299-Comparing-eboot-converters-%28Surprising-results!-Not-all-eboots-are-created-equal%29) about how some converters don't handle some games very well, and saying which ones to use if you have problems.


There are some sites online where you can get the games, already converted; but I never bothered with that much, since pretty much all the games I'd want I have a PSX Disc For.
ff6 on PSP and ff7 on PSP were fun ways to kill time on the bus. Oh; on the PSP you can pause the game any time by pressing the home button iirc.
Umm. Multi-Disc Games are a bit harder; you're better off hunting for pre-combined isos that put all the discs into one psp eboot.
You can compress the PSX Games, and I did notice FFT was slightly slower when I had the game on the highest compression (It took very little space on my memory card though.)

And here are some pre-made graphics/sounds (http://forums.maxconsole.net/showthread.php?42238-My-custom-PS1-game-menus-with-*animated-icons-and-sounds*) for your PSP Menu for the games.
And Here (http://forums.qj.net/psp-themes-mods-media/85800-ps1-eboot-backgrounds-icons.html)
And some other ones (http://www.riotsgraph.jp/pochistyle/) for non PSX Games.

This one's really Nice for FF6 (http://forums.qj.net/psp-themes-mods-media/85800-ps1-eboot-backgrounds-icons-38.html#post2235706)
I can't seem to find a good one for FFT, though you could extract the menu from WotL I suppose.

Quote from: Pickle Girl Fanboy on April 04, 2011, 07:37:44 pmDo you think they could've ported FFT to another language, and that might cause the slowdown?
I don't think so, I mean why bother. Basically all they have to do is change the screen resolution to match the psp screen, and maybe one or two changes for the psp speakers, and then keep in mind they have a better processor, better graphics chip, more RAM, and that UMDs can hold more than CDs to work with, so they're free to add more stuff.

But yeah; you can pretty easily run any of your PSX Games, or Modded PSX Isos on your PSP.

If you test FFT on your PSP this way, let me know if there is a comparable slowdown.
Also, if you have M33 firmware, at the main menu, press select, and change your USB device to UMD Disc, you can now rip the iso off the UMD, put it on your PC, then when you change it back again, you can transfer it back to your memory card. It runs faster from your memory card, in my experience, and personally I didn't notice the slowdown on mine until someone pointed it out; but as I said, I never played it from the UMD.

Apparently many of the PSX Games can be bought on the PSN if you want to buy them over again for your PSP. Through from what I understand, most of them haven't been changed at all to fit the PSP better, and are exactly the same as a PS1 Rip.
Title: Re: Recompilation
Post by: Mega_Tyrant on April 05, 2011, 03:54:12 pm
As far as extra RAM goes I noticed no difference in animaion slowdown whether I play the game on my PSP-1000 or my PSP-2000.  i.e. they still both run at a snail's pace.

The extra RAM only seems to help when the game has to load large amounts of data, for example when playing Monster Hunter Freedom Unite switching between different areas occurs much faster on the PSP-2000/3000 than it does on the PSP-1000. Sometimes several seconds faster.  For WOTL where the animation effects are not exactly large files or massive amounts of files the extra ram has little effect if any at all.
Title: Re: Recompilation
Post by: Darkholme on April 05, 2011, 07:53:06 pm
Good to hear the difference between 1000/2000.
Have you compared UMD vs Memory Card?
Title: Re: Recompilation
Post by: MysticKnightFF5 on April 05, 2011, 08:50:41 pm
Memory Card is easily faster--Ethereal Kingdoms proves that easily. You can hardly even play EK on UMD.
Title: Re: Recompilation
Post by: Mega_Tyrant on April 06, 2011, 12:36:14 am
I haven't played anything from UMD in quite a while, years to be honest, but typically anytime the game has to read data from the disc it takes longer due to having to spin the disc.  But WOTL isn't anywhere as bad as EK when it comes to constantly having to load data from the UMD.
Title: Re: Recompilation
Post by: Darkholme on April 06, 2011, 01:49:57 am
Oh, I knew that. Nono, I meant; how bad is the spell slowdown from your memorycard?

It's been so long since I played the PSX version, I don't have a point of comparison anymore.
Title: Re: Recompilation
Post by: Mega_Tyrant on April 06, 2011, 07:28:14 am
here's a comparison video (not by me), It's pretty much exactly like that.  However the video doesn't show the sound desync very well (most annoying part imo).

http://www.youtube.com/watch?v=cNnyH-yS6lw

Title: Re: Recompilation
Post by: Darkholme on April 06, 2011, 09:37:23 am
Hmm. I don't think that's behaving like lag. That looks intentional.

Has anyone compared PSX English spell time to PSX Japanese spell time? I wouldn't be surprised if the PSX version of the game had sped-up animations here and they didn't bother to re-speed up the new translation. I mean, they dumbed down the difficulty in the psx english version as well.

Does the japanese WotL also have the slowdown?

http://www.nme.com/movies/trailers/id/lDayDcOR9xQ/search/movie (http://www.nme.com/movies/trailers/id/lDayDcOR9xQ/search/movie)
I dunno; I could go either way on that one.

Those are some funky sprites/portraits though. Look at delita, ramza, and those chocobos at 0:23 in.

Japanese PSX Version. and a guy talking about the PSP Port
http://www.chaptercheats.com/gamevideoplay/psp/24083/Final-Fantasy-TacticsWar-Of-The-Lions-Part-II/LEGvaRxgltM/ (http://www.chaptercheats.com/gamevideoplay/psp/24083/Final-Fantasy-TacticsWar-Of-The-Lions-Part-II/LEGvaRxgltM/)

Yep. it's apparently on purpose. I'll try out the Japanese ISO when I get the chance.

If it really goes away when you use FuSa I'm definitely interested in what it does. But this might involve ASM to the animations, and I don't imagine that would be the easiest thing to do.

Soo from what I understand, for whatever godforsaken reason, the slowdowncomes from them intentionally capping the FPS  during those animations at roughly half the speed they used to go. This was a design decision. Apparently the north american port was sped up slightly beyond the japanese version.

This might actually be as easy as finding where it is and changing a number; to raise the framerate during spell animations.

Also, this confirms my earlier mention that the PSX version runs at full speed on the PSP.
Title: Re: Recompilation
Post by: Atma on April 08, 2011, 03:00:47 pm
yeah, PSX version runs like a charm.  I've played WotL off my memory stick and UMD and they both have the same result with the effects.  I've tried FuSa, as well... the skill animations work much better, but the entire game runs slower.  i've tried a few games, it's just how it works.  on the site there's a compatibility list and most of the games mention that it runs slow, however, if the developer is able to decrease the slowdown or fix it entirely, it would definitely be all i'd need for the skill lag fix. 
of course, fixing it in a more accurate or direct way would probably be better.
Title: Re: Recompilation
Post by: Darkholme on April 08, 2011, 10:32:57 pm
Actually. I think if FuSa sped up; you'd have the skill Lag Back.

From what I understand from the articles I read when I was looking this up: They limited the FPS during skills to 15, instead of the usual 30-60.
From when I used FuSa with other games, what I got was a framerate drop. (Presumeably couldn't handle full-speed.)

So I think what's happening there is likely that FuSa can handle 15 FPS just fine, and can't handle full speed. So the rest of the game slows down, but the skill animations are going slow enough that FuSa doesn't lag them further.
:/

Of course, don't know that as a fact, just putting my experiences with FuSa together with what I read about how the slowdown was implemented.
Title: Re: Recompilation
Post by: Glain on April 08, 2011, 11:28:43 pm
Darkholme: Figured I'd check this thread out as you referred me from the other one. This is an interesting topic... I know next to nothing about the PSP version, though, so I could probably only offer logical/process insight, little else... (Unless randomly writing ASM helps things, but somehow I doubt it :))

I read a theory somewhere that the slowdown could have something to do with the PSP's vertical sync being slower... but if the PSX version runs fine on the PSP, then that wouldn't explain it.

One question, and maybe this has already been addressed, but what would happen if you took the effect files from the PSX ISO and put them into the PSP version? The idea being that the effect files have something to do with the animations, so maybe they could also affect the speed...
Title: Re: Recompilation
Post by: Darkholme on April 09, 2011, 12:35:54 am
Quote from: Glain on April 08, 2011, 11:28:43 pmOne question, and maybe this has already been addressed, but what would happen if you took the effect files from the PSX ISO and put them into the PSP version? The idea being that the effect files have something to do with the animations, so maybe they could also affect the speed...

That's an interesting idea. and they didn't add any new special effects. That might be one thing to look into.

What file has the graphical engine in FFT on the PSX?
Title: Re: Recompilation
Post by: MysticKnightFF5 on April 09, 2011, 12:52:02 am
Quote from: Darkholme on April 08, 2011, 10:32:57 pm
Actually. I think if FuSa sped up; you'd have the skill Lag Back.

From what I understand from the articles I read when I was looking this up: They limited the FPS during skills to 15, instead of the usual 30-60.
From when I used FuSa with other games, what I got was a framerate drop. (Presumeably couldn't handle full-speed.)

So I think what's happening there is likely that FuSa can handle 15 FPS just fine, and can't handle full speed. So the rest of the game slows down, but the skill animations are going slow enough that FuSa doesn't lag them further.
:/

Of course, don't know that as a fact, just putting my experiences with FuSa together with what I read about how the slowdown was implemented.


Logical theory is logical. Let's run off of that and see where it gets us...
by the way...
"the secret was to move the REST of the universe! Not your ship!!"
sounds like the same situation, lol
Title: Re: Recompilation
Post by: Atma on July 27, 2011, 07:58:30 pm
wow, been a while since the last post here.  I'm wondering if anyone is still interested in working on this?  I know a lot of people don't even wanna touch this version of the game cause of that damn skill lag, but other than that there's a lot of good reasons to mod this over the PSX version.  More Jobs, Abiilites, Equipment... added story content and battles, cinematics and alternate dialogue(yes, some people hate it, but it's easily replaced to the original or whatever u prefer)... and my favourite reason is that's it's 16:9 screen ratio.  I hate playing games on widescreen tv's that only fill up the 4:3 area >.>
I know Tethical is getting a lot of attention these days, but having a good custom version the the game is nice to have, at least while we wait for more work on it to be done.