Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
Derakon wrote:
Would it be possible to point Hourglass to the DLL you're expected to use? I.e. provide a path in a configuration file somewhere or something. Then you could point it at an "enabling" stub DLL without having to distribute that DLL with Hourglass or generally associate it with Hourglass in any way. Or just use the standard Steam DLL if you want to play a Steam game with savestates and slowdown without trying to make a movie file.
You can TAS games that use the Steam DLL already, syncability cannot however be guaranteed if the DLL does any sort of communication with the internet.
You could theoretically make a replacement DLL (kinda like a mini-image). A DLL that can physically replace the original DLL that the game wants to load. The tricky part with this solution is getting all the function locations the same in the stub as the original DLL. If something is off you can get really interesting results.
An alternative would be a second injected DLL that overrides all the calls to the original Steam DLL. I don't think this is a wise solution as there could be potential "override fighting", i.e. both DLLs hook a function, which one will get to execute it? There's no information on a situation like this, and I currently don't have the time to look into it.
jlun2 wrote:
Warepire wrote:
Everything is theoretically fixable, but developers are needed. I spend most of my free time currently rewriting everything regarding window-management as it (while working pretty good for most games) has serious issues with coordinates that cannot be fixed in the current implementation. The coordinates problem is the major thing holding mouse support back right now.
What's in the current code that makes mouse coords incompatible? :o
The coordinates for mouse are screen relative, with no option of reliably converting them between instances, the re-write makes the game think it covers the entire screen, all the time, and all the coordinates will be relative to the game window. Ensuring (hopefully) 100% syncability between instances.
If this is not done, even a different screen resolution could potentially desync the playback, even if the window is in the right place.
Would it be possible to point Hourglass to the DLL you're expected to use? I.e. provide a path in a configuration file somewhere or something. Then you could point it at an "enabling" stub DLL without having to distribute that DLL with Hourglass or generally associate it with Hourglass in any way. Or just use the standard Steam DLL if you want to play a Steam game with savestates and slowdown without trying to make a movie file.
You can TAS games that use the Steam DLL already, syncability cannot however be guaranteed if the DLL does any sort of communication with the internet.
You could theoretically make a replacement DLL (kinda like a mini-image). A DLL that can physically replace the original DLL that the game wants to load. The tricky part with this solution is getting all the function locations the same in the stub as the original DLL. If something is off you can get really interesting results.
I guess I was thinking of something where you'd tell Hourglass "Here's my replacement DLL for X", and then whenever the game tries to make a call to a function exported by X, Hourglass would redirect the call to the same function as exported by your replacement DLL. I assumed it's already doing similar things for certain calls just to be able to do rerecording.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
Derakon wrote:
Warepire wrote:
Derakon wrote:
Would it be possible to point Hourglass to the DLL you're expected to use? I.e. provide a path in a configuration file somewhere or something. Then you could point it at an "enabling" stub DLL without having to distribute that DLL with Hourglass or generally associate it with Hourglass in any way. Or just use the standard Steam DLL if you want to play a Steam game with savestates and slowdown without trying to make a movie file.
You can TAS games that use the Steam DLL already, syncability cannot however be guaranteed if the DLL does any sort of communication with the internet.
You could theoretically make a replacement DLL (kinda like a mini-image). A DLL that can physically replace the original DLL that the game wants to load. The tricky part with this solution is getting all the function locations the same in the stub as the original DLL. If something is off you can get really interesting results.
I guess I was thinking of something where you'd tell Hourglass "Here's my replacement DLL for X", and then whenever the game tries to make a call to a function exported by X, Hourglass would redirect the call to the same function as exported by your replacement DLL. I assumed it's already doing similar things for certain calls just to be able to do rerecording.
What Hourglass does is load an extra DLL (wintasee.dll), which then in memory creates trampolines out of the original function calls to our methods. All the original DLLs are still loaded, and work as before for all functions we do not hook.
Function calls are just jumps to different memory locations, we cannot immediately redirect the functions, that would require us modifying the executable binary of the game, and probably several of the DLLs. Instead we overwrite the first instructions of the real function and make that jump to us, this also lets us jump back to the real function in case we only want to prevent it executing entirely under certain conditions and merely update a local variable for the others.
Some details might be slightly wrong, I did not write the hooking code, and I have not fully grasped the theory about trampolines and how/why they work as they do.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
solarplex wrote:
South Park: Stick of Truth!
You can use a PS3 controller with it. May try to test it soon if possible.
Joypads of any sort do not have any proper support yet. If it's keyboard only it may work, otherwise you're stuck waiting on me to finish my attempts at fixing mouse-support like everyone else
South Park: Stick of Truth!
You can use a PS3 controller with it. May try to test it soon if possible.
Joypads of any sort do not have any proper support yet. If it's keyboard only it may work, otherwise you're stuck waiting on me to finish my attempts at fixing mouse-support like everyone else
Hmm I haven't played yet(had it installed since it came out). I know you can play with mouse and keyboard. Does Hourglass-resurrection work for mouse? I'm pretty sure I can just use keyboard for the entire thing though! :)
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
solarplex wrote:
Warepire wrote:
solarplex wrote:
South Park: Stick of Truth!
You can use a PS3 controller with it. May try to test it soon if possible.
Joypads of any sort do not have any proper support yet. If it's keyboard only it may work, otherwise you're stuck waiting on me to finish my attempts at fixing mouse-support like everyone else
Hmm I haven't played yet(had it installed since it came out). I know you can play with mouse and keyboard. Does Hourglass-resurrection work for mouse? I'm pretty sure I can just use keyboard for the entire thing though! :)
Mouse isn't finished yet, you are welcome to try if you can build it yourself, but remember that even if you produce a working TAS with it the movie format is not stable yet, meaning it will very likely change (several times) before we settle on a good one. The movie format is not the same as Nitsuja's Hourglass, and thus not accepted by TASvideos yet, we haven't given details on how to support it due to previously mentioned reason.
The movie format is not the same as Nitsuja's Hourglass, and thus not accepted by TASvideos yet, we haven't given details on how to support it due to previously mentioned reason.
I tried digging info about the current format out of source code. Some comments:
- Please change the magic before that thing is considered stable. The magic clashing with existing .WTF files will cause lots of headache.
- Variable-length records create trouble when trying to hex-edit, but OTOH, the full records are very large and storing them in full would seriously bloat the movie file...
- Mouse records store both relative and absolute values. Is there no relationship between the two (thinking about what wildly divergent values would do to games)?
Mouse isn't finished yet, you are welcome to try if you can build it yourself, but remember that even if you produce a working TAS with it the movie format is not stable yet, meaning it will very likely change (several times) before we settle on a good one. The movie format is not the same as Nitsuja's Hourglass, and thus not accepted by TASvideos yet, we haven't given details on how to support it due to previously mentioned reason.
Sounds good, i'll give it a try (already have a tortoisesvn set up for HourGlass-Res). I'll attempt something for fun, even if its not accepted yet. At least maybe the tutorial of the game if anything.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
Ilari wrote:
Warepire wrote:
The movie format is not the same as Nitsuja's Hourglass, and thus not accepted by TASvideos yet, we haven't given details on how to support it due to previously mentioned reason.
I tried digging info about the current format out of source code. Some comments:
- Please change the magic before that thing is considered stable. The magic clashing with existing .WTF files will cause lots of headache.
- Variable-length records create trouble when trying to hex-edit, but OTOH, the full records are very large and storing them in full would seriously bloat the movie file...
- Mouse records store both relative and absolute values. Is there no relationship between the two (thinking about what wildly divergent values would do to games)?
Would have appreciated this post in the Hourglass section.
- I changed the magic, it should be committed and different from Nitsuja's, make sure to look in trunk and not the branches. If it's wrong in trunk, show me and I will re-fix it.
- We are aware of the hex-unfriendlyness, the issue is that recording full keyboard, full mouse, full gamepads etc for each frame gives you a movie that is several kilobytes per frame. We decided this had to happen, a custom editor may have to be written.
- Mouse-recording is not done yet, there may be more issues with the movie format as well, nothing has been properly debugged yet as many things needed to debug it are still being introduced.
We are aware of the hex-unfriendlyness, the issue is that recording full keyboard, full mouse, full gamepads etc for each frame gives you a movie that is several kilobytes per frame. We decided this had to happen, a custom editor may have to be written.
A format that records only the changes ought to be much smaller. You could even use a text-based format (that encodes binary data in hex or e.g. base64 if no bin2txt converter is available).
We are aware of the hex-unfriendlyness, the issue is that recording full keyboard, full mouse, full gamepads etc for each frame gives you a movie that is several kilobytes per frame. We decided this had to happen, a custom editor may have to be written.
Maybe you could have a certain character, like *, at the start of each frame so the input for any one frame could be told apart from another (so *UpSpace*LeftSpace*UpAsterisk would be understood as three different frames). Then all the custom editor would have to do is make a new line at each * and number the lines, and the frame data could be easily edited.
Maybe you could have a certain character, like *, at the start of each frame
creaothceann wrote:
Instead of * you could also use a Unix newline character - editors like Notepad++ understand them.
Nope. At least not for now; HourGlass uses a binary format, something that's not really about to change.
Each frame starts with a flag, noting which input devices (in order: keyboard, mouse and x-box gamepad) are used during this frame. Then the length of the input and the input is listed, per device. It's still fairly simple to tell where frames start and end, that's not the problem. The problem lies in using default tools (= hex editors), as the basic location = header_size + frame_count * frame_size doesn't apply.
Joined: 4/22/2014
Posts: 59
Location: United Kingdom
How about The Floor is Jelly? That game only requires arrow keys for movement, and some definitely unique physics in which the entire world is bouncy.
Not sure if it's feasible at the moment... can Hourglass run Adobe AIR games?
Joined: 4/22/2014
Posts: 59
Location: United Kingdom
Warepire wrote:
Beed28 wrote:
can Hourglass run Adobe AIR games?
If it's an exe then there's only one way to find out. Try to run it.
If it's not an exe, then it will probably never be supported natively.
Haven't replied to this for a long while, but...
I don't actually use Hourglass, I was just asking to check if Hourglass can run Adobe AIR games. I don't think I can even run Hourglass, actually, since it apparently runs best only on Windows XP, and I have Windows 8.5.
Has anyone suggested Halo or Halo 2? I'm watching a speedrun of Halo for Windows at SGDQ2014 and even the skips that can be done in real time are awe-inspiring.
Joined: 11/13/2006
Posts: 2792
Location: Northern California
arflech wrote:
Has anyone suggested Halo or Halo 2? I'm watching a speedrun of Halo for Windows at SGDQ2014 and even the skips that can be done in real time are awe-inspiring.
Hourglass is nowhere even close to the point of being able to run Halo, let alone TAS it.
TASvideos Admin and acting Senior Judge 💙 | CohostwarmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
