[FF7] SpeedHack (Alpha)

  • Thread starter Thread starter Kranmer
  • Start date Start date
Status
Not open for further replies.
Okay, 0.7.7b will have a config option called load_library that simply loads whichever .dll into the game.

It won't be in the default config file though, so people will have to add that line.
 
Last edited:
Okay, 0.7.7b will have a config option called load_library that simply loads whichever .dll into the game.

It won't be in the default config file though, so people will have to add that line.
Click to expand...
Wow nice, Thanks alot Aali, That will be alot of help, I cant wait for 0.7.7b now.
 
@titeguy3 - Thanks for that i wasnt sure why, i had no idea it took it from the system.
Click to expand...
Ya know, now that I think about it I bet it just counts processor ticks. That would explain why the multi-core processors make the timer run slower.

This is my theory: The processor reports itself as running at ~34 Mhz (What the PSX runs at). So an internal timer counts out ~34Mil worth of ticks before incrementing the timer 1 second, right? This is the most reliable way to keep track of time when you are using a fast system than the one intended, don't have access to the system's clock, or you encounter lag that slows down graphics (so you can't count frames).
However, for multi-core processors, they'd report their speed at, say, 3Ghz. But each core reports that and it somehow gets translated as 6Ghz. Now the timer, which is running on only one core, is waiting for 6Bil ticks which takes 2 seconds rather than one. When you switch to a single-core affinity only one core reports its speed at 3Ghz so the timer waits for 3Bil ticks to pass and the timer counts down correctly.
 
@titeguy3 - Thanks for that i wasnt sure why, i had no idea it took it from the system.
Click to expand...
Ya know, now that I think about it I bet it just counts processor ticks. That would explain why the multi-core processors make the timer run slower.

This is my theory: The processor reports itself as running at ~34 Mhz (What the PSX runs at). So an internal timer counts out ~34Mil worth of ticks before incrementing the timer 1 second, right? This is the most reliable way to keep track of time when you are using a fast system than the one intended, don't have access to the system's clock, or you encounter lag that slows down graphics (so you can't count frames).
However, for multi-core processors, they'd report their speed at, say, 3Ghz. But each core reports that and it somehow gets translated as 6Ghz. Now the timer, which is running on only one core, is waiting for 6Bil ticks which takes 2 seconds rather than one. When you switch to a single-core affinity only one core reports its speed at 3Ghz so the timer waits for 3Bil ticks to pass and the timer counts down correctly.
Click to expand...
That actually makes perfect sense. That also explains why the timer never counts in seconds exactly. As for how the multicore processor speeds get reported inaccurately, I have no clue. One could test this theory, however, by running the game on a quadcore and dual core machine and seeing if the timer takes more or less time with more cores.
 
@titeguy3 - Thanks for that i wasnt sure why, i had no idea it took it from the system.
Click to expand...
Ya know, now that I think about it I bet it just counts processor ticks. That would explain why the multi-core processors make the timer run slower.

This is my theory: The processor reports itself as running at ~34 Mhz (What the PSX runs at). So an internal timer counts out ~34Mil worth of ticks before incrementing the timer 1 second, right? This is the most reliable way to keep track of time when you are using a fast system than the one intended, don't have access to the system's clock, or you encounter lag that slows down graphics (so you can't count frames).
However, for multi-core processors, they'd report their speed at, say, 3Ghz. But each core reports that and it somehow gets translated as 6Ghz. Now the timer, which is running on only one core, is waiting for 6Bil ticks which takes 2 seconds rather than one. When you switch to a single-core affinity only one core reports its speed at 3Ghz so the timer waits for 3Bil ticks to pass and the timer counts down correctly.
Click to expand...
That actually makes perfect sense. That also explains why the timer never counts in seconds exactly. As for how the multicore processor speeds get reported inaccurately, I have no clue. One could test this theory, however, by running the game on a quadcore and dual core machine and seeing if the timer takes more or less time with more cores.
Click to expand...
If I were a casual betting man, I'd put money down right now saying that a quad-core timer would be about half as fast as the dual core's.
 
setting my ff7 to run on all four cores, and then playing past guard scorpion to where the "i'm gonna BLOW!!!" counter starts resulted in it running the same speed as if it were only using one core affinity, and the same goes for two core affinity.
 
setting my ff7 to run on all four cores, and then playing past guard scorpion to where the "i'm gonna BLOW!!!" counter starts resulted in it running the same speed as if it were only using one core affinity, and the same goes for two core affinity.
Click to expand...
if you were to run the timer along with a stopwatch, would there be any difference?
 
It probably has something to do with the processor itself. On how it reports its speed, I mean.
 
I did run it alongside a stopwatch, and there was not much difference after five seconds (as in like .03 seconds, but could just be MY timing :P).
 
ok guys this hack is no longer needed.
Aali's newest custom driver (0.7.7b) now supports DLL's so i have made prepered the CFG and the DLL needed for the speedhack and attached them to the beginning of this post.
 
ok guys this hack is no longer needed.
Aali's newest custom driver (0.7.7b) now supports DLL's so i have made prepered the CFG and the DLL needed for the speedhack and attached them to the beginning of this post.
Click to expand...
I wonder what other kinds of mods you can make by injecting a DLL like that..?
 
well to be honest i cant think of that many that havent already been done some other way, but i supose you could just inject your own code like a trainer or a hack into the game without having to use external programs.

Also i have noticed the speedhack doesnt work on FF8 properly. it loads but it only speeds up FMV on FF8 so it proberly wont be of much use there.
 
I wonder what other kinds of mods you can make by injecting a DLL like that..?
Click to expand...
This could be very useful option for replacement of dziugo's various patches.  This way the exe won't have to be patched.
 
Feel free to request patches you want to see implemented as settings for the custom driver. No need to write another library just to do that.
 
i was actually thinking NFITC1's Mdef fix is a must...
Click to expand...
Second that, it's the only patch i use. Used to use the high res patch, But that was our mighty god(Aali)s first fix ;D
 
I agree that both the 9999 limit break patch and the mdef fix should be implemented, as they are the only ones really needed (mdef because it should have been fixed in the original game, and the 9999 limit break because it gives more flexibility with difficulty mods, though is overkill for the original :-P).

The GyptInstant patch could also be something to consider, as the ability to skip the FMV's can be helpful for those with movie issues, or those who are making difficulty mods (like me) who don't want to have to sit through all of the movies repeatedly, namely the intro  :roll:.
 
MDef fix is something I'd like to use myself, so that's a definite yes, I think I'll even leave it on by default. 9999 limit break is also a nice one and I will see what I can do about that. Skipping movies is already possible, just make sure the game can't access the file and the movie will be skipped. It's not as good as gypt, but since there are no crashing issues anymore it should be enough. Oh and if you do this on the intro movie you won't see anything in the first field screen, so run upwards into the first battle or open the menu and everything will be normal again.
 
MDef fix is something I'd like to use myself, so that's a definite yes, I think I'll even leave it on by default. 9999 limit break is also a nice one and I will see what I can do about that. Skipping movies is already possible, just make sure the game can't access the file and the movie will be skipped. It's not as good as gypt, but since there are no crashing issues anymore it should be enough. Oh and if you do this on the intro movie you won't see anything in the first field screen, so run upwards into the first battle or open the menu and everything will be normal again.
Click to expand...
Personally I have never used the MDef fix, so I would like to ask, does it alter the game balance at all?
I know it was supposed to be part of the game, but the fact is, it never has been.
So wouldn't implementing it now make the game somewhat easier than the FF7 that we all know and love?

That being said I do agree that it should be default, because having something in game that doesn't even work is just pretty silly.
 
Status
Not open for further replies.
Back
Top