1 2 3
Posted: 6/3/2022 8:16 PM
(Edited: 6/4/2022 4:52 PM)
slamo
Advisor, Expert player (2833)
Joined: 5/21/2013
Posts: 421
DS TAS of 2022 Computer TASer of 2016 Computer TAS of 2016 Computer TASer of 2013 Computer TAS of 2013
Dimon12321 wrote:
Doesn't it correlate with what you and feos responded to me earlier about non-deterministic Windows installation? So, if we use only one specific distribution, then we get it working fine, right?
Yup, we'll tell you the Windows version and the SHA1 of the CD to make sure everyone has the same setup.
How will it all work? 1. From what moment should the actual movie begin? Can put an installed game (folder + .exe) on a PCem hard drive and start a libTAS movie recording where we simply surf the explorer up to the game .exe, launch it and go on with the game as usual? Or should we begin with mounting a game image with, let's say, Daemon Tools and install it live, then launch it? - Can it be a separate movie? 2. What about game distributions? If we record us installing the game, will it be ok to show a CD key for a game? Specific distributions, that free you from using it or keeping a game disk in the reader to make it work, are actually more stable and convenient.
1. All modifications to the hard drive MUST be done within a libTAS recording, otherwise you introduce more variables that could cause desyncs. You can use installation discs, or we have a reliable method of putting files onto an ISO and you can copy it onto the hard drive within libTAS. And yeah, installation can be a separate verification movie, kind of like with SRAM for other emulators. 2. We definitely wouldn't want CD keys being distributed through movie files. Maybe we could have a discussion about allowing modified versions in this case.
I guess OpenAL installation should be added to the config. Or should it be included into the game installation part? Visual C++? Even though I can think of 2005+ distributions only, maybe elder versions existed that had to be installed back in the day.
What requires these? And would they not be included with the game?
Posted: 6/3/2022 8:28 PM
(Edited: 6/4/2022 4:52 PM)
Dimon12321
He/Him
Editor, Reviewer, Experienced player (805)
🇷🇴 Romania
Joined: 4/5/2014
Posts: 1484
Location: 🇷🇴 Romania
NES TAS of 2024
slamo wrote:
What requires these? And would they not be included with the game?
I'll be frank here. Knowing my dummy skills, I'd wish to have an installation movie doing something excessive rather than not doing something that's required =P
TASing is like making a film: only the best takes are shown in the premier. https://xkcd.com/3246/
Posted: 1/13/2023 9:14 PM
Post subject: Early 80s config?
slamo
Advisor, Expert player (2833)
Joined: 5/21/2013
Posts: 421
DS TAS of 2022 Computer TASer of 2016 Computer TAS of 2016 Computer TASer of 2013 Computer TAS of 2013
Thanks to Sand's recent Mixed Up Mother Goose submission, it brought to our attention the Tandy 1000 SL/2. We are missing an early 80s config and I think this would be perfect for it. It has MS-DOS 3.30 built directly into the ROM, so it doesn't require any bootable drive to work. It should be able to run any game that can run directly off the floppy, and I've confirmed it also works with the self-booting IBM PC game disks. This would be a much simpler setup than the other configs, essentially only needing the config file and the game disk(s). Here's what I'm thinking, based on Sand's config and the SL/2's specs: Machine: [8086] Tandy 1000 SL/2 CPU: 8086/8 MHz Memory: 512 KB Display device: Built-in video Sound device: None (would just be PC speaker) HDD: None (unnecessary with ROM) FDD1: 3.5" 720k FDD2: 5.25" 360k (did not come with this, but can be added) The only thing we would need to supply is the .cfg file. There is some NVR (/nvr/tandy.tandy1000sl2.bin) but it isn't really necessary for what we're trying to do, and can be deleted.
Posted: 8/19/2023 9:27 PM
feos
Emulator Coder, Site Admin, Skilled player (1284)
Joined: 4/17/2010
Posts: 11905
NES TAS of 2011
Wiki: EmulatorResources/PCem/Windows#WindowsXpInstallationMovie
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: 9/23/2023 7:20 AM
Post subject: Screen tearing and broken v-sync
InputEvelution
She/Her
Editor, Judge, Moderator, Player (231)
Joined: 3/27/2018
Posts: 252
Testing out the PCem Windows XP config, a number of games I've tested have had an issue with screen tearing. This seems to occur regardless of the game's performance, though altering the monitor refresh rate can sometimes affect how the tearing presents itself visually (for instance, raising it from 60Hz to 100Hz made the tearing appear more as a slowly moving scanline in high-performing areas of one game). The games themselves didn't have any options to turn off v-sync, but there was an option in the 3dfx Advanced Features menu. Turning this on revealed a larger problem; 3dfx D3D v-sync is completely broken, causing flickering bars to appear across the screen that make gameplay completely unwatchable (and also have some strange z-buffer interactions). My best guess is that this is some sort of driver bug, though I've only been able to find two pages that sound like they might be addressing the same issue (listed below). https://discourse.libsdl.org/t/how-i-fixed-my-voodoo-3-problem-ot-sorry-hoping-it-helps-other-libsdlers/4094 https://www.3dfxzone.it/enboard/index.php?topic=59 I've already mentioned all of this on Discord, but have made a forum post about the issue at feos's request.
Posted: 5 days ago
(Edited: 5 days ago)
feos
Emulator Coder, Site Admin, Skilled player (1284)
Joined: 4/17/2010
Posts: 11905
NES TAS of 2011
feos wrote:
I'm having some SERIOUS problems with reporting internal framerate of the machine to the user as a feature of PCem st-2. Kilaye figured out how to report it for SVGA which our 3 approved configurations use, but the oldest config is Tandy which has in-built video and it's a nightmare to determine the framerates for without in-depth knowledge of how the machine works. Reporting it for all machines is just not realistic, we don't have the required expertise for that. So it looks like outside of SVGA, users are gonna have to figure out which framerate they should use on their own. And I'm unlikely to be able to verify that it's correct, unless they explain it very thoroughly. Not that GPU framerate is absolutely critical to match in the movie, framerate in the movie is more about how often you wanna be sending inputs, less so how often you wanna see video updates (but still). So it's unlikely to affect integrity of the emulated environment. But not knowing which rate to set is just not super convenient, unless you know your game can force it to something known.
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
1782159632