Emulator Coder, Experienced Forum User, Published Author, Active player
(388)
Joined: 3/24/2006
Posts: 1802
Highness wrote:
Failed to inject DLL "Z:\home\highness\Downloads\hglass\hourglass-r39\wintasee.dll" into process id 0x2D IAT: Error while translating FS selector to virtual address, system error was: 5
According to MSDN, this error means that access was denied, which probably means that wine isn't properly handling THREAD_QUERY_INFORMATION access rights, which, unfortunately, is a wine problem that hourglass probably can't do anything about.
How fleeting are all human passions compared with the massive continuity of ducks.
Emulator Coder, Experienced Forum User, Published Author, Active player
(388)
Joined: 3/24/2006
Posts: 1802
Unfortunately, TlsAlloc and FlsAlloc appear not to actually initialize (or allocate) the local storage when they're called, so if we hook only the Allocs, we would then have to wait x milliseconds (causing a race condition) for the program to subsequently initialize a tiddata struct and assign its non-null pointer to the local storage index.
So our options are to hook *lsAlloc and *lsGetData or to identify at least one different exported function that is only ever called after the thread/fiber local storage is entirely initialized.
Perhaps we could have the custom *lsAlloc hook *lsGetValue, and *lsGetValue unhook itself when it's called with the index *lsAlloc last returned...
There's another wrinkle to this, though. On my Windows 7, hooking TlsAlloc causes all sorts of weird issues, like the game immediately crashing the first time it's run, and sound failing to play, while FlsAlloc works with no trouble at all.
How fleeting are all human passions compared with the massive continuity of ducks.
Emulator Coder, Experienced Forum User, Published Author, Active player
(388)
Joined: 3/24/2006
Posts: 1802
I've made a breakthrough.
It turns out _getptd() prefers to use Fls functions to Tls functions when they're available.
By hooking FlsAlloc and GetFlsValue, and installing some temporary hacks, I've been able to coerce hourglass into automatically adding each fiber-local random seed to the watchlist.
How fleeting are all human passions compared with the massive continuity of ducks.
Movies of games that are not emulated well (have graphical or functional glitches that do not exist on the real console) should not be submitted.
This isn't an emulator, per se, but the lack of sound support is definitely an absence of functionality.
This run should not be considered until proper sound support is added. Perhaps it should be delayed until then?
^
but what do you mean with delayed? I think people already voted on this one, should it be cancelled then resubmitted when it's ready?
One of the statuses that judges can set, aside from "accepted" and "rejected" is "delayed", which indicates that judgement on the TAS is suspended pending further development (usually indicated in the thread or edited into the submission text).
How fleeting are all human passions compared with the massive continuity of ducks.
Emulator Coder, Experienced Forum User, Published Author, Active player
(388)
Joined: 3/24/2006
Posts: 1802
nitsuja wrote:
I think the CRT is often statically linked, in which case I wouldn't know how to hook rand() since it's not exported by the game and I don't know its address. It might be easier to find _holdrand in the _tiddata in the game's TEB, or expose the TLS slots as if they're at fixed addresses.
I noticed that, and did a preliminary experiment hooking TlsGetValue, which is called by _getptd (also statically linked), which is called by rand. TlsGetValue, unfortunately, is called so frequently that simply adding a 1-line debugprintf slowed the game significantly and ended up creating 80 megabyte log files for ~100 frames of cave story...
Edit:
Additionally, while TlsAlloc should only be called once per thread, it either isn't getting called at all in cave story, or I can't get it hooked before that one call happens.
How fleeting are all human passions compared with the massive continuity of ducks.
Emulator Coder, Experienced Forum User, Published Author, Active player
(388)
Joined: 3/24/2006
Posts: 1802
I've discovered (and tested) the algorithm that windows' implementation of cstdlib uses to produce random numbers.
Compare how many numbers? 15
With what seed? 528
rand() myrand()
1762 1762
14014 14014
16336 16336
26650 26650
15462 15462
20726 20726
13339 13339
26780 26780
12282 12282
28464 28464
26063 26063
18589 18589
25061 25061
20453 20453
7055 7055
Press any key to continue . . .
Numbers on the left are produced by actually calling rand(), numbers on the right are produced by calling my reimplementation with the same seed value.
This seems like it would be useful functionality for hourglass, to have, but unfortunately, in real use cases random seed is stored in dynamically allocated memory, pointed to from dynamically allocated memory, pointed to from dynamically allocated memory which means that, even using MHS, it is very difficult to find and track in a meaningful way.
However, it seems like it should be relatively simple for hourglass to hook rand() and track the per-thread _storerand value somewhere user accessible.
How fleeting are all human passions compared with the massive continuity of ducks.
Emulator Coder, Experienced Forum User, Published Author, Active player
(388)
Joined: 3/24/2006
Posts: 1802
brocoli wrote:
Using the ATI card, loading a savestate in the same paused frame either works or hourglass decides that the game has crashed (rarely - DirectSound creation disabled doesn't fix this).
Creating a savestate, stepping one frame, then loading the savestate always makes the game stop drawing, and most of the times makes hourglass say the game crashed.
I'm also experiencing this issue on my laptop (which uses a radeon). I didn't really test on this game before hourglass was released, I just made sure that it was running at all, whereas previously it was always freezing up before the window even got drawn.
How fleeting are all human passions compared with the massive continuity of ducks.
Emulator Coder, Experienced Forum User, Published Author, Active player
(388)
Joined: 3/24/2006
Posts: 1802
I was surprised that anybody here besides myself (and nitsuja) has heard of Bunny must die. Except that now I remember telling people here about it while I was working on the translation patch.
Possibly worth noting, the english translation patch has significantly more boxes of text than the original Japanese version, because english sentences don't fit nearly as well in such limited spaces.
I like the idea of the no-mobility-items run more than a true low%, so long as it has low% as a secondary goal. Any% and 100% runs for both characters, of course would also be absolutely worth watching.
How fleeting are all human passions compared with the massive continuity of ducks.
Emulator Coder, Experienced Forum User, Published Author, Active player
(388)
Joined: 3/24/2006
Posts: 1802
I'm not sure I have the wherewithal to complete the project on my own, but I've produced a WIP that get to the collection of the polar star with something approaching optimization.
If anybody else is working on cave story, perhaps we could compare notes.
How fleeting are all human passions compared with the massive continuity of ducks.
Emulator Coder, Experienced Forum User, Published Author, Active player
(388)
Joined: 3/24/2006
Posts: 1802
Hourglass does not (yet?) support networking at all. I also would not be entirely surprised if Diablo II entirely fails to run under it. Somebody should check to see if Diablo works under hourglass before any serious TAS plans are made for it.
How fleeting are all human passions compared with the massive continuity of ducks.
Emulator Coder, Experienced Forum User, Published Author, Active player
(388)
Joined: 3/24/2006
Posts: 1802
nitsuja wrote:
upthorn wrote:
This is definitely not true for eversion under Windows 7 x64. I'm not surprised if this is being caused by an additional layer of instability that is added by x64, but it definitely happens and can be very frustrating to deal with.
Hmm, that could be something else... can you try this and see if it makes Eversion more stable?
- Runtime > Disable Pause Helper
- Runtime > Multithreading Mode > Disable
Disabling pause helper doesn't seem to change anything. Disabling multithreading prevents eversion from proceeding past frame 2. It doesn't crash or anything, it just stalls. If I disable multithreading after getting to frame 3, that doesn't seem to change anything either.
How fleeting are all human passions compared with the massive continuity of ducks.
Emulator Coder, Experienced Forum User, Published Author, Active player
(388)
Joined: 3/24/2006
Posts: 1802
nitsuja wrote:
upthorn wrote:
However, in hourglass, because there are still issues where some games crash for me pretty frequently when savestates are loaded, I would really appreciate the ability to resume recording without mucking with savestates.
I added this feature just now, although I don't think savestate instability on its own is a valid reason to prefer it. I think the case of loading the same frame you're already on is completely stable even for games that would "normally" crash
This is definitely not true for eversion under Windows 7 x64. I'm not surprised if this is being caused by an additional layer of instability that is added by x64, but it definitely happens and can be very frustrating to deal with.
How fleeting are all human passions compared with the massive continuity of ducks.
Emulator Coder, Experienced Forum User, Published Author, Active player
(388)
Joined: 3/24/2006
Posts: 1802
Lex wrote:
nitsuja wrote:
If you mean you want to switch from playback to recording at any time, (you probably didn't mean that but) the normal way of doing it (switch to read+write mode and then save and load a savestate) should work.
Woah! That's the normal way of doing it in emulators? In Worms Armageddon's TAS build (what I've used the most for TASing), there's a single "take control" bind, which works even while paused. It switches from "playback" (or "rerecording") mode to "recording" mode. It should really just be that easy.
In normal emulators there's not a problem with this, because you want a savestate right where you start recording etc etc. However, in hourglass, because there are still issues where some games crash for me pretty frequently when savestates are loaded, I would really appreciate the ability to resume recording without mucking with savestates.
How fleeting are all human passions compared with the massive continuity of ducks.
Emulator Coder, Experienced Forum User, Published Author, Active player
(388)
Joined: 3/24/2006
Posts: 1802
Derakon is close to, but not entirely correct. Hourglass savestates are incomplete due to a limitation caused by system resources called "handles". In windows, a Handle is a number that refers to a resource that has been opened by the operating system. If a program closes, all of its resource handles are closed by the operating system, and when the savestate is reloaded, the handle numbers in memory will refer to resources that are not guaranteed to be valid, let alone the expected resource.
For this reason, in order to load a savestate when the program has been closed and re-opened since the state was made, it is necessary to play the movie back from its beginning to the point where the savestate was made, and then re-save the state.
Graphics and textures are actually stored in the savestate, so long as "graphics->surface memory" is set to "system memory", as this forces the graphics to be kept in an accessible memory location. They may not be saved in other cases, because it is not always possible to read or write to the GPU's memory directly.
How fleeting are all human passions compared with the massive continuity of ducks.
Emulator Coder, Experienced Forum User, Published Author, Active player
(388)
Joined: 3/24/2006
Posts: 1802
If the bug-bounces are, indeed, caused by terrain ejection, it is likely that the resulting speed value comes from the amount of pixel overlap into the terrain.
How fleeting are all human passions compared with the massive continuity of ducks.
Emulator Coder, Experienced Forum User, Published Author, Active player
(388)
Joined: 3/24/2006
Posts: 1802
nitsuja wrote:
By the way, I don't know if this will work for everyone, but here's a RAM Watch file that might help for a Cave Story TAS:
I have couple more values in mine, which are helpful for optimizing text-boxes.
0
12
00000 0049E66C d s 0 X speed
00001 0049E670 d s 0 Y speed
00002 0049E654 d u 0 X pos
00003 0049E658 d s 0 Y pos
00004 0049E664 d s 0 X cam offset
00005 0049E660 w s 0 Y cam offset
00006 0049E6B0 w h 0 flags
00007 0049E6CC w s 0 health
00008 0049E1EC d u 0 framecounter
00009 004A5ADC b s 0 Event Status
0000A 004A5B00 d s 0 Wait length
0000B 004A5AFC d s 0 Waited Frames
A small explanation of those last 3:
Event status is a flag that happens during script events that says what kind of action is currently taking place.
means text is being displayed
means it is waiting for input
means text is scrolling
means delaying for a pre-set number of frames, during which,
"Wait length" is set to the number of frames to delay for
"Waited frames" counts up from 0 until it reaches wait length
means the screen is fading in or out
means it is waiting for the user to reply to a Yes/No popup, and
means it is waiting for the player to fall to the ground.
nitsuja wrote:
Watching the X velocity value, it seems that the character has a continuously oscillating speed when on the ground that locks to something in the air (like in SNES Mario games, I think), which can probably be abused by always jumping at good speed values to go slightly faster than normal.
I can verify that this works from old and lost test files made back in the early days of wintaser testing. I cannot currently remember the optimal jumping pattern that I found, though, and I can recall that water was simply horrible to optimize this way.
How fleeting are all human passions compared with the massive continuity of ducks.
Emulator Coder, Experienced Forum User, Published Author, Active player
(388)
Joined: 3/24/2006
Posts: 1802
nitsuja wrote:
upthorn wrote:
Input is not yet working on Nothing, (probably a similar situation to Super Meat Boy, but different input library), not that it's a good TAS candidate yet, but I think it'd be fun to just play around with in Hourglass and experiment with knockback.
If it's just for testing, you can try setting "Runtime > Wait until sub-process creation" and "Runtime > Message Sync Mode > Unchecked (native messaging)".
Checking "wait until sub-process creation" causes the game not to stop when the paused checkbox is set. Setting Message Sync Mode to "unchecked" without "wait until sub-process creation" causes the game to crash right as it loads the first area.
How fleeting are all human passions compared with the massive continuity of ducks.
Emulator Coder, Experienced Forum User, Published Author, Active player
(388)
Joined: 3/24/2006
Posts: 1802
Input is not yet working on Nothing, (probably a similar situation to Super Meat Boy, but different input library), not that it's a good TAS candidate yet, but I think it'd be fun to just play around with in Hourglass and experiment with knockback.
How fleeting are all human passions compared with the massive continuity of ducks.
Emulator Coder, Experienced Forum User, Published Author, Active player
(388)
Joined: 3/24/2006
Posts: 1802
I did some testing today, and those games which I was able to make run on both my old 32-bit WinXP laptop and my new 64-bit Win7 laptop synced on both machines.
How fleeting are all human passions compared with the massive continuity of ducks.
Emulator Coder, Experienced Forum User, Published Author, Active player
(388)
Joined: 3/24/2006
Posts: 1802
There is already a 2P hardexpert mode publication, and 2P movies are preferred over 1P movies, so if you want your gunstar heroes run published, it's best if you do a 2 player improvement.
How fleeting are all human passions compared with the massive continuity of ducks.
Emulator Coder, Experienced Forum User, Published Author, Active player
(388)
Joined: 3/24/2006
Posts: 1802
I was a bit bothered by the fact that SMB1 takes optimal warps and finishes 1/3rd of the way through the movie, but SMB2 avoids optimal shortcuts in order to finish at the same time as SMB2J and SMB3. Either SMB1 should take longer and avoid warps to end the same time as the other three games, or SMB2U should take optimal shortcuts and finish as quickly as possible.
The current solution is not consistent in its goals, which is one of the most important things for a TAS to avoid.
(My personal preference would be that SMB1 be made to take longer, by the way)
How fleeting are all human passions compared with the massive continuity of ducks.
