Qhimm.com Forums
Final Fantasy 7 => FF7 Tools => Topic started by: Kranmer on 2010-04-04 22:29:22
-
This hack is no longer needed since Aali's Custom Driver (0.7.7b) now supports loading the DLL so the EXE no longer needs patching.
here is Aali's Custom Driver 0.7.7b with the speedhack.dll and enabled in the CFG
http://www.mediafire.com/?wz3mmyofnmg
-------------------------------
Hi guys, I was reading through the "Custom Driver" Thread yesterday and a few people have asked how to make the game go faster or just for higher FPS, So i decided to implement Dark Byte's Generic Speedhack (speedhack.dll) into FF7 so that a box will run along side the game allowing the user to change the speed that the game will play at.
Here are some screenshots
here the game boosted by a very little amount.
(http://img260.imageshack.us/img260/6222/ff7speedhack1.jpg)
here it is boosted by a lot.
(http://img263.imageshack.us/img263/12/ff7speedhack2.jpg)
Anyway here is the patch
http://www.mediafire.com/?zzzugekamyf
THIS IS A ALPHA TEST AND WILL ONLY WORK ON A UNMODDIFIED FF7.EXE 1.02.
ALSO BACKUP YOUR FF7.EXE BEFORE APPLYING THE PATCH.
Any Feedback is welcome.
This patch is completely compatible with Aali's Driver and all patches that dont require ff7.exe being modifyed (like "custom textures" and "models" etc).
Known problems:-
1 - After exiting the game somtimes a error while appear (only happened once to me).
2 - If the speed is set too high (and i mean too high) the game may crash when entering a new area (for example 20speed is fine but 500speed isnt)
Thanks To:-
Dark Byte
-
Interesting, Is this just a hack that makes it run faster (sound plays double speed and everything is sped up) or is this a hack that makes it run smoother?
-
Interesting, Is this just a hack that makes it run faster (sound plays double speed and everything is sped up) or is this a hack that makes it run smoother?
I'm going to assume faster graphic motions. Making it smoother would mean increasing frame counts of all models by a factor of four. This would likely make all the sound effects go out of sync since they are executed by animation frames. Try summoning KoR and you'll see what I mean.
-
yes NFITC1 is correct, This is just a generic speed hack to make everything run faster, The audio does go out of sync on things like KoR but normal menu sounds and background music all seem in sync.
I also have noticed that if you use this in a part of the game that has a timer (like the first reactor) or even the battle with emerald weapon, the timer still runs at normal speed even if the game is running at 170+FPS,
Also V-sync limits this hack to 60fps so if your using this its best to disable it for higher fps (if you want higher then 60fps that is, if your happy with 60fps then leave v-sync on)
-
yes NFITC1 is correct, This is just a generic speed hack to make everything run faster, The audio does go out of sync on things like KoR but normal menu sounds and background music all seem in sync.
I also have noticed that if you use this in a part of the game that has a timer (like the first reactor) or even the battle with emerald weapon, the timer still runs at normal speed even if the game is running at 170+FPS,
Also V-sync limits this hack to 60fps so if your using this its best to disable it for higher fps (if you want higher then 60fps that is, if your happy with 60fps then leave v-sync on)
Yeah, the timer uses the system clock, and doesn't take framerates into account.
-
yes NFITC1 is correct, This is just a generic speed hack to make everything run faster, The audio does go out of sync on things like KoR but normal menu sounds and background music all seem in sync.
I also have noticed that if you use this in a part of the game that has a timer (like the first reactor) or even the battle with emerald weapon, the timer still runs at normal speed even if the game is running at 170+FPS,
Also V-sync limits this hack to 60fps so if your using this its best to disable it for higher fps (if you want higher then 60fps that is, if your happy with 60fps then leave v-sync on)
Yeah, the timer uses the system clock, and doesn't take framerates into account.
This is news to me...
I don't remember the PSX having a system clock... I think? I haven looked at mine in years, but I don't remember ever setting the time. I wonder how the original PSX did that...
-
Cool thanks kranmer, works great.
I made a video example of it here, on speed 6:
http://www.youtube.com/watch?v=B4-PSALKtBg
(10 points to whoever can guess what FF game the battle music is from)
-
Cool thanks kranmer, works great.
I made a video example of it here, on speed 6:
http://www.youtube.com/watch?v=B4-PSALKtBg
(10 points to whoever can guess what FF game the battle music is from)
Wow that's cool! But isn't that serpent's 'Viper Breath' suppose to be blue? Which mod made it change?
And imagine if you could speed up the FMV's. DAMN! lol
Anyways, pretty nice hack you got there. ;)
-
That would be my mod. I redid the flamethrower enemy skill. Did not realize it had a palette swap.
-
That would be my mod. I redid the flamethrower enemy skill. Did not realize it had a palette swap.
Aww. I kinda liked the blue-flamey thingy lol.
-
It can be fixed.
-
@titeguy3 - Thanks for that i wasnt sure why, i had no idea it took it from the system.
@Timber - Nice video, I have no idea on the music though.
@drfeelgud88 - i dont know how to get this to work with videos but you could always just reencode your videos at higher FPS to go with this.
-
I'm not sure how it does it (AFAIK there's no system time function in C++), but I remember having a discussion about how the timer completely ignores the framerate, so if you speed up the game you'll have an easier time with the timed segments, and if your game lags, you'll have a harder time with the timed parts of the game.
-
It prob just uses timegettime (the windows internal timer) and uses time based movement rather than frame based. I know that when I made a few games I often had to use Time based movements so that slower PC's would still run the game at the same speed. It is something like this (forgive me I am rusty and I hate time based movement):
Timegettime displays current number of milliseconds that Windows has been operational. It is independant of games and is always running in the background. See Aali's driver, he has also allowed you to upgrade to a more accurate timer performanceQuerycounter which is basically the same idea. http://msdn.microsoft.com/en-us/library/dd757629%28VS.85%29.aspx
http://msdn.microsoft.com/en-us/library/ms644904%28VS.85%29.aspx
below, lasttime, millisec and change are variables that I have made.
Lasttime=timegettime [lasttime becomes the current windows time]
millisec=millisec+change [the number of milliseconds elapsed since timer start is added from the change]
Display Number [formatted to show only when millisec clocks a second, doesnt have to be here in this loop]
change= timegettime-lasttime [The change in time is the current windows time minus the last windows time]
---------
That is bog standard and I hope I haven't made a mistake. The problem with this if I have it right, is that if you were on an EXTREMELY slow computer, the timer would count down at the correct speed but the game would be so slow you would be at a massive disadvantage to complete bombing mission. Not sure why they didn't use Frame based movement here.
I doubt it does this in the PSX version, I am guessing all of that will be frame based movement.
-
Also I think it is really worth mentioning that this speedhack can also be achieved using Cheat Engine 5.6
(since .exe mod patches don't like to play nice with eachother)
Link: http://www.cheatengine.org/
@Timber - Nice video, I have no idea on the music though.
Yeah I was being tricky, the music hasn't been released yet, but it's by Nobuo Uematsu.
-
Also I think it is really worth mentioning that this speedhack can also be achieved using Cheat Engine 5.6
(since .exe mod patches don't like to play nice with eachother)
Link: http://www.cheatengine.org/
@Timber - Nice video, I have no idea on the music though.
Yeah I was being tricky, the music hasn't been released yet, but it's by Nobuo Uematsu.
Basically cheatengine and this hack are very similar (we both use a speedhack.dll created by Dark Byte although we use different DLL versions) but my aim was to make it so that an external program wasn't needed, I basically just inject the speedhack.dll into FF7 everytime it runs.
I am trying to come up with a patch that will work with all FF7.EXE's but its hard since there are so damn many variations,
It may be easier to make different patches for different versions of the game by request then to make a universal patch that will work with every EXE.
-
kranmer, there will be compatibility for other versions of FF7.exe (modded/unpatched/international) of this speedhack in the future?
and other question: this program supports fullscreen view or not?
thanks for your work!
-
kranmer, there will be compatibility for other versions of FF7.exe (modded/unpatched/international) of this speedhack in the future?
and other question: this program supports fullscreen view or not?
thanks for your work!
@AlbusJC - As i said in my last post it is hard to get it working with all EXE's since there are so many different ones but i am trying to work on it but it isnt going well,
But if you want to make a request i will make a patch just for your EXE (either post the info on your EXE here or PM me if you want to request a patch for your ff7.exe).
This works with fullscreen and window and all mods that dont require modding the EXE (like "Aali's Custom Driver" etc)
-
What does it patch? If I make it an option in the custom driver you'll have support for any 1.02-based exe for free.
-
all i really do is basically dynamically load (inject) the speedhack.DLL into FF7 when you start the game.
The speedhack.dll and source is here
http://forum.cheatengine.org/viewtopic.php?p=31178&sid=81985a80cf716600c447fbbf0f3907ff
And i use a little of the DLL inject code from here
http://www.edgeofnowhere.cc/viewtopic.php?p=2483118
-
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.
-
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.
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.
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.
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.
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.
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.
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.
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.
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.
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..?
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 think the 9999 Limit Break should be a definite.
-
i was actually thinking NFITC1's Mdef fix is a must...
-
i was actually thinking NFITC1's Mdef fix is a must...
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.
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.
-
Auto-run with key to deactivate it when necessary!
Now that's something I'd love to see in a plugin!
-
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.
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.
I only made that fix because I could. I don't ever remember dying to an attack that didn't ignore magic defense anyway. It is more balancing because in later parts of the game, most monsters will have higher MDefs than your characters.
As I mentioned way back when I made it (http://forums.qhimm.com/index.php?topic=8133.msg98043#msg98043) it didn't make a lot of difference. An additional 85 MDef made a 7300 attack only do 6200 damage. I'd call that significant (it IS good datum), but it is going to make some monsters easier. The only monsters with real magic threats are the ones in Northern Crater and a few bosses. I suppose it makes everything a little easier to that point, provided you're using armors with a good amount of MDef.
-
Love that mod, but is possible to set the speed parameters on a .cfg file before launching game, to bypass the config window?
-
Love that mod, but is possible to set the speed parameters on a .cfg file before launching game, to bypass the config window?
It might be possible for someone with more coding experience to do this but the most i can do is remove the box and make a DLL that is set at a certian speed but i dont know how to get it to read from a CFG file.
If you would like me to make a DLL or a patch for your EXE so that the game will run faster at a pre-set speed with/without the box i can do this.
-
Hmm.. Can I use your speedhack while running FF7 Music??