Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
JXQ wrote:
Nach wrote:
RLE can easily be decompressed and recompressed.
So can non-RLE, like SMV. The difference is that every time I hex-edit, I don't have to do two stupid conversions that I hope keep all the metadata intact.
GROAN.
*Nach smacks JXQ.
You don't need two conversions, ZSNES can play back non RLE just fine.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Joined: 2/28/2006
Posts: 2275
Location: Milky Way -> Earth -> Brazil
A friend is the one who warns.
"Genuine self-esteem, however, consists not of causeless feelings, but of certain knowledge about yourself.
It rests on the conviction that you — by your choices, effort and actions — have made yourself into the
kind of person able to deal with reality. It is the conviction — based on the evidence of your own volitional
functioning — that you are fundamentally able to succeed in life and, therefore, are deserving of that success."
- Onkar Ghate
Bisqwit wrote:
Are there any hardware engineers here? It would be cool to try playing back a movie on a real console this way. NES is probably the easiest one to do this with, because games rely much more on accurate NES timing than most other consoles.
In my personal opinion, I don't see much of a difference between using a cheat code and using an emulator that doesn't emulate properly.
The hex editing problem is due more to a lack of proper tools than anything else. Delta-time/RLE would be fine if proper tools existed for such a format. Also, as someone in this thread suggested, a format could have a raw mode and a delta-time mode, and "release" builds of movies could be converted. Both would play in emulators.
Melissa
Adding in things like cheat codes, subtitles, and especially savestate checkpoints will make this a much larger problem. Personally I think movie files are a very nice size, especially compared to avi.
ZMV supports all that and is smaller than SMVs for the same movie in the tests I ran.
Does that mean that if a movie is submitted in the zmv format, the submission engine needs to perform checks in order to catch possible attempts at cheating?
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Warp wrote:
Nach wrote:
JXQ wrote:
Adding in things like cheat codes, subtitles, and especially savestate checkpoints will make this a much larger problem. Personally I think movie files are a very nice size, especially compared to avi.
ZMV supports all that and is smaller than SMVs for the same movie in the tests I ran.
Does that mean that if a movie is submitted in the zmv format, the submission engine needs to perform checks in order to catch possible attempts at cheating?
No.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Adding in things like cheat codes, subtitles, and especially savestate checkpoints will make this a much larger problem. Personally I think movie files are a very nice size, especially compared to avi.
ZMV supports all that and is smaller than SMVs for the same movie in the tests I ran.
Does that mean that if a movie is submitted in the zmv format, the submission engine needs to perform checks in order to catch possible attempts at cheating?
No.
Then how it should be checked that a submission doesn't contain eg. cheatcodes in it?
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Parsing the header tells you everything embedded in that ZMV. Certain types of additions are also external to the ZMV but work in conjunction with it.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Wouldn't the correct answer thus have been "yes" instead of "no"? If parsing the header is necessary to catch cheating attempts, then it *is* indeed necessary for the submission engine to contain additional code for this.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
The submission engine always had to parse the header. To get rerecords and all sorts of other vars.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
So the answer really is "yes, the submission engine would have to contain checks against possible cheating in the submission file"?
This is getting kind of repetitive.
Heck, the emulators have a hard enough time keeping sync running a video back using it's own cores, let alone a trying to play back movies on other emulators. It's just not feasible. It's not the movie format which causes these problems...
Afaik it is, since it's frame-based. :/
BoltR wrote:
To make a global header you are going to need some sort of bloated catch all set of fields which each emulator has pick it's way through to see which fields apply to it.
Like the PNG chunks or the blocks in SNES9x savestates?
Truncated wrote:
It possibly solves the problem if the console does not read controller states during the lag frame, like Myria explained. There could be 10 lag frames on one emulator and it would still only read the next input after the screen updated next time, like an emulator which didn't lag at all.
This is assuming that no games probe the controller during lag, and that the state after a frame of lag is the same as if the system hadn't lagged at all. Which to me sounds doubtful, but I have no knowledge of consoles' inner workings. Perhaps someone experienced with emulator cores can help?
I second that. When are games reading their controller input? In the VBlank IRQ handler? If not then there wouldn't be desyncs, IMO.
Tub wrote:
I'm also sceptical - do we really want to be able to play back TAS-input on a real console? That'd pretty much destroy unassisted speedrunning.
Because there's more opportunity to publish fake speedruns?
Warp wrote:
Nach wrote:
JXQ wrote:
Adding in things like cheat codes, subtitles, and especially savestate checkpoints will make this a much larger problem. Personally I think movie files are a very nice size, especially compared to avi.
ZMV supports all that and is smaller than SMVs for the same movie in the tests I ran.
Does that mean that if a movie is submitted in the zmv format, the submission engine needs to perform checks in order to catch possible attempts at cheating?
Heck, the emulators have a hard enough time keeping sync running a video back using it's own cores, let alone a trying to play back movies on other emulators. It's just not feasible. It's not the movie format which causes these problems...
Afaik it is, since it's frame-based. :/
You know that the desyncing is sometimes more than just a missing frame of input right? Sometimes the RNG is in a different state and causes things to behave differently in the game. It goes much deeper than 'The controller isn't polled on the same frame anymore'.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
BoltR wrote:
creaothceann wrote:
BoltR wrote:
Heck, the emulators have a hard enough time keeping sync running a video back using it's own cores, let alone a trying to play back movies on other emulators. It's just not feasible. It's not the movie format which causes these problems...
Afaik it is, since it's frame-based. :/
You know that the desyncing is sometimes more than just a missing frame of input right? Sometimes the RNG is in a different state and causes things to behave differently in the game. It goes much deeper than 'The controller isn't polled on the same frame anymore'.
I've tried telling him that before, he doesn't want to listen.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Nach, pardon me if i'm being stupid, but is it not feasible to convert SMV to ZMV? 'm not sure how the timing differs between SNES9x and ZSNES (which I was using back when MSDOS 6.22 was my OS and Nesticle was still the shit ... so kudos for a good app), but something along the lines of nesmock should be able to make the movies (somewhat) cross-compatible.
EDIT. Sorry ... kinda went off topic
Heck, the emulators have a hard enough time keeping sync running a video back using it's own cores, let alone a trying to play back movies on other emulators. It's just not feasible. It's not the movie format which causes these problems...
Afaik it is, since it's frame-based. :/
You know that the desyncing is sometimes more than just a missing frame of input right? Sometimes the RNG is in a different state and causes things to behave differently in the game. It goes much deeper than 'The controller isn't polled on the same frame anymore'.
I've tried telling him that before, he doesn't want to listen.
Because I don't necessarily accept someone else's stance if I don't know their reasons.
I didn't know/couldn't imagine how exactly a controller-port-based format would still have desyncs. It was explained in greater detail now.
Several reasons:
- Not everyone is using emulator movies to do speed runs.
- Specifically authorized cheats to get to harder game modes quickly, like 150cc in Super Mario Kart and 8 stars in Mario 2.
- Movies of games in weird states, which can be fun to watch.
Melissa
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
creaothceann wrote:
Nach wrote:
BoltR wrote:
creaothceann wrote:
BoltR wrote:
Heck, the emulators have a hard enough time keeping sync running a video back using it's own cores, let alone a trying to play back movies on other emulators. It's just not feasible. It's not the movie format which causes these problems...
Afaik it is, since it's frame-based. :/
You know that the desyncing is sometimes more than just a missing frame of input right? Sometimes the RNG is in a different state and causes things to behave differently in the game. It goes much deeper than 'The controller isn't polled on the same frame anymore'.
I've tried telling him that before, he doesn't want to listen.
Because I don't necessarily accept someone else's stance if I don't know their reasons.
I didn't know/couldn't imagine how exactly a controller-port-based format would still have desyncs. It was explained in greater detail now.
I told you the reasons already, it should also be obvious. When the input is received doesn't matter if it's being handled completely differently. You of all people should know emulators act differently for all sorts of stuff.
Take FEoEZ for example, in ZSNES the first fight always has the enemy open with the missile attack, and in Snes9x it's always the lazer attack. The input is going to be for the wrong situation.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
When the input is received doesn't matter if it's being handled completely differently. You of all people should know emulators act differently for all sorts of stuff.
Graphics and sound, yes.
Nach wrote:
Take FEoEZ for example, in ZSNES the first fight always has the enemy open with the missile attack, and in Snes9x it's always the lazer attack.
Er, yes those kind of effects would indeed complicate matters. :/
I was somehow assuming that the CPU part would not be affected that much. :P
