Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
TASeditor wrote:
Masterjun wrote:
TASeditor wrote:
Tasvideos userfiles also doesn't allow .lsmv.
Weird, I tried to upload one yesterday, but it didn't worked.
For lsmv, it only allows movies, not savestates (but savestate-anchored / SRAM-anchored movies are OK).
I guess I should fix that.. Edit: Fixed.
Also note that lsmv files must have extension .lsmv in the final filename (which is the same as upload filename if filename box is empty, or the contents of filename box if non-empty) or it won't work (all formats are similar here, e.g. openMSX movies need .omr extension).
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
pyromaniac wrote:
No matter how much I try, I can not seem to get the SNES Memory Watch to work for me. I am using Snes9X v1.43+ v10 using rev.13 memory watch.
Snes9x v1.43 is really inaccurate and really really not recomended to be used.
Use lsnes or Bizhawk (or if you really must use snes9x, at least some 1.5x version).
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
diggidoyo wrote:
For a specific question, I'm looking for my rerecord count. I'm told it's a 32 bit unsigned integer at offset 0x02D. Using my best reasoning skills, I'm guessing that means it's here:
<snip screenshot>
Correct.
diggidoyo wrote:
So does that mean my rerecord count is 8914, or do I have to convert "00 00 00 00 00 00 00 00 00 00 00 00 00 89 14 00" into decimal format, or am I looking in the completely wrong place?
32-bits means 8 hex digits (4 pairs). Also the rerecord count is little endian, so the pairs have to be swapped. So 32-bit integer starting at 0x02D reads as 0x00001489. Now, that is in base-16. Converting to base 10 yields 5257.
So 5257 rerecords.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
feos wrote:
For some reason, this is what's called at the end of the movie instead of proceeding to the ending. Looks like Pause. How to fix that?
A well-known Mupen64 bug. Basically, on end of movie, all buttons get pressed.
The fix is to increment the VI count and input sample count in movie header and append some zeroes to the input data. See the M64 format docs for more details.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
SoulCal wrote:
I believe I found them, but when trying to modify the values it changes right back to what they were. It could just be that those values can't be changed.
That sort of behavior is typical if one hit some sort of derived value closely associated with the position instead of the position itself. The real position addresses should warp the character if written to...
As for finding those, no idea...
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
darko21 wrote:
for exemple I realized that my frame 500 isn't good i wanna go back to frame 499.
What you I do?
If you have savestate for frame 499, load it. Or load earlier savestate (or start playback from beginning) in read-only mode, and play movie until frame 499.
Then stop and switch to read-write mode and continue.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
Robert_Ordis wrote:
But, I wish if thumbnail of this site were able to be switched with others like Amazon...
There are animated alternative screenshots (hover on image), but other kind of screenshot switching is currently implemented. :-/
Oh, and because sanity checks on those also aren't implemented, an admin-level is needed to add one.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
amaurea wrote:
It would be nice if rerecording did not discard the part of the movie that is being revised, but instead kept all the input in a tree of histories, much like the full undo history in text editors like vim. This would make it much easier to make videos like this: https://www.youtube.com/watch?v=T2OytHzZ72Y. These alternative histories generalize the concept of the number of rerecords from a single number to full temporal information about when they happened and what approaches were explored.
Sounds similar to my earlier "Multirecording" ideas.
There are some subtle issues with things like sharing progress.
Oh, the thing corresponding to rerecord count would be branch count (number of segments minus number of branching points).
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
STBM wrote:
I really hope somehow understand where does this audio desync comes from...
Based on what I recall from seeing some videos, it looks like the audio desync is caused by errors in video capture (strange, given that video capture should be easier than audio capture).
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
JohnnyG wrote:
it looks like that youtube hd encodes can get really big in filesize which might be a problem because the youtube filesize limit is 20gig.
Yes, they get big. And AFAIK, the limit is 64GB now.
JohnnyG wrote:
i see a 320x240 psx movie i.e. is after encoding 2560x1920 but wouldn't it be enough to get 1440x1080 which would be max resolution on youtube?
Actually, 2560x1920 is likely going to result smaller encode than 1440x1080 (due to how h.264 works). And youtube does support resolutions above 1080p (at least up to 4096x3072).
