Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
This movie syncs on the latest SVN bizhawk when converted to BK2 and metadata tweaked so the emu knows which frame mode to use; no input log changes. It takes 14414574424 ticks to execute, for a total calculated time of 1:54:33.40.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
MrWint wrote:
natt wrote:
As of r7519, you can have both options; that way no one is happy. This will be in the next release; which probably won't happen anytime soon.
That's awesome. So basically you also have backwards compatibility to pre-1.7 movies again (except for those who use the RTC, but hey).
I feel kinda obligated to use this and create more GB movies now that my whining about the frame timing was successful...
I haven't put it through its paces yet, but pre-1.7 movies will require some minor manual header adjustments to work.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Patashu wrote:
jlun2 wrote:
No. This game sucks.
Also due to forgoing game end glitch, this is unvaultable.
Imo the 'game end glitch' is more of a debug code. It's the equivalent of opening a game, selecting 'credits' from the menu and ending the TAS. It's not clever or interesting.
I agree; looking at the description of it and some of the other unused glitches, it seems more likely that they're just controller 2 deubbing\testing stuff that was left in for release.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
RaijinXBlade wrote:
natt wrote:
RaijinXBlade wrote:
IIRC, Pier Solar can't be emulated because it makes use of things on the hardware that haven't been bought over to the emulator side properly, or at all. Of course, I could be wrong and they could have updated the emulators by now.
Did you not read my post 3 posts before your post or did you just not believe it?
GPGX can fully emulate this game. How many times does it need to be said?
What's your problem? My post was confirmed to be incorrect already by hegyak.
The reason I didn't believe it was possible is because I was talking to a guy who helped developed the game a while back and he mentioned it, but if it's possible now, that's great. No need for the attitude.
You directly contradicted my post without actually addressing the points brought up in it. That makes you no better than a gradeschooler chanting "nuh-uh!" on the school yard.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
feos wrote:
So what do you guys think of my own function? I'm already encoding with it. The only not yet automated part is importing the files by name. If PSXjin had an option to not append the resolution to the name, it would be completely solved to me. I even can do it myself, I just don't have the proper access.
It forces you to handle all resizes in the same way (lanczos with no cropping and no position offset parameters). In some cases you might want more control.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
feos wrote:
Other option is to resize all those segments to 256x240 using lanczos on the AVS side, on import. But that requires some extra automation avisnth doesn't provide. It would still look wrong, but it's the best we can do I guess.
That part is pretty trivial in avisynth; just use a loop (or what passes as a loop in that horrible language) to call a function like this for each filename:
Language: avisynth
function ImportFunc (string s)
{
FFVideoSource (s)
#Info
AssumeFPS (1, 1)
#PointResize (640, 480)
#320x240: only the first loading part
last.height == 240 ? Crop (0, 8, -0, -8) : last
#320x216: rather common, battle screens
last.height == 216 ? AddBorders (0, 4, 0, 4) : last
#368x224: text screns
last.width == 368 ? LanczosResize (320, 224, 0.0, 0.0, 368.0, 224.0) : last
#640x480: opening and disk switch
last.height == 480 ? Crop (0, 16, -0, -16).LanczosResize (320, 224) : last
return last
}
(This code is from a different attempt at FF8, where I tried to use MPPipeline to get around memory limitations. Unfortunately, MPPipeline is garbage.)
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Every time I had to do one of these, I cooked up something new. I think I did a SOTN once, but with enough cajoling I was able to get all the clips into memory at once (it was a shorter run I suppose?) Final Fantasy VIII and IX each had their own special setups involving a secondary program stitching together video files into bigger video files so I wouldn't have any out of memory problems.
Final Fantasy VIII was by far the worst. My scripts processed all of the segments for each resolution into a single large video, together with a timeline for how it all assembled back together: http://pastebin.com/emfw295L
When in that form, choosing a scaling treatment for each resolution is trivial (and you can see what I chose for FF8: 320x224, cropping or padding 320x* to fit, lanczos resize on anything else).
If we're willing to hack something new into psxjin, you could do something like the final fantasy 8 encode without too much trouble with most of the work being automatic behind the scenes.
Any solution that has the number of files open scaling with the length of the run is going to fail eventually, regardless of input plugin, and should be avoided.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
RaijinXBlade wrote:
IIRC, Pier Solar can't be emulated because it makes use of things on the hardware that haven't been bought over to the emulator side properly, or at all. Of course, I could be wrong and they could have updated the emulators by now.
Did you not read my post 3 posts before your post or did you just not believe it?
GPGX can fully emulate this game. How many times does it need to be said?
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Odongdong wrote:
One thing to note is that it utilizes optional Mega-CD expansion for audio enhancement. While the game ifself is on cartridge and works standalone, by inserting
enhanced soundtrack disc on Mega-CD, you can hear the CD music in the game. I'm pretty sure any current emulator doesn't support this as there're no official game using this technique.
There are two other "games" besides peer solar that use CD+Cart. GPGX supports them all. As of right now, Bizhawk-GPGX does not support CD+Cart due to some unimplemented practical concerns, but nothing major.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Turbo mode does temporarily stop audio, as a way to increase speed. But that doesn't always give that much FPS, and one could already be at the limit of their machine (with NESHawk). So in that case turobing would mute but cause no other real changes.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
thecoreyburton wrote:
Apologies, I was trying to re-create the error but managed to go a day without it popping up.
After which closing the application still leaves it running as a background process.
I've found that in some cases, deleting BizHawk and extracting a clean version will allow me to avoid this error at first, but it's not always the case. It's just more likely to work. It's been a problem for me since 1.5.1, and is still apparent in 1.7.3 as far as I can tell.
The FFMPEG writer should do much better on memory than the AVI native writer, for a number of reasons; somewhat more efficient code as well as putting the video compression's memory usage in a different process. Capturing Saturn at 1600x1200, I don't go over 300MB with it in a short test (compare with over 900MB with AVI native writer).
(Note that I still want this in the bug tracker to remind me of things that need to be done).
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Warepire wrote:
I vote for frame-timing á la 1.6.x
I'm not sure if one can really count the CPU cycles either, if I remember correctly the CPU fully and entirely stops during the HALT (or STOP?) instruction. Though if I am wrong here, that would be the ultimate solution. (Number of cycle counter roll-overs + cycles passed since last roll-over)
I don't think there is any fully accurate way to track time in the gameboy without running into issues where time might not be represented 100% accurately. I do however not see this as a major issue, compared to the issue that it might not be possible to provide input during certain situations.
What is the purpose of more accurate emulators if we botch the timing? That is potentially as bad as using emulators of less accuracy.
One can count ticks of a reference clock, which continues ticking at a constant rate even when the cpu is HLT/STP. Although Bizhawk doesn't do so now, it could easily be modified to show the exact number of refclocks elapsed at any particular frame end, and so the exact correct time elapsed could always be known regardless of frame end choice.
MrWint wrote:
You're right, there's no frame-based timing that will fit all games, since GB games can use joypad interrupts (well you could make inputs accurate to the CPU cycle, but that's not practical). But the old timing was fitting some if not most of the games, and my point is that the slight timing accuracy gain is not worth making the frame timing fit literally none of the games, especially when the accuracy could be achievd in a different way that doesn't have this drawback.
Joypad interrupts are not a problem; it was such a useless feature that the CGB doesn't even support them, and games didn't use them. Mid-frame power off could be useful, though. That would be moving all the way to arbitrary timed input which Bizhawk does not do.
Point to consider: Every single NES emulator (FCEUX, Bizhawk, others) uses the same timing scheme as old GBHawk, where variable length frames are used with the frame end being consistent relative to NMI, but not consistent in total time length. The magnitude of error is much smaller in NES, though.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
thecoreyburton wrote:
Does anyone else regularly have capturing problems when capturing high resolutions of n64 games? 1600x1200 or above, usually on graphically intense scenes and more frequent with glidemk2 as opposed to rice. Banjo Tooie was doing it a lot at one point. I'll capture the error when I see it next.
Yeah, we're going to need some more specific information on what exactly is going wrong.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
NesHawk's FDS mapper emulates loading speeds as being very very very slow for some games, relative to other emulators like FCEUX. I've looked through what information I can and I believe NesHawk is behaving correctly here; it should really be about that slow on the real console.
I'm not sure if this is the same ROM or not. The MD5 of mine is 8df0104553f85bc585b2ef7c199e7c13, which doesn't match what hegyak posted.
hegyak wrote:
When/where did you pause your game? I was in the starting area (with the drawbridge (?) and moat (?) and fireball thingy.
That's the same place I was, but I can make it happen in at least the first few rooms (I didn't try too far after that).
does bizhawk say that your rom is a good rom? if not, get a good rom
After which closing the application still leaves it running as a background process. I've found that in some cases, deleting BizHawk and extracting a clean version will allow me to avoid this error at first, but it's not always the case. It's just more likely to work. It's been a problem for me since 1.5.1, and is still apparent in 1.7.3 as far as I can tell.