Also, the glitches being in different places in different resolutions suggests that it is not problem with decoding the uploaded video, but a problem encoding the resized video (so playing with formats won't help)...
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
The builds of lsnes I have done recently all have used compatibility core.
But it is possible to make a custom build against accuracy core (which runs at about half the speed of compatibility).
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
Yeah, there have been a fair number of changes, on areas like:
ROM loading
DnD of ROMs and movies/savestates
Memory watching
Memory searching
Menus
Savestate anchoring
Read-only mode
Classical TAS editor would need to savestate every frame, which is pretty nasty with bsnes core (alters sync).
I had an idea for something that could be used for editing input, but wouldn't require loads of savestating, but haven't even tried implementing that yet.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
The loading time emulation is crapshoot anyway.
But there might be loading time differences on actual hardware too (for those, one would have to compare it on real console).
Not that it matters much right now, as only one port is TASable.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
I think natt was referring to actually uploading Lagarith to Youtube (which doesn't work properly), not using lagarith and running the thing through AVISynth and x264 (which does).
Also, don't run Lagarith directly through x264 (it doesn't work right either).
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
In the latest version, something like this could work:
on_input = loopwrapper(function(wait)
for i = 1, 60 do
input.joyset(1,{right=true,down=true,A=true})
wait()
end
for i = 1, 200 do
input.joyset(1,{})
wait()
end
for i = 1, 70 do
input.joyset(1,{L=true})
wait()
end
end);
(The functions loopwrapper and input.joyset are new in the latest version).
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
If mupen64 is anything like other emulators (might be a bad assumption), first open suitable ROM (game) and then load the .m64 ("movie").
.m64 file is essentially a sequence of controller keypresses that can be fed to the game.
Note that video/audio/RSP plugins chosen may affect if the result is anything sane.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
It is .dtm. That's the format Dolphin uses to record the button presses (and wiimote motions).
Such files can be edited (using hex editor) to alter the input sent to the game.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
1) Trying to add https mirror link results in error message about having multiple mirrors from the same site.
1-a) This occurs even if there aren't any mirrors already.
1-b) This occurs even for users that have privilege to override the multiple mirror check.
2) Trying to replace mirror with https mirror link results in mirror being deleted with no replacement.
2-a) Even if this is the last mirror and user doesn't have privileges to bring mirror count to zero.
3) One can publish a movie with https:// mirror link entered... Resulting a publication with no mirrors.
This was noticed as apparently recently archive.org started offering https links (the collection pages on https://archive.org/details/ links to https URLs for files).
* Resulting in such URLs to be put as mirror URLs and torrent webseed URLs.
* HTTPS torrent webseed URLs have their own problems (but that's not a site bug).
How to fix this (there are multiple different ways)?
1) Allow HTTPS links, treating http://foo.example/ and https://foo.example/ as different.
2) Allow HTTPS links, treating http://foo.example/ and https://foo.example/ as the same.
3) Add explicit check against adding non-HTTP links, so those can be rejected early.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
The issue corrected was just a display issue, not issue with underlying counting.
Yeah, artifacts from data being corrupt. Basically, records are duplicated after emulator is restarted, up to 32 times for a single rerecord.
Well, it would be possible to fix just before submitting (based on the .rr file and the movie file).
The rerecord count estimate so far seems to be 18635, but I am not completely sure that is accurate (I would need to check that there are no suspicious common prefix lengths).
I added "memory watch to dedicated window" as a TODO (that would let watch more addresses in one go).
Bit of a hacky idea that would work with current version: Set display scaling to something larger than 1x. That makes the window bigger, so more rows fit (since status panel does not scale with display).
And of course, there are Lua scripts too (idea for feature: Take in memory watch file and output a Lua script for watching)... Those can watch many more addresses.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
There are no necroposting timelimits on this site.
(of course, that doesn't prevent from getting comments about necroposting if one bumps thread old enough.)
And as to if there is a thread with newest post older than that, yes, there is. Quite a few actually.
Official time between posts: 265011663 seconds, which is a new record.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
Got it, thanks.
Basically, looks like earlier lsnes versions had buggy rerecord counting. The buggy versions worked correctly with movies from buggy version. But non-buggy version goes pretty crazy loading buggy data.
I tried to get non-corrupt estimate of rerecord count, getting 15708.
I don't think it is the same issue...
Found two other bugs:
- Read-only mode still overwrites lots of things it should not.
- Rerecord count display is buggy.
The latter can make it seem that rerecord count jumps around, even if it increments at 1 per load.
I also noticed, that there is no way to show what the emulator thinks is the rerecord count without saving and loading again.
I added task list entries for these three issues, will fix [EDIT: fixed in rr1-maint, will be in the next release].
I don't think even the earlier desync problem was unique to Shadowrun.
These recording count issues are definitely not anything game-specific.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
If it is for official encode, then yes, you have to include them and no, you can't speed them up (also, these encodes have to have logo, subtitles and be on TVC).
If it is for unofficial encode (or quick'n'dirty encode), then do whatever you want.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
Watch what happens after the timer on the game over screen counts to zero and the game over screen autodismisses...
And as for if this counts as completion, if SMW glitched counts, this does as well.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
WTH? Looking at the data the file has about rerecords, the compression is OK, but the data itself has clearly gotten corrupted multiple times.
Basically, it looks like the project rerecord data file had a framing error [1] (reading junk from movie rerecord data would produce completely different type of corruption[2]).
The way that file is read/written should guarantee absence of framing errors, even if simultaneous writing corrupts records.
Syncwise, syncs for me.
The contents of file named %APPDATA%\lsnes\45e1f031c1007bda02038cbaf3b38a7fc022f7e1.rr could be useful in figuring out the order of events... ZIP / 7-zip (especially the latter) should be able to compress that file nicely (please don't use .rar, I can't unpack that).
[1] This type of corruption manifests as numerous records that are a shift of runs of other records appearing. This is exactly what is seen. Except that there isn't just one shift. There are multiple shifts (which would mean it has gotten frame-shifted multiple times.
[2] This type of corruption would very likely cause numerous runs of consecutive records, some millions of entries in length.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
Where does that "53%" come from? Is it some sort of goal (seems very arbitrary) or is that just what the completion percentage happens to be?
If the latter, you should clear the branch name.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
Encodes are done and uploaded, so the publishing should come very soon.
Seemingly the main slowdown has been getting the youtube encode up (which finally happened very recently)...
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
Okay, released rr1-Δ13ε1 that fixes the problems I found (makes it consistently desync on that fight).
After upgrading, don't use the savestates (movies are OK up to how they sync) from older version, as those likely are already desynced (I am amazed how long it took for desync of this type to become apparent).
Also, delta 13 makes the emulator act more like other rerecording emulators:
- Menu layout is different (most entries are the same, just moved to different places)
- Emulator no longer prompts a ROM at startup. Use FIle -> Load -> ROM... to load one (or use Drag'n'Drop).
- Nor does it prompt for movie settings / movie file. Use File -> New -> Movie..., File -> Load -> State..., File -> Load -> Movie... or DnD)
- Loadstate when in readonly mode works like in other emulators (preserves the input). Use 'set-setting preserve_on_readonly_load false' if you want the old lsnes behaviour (load the input).
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
Er, what: The first time I play it back, it desyncs. When I rewind it to start and play it back, it syncs?
Sounds like uninitialized variables in bsnes core... I'll try to debug those a bit later.
Unfortunately, it seems that when played from clean state, it indeed desyncs.
Some technical debugging stuff:
* If one dumps core state immediately upon playback and upon rewinding, the states differ...
* I found differences in states of CPU, PPU, SMP and DSP...
* CPU: The differences are inside CPUcore.
* CPUcore: The offending variables appear to be aa.d, rd.d, sp and dp.
* SMP: The differences are inside SMPcore.
* SMPcore: The offending variables appear to be opcode, dp.w, sp.w, rd.w, wr.w, bit.w and ya.w.
* PPU: The following are the offending variables: line, pixel_cache, window, bg_info, active_sprite, oam_itemlist, oam_tilelist, oam_line_pal and oam_line_pri.
* DSP: Seems like samplebuffer and clock.
Those explain all the differences I found in the savestates. Initializing those variables to zeroes makes the run consistently desync (in that second fight).