Posts for Ilari


Emulator Coder, Experienced Forum User, Published Author, Skilled player (1142)
Joined: 5/1/2010
Posts: 1217
At least for 720p, it is not flash messing up. Mplayer2 also glitches on that video, and shows
[h264 @ 0x7f7711311b20]error while decoding MB 35 25, bytestream (-27)
[h264 @ 0x7f7711311b20]concealing 1014 DC, 1014 AC, 1014 MV errors in P frame
A:  57.0 V:  57.0 A-V:  0.000 ct:  0.002   0/  0  0%  6%  0.6% 0 0
[h264 @ 0x7f7711311b20]concealing 652 DC, 652 AC, 652 MV errors in P frame
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
creaothceann wrote:
Am I correct in assuming that lsnes and BizHawk use the bsnes compatibility core?
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
boct1584 wrote:
Would you be able to implement support for Nach's JMA ROM compression?
Hmm... Maybe.
boct1584 wrote:
Or alternatively, does lsnes already support some other form of compressed ROM?
Currently the only thing supported is loading ROMs out of .zip files, which can be compressed using deflate.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1142)
Joined: 5/1/2010
Posts: 1217
Warepire wrote:
Anyone tested a recent version of lsnes? If I remember correctly Ilari changed some of the GUI to make it easier to use.
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
TASeditor wrote:
Why hasn't LSNES a good TAS Editor yet.
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
Spikestuff wrote:
Gamecube I checked and when played back loading time is faster thank Xbox (in emulator)
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
STBM wrote:
I was using lagarith yes. Which one should I use ?
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
partyboy1a wrote:
Some ideas to make it less complicated?
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).
Post subject: Re: How to playback/watch .m64 file?
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1142)
Joined: 5/1/2010
Posts: 1217
AnotherUser wrote:
So I'm confused...how do you watch a .m64 file in mupen? What is a .m64 file anyway?
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
wuhu tour guide wrote:
Rog- dont even know what .dts means!
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.
Post subject: Publication HTTPS link woes
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
STBM wrote:
As you can see at 2:17, 4 seconds of the cinematic are skipped... But the audio continue, which create a desync.
Also, the end of level cinematics seems to have part (lightbeams scene) missing (with noticeable sound desync).
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1142)
Joined: 5/1/2010
Posts: 1217
TheHepper wrote:
I downloaded the new build, and I think the rerecord issue is fixed. That is, rewinding and resuming a section of the movie recorded under v14 correctly added 1 rerecord.
The issue corrected was just a display issue, not issue with underlying counting.
TheHepper wrote:
However, I gained around 2K rerecords after downloading v14 and resuming from a section recorded under v13.
Yeah, artifacts from data being corrupt. Basically, records are duplicated after emulator is restarted, up to 32 times for a single rerecord.
TheHepper wrote:
Is there a way to update the movie file with the correct rerecord count? If possible, I think this would be preferable to explaining in the submission text why the movie file has 79K additional rerecords.
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).
TheHepper wrote:
Also, while I like the new memory watch features, if you have more than 12 watches on one list, it starts to push down the "Other status:" rows. (i.e., with 14 watches you cannot see the SPD% row).
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
exdeath wrote:
Sorry, someone referenced this post in a recent thread and I forgot to see the date. If there is some problem I delete my post from this thread.
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
TheHepper wrote:
Ilari, here is the file you were asking about. I used a .zip compression since I only have winzip on this machine, but I can download a program with .7z if needed.
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.
TheHepper wrote:
I should also mention that rewinding the video and starting from an earlier spot (i.e., because a previous route wasn't working) tends to add around 400 rerecords. Not sure if it's due to the same issue or not, but it sounds like your [1] described.
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].
TheHepper wrote:
Sorry if these problems are unique to Shadowrun
I don't think even the earlier desync problem was unique to Shadowrun. These recording count issues are definitely not anything game-specific.
Post subject: Re: Credits in TAS encode?
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1142)
Joined: 5/1/2010
Posts: 1217
gamerfreak5665 wrote:
Do I have to put in the credits at the end of a TAS encode on youtube? I ask because a game i'm doing has 10 straight minutes of credits. so if i do need to include them, can i speed them up a bit?
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
mklip2001 wrote:
This is hilarious. However, it doesn't actually beat the game! It gets Game Over, which means you lost the game.
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
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1142)
Joined: 5/1/2010
Posts: 1217
Syncs for me on FCEUX 2.1.4a ROM MD5: 0xeefac97ac3b85048f3685e1623210efb Does not sync for me on FCEUX 2.1.5.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1142)
Joined: 5/1/2010
Posts: 1217
TheHepper wrote:
However, for some reason my rerecords went way up. I think they should be 13K, instead of 93K. See the file below.
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
hellagels wrote:
The movie have not been published yet?
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
amaurea wrote:
PS. You should upload your videos to microstorage rather than mediafire.
Or here: http://tasvideos.org/userfiles/ Even Limited Users should have upload permissions there.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1142)
Joined: 5/1/2010
Posts: 1217
TheHepper wrote:
Thanks for looking into it, Ilari.
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
TheHepper wrote:
Could someone please watch this run and let me know if it desyncs? I've gotten mixed results. It will either desync on the second arena guy, or it will sync and kill the third.
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).
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1142)
Joined: 5/1/2010
Posts: 1217
Cooljay wrote:
Could it be possible to allow .YMV as well It appears saturn movie files aren't accepting by the Upload a WIP.
Its .ymv (lowercase).