Should we add exceptions to hardware emulation rule?

Greenalink

Edit history:

Greenalink: 2020-02-16 06:28:05 am

Greenalink: 2019-05-19 08:02:04 am

Greenalink: 2019-05-19 08:01:47 am

2019-05-19 07:55:43 am

DS Dictator

I have been speedrunning Contra Hard Corps lately and I have been playing it on the Mega SG, an FPGA console designed to play Sega 16-bit games, Master System, Sega CD* and Game Gear**

Why not the official system?

I do have a Genesis 2 model with the Triple RGB bypass installed and a switchless language switch to support heavily region locked games.
There are 2 disadvantages to this.

1) The official consoles do not have any kind of Digital to Digital HDMI mod yet and the best solution for RGB SCART/"HD Retrovision" Component cables is the Datapath internal capture card, which isn't an easy item to get nor to use straight away.
2) This one is a personal problem with my system but the soft reset command does not work, I need to look inside at what needs to be done with it.

The Mega SG does support 3 video buffer options, 2 of them run the game at a cycle accurate of 59.92hz instead of pure 60hz, which I'm sure a lot of official microconsoles (NES Mini, SNES Mini) and digital releases of the pre-Dreamcast games use.

What is great with the Mega SG is the digital to digital output HDMI for very clean recordings without effort.

* Mega CD add-on uses an official SEGA Mega CD part, meaning it's half hardware emulated, half official.
** Game Gear cartridges can be played on the system by using the GG Adapter (but avoid using the version 1.0 as they are confirmed to be defective).

Below is a video review of the product by Digital Foundry and why it surpasses many other clone consoles of its type.
[12:57] is a very good part to watch.

Super NT video (Super Nintendo counterpart).

I thought about this suggestion mainly because I had a feeling that the rule was written when we had a lot of crappy microconsoles by ATgames in the market with sub-par video emulation quality. Now there are some consoles that have raised the bar to the point it's just as accurate than the original machines and more accurate than emulated re-releases.

I have also added 3 attachments of Contra Hard Corps.

Thread title:

I have been speedrunning Contra Hard Corps lately and I have been playing it on the Mega SG, an FPGA console designed to play Sega 16-bit games, Master System, Sega CD* and Game Gear**

Why not the official system?

I do have a Genesis 2 model with the Triple RGB bypass installed and a switchless language switch to support heavily region locked games. 
There are 2 disadvantages to this.

1) The official consoles do not have any kind of Digital to Digital HDMI mod yet and the best solution for RGB SCART/"HD Retrovision" Component cables is the Datapath internal capture card, which isn't an easy item to get nor to use straight away.
2) This one is a personal problem with my system but the soft reset command does not work, I need to look inside at what needs to be done with it.

The Mega SG does support 3 video buffer options, 2 of them run the game at a cycle accurate of 59.92hz instead of pure 60hz, which I'm sure a lot of official microconsoles (NES Mini, SNES Mini) and digital releases of the pre-Dreamcast games use.

What is great with the Mega SG is the digital to digital output HDMI for very clean recordings without effort.

* Mega CD add-on uses an official SEGA Mega CD part, meaning it's half hardware emulated, half official.
** Game Gear cartridges can be played on the system by using the GG Adapter (but avoid using the version 1.0 as they are confirmed to be defective).

Below is a video review of the product by Digital Foundry and why it surpasses many other clone consoles of its type.
[12:57] is a very good part to watch.

[hidden]https://www.youtube.com/watch?v=_ZCQ6kN9Ie0[/hidden]

Super NT video (Super Nintendo counterpart).
[hidden]https://www.youtube.com/watch?v=LOSQgBEf5ac[/hidden]

I thought about this suggestion mainly because I had a feeling that the rule was written when we had a lot of crappy microconsoles by ATgames in the market with sub-par video emulation quality. Now there are some consoles that have raised the bar to the point it's just as accurate than the original machines and more accurate than emulated re-releases.

I have also added 3 attachments of Contra Hard Corps.

Attachments:

Contra Quality Test_HQ.mp4

Contra Quality Test_IQ.mp4

