Joined: 8/3/2008
Posts: 157
Location: The Land Down Under
Obviously this has had speedruns of it in the past with especially built emulators. The question is, given that the current records are known to not be optimal, would they be beatable using a current version of DosBox+rr/JPC-rr?
I've also been toying with the idea of doing an IDCLIP run (not to submit to the site, but just for the sake of it). Would DB or JPC be better to use right now for making a TAS of this game?
Obviously this has had speedruns of it in the past with especially built emulators. The question is, given that the current records are known to not be optimal, would they be beatable using a current version of DosBox+rr/JPC-rr?
Both should in theory work, but:
* JPC-RR is very slow emulating this game
* AFAIK, nobody has played through DOOM II using JPC-RR, so one can't be absolutely sure it is beatable (but I would expect it be beatable).
* General MIDI music in DOOM II doesn't work all too well (newest mainline JPC-RR revisions do emulate it, but it is barely possible to encode runs using it) so one would have to use worse-sounding FM music (granted not many have even heard what DOOM II sounds like with MIDI music).
* DosBox+RR is not sync-stable between different computers (and not approved by the site for this reason)
* Back when I was trying DosBox+RR, I couldn't even get basic rerecording to work (loadstate crashed or locked up the emulator).
So you are welcome to try and it should be possible, but it would take quite hard-core TASer to pull it off.
ThMrksman wrote:
I've also been toying with the idea of doing an IDCLIP run (not to submit to the site, but just for the sake of it). Would DB or JPC be better to use right now for making a TAS of this game?
I think that would be boring (just turn and run towards exit).
edit: version -> revision (since those aren't releases but VCS revisions)
* General MIDI music in DOOM II doesn't work all too well (newest mainline JPC-RR versions do emulate it, but it is barely possible to encode runs using it) so one would have to use worse-sounding FM music (granted not many have even heard what DOOM II sounds like with MIDI music).
Some people might think the FM music sounds better for some of the songs (e.g. to me, the titlescreen tune sounds downright awful in MIDI).
From another point of view, they're the one version that everyone has heard - most soundcards have different MIDI instrument sets, but the FM synth versions sound the same on everything.
* Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another
When I made this brief Duke3D video on DOSBox, I found Gravis to produce the best MIDI sound available*. FMOPL (AdLib/SB) would have worked too. Using MIDI (MPU-401) would have required me to hook up TiMiDity++ into the MPU emulator and somehow I just was not able to make that work, no matter how hard I tried. It would have been the best choice though, given the non-reproducability requirement (I could choose my own patch sets).
I suspect the same trends hold true for JPC-RR too. Only it does not even have an OPL3 emulator yet, or does it?
*) Not that I have anything against OPL3 sound.
I suspect the same trends hold true for JPC-RR too. Only it does not even have an OPL3 emulator yet, or does it?
Currently, the following sound output devices can be captured (in mainline version):
* PC Speaker (since r1)
* SB16 PCM (since r10)
* OPL3 FM (since r10)
* MPU-401 (UART mode only, not in any released version)
I have successfully encoded all of those into PCM sound data.
Calling the current records not optimal is true, but improving upon these records is a tall order. The current fastest TAS run is 30uv1402, which you can also find on YouTube. This run can be improven as shown by this run, which is the first 13 levels done approx. 30 seconds faster than 30uv1402.
Not saying these runs can't be improved, certainly they can. That half run is (as far as I know) optimal up to the point it finishes, although there are some tricks in later levels that could be implemented which would make it perhaps up to a minute faster than 30uv1402. However the effort required to replicate and then beat these runs would be extremely high.
Of course, I would love to see something faster than these. So if you want to go ahead with this then I wish you the best of luck, just as long as you know where the bar is.
Any TAS made for this site would be done on the Nightmare difficulty as it is the highest one, so the times wouldn't really be directly comparable even if the strategies and routes would be mostly the same.
Any TAS made for this site would be done on the Nightmare difficulty as it is the highest one, so the times wouldn't really be directly comparable even if the strategies and routes would be mostly the same.
I disagree with this. Nightmare is more of a gimmicky difficulty that actually gets in the way of certain high speed strategies and would probably wind up being less entertaining to the players and more frustrating to the TASer.
Does the LMP format actually guarantee that the resulting movie could have been made with the original Doom?
It seems to record actual user inputs - but it doesn't save them as key presses, but as speed and direction. I see three potential problems here, that might result in LMPs violating tasvideos' requirements for emulators/movie formats:
What happens when someone creates an LMP with a speed above 50? Will vanilla doom correctly cap the value?
A perfect straferun, SR50, doesn't allow you to turn at the same time (when done using vanilla doom), but it seems possible to create an LMP which turns and does a perfect strafe at the same time. Are there safeguards against this?
There are patches for prboom that use 2 bytes for the direction, resulting in greater aiming accuracy, but those are incompatible with vanilla doom. Were they used in existing TASes?
A way around these problems would be to TAS a doom game using JPC-RR while having LMP recording on. This would generate an JPC-RR movie for validation and an LMP for high-quality encodes.
The downside is that demo recording limits angles to 1 byte, reducing accuracy.
The other way around this would be to try for acceptance of LMP. It should be possible to create a tool that verifies whether an LMP uses invalid values or not and to use vanilla doom as a baseline for verification.
Quick bookmark because I just found the url: lmp format documentation
If you attempt to play back a demo in Doom that has >50 movement it will say that the "Player is Turbo". Also the LMPC is an already existing tool that provides stats on an LMP file, including how many tics are >50. In general verifying an LMP file falls within certain restrictions is pretty trivial.
Using JPC-RR might create a run that is 'acceptable' to this site, but it is adding overhead and difficulty of making an LMP run that existing tools (such as the Doom Replay Editor) do not have, which would probably result in a lower quality run.
And I also agree that there shouldn't be an assumption of performing a run in nightmare difficulty. Certainly a fully TASed/Built nightmare run would be awesome to watch, however nightmare and ultra violence are two very different games, which is why the Doom speed running community has always seperated between them. Although due to the lack of built nightmare runs the bar is a lot lower for creating a 'record' time, so that could be one reason to choose nightmare.
moozooh wrote:
Oh wow, an unexpected pleasure seeing you here years after the 30uv1402 release, Rambo. :)
I lurk around on here and the SDA a bit :), just don't post much
