- Get PrBoom-Plus
- Use .kkapture Version 1.02 and capture at 35.0 FPS
- While capturing, turn off anti-virus as it sometimes interferes with .kkapture
- Use glboom and make sure it is in window mode
- Use the follow settings in glboom-plus.cfg
Note: You need to manually change the screen_resolution since the options are not there in the game itself
- Get the ogg sound pack of SC-55 and modify glboom-plus.cfg to use the music
- Capture twice, once for YouTube and 512kb file (2880x2160), and once for regular file and optionally high resolution file (2560x1600)
- Use AreaResize to downscale to 512kb file or regular file. Get it here: http://www.mediafire.com/download.php?kn56wh7r81vk2rx
- The resolution for 512kb file is 320x240 while the resolution for regular file is 320x200
- For YouTube, make sure you add ChangeFPS(60) to change the frame rate to 60 FPS since it is choppy at 30 FPS
Here is a comparison of downscale methods where it shows AreaResize is the best:
http://imgur.com/a/NkFVl
At one time I was a contributor to the PrBoom-Plus project and implemented an exact capture system in it. If that code is still there and still works, it would be superior to kkapture.
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.
At one time I was a contributor to the PrBoom-Plus project and implemented an exact capture system in it. If that code is still there and still works, it would be superior to kkapture.
That would be great! Only reason I don't use the internal capture was due to the melt effect is missing. This is being captured by .kkapture though. Maybe your code didn't get to the stable releases =/.
At one time I was a contributor to the PrBoom-Plus project and implemented an exact capture system in it. If that code is still there and still works, it would be superior to kkapture.
That would be great! Only reason I don't use the internal capture was due to the melt effect is missing. This is being captured by .kkapture though. Maybe your code didn't get to the stable releases =/.
So you're wasting time and getting inferior output just to get that stupid melt? Ok, have fun.
So you're wasting time and getting inferior output just to get that stupid melt? Ok, have fun.
Exactly. Can there be a way to capture it internally?
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.
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
natt wrote:
Aktan wrote:
natt wrote:
At one time I was a contributor to the PrBoom-Plus project and implemented an exact capture system in it. If that code is still there and still works, it would be superior to kkapture.
That would be great! Only reason I don't use the internal capture was due to the melt effect is missing. This is being captured by .kkapture though. Maybe your code didn't get to the stable releases =/.
So you're wasting time and getting inferior output just to get that stupid melt? Ok, have fun.
To be fair, the melt effect is an integral part of the game's visual appeal. Also, how does kkapture produce inferior output if each frame is captured fully? It hooks the target application's video output to capture every frame accurately, if I understand it correctly. I might be wrong, and I genuinely desire to be educated.
Tell me which config tweaks we need to change for this to become official.
Looks pretty damn close to native if you ask me:
DOSBox dumpPrBoom dump
PS: This is meant to be pixel accurate to native Doom look, with shrinking width to be 4/3 of height in post. Can't trust that job to prboom since non-square pixels won't look right at low resolutions.
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.
So I talked to Doom speedrunners (and TASers) and I thought we might update our Doom encoding standards a bit, because this is no longer just a DOS game. Official release includes many features that are common in modern source ports, and even some exclusive things.
They allow increasing internal res after they switched from Unity to the KEX enginelast year.
The new thing is widescreen resources which are included in the official WADs. In 2020 they were released separately for regular users.
bethesda.net wrote:
Limited License: The DOOM widescreen image assets (the “Assets”) are licensed to you for use with DOOM and DOOM II and may only be distributed as incorporated into, or layered with, a WAD file. The Assets may not be used or distributed in any other fashion, and may not be monetized or distributed commercially. All rights not expressly granted in this Limited License are hereby reserved to id Software LLC. id Software LLC reserves the right to revoke this Limited License in its reasonable discretion if the license terms are violated. By clicking “Download,” you agree to be bound by the terms of this Limited License.
However the KEX version includes an updated status bar which they haven't released. Bottom is the released PNG, top is new DOOM.WAD in SLADE. In the latest Unity release the cracks are there too but maximum width is lower.
So the license says the pics must be put into a WAD file, and people did.
Basically it's just a matter of creating a new Doom WAD Archive in SLADE, dragging in the pics that belong to the game you're running, selecting them all, Convert Gfx To..., and picking Doom in the right dropdown. That's it, save as WAD, and that WAD can be used as a supplement -file now, replacing the regular resources with widescreen ones. Aside from supplying it from commandline, you can put it in the autoload folder for the IWAD you're running.
Since the status bar is common across different IWADs, you can put just the STBAR image in a WAD and put it in autoload\doom-all. PWADs with custom status bars will replace it I think, haven't tested. But for a whole bunch of those there's already widescreen versions at both links above.
The doomworld.com link contains STBAR without cracks. Also the width is smaller than in the official game and on forum.zdoom.org, but that shouldn't matter because we won't need anything wider than 16:9. The latter has both versions with and without cracks, cracks being the _v2 variant of doom_uwide.
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.
The config file loaded by default is whatever is called dsda-doom.cfg near dsda-doom.exe. If you delete it, it will be created upon launch with upstream default settings. So in the config I'm shipping for our encoding, some settings are tweaked.
If you want to load a specific config file, pass the -config <file path here> argument to dsda-doom.
I modeled some of this after the official KEX rerelease to have at least some reference with all the insane amount of settings that we have in source ports, whatever is official should be the least controversial.
This soundfont is the most accurate sf2 replication of the SC-55 device used by the game's composer, and it's better than duke4's recordings because the volume of individual tracks is much more uniform. But it's still much more quiet than the OPL3 synth and sound effects, so we use relatively high gain to make them also even. 15 volume because why not.
screen_resolution "854x480"
16:9 mode for 480p which we use for downloadables. For youtube it will need to be set to 3840x2160, because lowres footage makes textures look like noise to the codec during gradual movement, so it wastes too much bitrate on it and still looks like crap. Even if you point-resize it to 4K and upload lossless to youtube. But at high resolution textures have enough details for the codec to understand movement, so it looks clean.
If you don't have enough space for lossless 4K footage, use something smaller that still fits.
The wipe/melt screen can't be made 100% identical across resolutions and framerates, so the timings you used to set up your script to encode the downloadable won't match those in the HD dump. You can readjust things manually, or simply opt to only dumping HD and downscaling it to SD with this drag-n-drop script (included in the package):
Download downscale.bat
Language: batch
echo off
ffmpeg -i "%~f1" -vf scale=854:480 -sws_flags area -c:v utvideo -pred median -pix_fmt gbrp "%~f1"_480p.avi
pause
Then setting up the script against the SD dump will also work on the HD one.
Also note about videomode "Software" that we're not changing, even tho OpenGL is faster. OpenGL also has bugs, so we can't use it until they're fixed.
dsda_fps_limit 60
Regular monitors run at fixed rate (usually 60 I guess), and youtube has a 60fps limit. But vanilla Doom ran at 35 fps on a 70fps-capable CRT monitor. So to make movement look smooth and not drop frames, we're using modern standard for framerate. This setting only works when uncapped_framerate 1 is set, but it is by default even in upstream so we're good. The difference from upstream here is that it doesn't limit fps at all.
hudadd_demoprogressbar 0
Upstream shows it because it now works as a navigation slider across the demo, but we don't need it.
dsda_show_level_splits 0
Upstream defaults to 1, but official releases don't have it, because they don't primarily target speedrunners.
dsda_skip_quit_prompt 1
It's annoying to confirm quit every single time by hitting Y.
dsda_demo_end_quit 0
Very important setting that makes DSDA-Doom not exit on demo end, which will allow us to encode as much of the ending as we want.
Unfortunately the screen in Doom 2 & co. where cast dies can't be advanced in demo mode, so encoding it is not required.
There's also a quirk in PrBoom derivatives (which DSDA-Doom is) that after the final boss in the first Doom you see the results screen and not the ending right away. This was added in lxdoom v1.4.0 for speedrunning purposes, because Doom speedruns are timed by the in-game time, so skipping the last results screen defeats the purpose for them, and it stuck even since.
So since it's unhelpful for speedruns, we don't skip it either. But that means that a bunch of demos will just end on that screen. Previously we extended the demos by hacking them in a hex editor, turns out it's much easier to just add the U press at whatever frame we want using XDRE. But IMO it's not a problem either to just manually hit Fire or Use on the mouse when you're capturing the video.
Dump lossless AVI using utvideo, with melt/wipe screens, at 60fps. Melts were made (almost) independent from resolution and framerate in the video, but can't be made fully identical.
Upstream dumps video and audio separately and then muxes them together, which takes a ton of time at high resolutions, and also twice the space until it finishes and removes the temp files. We skip the muxing step and only dump audio and video files that will be used for encoding directly.
To help you not overshoot, my fork tells you how many minutes of video it has dumped, so when demo ends (which using -timedemo will tell you) you can count the needed amount of minutes depending on actual tune duration (check Doom OST for that) and end the video there.
Doom speedruns can have instant turns to whatever angle for 1 frame and back, this setting makes it look a bit less accurate and a bit more watchable by humans.
screenblocks 11
hud_displayed 1
Replaces default heads-up display that covers a giant part of the screen with small text on the sides. Makes some speedrun tricks visible.
palette_ondamage 0
Whenever a lot of damage is intentionally taken (for example, for rocket jumping), the screen will turn almost completely red for a few seconds, making it impossible to understand what's going on. We disable this effect.
dsda_show_minimap 1
Extra hint on what's going on, because a whole bunch of things are unclear from the actual screen. As an extra feature, run DSDA-Doom with the -command "iddt; iddt" argument, then all the map will be revealed and object hitboxes will appear on the minimap.
Native res is not 4:3 so it requires aspect ratio correction in post-processing. Not inside the game because it'd make pixels look very uneven.
Plutonia and TNT have custom MIDI soundtracks, if you want to use them put them into respective autoload subdirectories.
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.
They allow increasing internal res after they switched from Unity to the KEX engine last year.
The new thing is widescreen resources which are included in the official WADs. In 2020 they were released separately for regular users.
So the license says the pics must be put into a WAD file, and people did.
Basically it's just a matter of creating a new Doom WAD Archive in SLADE, dragging in the pics that belong to the game you're running, selecting them all, Convert Gfx To..., and picking Doom in the right dropdown. That's it, save as WAD, and that WAD can be used as a supplement -file now, replacing the regular resources with widescreen ones. Aside from supplying it from commandline, you can put it in the autoload folder for the IWAD you're running.
Since the status bar is common across different IWADs, you can put just the STBAR image in a WAD and put it in autoload\doom-all. PWADs with custom status bars will replace it I think, haven't tested. But for a whole bunch of those there's already widescreen versions at both links above.
The doomworld.com link contains STBAR without cracks. Also the width is smaller than in the official game and on forum.zdoom.org, but that shouldn't matter because we won't need anything wider than 16:9. The latter has both versions with and without cracks, cracks being the _v2 variant of doom_uwide.