Contra Quality Test_XQ.mp4

LotBlind

2019-05-22 11:34:54 am

Currently discussing this.

nate

2019-05-23 08:41:46 am

i have both the analogue 16-bit consoles and i like them. as greenalink already noted, out of the box they run at the wrong speed in order to get vsync on digital tvs (36:40 in the mega sg youtube video). it's imperceptible but it will make your time wrong. so verifiers would need to take care to note whether duplicate frames or tearing appear in order to confirm that vsync has been turned off and the game's speed is correct. obviously verifiers would have final say as well if other issues appear with specific games. but beyond that i have no reservations about accepting runs done on the mega sg or super nt with up to date firmware.

LotBlind

Edit history:

LotBlind: 2019-05-27 01:03:56 pm

2019-05-27 01:03:45 pm

So the basic outcome of the Slack discussion was that we don't have a huge amount of data on these systems yet but we couldn't find any threads or such talking about any glaring problems, so everyone seems to think along the same lines as nate here.

nate: do you think we should require the runners to show the start-up screen/options screen (is there one?) and also what should the default settings be aside from that 59.92 Hz thing?

I suppose we'll assume the Nt mini is analogous (pun not intended) to the other two. There's another one called the "Ghostly" but that one seems to have been just some special edition of the Super Nt. This thread was about the mini... In it coolmatty's first post makes it sound like for that one at least, the system runs slower, not faster, by default, and that runners will have to accept 1 frame latency if they want the original speed. So I guess we won't have a difficult time verifying those runs if you can only lose time with the wrong settings, right?

So the basic outcome of the Slack discussion was that we don't have a huge amount of data on these systems yet but we couldn't find any threads or such talking about any glaring problems, so everyone seems to think along the same lines as nate here.

nate: do you think we should require the runners to show the start-up screen/options screen (is there one?) and also what should the default settings be aside from that 59.92 Hz thing?

