Following this thread (specifically my latest post), I looked for another VGA BIOS image that won't display garbled text. I stumbled upon a legacy VGA BIOS image for Bochs (NB: JPC-RR uses the Bochs BIOS) named "VGABIOS-elpin-2.40" (which, by the way, is listed here). I imported it in JPC-RR, restarted it, assembled the machine, and...
No garbled text!
However, whether it syncs at all with this TAS is a different story, considering it seems to take longer to boot with the aforementioned VGA BIOS.
A failed attempt was importing the IBM VGA BIOS (game wouldn't launch at all).
Okay, I'm going to retract my statement on the garbled text being an emulation bug, because it actually isn't. It's related to the VGA BIOS JPC-RR is using (which is this one by default). As pointed out right here:
Some of the newer graphics cards might garble the text in these games and make it unreadable.
Maybe one could test with a proprietary VGA BIOS (if that's at all supported by JPC-RR) that's old enough to actually display the text properly. So...further testing needs to be done.
Something to consider is that Space Quest I (AGI) is an EGA game.
Speculation time:
Maybe it could have something to do with it running on FreeDOS instead of MS-DOS?
The thing is, JPC-RR is also a DOS emulator, and the site mentions that "To get around this, the AGI games might need to be run with a third party DOS emulator like DOSBox or one of the new third party AGI interpreters such as NAGI or Sarien.".
Maybe one would have to test on MS-DOS inside JPC-RR and see if the text's garbled there as well?
EDIT: No dice. It's an emulation bug.
Link to video
(in French)
That may be one of the weirdest music videos to ever grace Belgian television.
(context is given in the video description, also in French)
For what it's worth, the game was released in Brazil (and thus in a PAL region). However, Brazil's PAL-M standard actually is much closer to NTSC in terms of lines displayed and framerate (not to be confused with PAL-60!). It's literally the oddball of the PAL standard.
So....seeing it was released in Brazil, having it played back as an NTSC game, ironically enough, is fair game.
I can safely confirm the run syncs in JPC-RR 11.8 RC2.
By the way, here's the contents of the RESOURCE.CFG file that matches with the one this TAS uses:
On a CRT television, most of the left and right overscan area won't display, if at all, as in this example picture.
However, on an LCD television, you are going to see the entire overscan area (or at least a lot more), as seen in this picture. Similarly, capture cards will also capture the entire overscan area (or at least a lot more) (see basically every single Master System speedrun on SDA).
BTW, we don't crop away the overscan area for PS1 either for proper aspect correction (but then again, PS1 changes resolutions a lot more than SMS does AND would also be game dependent).
I'm more in favour of keeping the overscan area intact, even if the border is black. For more information, read marzojr's post.
By the way, BizHawk dumps PAL SMS with overscan at 284x288.
This is exactly what I mean by "we all know how this is going to end".
Do us a favour and stop wasting our time like you did before.
I'm just going to repeat this:
fsvgm777 wrote:
Leave it to us (as in the encoding/publishing team) for making encodes.
I don't want to go through that hell again and teach you do things properly, because encoding bizhawk's psx is not as simple as you think.
Honestly, we all know how this is going to end. There's a reason your encoding privileges were revoked.
Leave it to us (as in the encoding/publishing team) for making encodes.
I replaced the movie file with one that removes about 8 seconds of blank input at the end.
Anyway, barring the BIOS sequence (which can't be skipped), you don't skip the intro immediately and you wait a good second before selecting Sonic. Therefore, it seems more likely that you timed not from console power-on as we do, but from the moment you selected Sonic, which would more likely explain the 11:02.45 you're getting.
So, BizHawk should be able to generate lags as Snes9x 1.43.
BizHawk should absolutely not emulate lag as in Snes9X 1.43, because the latter emulates it very incorrectly. bsnes/higan and Snes9X 1.54 (both integrated in recent versions of BizHawk) emulate lag much closer to the original console (if not on par).
In other words, the BizHawk devs should not sacrifice accuracy to suit your needs.
Okay... sorry for the bad dump, but the only ones I found was [f1] and [f1+c], thanks for suggestion and... yes, it's a modification of Squirrel King
For what it's worth, the SHA1 checksum of the verified good dump is 5011E16F0AB3A6487A1406B85C6090AD2D1FE345. This doesn't match the SHA1 checksum of the [f1+C] dump (FF6661D39B2BAD26F460E16106CA369421388596).
This game is a slightly more elaborate hack of Squirrel King. What also ticks me off is that you used a fixed dump, when a verified good dump is available.
I'm not going to vote.
I did a little bit of research, and it seems you ran the Japanese ROM (published by Micro Cabin) on a PAL machine (the Philips NMS 8250) instead of the usual Panasonic FS-A1WSX (Japanese MSX2+ machine). Therefore, the game runs 16.7% slower than it should.
This is especially apparent in that there's Japanese text at the bottom of the screen that isn't present on the European version (see this video for an instance). Also note that the European version says "BY R.S.GOODLEY" instead of "BY MICRO CABIN".
For the encode, I used Mr. Do's DRAGRACE.ZIP Artwork file with a custom DEFAULT.LAY. Because this is an older version of MAME, recording AVI for a game that has an Artwork file causes all elements of the Artwork file to be included in the AVI, even if these elements are disabled in MAME's Video Options.
If you specify -artwork_crop in the command line when recording to AVI, you will only get the relevant part, namely the game screen with the overlay text. However, since the overlay text looks like complete garbage when upscaled (said overlay is 1928x1446!), I had to resort to something slightly different to make the overlay text look good:
Language: AviSynth
ovrlay = ImageSource(file="dragrace_overlay.png", start=0, end=46686, fps=last.FrameRate, pixel_type="RGB32") # end probably doesn't have to be this long
ovrlay = hd ? ovrlay.LanczosResize(2880, 2160, taps=2) : pass != 0 ? ovrlay.LanczosResize(256, 240, taps=2) : ovrlay.LanczosResize(320, 240, taps=2) # pass != 0 is for primary 10bit444 downloadable
mask = ovrlay.ShowAlpha("rgb") # needed to have the transparent part be actually transparent below
g = hd \
? Overlay(PointResize(width, height), ovrlay, mask=mask, output="RGB32") \ #2880x2160
: handheld || pass == 1 || pass == 2 \
? Overlay(last, ovrlay, mask=mask, output="RGB32") \ # 256x240 later aspect-corrected by x264 (NB: pass != 0 would also work)
: Overlay(LanczosResize(width, height, taps=2), ovrlay, mask=mask, output="RGB32") # manual aspect ratio correction for 512kb
(this isn't perfect, but it worked just fine, so...)
You sure? The left eye and the left tooth of the snake are a bit wider than the right ones... unless that's just my impression.
That said, I'd like to see point8x+lanczosARC to compare how it fares at 4k.
No garbled text!
However, whether it syncs at all with this TAS is a different story, considering it seems to take longer to boot with the aforementioned VGA BIOS.
A failed attempt was importing the IBM VGA BIOS (game wouldn't launch at all).
