1 2 3
Posted: 12/8/2020 3:14 PM
(Edited: 6/4/2022 4:52 PM)
Quote
feos
Site Admin, Skilled player (1254)
Joined: 4/17/2010
Posts: 11475
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
NES TAS of 2011
UPDATE: Official rules are here: https://tasvideos.org/EmulatorResources/PCem#MovieSubmissions We finally started working on getting libTAS+PCem approved for submission, and we're starting with DOS. The goal is running DOS games in PCem that's hooked into libTAS, and that's on either Linux or Windows+WSL2. That way you will be able to TAS DOS games without having to rely on emulation hacks (think DOSBox) or poor savestates (libTAS captures state of the entire program it runs). The cost is having to set up the environment though. But if PCem is ever supported in bizhawk, we'll already have the setup figured out by then. What we want is to officially provide 3 emulated hardware configurations for PCem, to cover 3 eras of DOS games: late 80s, early 90s, and late 90s. Early 80s would be harder, because games weren't all that appealing back then, and PCem doesn't emulate the turbo button, but as a lower priority, maybe we come up with something later, as a 4th config. We will create packages including PCem config files, pre-installed software we can distribute, and ideally, 99% of DOS games would work in either of those 3 packages. That means we need to figure out what hardware we want PCem to emulate for each of those packages, and what software we want to pre-install (and pre-configure). Here's a full list of what it emulates as of v17. We want to ship FreeDOS wherever we can for this, here's an example package slamo created for testing how well it works and whether it can cover 99% of DOS games. For the sake of testing how well things work, you won't need Linux or libTAS, just grab this Windows build of PCem (it includes the single-threading patch that we need for TASing, so report all the errors you get, if they're not present in official PCem). If you're running it on Linux, here's the branch we're relying on, the build steps are mentioned in the readme. EDIT: https://github.com/TASEmulators/pcem/releases
TL;DR: What would be the most compatible hardware and software (that we can safely ship) required to run majority of DOS games of 3 eras - late 80s, early 90s, and late 90s?
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Posted: 12/8/2020 3:44 PM
(Edited: 6/4/2022 4:52 PM)
Quote
Nach
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
To get the ball rolling, how about the IBM PS/2 Model 70 386DX at 25 MHz Built-in VGA As a machine for late 80s games? It should play everything reasonably well. We can consider that many games of that era for designed for that machine or a similar machine. Some games back then had early sound systems like Adlib. Can we put any sound card into such a machine in PCem? Or are we limited to a certain subset? I think for that era, a 3x86 is ideal, because it's 16-bit, so it gives us access to all that software, while at the same time, isn't so new and fast that it's heavily divorced from the software of the era.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Posted: 12/8/2020 4:11 PM
(Edited: 6/4/2022 4:52 PM)
Quote
slamo
Reviewer, Expert player (2435)
Joined: 5/21/2013
Posts: 414
DS TAS of 2022 Computer TASer of 2016 Computer TAS of 2016 Computer TASer of 2013 Computer TAS of 2013
That chipset is compatible with: Adlib Sound Blaster MCV Sound Blaster Pro MCV I would highly recommend downloading PCem and making these configurations in that so you can see which hardware is compatible with each other. Even if you make the config in Windows it's very easy for me to use it in Linux.
Posted: 12/8/2020 11:23 PM
(Edited: 6/4/2022 4:52 PM)
Quote
Nach
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Since we're having some issues with my previous suggestion, how about the: Compaq Deskpro 386 386DX at 20 MHz 4MB RAM It supports ISA, so we can use it with IBM VGA and a Sound Blaster Pro. The SB Pro is backwards compatible with the original SB and Adlib, so it should give us sound in practically every 80s game. Edit: Added RAM amount.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Posted: 12/8/2020 11:44 PM
(Edited: 6/4/2022 4:52 PM)
Quote
Nach
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Other suggestions: Early 90s: Packard Bell PB570 (Hillary) Pentium 133 8 MB RAM Sound Blaster 16 Built in GD-5430 I think this is a reasonable spec for that time frame, and it should cover pretty much everything of that period. Only question is the video card, I think it's sufficient. What do you guys think? Late 90s: Gigabyte GA-686BX Pentium II 450 32MB RAM Sound Blaster 16 Phoenix S3 Trio64 3DFX Voodoo 2 For late 90s, I would even go Pentium III, but it doesn't seem we have anything beyond a Pentium II in PCem. Cyrix had some good processors back then, but you'd run into the odd compatibility issue. Sound Blaster 16 still seems to be the most compatible option that doesn't require external firmware. For 2D video, the S3 Trio was by far the most popular series, this card seems to be the best of the bunch available. Going for separate 2D and 3D instead of one of the combined because the early 3DFX combined 2D/3D cards were known to have some 2D visual quality issues. There's combined S3 ViRGE based video cards, but then it won't be able to accelerate games designed specifically for 3DFX cards. The Voodoo 2 is the best one PCem has.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Posted: 12/9/2020 7:44 AM
(Edited: 6/4/2022 4:52 PM)
Quote
Nach
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
One important factor for 90s DOS software is the VESA BIOS extensions. It'd be nice if we had good video cards which supported VBE 2 and 3 because those added support for higher resolutions and greater bit depths which some games might be able to make use of. However, a lot of that can be added via software if necessary, and we should bundle it if PCem doesn't supply us video cards with those extensions. Incomplete list of video cards supporting these extensions: https://web.archive.org/web/20090112210259/http://www.xerxys.info/index.php?title=VESA SciTech released their UniVBE/Display Doctor which added modes via software, worked great on various S3 Trio chipsets, and eventually became freeware. It can be found on ftp://cyberia.dnsalias.com/pub/filebase/freedos/FILES.HTM along with some other DOS utilities.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Posted: 12/9/2020 2:56 PM
(Edited: 6/4/2022 4:52 PM)
Quote
feos
Site Admin, Skilled player (1254)
Joined: 4/17/2010
Posts: 11475
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
NES TAS of 2011
Keylie fixed the windows build of PCem-single-threaded https://yadi.sk/d/jVBaAadea3LI1w
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Posted: 12/10/2020 5:03 PM
(Edited: 6/4/2022 4:52 PM)
Quote
slamo
Reviewer, Expert player (2435)
Joined: 5/21/2013
Posts: 414
DS TAS of 2022 Computer TASer of 2016 Computer TAS of 2016 Computer TASer of 2013 Computer TAS of 2013
Here's what I've got for early 90s. It's ready to test, and it has very easy instructions to get you set up within a few minutes. If you don't have a collection of roms for PCem, you should get one and put it in the roms folder. https://drive.google.com/file/d/1KF5WPXgZTHVQL4UV8EmHlxP6Fag_BTot/view?usp=sharing Games I've tested in it: Monster Bash: Runs perfectly, emulates the digital sound effects correctly with EMS active. Terminal Velocity: This one will probably end up getting TASed on the late 90s config, but it runs very nicely. DOOM: Synced the current DOOM submission in it, no problems here. One Must Fall 2097: This game's speed is tied to the CPU speed. It runs way too fast on a Pentium at default settings, but there's an in-game setting where you can lower the speed and this makes it playable.
Posted: 12/10/2020 5:12 PM
(Edited: 6/4/2022 4:52 PM)
Quote
Nach
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
slamo wrote:
Terminal Velocity: This one will probably end up getting TASed on the late 90s config, but it runs very nicely.
We should probably have some rules along the following lines: Games released until 1989-12-31 should be played on 80s machine. Games released from 1990-01-01 to 1994-12-31 should be played on early 90s machine. Games released from 1995-01-01 to 1999-12-31 should be played on the late 90s machine. If a game was originally released in one time frame, but is using official patches or secondary release from a later time frame, it can be played on machine in either time frame. However, if the patch or secondary release requires features of the later time frame, then obviously it should be played in the later one.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Posted: 12/10/2020 8:47 PM
(Edited: 6/4/2022 4:52 PM)
Quote
feos
Site Admin, Skilled player (1254)
Joined: 4/17/2010
Posts: 11475
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
NES TAS of 2011
If a config from a different era appeals better to official requirements of the game than its actual time-wise era, that means it's a legitimate environment for that game too. I'd allow both in such cases.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Posted: 12/10/2020 8:54 PM
(Edited: 6/4/2022 4:52 PM)
Quote
Nach
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Agreed.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Posted: 12/11/2020 3:42 AM
(Edited: 6/4/2022 4:52 PM)
Quote
DrD2k9
He/Him
Editor, Judge, Expert player (2213)
Joined: 8/21/2016
Posts: 1090
Location: US
Arcade TAS of 2023 Exotic platforms TASer of 2020 First edition TAS of 2020 Gameboy TAS of 2020 Exotic platforms TASer of 2019 Computer TASer of 2017
First thought: Many PC games (at least in the 90s) were released with some form of documentation--either in the manual, or on the game's packaging itself--that provided minimum and/or recommended system specifications. If the game being TASed included this form of minimum/recommended specs, those should be settings of the emulated system regardless of year of release. Second Thought: While the idea of 3 major generalized settings that should cover most games definitely makes things simpler, it also goes somewhat contrary to the way things are currently with JPC-rr as the only effective method of TASing DOS. Current/JPC-rr method: Essentially, in games where the speed of gameplay itself is affected by the CPU speed, the emulated speed is limited to speeds available at the time of the game's release. If ONLY loading times were affected by CPU speed, any emulated speed is allowed as it doesn't affect gameplay itself. Unfortunately, this presents a dilemma with the '3 Generalized Settings' approach. 1) If the generalized setting is from somewhere in the middle of the era, latter games in that era will be emulated slower than for systems they were released. 2) If the generalized setting is from the near the end of the era, some games from early in the era may be emulated at much more rapid speeds than systems for which they were intended. 3) Either of these effectively allows for games to be played outside of the CPU speed limitations that are currently imposed on DOS runs created in JPC-rr. Regarding #1 above, if the later year releases of a given era are allowed to be TASed with the settings of the next highest era, this again could result in the game running at significantly faster CPU speeds than intended. Regarding #2 above, this would likely affect 80's era games more than 90's era(s), as a comparatively greater percentage of 90's era games have gameplay speed tied to real time as opposed to CPU speed. For reference: CPU speeds in the 80's ranged from under 10mHz up to 33mHz. Meaning speeds could be up to 3 times faster for an early released game played at end-of-era settings. CPU speeds in the early 90's (1990-1994) ranged from around 20mHz up to 200+mHz. Meaning speeds could be up to 10 times faster for an early released game played at end-of-era settings. CPU speeds in the late 90's (1995-1999) ranged from around 150-200mHz up to 1GHz. Resulting in speeds which could be up to 5+ times faster for an early released game played at end-of-era settings. TLDR:The idea of 3 generalized settings sounds like it should be effective enough. However, looking at the rapidity of how quickly CPU speeds increased over the years, shows that a large discrepancy in CPU speeds still exists from the beginning to end of each of the three noted eras. In the for what it's worth category: I understand the desire for accuracy/authenticity of emulated systems for TASing. This desire is what has driven both previous and current discussion about PC emulation settings. However, when it comes to TASing PC/DOS games, I feel we also need to consider that one core concept of TASing is to show superhuman ability. Given that real humans are speedrunning some of these games on real systems with MUCH higher than intended specs or on unthrottled emulated systems; it is theoretically possible that a human could outmatch a TAS which is forced to be limited to release-date specs. (I'm actually wondering if this will be the case for King's Quest 6, which I've done some basic TAS work on--the RTA community uses an unthrottled emulator which affects movement speed at the highest in-game speed settings). If this occurs, then the TAS is only partially superhuman: 1) If the human is forced to run on native specs, then the TAS would be superhuman. 2) But if the human's unthrottled run is compared to the TAS, the TAS may no longer appear superhuman. So considering both superhuman play and the concept of fastest completion, I personally have no problem with TASes of DOS games having no CPU speed restrictions at all. Even from the perspective of obsoletion in TASing, I'd be fine with a higher CPU speed run obsoleting a lower CPU speed run even when CPU speed affects gameplay aspects of the TAS. For example: If the highest CPU setting that one TAS author is able to complete a game is 100mHz, and the submission is published; then another author comes along and is able to beat the same game at 300mHz speed resulting in a faster run. I feel that being able to finish the run using 300mHz speed when other's can't shows greater TASing ability than the author using 100mHz speed. Obviously this would only apply to situations where the CPU speed affects gameplay itself and loading time is disregarded. I realize there may be many in the community who would disagree with this particular perspective, and I realize that this perspective is unlikely to result in changes to the current rules for JPC-rr or for the rules ultimately created for PCem. I offer it mainly as a way of documenting that this is a perspective that exists in the community.
Posted: 12/11/2020 6:17 AM
(Edited: 6/4/2022 4:52 PM)
Quote
slamo
Reviewer, Expert player (2435)
Joined: 5/21/2013
Posts: 414
DS TAS of 2022 Computer TASer of 2016 Computer TAS of 2016 Computer TASer of 2013 Computer TAS of 2013
You definitely raise some good points, and I want to clear something up. I have been under the impression, and I strongly believe this should be the case, that the 3 setups are provided purely for convenience so that it's much easier for people to jump right into a working DOS machine, rather than requiring people to use one of these setups in order to have their TAS accepted. I've even made instructions on how to make your own configuration. The 3 packages should be viewed as more of a guideline than a rule. As for suitable CPU settings, personally I think the current way it's handled with JPC-rr is fine. I guess this discussion has already been done before, so I don't want to get into it too much here, but I don't think running a game on unintended specs is "more superhuman" (at least it doesn't impress me that much), and if RTA runners want to run games on silly settings, then that shouldn't affect our decisions. I think limiting it to in-game speed settings is probably a good place to draw the line if we want the games to be run authentically.
Posted: 12/11/2020 8:46 AM
(Edited: 6/4/2022 4:52 PM)
Quote
Nach
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
The idea behind having 3 machines is mainly for convenience as slamo has said. For games where there is absolutely no information regarding requirements you really have to go based on when it was released. Also even when we do have recommended requirements, PCem doesn't necessarily offer that exact setup. Sometimes the requirements will also not be all encompassing. Therefore having a preset goto system for the era is helpful. As for the machines I suggested, I purposely suggested things which lean towards the high end of the era so they're capable of playing anything, but not so high end that it should seem ridiculous for most of the games of the era. If you have a different suggestion which you believe is better, we're certainly open to reviewing it. Also at least for the 90s, the games at that point understood the existence of shifting clock speed and more powerful CPUs, and nearly all those games were designed to self-adjust to the speed of the computer. They should run well on a machine which wasn't top of the line when they came out, as well as machines that would be out a year or two later. Then the only real difference at that point is loading times, and for TASVideos purposes of judging this sort of thing, that's not actual gameplay. Lastly, we also need to consider the needs of the judges and encoders. Having players just choose any machine randomly is going to make a judge's life miserable, as they'll need to put in a lot of work to get the same setup and get things to sync. Accepting a drive image from a player is problematic, because they could hide something in there which affects game play, and it will be difficult for a judge to be aware of it. Using a preset machine helps keep things simpler and verifiable. We want to keep things as consistent as possible where players of a particular game use the same setup each time, not constantly changing it between each run. We could have a discussion before each first run of a game is made and if someone suggests a more suited machine, our judges can put something together to ensure it is done without any underhanded activity, and provide a consistent setup. But this could get cumbersome. If you have better ideas how we could meet these goals, they are most welcome.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Posted: 12/11/2020 4:21 PM
(Edited: 6/4/2022 4:52 PM)
Quote
slamo
Reviewer, Expert player (2435)
Joined: 5/21/2013
Posts: 414
DS TAS of 2022 Computer TASer of 2016 Computer TAS of 2016 Computer TASer of 2013 Computer TAS of 2013
Here's what we've got for a late 80s config, thanks to Dacicus for this one. It has the same instructions as the early 90s machine I posted earlier. https://drive.google.com/file/d/19fLFt5iaRRnldGPLPtAi8YlM4mV_QOkS/view?usp=sharing We've tested this one quite a bit. EGA, CGA, and VGA video modes all seem to work fine. ZZT, which actually didn't run in JPC-rr, plays perfectly. I also tried Prince of Persia with both Adlib and Sound Blaster and they both work.
Posted: 12/12/2020 9:28 AM
(Edited: 6/4/2022 4:52 PM)
Quote
feos
Site Admin, Skilled player (1254)
Joined: 4/17/2010
Posts: 11475
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
NES TAS of 2011
To document this problem: 
<slamo> not sure how we should handle hard drive space in the late 90s config...
<slamo> some of the games with FMVs have huge install options, and i don't know if we should support that
<slamo> for Fallout, installations range from 3 MB to 645 MB
<feoss> looks like a few things will have to be left to the user to finish the config (probably cpu speed too for example)?
<feoss> or we provide something that should be enough, it compressed well after all. tho I forgot if hdd size affects libtas savestate size
<slamo> it affects savestate size and speed
<slamo> hard drive size is not something a user can easily config, they would have to make another hard drive image
<slamo> or, we can offer 2 late 90s configs, one with a 200 MB hard drive and one with a 2 GB or something
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Posted: 12/13/2020 4:19 AM
(Edited: 6/4/2022 4:52 PM)
Quote
slamo
Reviewer, Expert player (2435)
Joined: 5/21/2013
Posts: 414
DS TAS of 2022 Computer TASer of 2016 Computer TAS of 2016 Computer TASer of 2013 Computer TAS of 2013
I'm fairly sure we can reasonably do a 1 GB hard drive. I fooled around with it in libTAS with Quake and Carmageddon, savestates/loadstates take around 0.2 s (this is on a 10 year old laptop) and are around 10 MB. Sounds good?
Posted: 12/13/2020 8:04 AM
(Edited: 6/4/2022 4:52 PM)
Quote
Nach
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Sounds good. Just want to check, PCem supports juggling CDs during play, right? Some late 90s games have 4+ CDs to them.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Posted: 12/13/2020 3:25 PM
(Edited: 6/4/2022 4:52 PM)
Quote
slamo
Reviewer, Expert player (2435)
Joined: 5/21/2013
Posts: 414
DS TAS of 2022 Computer TASer of 2016 Computer TAS of 2016 Computer TASer of 2013 Computer TAS of 2013
PCem supports that, you can right-click the screen to bring up a menu where you can change the image. However, this menu bugs out if you're using PCem via libTAS so there's currently no way to use it during a TAS. There will have to be some alternative method if we want to swap CDs during a TAS.
Posted: 12/13/2020 3:30 PM
(Edited: 6/4/2022 4:52 PM)
Quote
Nach
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
You could in theory add a CD drive for each CD and put one in each, and this technique is good up to 23 CDs (I think the largest game is 14 CDs or so). However, I don't think DOS games are able to scan all CD drives for the appropriate files. They have one configured up front, and then keep checking that one. If the game is able to pause and resume at the CD swap point, you can change the config or use the DOS assign command to swap a CD drive over. However, that's probably rare for most of those multi-CD games as well.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Posted: 12/13/2020 5:41 PM
(Edited: 6/4/2022 4:52 PM)
Quote
keylie
He/Him
Editor, Emulator Coder, Expert player (2840)
Joined: 3/17/2013
Posts: 392
SNES TAS of 2023 PC TASer of 2020 PC TAS of 2020 TASer of 2019 PC TASer of 2019 First edition TAS of 2019 PC TAS of 2019 TASer of 2018 PC TASer of 2018 First edition TAS of 2015 First edition TAS of 2014 Computer TAS of 2013
I could try fixing libTAS to allow right click to be used on PCem. However, that will look a bit awkward. Until then, using libTAS + PCem was equivalent to bringing TAS tools to PCem. but with CD swap, you would need to make mouse inputs to bring up the contextual menu and browse through it to change the cd. It means it takes some actual frames to do that. So it becomes TASing an emulator and not TASing an emulated game, which has some consequences with TAS length I guess (does PCem pauses when the contextual menu is opened?) There could also be some desyncs regarding where the contextual menu will appear, and I guess the contextual menu won't be part of the encode. So that raises several issues actually.
Posted: 12/13/2020 5:51 PM
(Edited: 6/4/2022 4:52 PM)
Quote
feos
Site Admin, Skilled player (1254)
Joined: 4/17/2010
Posts: 11475
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
NES TAS of 2011
Can any kind of internal queue be added to PCem, with a command (a hotkey?) to go over them and load the next one in the list, like that menu would load from a path?
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Posted: 12/13/2020 5:52 PM
(Edited: 6/4/2022 4:52 PM)
Quote
slamo
Reviewer, Expert player (2435)
Joined: 5/21/2013
Posts: 414
DS TAS of 2022 Computer TASer of 2016 Computer TAS of 2016 Computer TASer of 2013 Computer TAS of 2013
A possible solution for the future could be to program some kind of disc swapping hotkeys into the PCem TASVideos build. Like the hotkey would be <key>+1 through 9, and the file paths for CDs 1 through 9 could be enumerated in the .cfg file.
Posted: 12/13/2020 5:57 PM
(Edited: 6/4/2022 4:52 PM)
Quote
keylie
He/Him
Editor, Emulator Coder, Expert player (2840)
Joined: 3/17/2013
Posts: 392
SNES TAS of 2023 PC TASer of 2020 PC TAS of 2020 TASer of 2019 PC TASer of 2019 First edition TAS of 2019 PC TAS of 2019 TASer of 2018 PC TASer of 2018 First edition TAS of 2015 First edition TAS of 2014 Computer TAS of 2013
Hotkeys seem like a much better solution, if it is fine modifying PCem even more for TASing
Posted: 12/13/2020 6:01 PM
(Edited: 6/4/2022 4:52 PM)
Quote
feos
Site Admin, Skilled player (1254)
Joined: 4/17/2010
Posts: 11475
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
NES TAS of 2011
Looks like we don't have a choice. I think having as many CD paths as the user needs, in the config file, would be a good approach so that PCem would load the paths, but only make use of them once the key is pressed. If it's a limited set of keys (0-9), we'd be limited in how many CDs we can use, so I feel having just "next CD" is enough, since the image paths would be in a certain order in the config file (would "previous CD" ever be needed?) Since it's a string field, we could provide several paths using a separator, instead of having several vars, each responsible for a single CD. Also won't the same approach be needed for floppy disks as well?
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
1 2 3