I suppose we'll assume the Nt mini is analogous (pun not intended) to the other two. There's another one called the "Ghostly" but that one seems to have been just some special edition of the Super Nt. [url=https://www.reddit.com/r/speedrun/comments/7vxc6q/discussion_are_fpga_systems_viable_for/]This thread [/url]was about the mini... In it coolmatty's first post makes it sound like for that one at least, the system runs slower, not faster, by default, and that runners will have to accept 1 frame latency if they want the original speed. So I guess we won't have a difficult time verifying those runs if you can only lose time with the wrong settings, right?

Greenalink

2019-05-28 11:31:20 am

DS Dictator

I don't have the NT Mini (NES/Famicom counterpart) simply because it doesn't have the native hz setting, just the slightly downclocked 60.00hz option.

I can confirm that there is a (customisable) button combination to show the analogue Super NT/Mega SG menu, to make things easier, I usually go to the buffer settings and close it so that when I have done a run, I can push a button combination to show the buffer settings straight away.

Only the Mega SG can save time for choosing the inaccurate yet lag free 60.00hz friendly option over the native 59.92hz setting.

LotBlind

2019-05-31 01:08:24 pm

So...

Super NT: Have to show menu before or after run to see the firmware version, which has to be the latest one.

Mega SG: have to show the menu for framerate (59.92) and firmware version.

NT Mini: Hmm... nate, what do you think? It should be easy to recognize that someone has used this console even if they don't mention it (based on video quality?), and do some maths to make their time comparable.

nate

2019-06-01 04:53:49 pm

man, i totally forgot about applying a multiplication factor to convert the time. that's way better than forcing people to lose vsync. still have to show which clockspeed setting was used though to make sure we're using the correct multiplier.

of course this assumes running games at the wrong speed changes nothing other than their speed. on one hand, it's such a small difference. but on the other hand, you never know. that's why i say verifiers have to have final say.

LotBlind

2019-06-02 12:58:47 pm

So couldn't we simply go "show the menu, and use at your own risk" on all of them?

Koston

2019-06-02 02:11:11 pm

If you're going to allow systems that run at incorrect speed (!), please at least do framerate conversion before final video upload.

LotBlind

2019-06-03 11:11:18 am

Koston: I suppose what you mean is that even if we've timed the video right, someone could mistakenly use it as a direct point of comparison for their attempts and wonder why they're slower? Are you saying you don't think it's enough to require showing the settings before/after the run? (I guess someone could stop watching before it got to that part) We could also ask people for an explicit mention of the setting used in the run comments, but those aren't always supplied.

Still, it's extremely rare to come down to any kind of frame wars on SDA, and it really shouldn't for most games. And anyone dedicated enough to submit an improvement should probably know where and why they were faster (or seemingly slower). Was there something else on your mind though?

Koston

2019-06-05 06:19:58 am

As far as I understood, all uploaded videos are re-encoded anyway. There are many reasons for converting the framerate to match original hardware; are the any for *not* doing so?

ktwo

2019-06-06 10:11:10 am

The published videos on SDA are encoded, but the framerate isn't changed during this process (other than deinterlacing interlaced recordings). I don't think it's a good idea to tamper with the framerates and definitely not starting with it now. It seems like a better idea to me to write next to the link on the game page that a different hardware was used. If it becomes a frame war and people want to do the conversion, they can always calculate the corresponding time. I'm guessing that in most cases the involved parties will switch to the slightly faster original NES hardware before competition gets this fierce though.

LotBlind

2019-06-06 02:27:54 pm

^ Yeah, a lot of effort for minimal profit (and potential downsides, namely masking the fact of how the run was recorded if it wasn't obvious).

Actually a lot videos are encoded by the runners, not us, as well.

LotBlind

Edit history:

LotBlind: 2019-06-16 10:40:17 am

LotBlind: 2019-06-12 12:29:56 pm

LotBlind: 2019-06-11 02:03:42 pm

LotBlind: 2019-06-11 01:57:56 pm

LotBlind: 2019-06-11 01:53:53 pm

2019-06-11 01:35:36 pm

Need input especially from those who already have some of these systems.

Okay, so the consoles rule currently has this:
"- Clone consoles are considered as equivalent to hardware emulation and are not allowed."

Right after that sentence, shall we add:
"The Analogue consoles (Super NT, Mega SG and NT Mini) ARE allowed on SDA since their accuracy far surpasses any other clone systems. If any gameplay differences are noticed compared to the original hardware, your run could still get rejected or removed (so try to make sure any bugs that you're exploiting are present in the original as well). When submitting runs on these systems, if you use analog output, the console will output at the original framerate and no adjustments are required. However, using digital output, the choice of *buffer modes* on the Super NT and Mega SG affects how fast the system is running. In that case, you *have to* show the menu either before or after the run for which buffer mode you're using. In both cases, you must also show which *firmware version* you're using. Use the *most recent firmware*.

Super NT: Can be used to run SNES and Super Famicom games.
The Buffer Mode is shown under "Video" -> "Advanced Mode" -> "Buffer Mode" and the firmware version can be seen in the "About" menu.
- Fully Buffered: original speed 60.08hz, up to 1 frame of lag, drops 1 frame every 10 seconds but this is cosmetic and doesn't affect gameplay
- Zero Delay: downclocked to exactly 60hz, no lag, you lose roughly 1 second every 10 minutes
- Single Buffer: original speed 60.08hz, no lag but has screen tearing every 10 seconds
- if you choose the Zero Delay mode, we will convert the time to match the original consoles (60.08hz)

Mega SG: Can be used to run Master System, Sega CD and Game Gear games.

- Fully Buffered: original speed 59.91hz, up to 1 frame of lag, 1 duplicate frame every 13 seconds but this is cosmetic and doesn't affect gameplay
- Zero Delay: sped up to exactly 60hz, no lag
- Single Buffer: original speed 59.91hz but has screen tearing every 13 seconds
- if you choose the Zero Delay mode, we will convert the time to match the original consoles (59.91hz for all).
- the Sega CD emulation might have more bugs than the other two so be careful.

NT Mini: Can be used to run NES and Famicom games.
NES/Famicom 60.08hz Firmware shown under Settings
- runs at 60hz if you use digital output, 60.08 if analogue (50 PAL?)
- if you use digital output, you're losing 1 second every 10 minutes, but we will compensate for this in timing
- obviously can't run PAL games on NTSC settings to make them faster
- If you use digital output, we will convert the time to match the original consoles (60.08hz).

PAL

- None of these can be used to run other systems than they were natively designed to run. This means no emulated cores (e.g. Colecovision in the NT Mini). Any officially released adapters for getting games for other systems to run ARE allowed (e.g. Sega Master System on the Mega SG or Super Game Boy on the Super NT). The games may not run at the original framerate though, so tell us if this is how you're running them so we know what kind of time adjustment to use.

- Output methods, order of preference: HDMI or component > S-video > composite (except PAL in which S-video and composite are the same thing) > RF

- You can use any of a variety of audio/video settings that you feel are right, so long as these basic requirements are met:
1) You are not cropping the screen ("junk pixels" have to be left in).
2) All audio channels are heard and balanced.
3) No extreme/"out-there" settings are used for either video or audio.

