Experienced Forum User, Published Author, Player
(59)
Joined: 9/15/2023
Posts: 71
feos wrote:
Technoturnovers wrote:
There are drivers in MAME, such as Pong and Breakout, that do not require any ROMsets in order to run- you just use MAMEUI or the commandline to launch the game directly, ie, 'mame pong', and it just works. BizHawk, however, naturally expects one to open a ROM in order to want to play a game- is there any way to get around this?
Didn't know about this. What happens if you give it an empty archive named pong?
It just throws the exception below, then asks me to choose a file from the archive (like when you open a MAME ROMset without having the required other sets bundled).
System.ArgumentOutOfRangeException: InvalidArgument=Value of '0' is not valid for 'index'.
Parameter name: index
at System.Windows.Forms.ListView.ListViewItemCollection.get_Item(Int32 index)
at BizHawk.Client.EmuHawk.ArchiveChooser.ArchiveChooser_Load(Object sender, EventArgs e)
at System.Windows.Forms.Form.OnLoad(EventArgs e)
at System.Windows.Forms.Form.OnCreateControl()
at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
at System.Windows.Forms.Control.CreateControl()
at System.Windows.Forms.Control.WmShowWindow(Message& m)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.Form.WmShowWindow(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
Experienced Forum User, Published Author, Player
(59)
Joined: 9/15/2023
Posts: 71
I recently managed to construct a functional TASing environment for Baby Pac-Man (details and instructions linked here), and other electromechanical pinball/video arcade games supported by Visual Pinball and Visual PinMAME by extension, using PCem running under libTAS; however, having managed to do that, now I feel like it raises many questions regarding how to categorize game versions, 'emulation accuracy' regarding the simulated pinball table, and etc. I might just be overthinking all this, but here goes.
Can a TAS of a simulated pinball table be considered an actual TAS of the game itself for cataloging purposes, or is it only a TAS of that particular simulated table? If a TAS of a simulated table is considered a "real" TAS of the actual game, should different versions of the reproduced table be considered different game versions?
What is considered "accurate emulation" for a simulated pinball table? (In this case the Baby Pac-Man table is accurate in physics as far as I can tell, but that might not be the case for all tables).
How do deal with the difficult reproduction/syncing workflow?
To elaborate: files required for pinball simulators and VPinMAME cannot be found in the same places as ordinary ROM and emulator resources. The tables themselves are particularly problematic, as in addition to containing the original manufacturer's copyrighted cabinet artwork and thus being unlinkable, they also contain the original work in physics parameters and scripting by the person who performed the recreation effort. As such, rehosting these tables is not allowed, and the original sites that host them require registration in order to download files. Basically, finding the required files independent of any direct aid (which would be prohibited by site rules) is a hell of an adventure, to say the least.
I also have another more specific question regarding Baby Pac-Man: namely, what is a suitable TASing goal? To the best of my knowledge, Baby Pac-Man does not have a killscreen, or at least, no documented killscreen. This leaves a few options for a goal:
Hardest cycle: In Baby Pac-Man, there are only 3 unique mazes; however, at a certain point some of the inner maze walls become invisible, and then eventually they all become invisible, thus defining the point at which the game has reached its hardest difficulty and exhausted all (maze-related) content. However, this goal is not preferable, as it means that time saved by acquiring energizer pellets in the pinball portion becomes highly tenuous, if it saves any time at all, and if the pinball portion is never entered then that means there's no point in not just emulating this via MAME or PinMAME running standalone.
Score attack: In Baby Pac-Man, the score counter can reach up to 10,000,000 points before rolling over. This offers some interesting TASing potential, allowing for more time spent in the pinball portion for acquiring energizers and advancing the fruit. However, it also risks meeting the goal before all unique content has been exhausted, as the fastest way to reach high-score could potentially entail not reaching the final, all invisible walls maze.
"100%"/All bonuses: There are three types of bonuses in Baby Pac-Man; up to 4 Energizers per stage, the Banana as the top-tier fruit (requiring advancing the fruit 7 times), and a maximum tunnel speed of 8 (also requiring advancing the speed 7 times). As such, it is possible to construct a goal of reaching the hardest stage while maxing tunnel speed, acquiring all energizers, maxing out the fruit type, and finally collecting at least one fruit per stage, thus offering a balanced combination of pinball play and maze play. This is the option I'm currently leaning towards, but it also could potentially be considered arbitrary, hence asking for judge input.
Experienced Forum User, Published Author, Player
(59)
Joined: 9/15/2023
Posts: 71
feos wrote:
Technoturnovers wrote:
Is it possible to load MAME builtins in MAMEHawk, main examples being TTL games like Pong and Breakout? Because I find the idea of TAS submissions that have an empty or N/A ROM field greatly amusing
I don't understand.
There are drivers in MAME, such as Pong and Breakout, that do not require any ROMsets in order to run- you just use MAMEUI or the commandline to launch the game directly, ie, 'mame pong', and it just works. BizHawk, however, naturally expects one to open a ROM in order to want to play a game- is there any way to get around this?
Experienced Forum User, Published Author, Player
(59)
Joined: 9/15/2023
Posts: 71
Playing Back The Verification MovieStep 0: Setting up PCem/libTAS
Before anything else you need to setup PCem and successfully run the Windows XP installation verification movie, as detailed on the wiki here. Beyond this no further changes to the windowsxp.cfg file or pcem.cfg file should be necessary, beyond changing the mounted ISO as needed.
In addition, you will also want to want to download create_iso.sh, which we will be using to create the ISO with all of our required files and verifying its integrity later; as a prerequisite, make sure you have the program xorriso installed on your chosen Linux distribution.
Step 1: Required Files
Unfortunately, these files are not ones you will be able to find on the same sites as standard ROMsets, and I mostly won't be able to give any names or links due to the rules on copyrighted material; what information and details I can provide will be linked below; hashes for all the files are listed on the Verification Movie's userfiles page.
My Baby Pac-Man Verification Movie, uploaded to userfiles here.
Visual PinMAME 1.52, available from SourceForge here.
Filename: vpinmame_152.zip
Site A is a popular community and forum for enthusiasts of virtual pinball cabinets and simulators, which I am not allowed to link to or name due to site rules. You will need to register there in order to obtain the following files:
s3250u3.zip ("Sound Samples")
Contains many WAV files dated 2004-8-31.
vpvbs3_58.zip ("VBS Scripts 3.58")
Contains many VBS files dated 2021-12-22.
babypac.zip ("Baby Pacman - ROM - babypac.zip")
This version of BABYPAC is not from the standard MAME ROMset, and attempting to use the standard version of BABYPAC.ZIP will not work.
Site B is another popular community and forum for enthusiasts of virtual pinball cabinets and simulators, which I am also not allowed to link to or name due to site rules. You will need to register there in order to download the Visual Pinball 8 table we will be using.
Create a clean working directory, preferably in a place accessible to your Linux system; the name of this directory does not matter, as it is the contents that will end up in the final ISO.
Extract the contents of "52796-Baby_Pacman.zip" into your working folder.
Create a folder named "Visual Pinball", and extract the contents of "VPinball_8.1.zip" into it. Create two additional folders within the "Visual Pinball" folder, named "Scripts" and "VPinMAME" respectively.
Extract the contents of "vpvbs3_58.zip" into "{WORKINGDIR}/Visual Pinball/Scripts/".
Extract the contents of "vpinmame_152.zip" into "{WORKINGDIR}/Visual Pinball/VPinMAME/".
Copy, but do NOT extract, the file "s3250u3.zip" to "{WORKINGDIR}/Visual Pinball/VPinMAME/samples/".
Copy, but do NOT extract, the file "babypac.zip" to "{WORKINGDIR}/Visual Pinball/VPinMAME/roms/".
Once done with these steps, run "create_iso.sh" and specify the FULL PATH of your working directory as the target to be made into an ISO. Your create_iso.sh output should match the the output log shown on the Verification Movie's userfiles page, and you should now have the file "TAS_CD.iso".
From here, you can now set edit the Windows XP CFG file to mount TAS_CD.iso, and run the verification movie in the same way as the Windows XP Installation movie to create your SRAM state. The verification movie creates a shortcut in the startup folder in order to automatically start Baby Pac-Man as soon as login occurs.
Another post on my plans for this game, as well as additional details on the workings of the verification movie, is coming soon (tomorrow, probably, it's getting late).
Experienced Forum User, Published Author, Player
(59)
Joined: 9/15/2023
Posts: 71
Introduction and Technical BasisBaby Pac-Man is a hybrid Solid-State Pinball and Video Arcade game, developed by Bally Midway in 1982 and released just 9 months after Ms. Pac-Man. It is notable for being one of the few unique fully fleshed-out games of its kind, its extreme inaccessibility to home players, and its brutal difficulty (being the consensus hardest Pac-Man game of all time). However, despite its hybrid nature, it is possible to TAS; PinMAME is a fork of the original MAME, aiming to be an emulator designed to emulate the electronic components of pinball games, including LED and DMD (Dot-Matrix Display) screens, scoring, and etc. Using its component application and COM library, VPinMAME, it is possible for PinMAME to communicate with a Pinball simulator to automatically control the PinMAME hotkeys that PinMAME uses to represent communication functions of the physical element of the pinball cabinet. This library configuration is extremely crude, however, being just above using some form of macro script to manually transmit keyboard keys from the Pinball Simulator to PinMAME; PinMAME and the Simulator run as separate windows and processes, rendering them impossible to TAS using a program such as Hourglass. However, there is another way.
The most popular and well-supported Pinball Simulator project is Visual Pinball, having been released in alpha form in the year 1999. VP and MAME are both VERY old programs, and while the modern versions of VP and VPM don't run on Windows XP, there are older versions that do, and have very good support for Baby Pac-Man's ROMset and have a compatible and workable table. The versions we're targeting to run under PCem+libTAS are VP 8.1 and VPM 1.52, both being released circa 2005, with a recreated Baby Pac-Man table made in the same year. The table in question is visually crude, but totally functional and presents no real accuracy concerns. While programs from 2005 seem ancient, it's worth keeping in mind that the current standard and support PCem configuration emulates a system with hardware dating circa 1999, and it's only because VP and VPM are such basic, low-spec programs that they run at good performance at all.
Soon, I'm going to edit this post (or create a new post) with a full guide to creating the reproducible ISO file used to provide all required components to our cursed, jank setup, the verification movie that uses said ISO, and some other technical notes. In the meantime, however, have a preview in the form of some brief gameplay I encoded while testing the verification movie:
Link to video
Experienced Forum User, Published Author, Player
(59)
Joined: 9/15/2023
Posts: 71
Is it possible to load MAME builtins in MAMEHawk, main examples being TTL games like Pong and Breakout? Because I find the idea of TAS submissions that have an empty or N/A ROM field greatly amusing
Experienced Forum User, Published Author, Player
(59)
Joined: 9/15/2023
Posts: 71
Dacicus wrote:
Not enough Zelda, voting No.
Why did you choose Myst instead of one of the best CD-based Zelda games as the first(?) CD-i submission, btw? At around 1:40, it looks the wheel turns in the same direction despite you moving the cursor to different spots. Is there a point to moving the cursor?
Actually, the CD-i Zelda games ARE the best CD-based Zelda games by definition, because Nintendo never made any CD-based consoles- they skipped straight to Mini-DVD from the N64 to GameCube
Experienced Forum User, Published Author, Player
(59)
Joined: 9/15/2023
Posts: 71
Rejection reason is totally fair, I'm really just glad that some people saw my recording and liked it at all even if it ultimately wasn't good enough to get accepted. Honestly, if I had known about EZGames69's prior work on this before starting, I might have reconsidered my game choice entirely, but it is what it is, and I really can't be mad considering people have spent multiple years just to nail down a perfect run. That sort of effort just isn't in the cards for me unfortunately, I do not have NEARLY enough focus and dedication for that; at this point, the best I can hope for is getting added to Gruefood Delight, IMO. Thanks for the consideration
Experienced Forum User, Published Author, Player
(59)
Joined: 9/15/2023
Posts: 71
nymx wrote:
Technoturnovers wrote:
nymx wrote:
Got a question for you Technoturnovers. I've studied your inputs and it appears you are recording with a controller. Is this correct? If so...this can explain the reason why you are not able to easily manipulate the game's RNG.
I am not recording with a controller, I am recording with the keyboard. And effectively every keyboard button on the ZX Spectrum does something in this game due to its antiquated, spread-out control scheme, so I'm not able to use non-input keys to manipulate RNG even if the game polled such non-input keys for the seed to begin with. See also EZGames69's recording, which uses basically the same amount of keys as mine.
Ok, so you are using the "TAS Studio Editor"?
My workflow is as follows: I stay in pause and record mode, focusing the main emulator window, and holding down the desired game inputs using my ordinary binds and hitting frame advance to record them. When I need to go back and rerecord, or edit multiple different inputs in bulk, I go back to the TAStudio window and use the piano roll for finer control than merely using the load branch/savestate hotkey does. My workflow is already very optimized, and changing it isn't terribly relevant for the purposes of RNG manipulation in this game.
Experienced Forum User, Published Author, Player
(59)
Joined: 9/15/2023
Posts: 71
nymx wrote:
Got a question for you Technoturnovers. I've studied your inputs and it appears you are recording with a controller. Is this correct? If so...this can explain the reason why you are not able to easily manipulate the game's RNG.
I am not recording with a controller, I am recording with the keyboard. And effectively every keyboard button on the ZX Spectrum does something in this game due to its antiquated, spread-out control scheme, so I'm not able to use non-input keys to manipulate RNG even if the game polled such non-input keys for the seed to begin with. See also EZGames69's recording, which uses basically the same amount of keys as mine.
Experienced Forum User, Published Author, Player
(59)
Joined: 9/15/2023
Posts: 71
Alright, I set up the RAM Watch, but current progress is NOT terribly promising. DigitalDuck was basically right that the RNG seed is effectively impossible to intentionally influence towards any given outcome, and while having access to the Fuel X-pos and Game Timer is useful in avoiding some small amount of repeat work in bruteforcing, scripting it is totally infeasible because the enemies just do NOT cooperate; any attempt to automate movement would just result in you ramming some random dick meteor or whatnot. And I still can't get fuel spawn RNG manipulation to amount to ANY real timesave, because enemy spawns are STILL a problem, attempting to RNG manipulate them just increases the luck factor by several orders of magnitude, and more often than not attempting to force the fuel to spawn at 128 or 136 actually just loses time over taking a longer route because of needing to hover to wait out the meteors passing by. The whole point of comparison here is EZGames69's stage 1 recording, but to be completely explicit here, sustaining anything CLOSE to that pace over the course of an entire run is impossible, for all intents and purposes. Fuel spawns at 128 and 136 need to be perfect in order to avoid losing time over further away spawns; they NEED to be fast and there has to be no enemies that will get in the way several seconds after the spawn occurs, or you WILL piss away all of your timesave waiting. EZGames69 said that he doesn't expect me to be any faster than his WIP, but the way enemy spawns work means that that level of perfect RNG is more or less required for spawns at 128 and 136 to work, period, no in-between.
Experienced Forum User, Published Author, Player
(59)
Joined: 9/15/2023
Posts: 71
Was it really necessary to wipe the original submission comments? Those can still be useful to other runners/TASers after all, and just because a submission doesn't get published doesn't mean that people might not still watch it in submission form
Experienced Forum User, Published Author, Player
(59)
Joined: 9/15/2023
Posts: 71
Oh, sick, yeah this should make things WAY easier. I'm actually in the middle of something else right now (Arcade Gorf), but I don't see that taking terribly long, so I'll try to take advantage of this soon.
Experienced Forum User, Published Author, Player
(59)
Joined: 9/15/2023
Posts: 71
CloakTheLurker wrote:
I started encoding runs from Gruefood Delight to replace encodes with rough quality and that have been taken down from YouTube.
Encodes I've uploaded so far:
You know, on the topic of the Somari submission, there are two things that kind of bother me in the rejection reasons: well, first of all, it's poorly optimized and I'm not disputing that, but this is a bootleg Sonic game, so it should have been judged off of the standard that Sonic submissions have (as far as I'm aware) always used of In-Game Time. And secondly, "This is probably a bad game choice."? Ehmmmm.... no? Even based off of the standards back then, Somari is an inherently notable and interesting NES game, even if it's a bootleg of dubious quality and polish. And I'm 99% sure that a properly optimized run could easily pass on today's site, but I have to wonder if that sort of opinionated comment on "bad game choice" might be a factor in turning people off who might otherwise record a run for it. Something to consider....
Experienced Forum User, Published Author, Player
(59)
Joined: 9/15/2023
Posts: 71
I tried the first stage again, forcing center fuel spawns, and I didn't gain any time. hhhhhhhhhhhhhurrrrrrgh. I literally entered the rocket at the exact same frame as I did in the current submission.
EDIT: To elaborate, a lot of that was because of bad enemy spawns, which are another RNG-based frustration, except this time I don't even know when the roll occurs for selecting the spawn location. The fastest route from the middle fuel spawn to the rocket has you go directly through a location where recently-spawned enemies will also be passing through, with absolutely no clearance to either side of them and forcing you to piss away time by waiting a hovering. The longer routes I take in the current submission actually allow me to largely avoid this issue, because I have MUCH more flexibility with where I choose to drop in to the lower part of the stage and being able to actually shoot enemies.
Experienced Forum User, Published Author, Player
(59)
Joined: 9/15/2023
Posts: 71
EZGames69 wrote:
For the record, I'm not really expecting you to be faster than my WIP. I'm mostly hoping you can use the same strategy I used, by spawning the fuel as close as possible to the ship, as that can save a ton of time. Actually trying to optimize those fuel spawns to be optimal every time is not something I'd expect anyone to do without a script of some sort.
Unless I'm drastically missing out on some key game mechanic here to guarantee spawn locations, spawning fuel as close to the ship as possible is really the issue- spawn time too, of course, but even just getting it to spawn at the middle island every time is a major obstacle even if you accept some seriously delayed spawns. Again, I did use RNG manipulation on every fuel spawn, I just mainly stopped at accepting getting the fuel closer to the player and/or rocket.
Experienced Forum User, Published Author, Player
(59)
Joined: 9/15/2023
Posts: 71
nymx wrote:
Ok...that helps. Please remember, this submission can be put on delayed. I would like to see this through. If you don't mind, please take a few weeks and see what you can do. I find that taking a segment of a game each day helps in keeping up the motivation. Perhaps a stage a day?
So are we in agreement for setting this to "Delayed'?
Well, see, that really does depend on the level of improvement that you want to see- because over 2000 rerecords in a single day is kind of a LOT, even for me. I could optimize Stage 1 to the level apparent in EZGames69's recording, and that would technically bring the entire recording up to known peak play since that level of RNG manip has only ever been demonstrated for, well, Stage 1. But if I seriously wanted to break the fuck out of this game, then I need scripting to do that, and the total lack of memory watch address for the fuel's current X-position is a major, MAJOR obstacle. If I did have memory watch and probably some more help from people more experienced in Lua scripting, then I could write a script that, between each fuelling, would thrust up and randomly spam left/right and reload the branch until the fuel spawns between a given desired range and by a certain desired deadline, but that's all contingent on me A: figuring out the memory address and B: successfully writing such a script.
Experienced Forum User, Published Author, Player
(59)
Joined: 9/15/2023
Posts: 71
nymx wrote:
So here is what I would like to do. Technoturnovers, can you please explain your methods of controlling RNG? This will help me to identify how much time it would require to redo any work.
Since I lack any relevant memory watch or prior reverse engineering effort, my RNG manipulation takes the form of randomly spamming all available controls (left, right, thrust, hover, and fire) between the last fuel entering the rocket and the next one actually spawning. This is visible as me constantly changing directions while I'm flying. Most of the time, I'm successful in getting the fuel to spawn closer than it would have otherwise with a dozen or couple dozen attempts; sometimes, this doesn't work out and it takes even longer, sometimes it REALLY doesn't work out and I end up needing to change my actual trajectory on my route outright. And I'm effectively never able to guarantee instant fuel spawns, and the required movements would probably end up wasting away that timesave anyways. For reference, EZGames69's honestly jaw-dropping first screen recording encompasses over two THOUSAND rerecords, I can only assume all done manually rather than with the help of a script. He says that he lost motivation to work on the project after that, and I can really only say, yeah, no shit lmfao, how did you even get that far in the first place?
So, if I end up getting rejected because of this, I honestly won't even be mad, it just is what it is really. But I'm not putting over 2000 rerecords solely into RNG manipulation for each individual screen of this game, because I value my sanity (ignore the fact that I TASed SMB Special).
Experienced Forum User, Published Author, Player
(59)
Joined: 9/15/2023
Posts: 71
EZGames69 wrote:
So I had actually worked on a movie of this back in Bizhawk 2.6.2 but got demotivated to work on it. The first rocket screen I tried to manipulate the fuel to spawn as close to the rocket as I could in order to save x movement time.
This first screen from a very rough estimate saved around 7 seconds compared to the first screen in this submission:
Link to video
Here's my abandoned bk2 file which completes the first two screens (although keep in mind I haven't tested to see if it syncs in BizHawk 2.9.1):
https://tasvideos.org/UserFiles/Info/638315980447033759
I just checked, and this movie doesn't sync on the latest version of BizHawk, the movements are totally screwed up. That might be down to more accurate tape loading times, although I'm certain that that would have knock-on effects as to the RNG seed as well. I actually did make use of RNG manipulation in my own recording, it's just that I didn't aim for perfect results (ie, always the closest fuel spawn) because RNG is really, REALLY stubborn in this game, and it always seemed to want to spawn the fuel in the same one or two locations unless I really went far off my intended route. As such, I just generally tried to make sure that the fuel spawned closeer to me than it would have otherwise. I'll still go back and see if I can make better RNG manipulation work, though.
EDIT: I managed to get close fuel spawns for all of the first screen/rocket, but with only a timesave of 26 frames (due to the spawns not being instant) and at the cost of desyncing the entire rest of the movie. This is definitely NOT a trivial task
Experienced Forum User, Published Author, Player
(59)
Joined: 9/15/2023
Posts: 71
EZGames69 wrote:
So I had actually worked on a movie of this back in Bizhawk 2.6.2 but got demotivated to work on it. The first rocket screen I tried to manipulate the fuel to spawn as close to the rocket as I could in order to save x movement time.
[snip]
https://tasvideos.org/UserFiles/Info/638315980447033759
Okay, I get that any gameplay can demonstrate improved optimization to have a submission be rejected, but it would kinda suck to have that happen because of one RNG-manip intensive screen of a WIP recording out of an entire 16 screen run, especially when said first screen could feasibly be grafted onto the whole recording and still sync for the rest of it. And I thought I was done 4 days ago, which is a real bruh moment, although I guess I'll see what I can do here.
Experienced Forum User, Published Author, Player
(59)
Joined: 9/15/2023
Posts: 71
scrimpeh wrote:
This was recorded on Windows XP Professional Service Pack 3, Version 2002.
And this is why I was hoping we could've ditched hourglass a decade ago.
Anyhow, this is a game I'm actually fairly partial to. Obviously the movement is quite simple, and even in six minutes, it kinda begins to drag on, but it's not too bad. I only wish there were more skips. Is it impossible to stand on the edge of the spikes at 4:52 in the encode?
Anyhow, I enjoyed this enough to vote yes. Keep it up, and huge props for actually having the patience to deal with hourglass.
It really wasn't that bad, it only crashed like a dozen times! As for that bit with the spikes, I was following along with harry9397's absolutely herculean 6:23 time recorded on SDA (https://speeddemosarchive.com/demo.pl?MightyJillOff_623), which is still the world record by a huge margin despite being 10 years old. That thought occurred to me too, but I'm certain that I wouldn't actually be able to jump high enough to get anywhere from that point so I decided not to try that. Thanks for watching
Experienced Forum User, Published Author, Player
(59)
Joined: 9/15/2023
Posts: 71
Alright, I've got some bad news:
- First, BizHawk PJM importing appears to be SUPER scuffed. It didn't populate the Core field in the header, so it just crashed when I tried to create the converted BK2 recording, and once I unzipped it and fixed the header, it appears that the conversion process has dropped all of the Start inputs, and probably more.
- Secondly, sync DOES appear to be BIOS dependent, as when I attempted to sync the recording in PSXjin with a BIOS other than the 1001 BIOS the movie was initially created with, it ate shit once it encountered the second menu selection within the game proper, and totally screwed up the timing at the second shooting segment as a result.
While none of this is impossible to overcome, these issues bring this strongly out of the realm of "easy job", and it would probably take enough time and effort that I would end up yoinking primary authorship of the submission all things considered. As such, I can't really suggest leaving this submission open indefinitely when I can't really offer any concrete timeline for when I'm gonna get this movie remade to modern emulator requirements if ever, and if I do end up doing it it would probably be better off as a new submission. I think this one's gonna go back to gruefood, unfortunately
Experienced Forum User, Published Author, Player
(59)
Joined: 9/15/2023
Posts: 71
Noting for posterity that it's VERY helpful if you make sure to list your ROM version with proper scene naming scheme, the group to which said naming scheme complies if relevant, and the hashsums of all of said files; this particular game fortunately doesn't appear to have multiple releases to worry about, but I would really rather be sure, especially when I have to deal with a THREE DISC (!!!) game taking up valuable space on my hard drive for the purposes of converting a TAS recording.
