Would it be possible to add an "keep aspect ratio" option to the "fullscreen stretch to fit" feature?
The GBA screen format (12:8) clashes with the common PC format (12:9 aka 4:3), ie. everything gets stretched vertically.
Well, to me it seems interesting so far. Can't promise it will stay that way...
I guess that not many people have played it much, so a movie would probably have to rely much on surprising actions to be interesting.
At least when people get them here, they'll see that there's a link to the original emulator as well; elsewhere, it seems that 50% say "omg u r teh gr8test speedrunner evar" and 50% say "wtf u cheatted moran". >.>
It seems to me that people can be quite blind to certain things. Just look at how often the forum stickies are not read.
If you'd put a large blinking text there they'd probably just dismiss it as ads or something. :/
EDIT: http://xkcd.com/c202.html
FCEU displays a "0" at certain occasions (e.g. here). I know that the NES can display only a limited number of sprites per line, but this seems to be a game issue, right?
One viewer thinks that you can see Samus' dying and Zoizite's reloading...
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
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.
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?
... then I thought that was dumb so I reverted back [...] I tend to get on this redesign kick too often, and it affects my ability to move forward with development
I do that, too. Progress stalls, but the existing features become stronger.
In the end it'll all fall into place. :)
it is sometimes advisable [...] difference in speed is hardly noticeable but it still helps in certain situations
This seems OK to me. As long as it doesn't get repetitive and yawn-inducing...
(Arm-pumping is repetitive as well, but hardly noticeable after a while.)
>I figured users might want to see everything in the same list.
Yes please. That is probably the best reason for using your version. I wouldn't want to see that changed.
Huh? Don't know why you'd want that, but I haven't done any serious editing/running either. :) At least you can switch quickly via Alt+1..5.
Anyway, 14 buttons * 16 pixels * 5 players would already consume 1120 pixels horizontally, hence the trend to separate planes. Do you want to list the 5 players vertically, for each input frame? Or display only the required number of columns?