It is ultimately rests on the the verifiers to decide if your run meets these criteria.

- You may use the increased sprite limit option in the NT Mini (prevents flickering)
- Scanlines are not required.

-----------------

[b]Need input[/b] especially from those who already have some of these systems.

Okay, so the consoles rule currently has this:
"- Clone consoles are considered as equivalent to hardware emulation and are not allowed."

Right after that sentence, shall we add:
"The Analogue consoles (Super NT, Mega SG and NT Mini) ARE allowed on SDA since their accuracy far surpasses any other clone systems. If any gameplay differences are noticed compared to the original hardware, your run could still get rejected or removed (so try to make sure any bugs that you're exploiting are present in the original as well). When submitting runs on these systems, if you use analog output, the console will output at the original framerate and no adjustments are required. However, using digital output, the choice of *buffer modes* on the Super NT and Mega SG affects how fast the system is running. In that case, you *have to* show the menu either before or after the run for which buffer mode you're using. In both cases, you must also show which *firmware version* you're using. Use the *most recent firmware*.

[hidden]

Super NT: Can be used to run SNES and Super Famicom games.
The Buffer Mode is shown under "Video" -> "Advanced Mode" -> "Buffer Mode" and the firmware version can be seen in the "About" menu.
- Fully Buffered: original speed 60.08hz, up to 1 frame of lag, drops 1 frame every 10 seconds but this is cosmetic and doesn't affect gameplay
- Zero Delay: downclocked to exactly 60hz, no lag, you lose roughly 1 second every 10 minutes
- Single Buffer: original speed 60.08hz, no lag but has screen tearing every 10 seconds
- if you choose the Zero Delay mode, we will convert the time to match the original consoles (60.08hz)

Mega SG: Can be used to run Master System, Sega CD and Game Gear games.

- Fully Buffered: original speed 59.91hz, up to 1 frame of lag, 1 duplicate frame every 13 seconds but this is cosmetic and doesn't affect gameplay
- Zero Delay: sped up to exactly 60hz, no lag
- Single Buffer: original speed 59.91hz but has screen tearing every 13 seconds
- if you choose the Zero Delay mode, we will convert the time to match the original consoles (59.91hz for all).
- the Sega CD emulation might have more bugs than the other two so be careful.

NT Mini: Can be used to run NES and Famicom games.
NES/Famicom 60.08hz Firmware shown under Settings
- runs at 60hz if you use digital output, 60.08 if analogue (50 PAL?)
- if you use digital output, you're losing 1 second every 10 minutes, but we will compensate for this in timing
- obviously can't run PAL games on NTSC settings to make them faster
- If you use digital output, we will convert the time to match the original consoles (60.08hz).
[/hidden]

PAL

- None of these can be used to run other systems than they were natively designed to run. This means no emulated cores (e.g. Colecovision in the NT Mini). Any officially released adapters for getting games for other systems to run ARE allowed (e.g. Sega Master System on the Mega SG or Super Game Boy on the Super NT). The games may not run at the original framerate though, so tell us if this is how you're running them so we know what kind of time adjustment to use.

