each format is a class that encapsulates all the necessary properties and methods required to define and interact with the desired format (bad grammar eh?). The main logic attaches cases to the form controls that fire based on what kind of movie file is loaded.
Have you thought about implementing the required functions in the root class? You'd then not have to do case selections in the main code.
Or I didn't understand it correctly...
I'm working on a library (DLL) that should allow easy sharing of memory blocks across application boundaries while taking care of the mutex stuff...
If (when?) it's finished you'd be able to write a small application that just hooks into the emulator's shared variables (e.g. RAM) instead of having to modify the emulator's source.
Might be useful to somebody, who knows. :/
EDIT: Typo.
Is there interest in this game? Here's a demo that shows the gameplay: Jump'n'run and Space Shooter.
emulator: snes9x-1.43plus-rerecording-v10
settings: WIP1 timing
ROM: Rendering Ranger R2 (J)
CRC32: 8FB5AC86
The game does not work in SNES9x 1.501 for some reason.
It's not supposed to be a speedrun; just normal gameplay at 24% speed and with a few rerecords. Done in two segments because my PC decided to reboot - and I don't know how to resume recording... there's not much interesting stuff in the rest of that level anyway, apart from the spaceship launch.
"It looks cool precisely because it looks ugly and confusing" just doesn't make any sense.
I don't think that's why others consider it "cool". I think it's more the fact that Super Metroids game engine was successfully broken ("hacked" in its original meaning). It's so impressive because Super Metroid's engine is quite powerful, compared to many other games.
And yes, it looks ugly. :-j
- Zelda 4: two cyclopses in the last fight
- SMW2: killing that one piranha plant boss before the fight officially started (not a bug per se, but cool)
- SMW2: warping back to the top of a level in sector 1 to complete a later level
- Super Metroid: killing the Golden Pirate Boys with a shinespark (Saturn's teaser #3)
Hi, on your speedrun preview #2 for Metroid (SNES), what song are you using on there? There is a guy that says "Hasta La Vista Baby"
By the way, your videos rock!
Couldn't the conversion still work by playing back with the old method while recording with the new one? [...] Of course, it would have to be done in the older emulator because only that can play the movie based on frames without desync, and I have a feeling that most converted movies still won't play back properly in newer versions.
Well, if you want to have both methods in one emulator, then of course it'd work as usual.
nitsuja wrote:
Or are you saying pressing buttons at certain times can have effects other than the reading of those registers?
Not directly - the reading is done by the game; button presses don't cause x86-like interrups or something like that.
An example: In Super Metroid there's a point where Samus is carried by a Chozo statue across a field of spikes, and the player can't control anything for a few seconds. There's been a movie posted though where the author pressed the appropiate shoulder button (L or R) as if giving commands to the statue. (Viewers who have input display enabled can watch this.)
Now if the game is still reading these pad changes but discards them, then there wouldn't be a problem for the conversion. But if the game doesn't access the input registers then a movie converter would add the inputs up and feed them back when the game begins reading "real" input again.
IMO it's safe to say that less than 50% of all SNES movies on tasvideos will have that issue, probably much less but I'm bad at guessing. The rest, maybe only a handful, would require some manual fixing, ie. removing that unnecessary input.
They are connected to the same gamepad ports, so the peripherals are using the same registers. They just have a different data format (see anomie's docs and snestech.txt if you're interested), but for movie recording/playback this shouldn't matter.
Mmmh, one thing that could break the conversion of older movies (assuming there's a need for that) is if the player pushed buttons when the game wasn't reading from the registers. This would then need manual fixing, I guess.
4016 rwb++++ JOYSER0 - NES-style Joypad Access Port 1
Rd: ------ca
Wr: -------l
4017 r?b++++ JOYSER1 - NES-style Joypad Access Port 2
---111db
[...]
Note that Auto-Joypad Read (see register $4200) will effectively write
1 then 0 to bit 'l', then read 16 times from both $4016 and $4017. The
'a' bits will end up in $4218/9, with the first bit read (e.g. the B
button) in bit 15 of the word. Similarly, the 'b' bits end up in
$421a/b, the 'c' bits in $42c/d, and the 'd' bits in $421e/f. Any
further bits the device may return may be read from $4016/$4017 as
normal.
The effect of reading these during auto-joypad read is unknown.
See the section "CONTROLLERS" below for details.
So the automatic reading uses these registers as well.
Maximus wrote:
Forgive me if I'm a tad ignorant as far as the inner workings of the emulators are concerned, but what would be the advantage of storing those values versus frame input?
No more desynced movies!
Different emulator builds may cause the game to read the controller registers on different frames, causing them to miss the right data. They get the data for another frame (the one before or after).
By enumerating the reads instead they can't be missed, since no emulator build would break the game so much that it wouldn't read at all.
EDIT: Existing movies could easily be converted - just go through the file, save the keypresses and skip the "empty" frames.
OK, got the source. :)
Btw. are there plans to record the values the game reads from the controller registers (4016h & 4017h iirc) instead of recording the current input of a frame? This was discussed here...
Thanks guys. :) I got the Windows executable from rapidshare, BUT the source has been removed (not enough downloads) and filexoom doesn't respond over here. :(
Could you upload it again? If not then just send it to creaothceann{at}web{dot}de ... thanks in advance.
