Man, if this could work, I'd love to see some more PC game TASes.
Can anyone say "I Wanna Be the Guy?"
IWBTG has the same problems as Kaizohacks. Near perfect play is required to even progress, so any TASing wouldn't be significantly faster than an otherwise perfect non-speedrun and rather dull.
I'd rather see games such as Cave Story or An Untitled Story ran.
Hum the problem here, is that you are editing a game code to make it TASable.
How is hooking APIs via Detours or another library editing a game's code? It does not affect the game itself at all.
oh shi...i know nitsuja's method now....
Sorry everyone, I basically haven't even tried to do any work on this project for the longest time (due partly to lack of free time and mostly to a bizarre lack of interest). There are probably only a few weeks of work put into it so far and it could've been ready months ago if I'd stuck to it. But, I'm going to try to make enough time to get back into it now and at least make some sort of progress, even if it has to be slow progress.
mudlord wrote:
Hum the problem here, is that you are editing a game code to make it TASable.
How is hooking APIs via Detours or another library editing a game's code? It does not affect the game itself at all.
I think he was responding to MESHUGGAH's idea. None of those points are real detractors from my (indeed hooking-based) method. (I believe his idea has its own thread now and so doesn't need to be discussed further here.)
Hooking APIs doesn't change the game's code, but it does actually have plenty of potential to affect how the game runs. If done improperly it could cause all sorts of strange behavior, and it's very hard to do it properly in all cases. But that's really no different from the situation with emulators, where perfect emulation is hard to come by and emulator bugs can cause games to do weird things.
ZeXr0 wrote:
SaveState is a problem, because it should be an exact copy of the memory state. Which means you would have to read and write directly to memory the values you want (it will cause conflict at some point)
I was quite surprised with how easy it was to load savestates in running Win32 programs. I didn't really expect it to work, but the first thing I tried was simply overwriting ALL of the program's writable memory (and thread contexts), and actually it tends to work just fine, and quickly. To someone who knows anything about how complicated typical computer software is when you consider everything it's running and how it all interacts, it probably seems outrageous that this method could ever work, but it does. To be fair, there are some refinements required to deal with various things like textures in GPU memory, some of which I'm still working out, and I might yet discover some game that proves impossible to savestate, but all in all it's not bad for a "one size fits all" "instant brain transplant". There are several disadvantages though, so I don't recommend doing savestates this way for anything unless there is no other choice (which there always is if you have either the source code or a real emulator).
scrimpeh wrote:
sticktendo wrote:
Man, if this could work, I'd love to see some more PC game TASes.
Can anyone say "I Wanna Be the Guy?"
IWBTG has the same problems as Kaizohacks. Near perfect play is required to even progress, so any TASing wouldn't be significantly faster than an otherwise perfect non-speedrun and rather dull.
I think the level of play required to merely progress in IWBTG is a lot further from perfection than that. And what little TASing I've done of it so far suggests that there are plenty of little unintended timesavers (things you're unlikely to see outside of a TAS because of how risky they are). Plus, there's enough going on in IWBTG that most viewers probably wouldn't find a quick movie of it dull.
Ferret Warlord wrote:
I was poking around on my hard drive and came across two other games I'd like to see: Seiklus and Legend of Princess.
Thanks, I hadn't heard of Legend of Princess before, I can always use nice little test cases like that.
I am still on the lookout for simple, open-source (and ideally written in C++) games that run on Windows to use for testing. I'm probably looking in the wrong places, but so far the only ones I've looked at have been relatively epic in scope and/or more like a framework than a game. I'd make one myself but it's not something I badly need.
Is Rocks 'n' Diamonds simple enough? (It comes with its own primitive TASing facilities anyway, but if it's just for testing this system then that's no big deal.)
Joined: 10/27/2004
Posts: 1978
Location: Making an escape
nitsuja wrote:
I am still on the lookout for simple, open-source (and ideally written in C++) games that run on Windows to use for testing. I'm probably looking in the wrong places, but so far the only ones I've looked at have been relatively epic in scope and/or more like a framework than a game. I'd make one myself but it's not something I badly need.
I don't think it's very open source, but Ikachan is a short, simple game done by the Cave Story guy. Maybe that could help?
A hundred years from now, they will gaze upon my work and marvel at my skills but never know my name. And that will be good enough for me.
I don't think it's very open source, but Ikachan is a short, simple game done by the Cave Story guy. Maybe that could help?
The engine is so similar to Cave Story's that there wasn't much left to do to support this too, although it did lead me to fix one bug I'd forgotten about. (I know this wasn't the point of your suggestion, but I guess it's also not a very TAS-worthy game... How not to TAS Ikachan.)
Very doubtful. For one reason, Crysis and other modern 3D games probably don't use the same drawing code that this hooks into to get its special code executed. For another, the game state takes up way more memory here, which means that save states would be absolutely painful to deal with unless you have a complete beast of a machine.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Depends on how much time it will take to develop such wrapper for Crysis-level games. In 6-7 years (an optimist, aren't I) an average machine would probably be enough!
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
i don't mind of space and speed, if you are good, you can use 2 saves - 1 in the ram, and the other on the Hard Drive.
speed slowing down should be possible with any game, if it was programmed correct. i think it just needs understanding in the way, how DirectX is working together with games.
Very doubtful. For one reason, Crysis and other modern 3D games probably don't use the same drawing code that this hooks into to get its special code executed.
This would be the easy part. I already have it hooking into many different possible ways of drawing. Adding another might not be trivial but it's definitely possible.
Derakon wrote:
For another, the game state takes up way more memory here, which means that save states would be absolutely painful to deal with unless you have a complete beast of a machine.
This seems like a non-problem. Eventually it won't be much of a problem as hardware improves, and some creative methods of being selective about what to put in the savestates could help too.
That being said, Crysis is not what I would call "simple". It won't happen anytime soon for a huge number of reasons. Certainly not through my efforts, at least.
It seems, most recent games suffer from a bad case of DRM, which makes TASing them a lot more painful.
Aside from that, we just need to let hardware march on if a game is too technically advanced.
Also, there's one really difficult and fundamental problem I've been running into, which is more likely to matter in modern games. The problem is multithreading, or more specifically, how to make a multithreaded game run deterministically when given only a sequence of input. As far as I can tell, these are the only options that have any chance of working:
1: full-blown emulation
2: game-specific options to make them act single-threaded
3: store much more than only the player's input in the movie files and use it somehow on playback
4: only allow one thread to run at a time, and switch between them myself in some deterministic way
5: hope that the other threads don't really matter, and let them run amok
#1, The perfectionist in me likes this one the most. But I assume somebody somewhere is making more progress on this than I ever would and is still far from completion.
#2, I don't like this solution of inventing some hack per multithreaded game engine, but to be honest it sounds the most feasible.
#3, Perhaps this and/or writing their own kernel-level drivers is how Replay Solutions did it, but I really don't want to go there.
#4, Sounds promising, and I've implemented this already, but I haven't been able to find any good-enough criteria for deciding when to switch threads (something always deadlocks). Maybe mixing a bit of solution #2 in is the only way here.
#5, This has been my most successful method so far, but it's obviously not a long-term general solution. Even games that are basically single-threaded tend to multithread their loading screens, which is where I've seen the most problems so far (the actual game itself runs deterministically if I can only get past the loading screen with the same time on the simulated clock). And it would be nice to somehow handle games that do evil things like updating their RNG on a separate thread.
i've a simple idea: somebody starts making an emulator for a very simple game (old resident evil game for example). than it'll be updated more and more.
that shouldnt be SO difficult to add games, if you already have made the first step - the engine of the enulator.
that'd be good and not to difficult
Gunnar, you've made six posts in the last day all asking for someone to make a rerecording system for high-end games. We get it, okay? The high-level problem space is pretty well-understood, so unless you have some programming expertise that you're willing to contribute (which I'm guessing you don't), please just cool your jets a bit. These features will arrive when they're done. Asking for them repeatedly won't speed things up any.
Nitsuja: it seems to me that #4 would probably be your best bet. There's plenty of research done on various schedulers; it seems like you ought to be able to write your own simple deterministic scheduler that will prevent deadlocks, based on that research. I certainly wouldn't recommend trying to reinvent the wheel here, though.
I agree that #2 sounds disturbing, if only for the amount of extra work it'd entail for each new game you want to support. I'm not sure I understand what extra information you'd use in #3 to get it to work.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
it seems to me that #4 would probably be your best bet. There's plenty of research done on various schedulers; it seems like you ought to be able to write your own simple deterministic scheduler that will prevent deadlocks, based on that research. I certainly wouldn't recommend trying to reinvent the wheel here, though.
The problem is that I have so little information available: I can't measure the time (all system clocks are off-limits), I can't measure the number of instructions that get executed, and I can't measure the number of cycles spent or number of memory accesses or any other hardware counters or hardware events or OS events that trigger as a direct or indirect result of said hardware events. It's hard to imagine that anyone would have already created any sort of thread scheduler under those constraints that could replace a preemptive scheduler.
Derakon wrote:
I agree that #2 sounds disturbing, if only for the amount of extra work it'd entail for each new game you want to support.
Actually, in the best case it could be quite minimal, such as finding a few program counter addresses that represent good-enough "loop points" for the threads used by the game. I'd still like to avoid it if possible, though. For example, if that's really all that's necessary, maybe it's possible to auto-detect what those loop points should be in a deterministic way.
Derakon wrote:
I'm not sure I understand what extra information you'd use in #3 to get it to work.
Well, anything from saving extra values of some sort per frame that could be used to detect desync so that it could rewind until the desync doesn't happen, to detecting every context switch and storing enough information about them in the movie so that they can be enforced on playback, to saving full memory state delta information per frame. There's probably something in that range that would work. But I'll be avoiding that kind of thing because most of them would introduce verifiability problems or other headaches such as abysmal performance.
it seems to me that #4 would probably be your best bet. There's plenty of research done on various schedulers; it seems like you ought to be able to write your own simple deterministic scheduler that will prevent deadlocks, based on that research. I certainly wouldn't recommend trying to reinvent the wheel here, though.
The problem is that I have so little information available: I can't measure the time (all system clocks are off-limits), I can't measure the number of instructions that get executed, and I can't measure the number of cycles spent or number of memory accesses or any other hardware counters or hardware events or OS events that trigger as a direct or indirect result of said hardware events. It's hard to imagine that anyone would have already created any sort of thread scheduler under those constraints that could replace a preemptive scheduler.
Wait, why can't the wrapper access system clocks?
How fleeting are all human passions compared with the massive continuity of ducks.
Well, I have full access to all of that stuff, I just can't use any of it because there is no way to use it deterministically for thread scheduling or anything else that affects the game's timing. (Those are the same restrictions that the rest of the wrapper is already operating under, besides "frontend" stuff.)
I've been making some progress: Here's a test TAS of Hero Core. This game was previously giving me difficulties that I thought were due to multi-threaded logic at the splash/loading screens, but fortunately that problem is not quite as common as I thought it was. There are still more things to fix for it, but getting this game working could be a big step forward for overall compatibility, because it's a Game Maker game, and that is a fairly-commonly-used game engine (e.g. Iji, Jumper, Seiklus, Spelunky, An Untitled Story).
I've been making some progress: Here's a test TAS of Hero Core. This game was previously giving me difficulties that I thought were due to multi-threaded logic at the splash/loading screens, but fortunately that problem is not quite as common as I thought it was. There are still more things to fix for it, but getting this game working could be a big step forward for overall compatibility, because it's a Game Maker game, and that is a fairly-commonly-used game engine (e.g. Iji, Jumper, Seiklus, Spelunky, An Untitled Story).
Does this mean that Iji, Spelunky, et al are now working, or is there more work to do because this particular game maker game is significantly simpler than most?
I'm guessing the latter but I think it might be useful to clarify before you get inundated by people assuming the former.
How fleeting are all human passions compared with the massive continuity of ducks.
I think those other games are all very similar to Hero Core in whatever measure of simplicity matters here. I haven't tried them recently so I really don't know whether they work now, I was just mentioning that if I can get Hero Core to work (which it is mostly, but not flawlessly yet) then most of the groundwork should already be laid for those other games since they're all using the same engine/framework, or at least, it implies that all of them can be supported.