- Output methods, order of preference: HDMI or component > S-video > composite (except PAL in which S-video and composite are the same thing) > RF

- You can use any of a variety of audio/video settings that you feel are right, so long as these basic requirements are met:
1) You are not cropping the screen ("junk pixels" have to be left in).
2) All audio channels are heard and balanced.
3) No extreme/"out-there" settings are used for either video or audio.

It is ultimately rests on the the verifiers to decide if your run meets these criteria.

- You may use the increased sprite limit option in the NT Mini (prevents flickering)
- Scanlines are not required.

-----------------

nate

2019-06-11 02:57:07 pm

imho scanlines is just nostalgia pandering and definitely should not be required.

i think the video output preference is the same as it always is. hdmi or component > s-video > composite (except pal in which s-video and composite are the same thing) > rf.

strictly speaking, input lag would be the time from pressing a button to the game software processing the input, while display lag would be the time from the game hardware transmitting the video signal to it appearing on the display. in practice they are often spoken of as the same thing but i was recently shocked to learn that the old school sonic games have not 1 but 2 frames of input lag - totally independent of display lag. so if you have display lag too on top of that, it really adds up.

yes, it makes sense that the analogue consoles will run at the original speed with analog out, because the intended use for that is crt displays which obviously handle the original speed just fine. again, with digital out, people can pick whatever speed works best for them, but they need to show that selection in the menu before or after the run so that the correct multiplier can be applied to their time. this is no different from the policy from 2004 for runs done on the super game boy, which also runs at the wrong speed (as explained in the video). and i see no reason why the same policy couldn't also apply to runs done on the super game boy plugged into a super nt. just maybe have to apply two multipliers to the time instead of one.

imho scanlines is just nostalgia pandering and definitely should not be required.

i think the video output preference is the same as it always is. hdmi or component > s-video > composite (except pal in which s-video and composite are the same thing) > rf.

strictly speaking, input lag would be the time from pressing a button to the game software processing the input, while display lag would be the time from the game hardware transmitting the video signal to it appearing on the display. in practice they are often spoken of as the same thing but i was recently shocked to learn that the old school sonic games have not 1 but 2 frames of input lag - totally independent of display lag. so if you have display lag too on top of that, it really adds up.

yes, it makes sense that the analogue consoles will run at the original speed with analog out, because the intended use for that is crt displays which obviously handle the original speed just fine. again, with digital out, people can pick whatever speed works best for them, but they need to show that selection in the menu before or after the run so that the correct multiplier can be applied to their time. this is no different from the policy from 2004 for runs done on the super game boy, which also runs at the wrong speed (as explained in the video). and i see no reason why the same policy couldn't also apply to runs done on the super game boy plugged into a super nt. just maybe have to apply two multipliers to the time instead of one.

LotBlind

2019-06-12 12:30:05 pm

Is using RF output grounds for rejecting if it's so bad?

Are hotkey options allowed? What would this mean for input methods?

AFAICT, PAL runs at exactly 50hz, right? Not at like 50.09? In that case PAL runs at least don't have to be applied multipliers to regardless of output? Or buffer settings? I'm confused about this since all the videos only discuss NTSC framerates.

Updated the thread above.

nate

2019-06-13 05:07:22 pm

i don't think anyone will be using rf with these consoles so it's probably a moot point.

i'm not sure what the problem is with hotkeys. afaik on these systems the only things you can do are go into the menu or soft reset, both of which are useful in their own ways.

good point about pal. i have to admit i don't know whether a multiplier would be needed in the case of games running at pal speed. just because pal nominally has integer framerate doesn't mean the old school consoles didn't run at different speeds, especially since they were hacked versions of ntsc originals. in any case, it's as simple as checking the video setting used in the analogue menu to see what speed the game is actually running at, looking up what speed it's supposed to be running at, and then multiplying the time by the corresponding ratio. btw i agree with not messing with the framerate of the video of the run because that would hide information about the run without any benefit i can see other than cutting down on people coming on the forum to tell us that the run was timed wrong when it actually wasn't.

i don't think anyone will be using rf with these consoles so it's probably a moot point.

