Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
You may only link to the game if it's freeware. Otherwise it falls under the "no linking roms" rule.
Mouse support is worked on, but I cannot give an ETA.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
Radiant wrote:
I believe this is our first run on the site on a difficulty level that is intended to be completely and utterly impossible. That strikes me as unique value of this run, and would be a good reason to star it, wouldn't it?
One would think so, but as far as I can see Warcraft II isn't starred, which was our first proper RTS TAS.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
Movies made on Snes9x 1.43 is no longer allowed to be submitted due to the emulator version being too inaccurate. However, if the lags are a result of more accurate emulation (which sounds like the case), the difference in lag will not be considered during judging.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
QuizmasterBos wrote:
Warepire wrote:
Did you disable Ad Hoc networking on the laptop? I've seen that cause some very interesting things.
Well, I'm not very knowledgeable in this, but I DO have a Bluetooth device in my network settings, which I've turned off as a friend of mine told me I was better off disabling it. Do you think it's smarter to keep it on?
What happened for me when I used my laptop at university once was that there were 3 Ad Hoc APs and a real AP within range, and my laptop decided it would constantly drop connection and switch AP, at the university when the connection was dropped, even for a second, you had to log in to the university network again before you could surf.
I've seen some crazy things with computers, it would not surprise me if you had a network loop between 2 APs. But even if this isn't the problem, doing this is a tad safer.
Here's some detailed reading about removing existing ad-hoc networks and disabling it all together:
http://www.sevenforums.com/network-sharing/50453-remove-saved-ad-hoc-network.htmlhttp://superuser.com/questions/163117/how-to-disable-ad-hoc-wireless-connections
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)
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.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
henke37 wrote:
It is a rather trivial API to stub. Most games will just accept the calls doing nothing. Or we could log them and edit in fake achievement popups.
I'm aware it is fairly easy, it is also fully against Steam's EULA for the SDK, and can be used to pirate Steam-games. Hourglass in it's current state does not in itself grant the user the ability to run an illegal copy of a game, while cracked versions of games can be run, Hourglass is not the enabler. Adding the Steam API would make Hourglass an enabling tool. And THAT is what I was referring to.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
CoolKirby wrote:
Whenever Steam games can be TASed, I think it'd be cool to see Angry Video Game Nerd Adventures run, and maybe broken (who knows?).
Not to rain on your parade, but Steam games are going to be the least compatible for as long as I am involved with the Hourglass project, if the game runs without the need to run Steam or have an internet connection, then it can probably work (see Super Meat Boy and VVVVVV). Otherwise we'd need to hook the Steam API, and that can create all sorts of problems that I don't want to face.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
The biggest problem that I know of with modern games is that they need more hooks. For mouse currently in Hourglass we tell the game the acquire of the mouse was ok, then we return error on all the device queries about it. This has to confuse the hell out of the game code.
Another issue is sync-ability over installations.
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.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
Patashu wrote:
Total control confirmed. Program counter flowed into the inventory. Next step is a payload.
**Apu's son's voice** How I have been waiting for this day!
I'm thinking we need to outshine the recent SMW Total Control since it's the PSX we're playing with... A Castlevania themed pinball game could be fun, but implementing it would probably be a nightmare.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
Joseph Collins wrote:
However, a full 106% TAS requires making Hourglass much more robust.
Aww... that's kind of a shame! What would need to be changed, exactly?
The main problem is random frames. Sometimes a load screen in the game passes one frame faster/slower. It is completely random, no way to control this in the game, which means there is probably a bug somewhere in Hourglass, or something needing to be hooked and controlled.
I am working on Hourglass, slowly, because a lot of other stuff keeps stealing my time, this problem, among many others are on my TODO list.
More developers are welcome, just PM me.