i'm not sure what the problem is with hotkeys. afaik on these systems the only things you can do are go into the menu or soft reset, both of which are useful in their own ways.

good point about pal. i have to admit i don't know whether a multiplier would be needed in the case of games running at pal speed. just because pal nominally has integer framerate doesn't mean the old school consoles didn't run at different speeds, especially since they were hacked versions of ntsc originals. in any case, it's as simple as checking the video setting used in the analogue menu to see what speed the game is actually running at, looking up what speed it's supposed to be running at, and then multiplying the time by the corresponding ratio. btw i agree with not messing with the framerate of the video of the run because that would hide information about the run without any benefit i can see other than cutting down on people coming on the forum to tell us that the run was timed wrong when it actually wasn't.

LotBlind

2019-06-16 10:40:10 am

Okay, I suppose we're almost done then. Could you check if this is true for the Mega SG as well?
"The Buffer Mode is shown under "Video" -> "Advanced Mode" -> "Buffer Mode" and the firmware version can be seen in the "About" menu."

Also how exactly does one reach the menu that gives the video setting for how fast it's running? This is different from the buffer mode menu? This goes for all three consoles, right?

nate

2019-06-24 02:42:06 pm

on the mega sg the clockspeed setting is under main menu -> settings -> video -> buffer mode (hidden unless advanced mode, below it, is checked). it seems that this is the same on both the super nt and the mega sg.

the hotkey combo to bring up the main menu on the mega sg is down + start by default (you can configure it to something different if you want).

LotBlind

2019-06-25 09:48:41 am

Right. What about that menu that shows "what speed the game is actually running at" as you said. Did you mean this should be shown only if you're using PAL, or with both PAL and NTSC? And did you mean that the Buffer Mode also still needs to be shown?

nate

2019-06-25 11:51:31 am

i'm sure it's the same with both pal and ntsc. i think in the context of the analogue consoles, pal is just a region setting (elsewhere in the menu). the purpose of the options in the buffer mode menu is to get vsync on the tv (since the console's true clockspeed probably never matches a digital tv's refresh rate). so you can choose to play at the correct speed but deal with tearing and/or dropped frames or to play at the speed of the display, which is slightly off, but known. my opinion is that playing at the wrong speed is not going to give anyone any advantages, so it's best to play at vsync (the default setting) and then multiply the run's time by the ratio of the two speeds, which is well known. this is no different from the policy on the super game boy from 15 years ago. reason we want people to open the menu and show the buffer setting is so we can be sure the correct multiplier is applied to the time. that way we can leave it up to the runner which setting they use. it can also be pretty trivially determined after the fact by going frame by frame and checking for tearing and/or dropped/inserted frames. but telling them to open the menu makes things more streamlined. and they should probably show the firmware version under about too in case there are any patches for specific games in later firmware versions.

LotBlind

2019-06-26 12:37:07 pm

Right, so you were talking about the Buffer Mode menu the whole time. I guess then, even if you have the PAL setting selected, you still show us the buffer mode? That sounds weird if PAL is always 50 hz exactly, but then you said that it depends.

In any case, I wrote this page and linked it to the rules. Could you take one last look at it? We'll announce it in the next update.

nate

2019-06-29 02:39:35 pm

page looks great. i made just one small change.

about pal, i just confirmed my suspicion that the pal versions of the old consoles don't run at 50 hz. e.g., 49.701459 hz (under "refresh rate") for the mega drive and 50.0070 hz (under "vertical scan rate") for the nes.

LotBlind

2019-07-01 04:29:26 pm

So just one more thing: I still don't understand if the runners running PAL games need to show those actual hertz counts (under "refresh rate" or "vertical scan rate" or whatever the case) or if it's somehow implied so long as we know what console it is and that they're using PAL settings. If they need to show it, how should this be generalized in the rules?

nate

Edit history:

nate: 2019-07-02 07:09:18 am

2019-07-02 07:08:13 am

they do. basically there's no difference between ntsc and pal when it comes to these consoles. so main menu -> settings -> video -> buffer mode (hidden unless advanced mode, below it, is checked).