OK so let's clean up the sticky welcome thread

[vdgg]

OK here are my proposed edits tu Lüt's original post. I will not edit that just yet, I want feedback. I will do the same with the remaining posts later. In short, I love this post and how much info is still relevant 18 years later but still... 

 

[Edit by Grazza, February 2012: Looking for the old Compet-N/SDA archives, but can't find them because the FTP is down? Browse a copy here or grab the lot (just Compet-N, not SDA) here. Let us know if this link dies. Thanks.]

After seeing a noteworthy interest in demos in recent threads, as well as receiving a few recommendations for a demos forum, we've decided to give it a try. This forum is now the place on Doomworld to discuss anything and everything related to recording and watching demos for Doom-engine games. In addition to discussing existing demos, demo styles, techniques, tools, compatibility, etc., this forum is also for users to post their own demos. You can do this using the "attachment" feature (see the final post in this thread). You can also share your demos by hosting them in your own webspace or e-mailing them to one of the moderators of this forum.

We should stress how important it is to zip your demos and to include a text file in the zip. This makes it far easier for everyone else to know how to watch the demo. As a minimum, this text file should include: your name, the filenames of any wads needed (e.g. hr.wad) and the demo-compatibility format (Doom2, Boom or other). Note that the zip file should actually be a zip file, and not a file in some other format that has merely been given the zip extension.

It is also desirable to include some basic details about the demo, such as the category (e.g. UV Speed) and the time, and the executable used (e.g. Doom2.exe, Prboom-plus 2.5.0.9, etc.). You're very welcome to include a description of your demo - please people tend to enjoy reading these, and it also makes it easier for people them to know whether they should credit you for any tricks or ideas of yours that they later use. If you have used other people's route ideas or tricks, then it is courteous to mention these too.

The demo's file name should be kept short (8 characters), and follow similar principles to the compet-n demo naming: a couple of letters for the wad, two digits for the level number, and three or four digits for the time (and one letter to suggest the category, space permitting). When you are recording on a wad for which there is a pre-existing naming convention in use, please follow that convention.  [hmmm this is fine but also obsolete, what about:]

 

As for the demo file name:

• if you are recording on a WAD for which there is a pre-existing naming convention in use, please follow that convention,
• the more in-depth summary is to be found here.

 

Examples of suitable topics for discussion include:

• how to record demos
• which port (if any) to use
• which demos you have most enjoyed watching
• what control set-up to use
• the techniques used by speedrunners
• which maps are most demo-friendly
• "demopack" projects
• demo categories
• demo news
• technical questions/discussions about anything to do with Doom-engine demos
• trick ideas and exploitable game physics
• built and tool-assisted demos: how to make them and which tools are needed

The new moderators of this forum are vdgg and dew [hmmm, is it true still? I don't know LOL]  Both are very active recorders and should be well-known to most members of the demos community. vdgg also maintains detailed records of new compet-n entries, while dew has a near-encyclopedic knowledge of Doom tricks.

If a demo is suitable for Compet-N (i.e. you have used Doom(2).exe and the demo improves upon a current compet-n record or fills a gap in one of the compet-n tables), this thread is the place to post these demos.

Doom Speed Demo Archive currently serves as an unofficial archive for demos posted in this forum. If you don't want a demo posted on his site, then say so - it's an opt-out, not an opt-in.

Feel free to comment constructively on other people's demos, and to ask for tips if you are having problems in your own attempts to record. No smack talk, please. The moderators of this forum both intend to watch all demos that are attached in this forum. [hahaha Okayyyy]

We accept demos recorded with the original exes or with any port - if you prefer Legacy, GZDoom, Eternity, Chocolate Doom, MBF, etc., there is no need to change. However, please note that demos recorded with the Doomsday engine (i.e. jDoom) tend to have very large file sizes, so if you want to use Doomsday, it is best to upload your demos to your own web space, and to place a link to them in this forum. And please note that Zdoom and its derivatives don't tend to have good demo compatibility between versions, so your demo may not be easily viewable very far into the future.

Many people use Prboom-plus to record or watch demos, as it has compatibility modes that make it a convenient choice for many wads. There are other threads in this forum that provide assistance with its settings. Be sure to state what compatibility mode you have used, and if a particular thread suggests a specific compatibility level, then it would be a good idea to use that level, unless there is a very good reason not to.

The rules for bumping threads are a little different from those for other forums. If you have a demo to post, and it fits neatly into an existing thread (e.g. if you have an Icarus demo, then the Icarus demos thread would be a natural place to post it), then post it there rather than starting a new thread. This applies even if the thread is old. But avoid bumping old threads just to make a comment on something that happened years ago.

If your demo doesn't fit into an existing thread, and the demo isn't on a major wad, then post it in the Misc. demos thread (or Misc. TAS demos thread if it is a TAS demo). This is also a good way to make sure it is seen by lots of people, since these threads will always be among the most prominent in the forum, rather than slipping well down the list. Only start a new thread if the wad already has a lot of demo interest, or is a major new project for which a lot of demo interest can be very confidently expected.

We hope this will prove a lively forum, and be useful to everyone in the Doom Community with an interest in demos, ranging from newcomers recording for the first time, to experts looking to achieve near-optimized runs.

Enjoy!

- The Doomworld staff

Last updated: 11 November 2020

[GarrettChan]

I'm thinking about doing a videos about how to recording with DSDA-Doom, and/or about some tricks for better visualization because it seems mostly they are in written forms. I don't know whether it's useful?

[vdgg]

There follows four posts by Grazza

 

1. About TAS - I think it's just perfect - nothing to change from me except text formatting which got a bit off after changing the look of Doomworld

Spoiler

Many people like to use Prboom-plus to record demos that are compatible with Doom2.exe (or Boom). This enables them to play outside a DOS environment (with sound) while maintaining compatibility (in terms of the game's behaviour) with the original game. There follows a quick no-nonsense guide to getting it working.


Where to get itchangelog and current test version <- recommended, as despite being called a "test version", it is generally the most stable, glitch-free and compatible of all; just think of it as "the current version"

prboom-plus sourceforge site (report bugs and make feature requests here)
official released versions (older)

I urge you always to use the most up-to-date version. This will be more likely than older versions to record and play back demos in the standard formats without problems, and has the most fixes and options to play back problematic demos.

Software and OpenGL rendering Prboom-plus comes in two flavours: prboom-plus.exe (software rendering) and glboom-plus.exe (OpenGL rendering by default). How glboom-plus.exe performs will depend on your hardware, and of course it is less similar to the original game from a visual viewpoint. If you encounter problems, one thing to try is using the older versions of the SDL files that are supplied.

complevels and cfg settings The game behaviour and settings are determined in two ways: by the contents of the cfg file (prboom-plus.cfg or glboom-plus.cfg) and by whether you include a "-complevel" in the command line. The full list of complevels can be found in the accompanying documentation (usage.txt - a good place to look if you need further info about prboom-plus's features), but here I'll just give a quick summary of the most important ones for recording:

-complevel 2 - "vanilla" Doom2.exe
-complevel 3 - "vanilla" Ultimate Doom.exe or Doom95
-complevel 4 - Final Doom (use this only when using tnt.wad or plutonia.wad as the iwad)
-complevel 9</b> - Boom</font>

Thus if you mostly want to record vanilla demos (and Boom when necessary), you can put 2 as your default compatibility for Doom2, 3 as the default compatibility for Ultimate Doom, and put -complevel 9 in the command line when recording on a Boom map. Nothing more to worry about.

These complevels do not enforce vanilla or Boom limits, and so are suitable for "limit-removing" maps or "Boom + additional removal of limits" maps.

Note that the "vanilla" and Boom complevels (2-9) will override the individual compatibility settings in the cfg. With MBF compatibility and above (11-17 and -1), many aspects of the in-game behaviour will be determined by the cfg settings. If you don't use a complevel at all, you will just get the default settings, which may not be what you're after at all. And crucially, it will not then record a demo that will play back with any other program.


Overflow settings
Prboom+ offers several options for emulating memory overflows that can occur with the vanilla exes. I recommend the following settings:
Spechits overflow emulation: yes
Reject overflow emulation: yes
Intercepts overflow emulation: no (this overflow can trash a recording attempt, especially on large limit-removing levels, and is useful only in exceptionally rare cases)
Playeringame overflow emulation: yes or no (this one is very rare)
Donut overflow emulation: yes
Missedbackside overflow emulation: yes


Example command lines glboom-plus -complevel 2 -iwad doom.wad -file uac_dead.wad -playdemo uac_dead
This plays back a Doom 1.9 demo (this pwad doesn't function correctly with Ultimate Doom)

glboom-plus -complevel 2 -iwad doom2.wad -file ksutra.wad -warp 15 -skill 5 -record kn15-xxx
This records a vanilla Doom2.exe demo

glboom-plus -complevel 3 -iwad doom.wad -warp 1 9 -skill 5 -record n1m9-xxx
This records a vanilla Ultimate Doom.exe demo

glboom-plus -complevel 5 -iwad doom2.wad -file icarus.wad -playdemo ic25uv
This plays back a Dosdoom .47 demo

glboom-plus -iwad doom2.wad -file nulspace.wad -playdemo nulnx415
This plays back an unconverted Tasdoom.exe demo (this demo format is autodetected, so there's no need to include -complevel 6 in the command line)

As you can see from the examples above, it is possible to specify a complevel for playback by putting it in the command line. This is to handle cases in which autodetection does not correctly identify the demo-type. Autodetection (i.e. prboom+ guesses the best complevel based on the information in the lmp header and the iwad that is being used) will work for the vast majority of demos.

If you use a complevel for playback by including it in the command line, it will override the autodetection of the demo type.

Autodetection will be used whenever a complevel is not given in the command line.

The default compatibility in the cfg will not override autodetection.

You'll normally only need to specify a complevel for playback when there is something unusual about the demo, such as it being a dosdoom .47 or tasdoom demo.

Note that the demo must have the same binary format as the complevel is expecting (so, e.g., you can't attempt to play back a vanilla demo with -complevel 9).

Once you have things set up, it would make sense to test that it is working correctly by recording some short test demos, and checking that they play back correctly with other exes (e.g. that "vanilla" demos play back with Chocolate Doom, and that "Boom" demos play back with Boom 2.02 or Prboom 2.02).

<h4>Usage Notes:</h4>

Note that if you use the regular Prboom instead of Prboom-plus, you will get a "demo recorded" dialogue (this dialogue is quite irritating, especially if you are making a large number of attempts at a short demo), and you will get a GF49 tic every so often when you should get a GF50 (normal forward running). You may also get a "kick" at start-up, and be unable to move for the first part of a second. It also lacks some compatibility fixes that are in prboom-plus, so there is a greater chance of recording a desynching demo.

Prboom-plus offers a number of TAS features (including slow motion and strafe-50 automation), so be careful that you don't inadvertently use any of them when recording standard demos (check the options menu or the cfg). The default settings are for them to be turned off, so you've nothing to worry about unless you have previously used or experimented with these features.

Check that you are using up-to-date versions of the SDL files that Prboom uses. If you have the most recent version of Prboom-plus, then you will probably have the current versions, but it is a good idea to check the SDL site every so often in any case to see if there are updates. If you have odd performance issues, try using a newer or older version of the SDL files.

Prboom-plus gives the option of overwriting an existing demo. Find demo_overwriteexisting in the cfg and give it the value 1. With previous versions or if you don't want to risk overwriting one that you want to keep, you will need to delete or rename each attempt (manually or via a batch file) before trying again.

The screen resolution can be set from the command line (e.g. -width 1280 -height 1024 - you only need to do this once, as it remembers it from then on) or by editing prboom.cfg or glboom.cfg. You can also set the resolution temporarily from the command line using in a way that is not saved in the cfg: -geom 640x480 for example.

You can set autorun by editing the cfg or by choosing autorun (CAPS by default) in-game. Then pressing Shift has the effect of making you walk.

If you need help with knowing what you should put in your command line to record demos generally, then you will find some useful examples (courtesy of Opulent) here, and guidance from Kristian here.

If you don't specify an iwad, Prboom will choose Doom2.wad if it finds it in the same folder. If you want to use a different iwad, you will need to use -iwad in the command line, or run it from a folder where it instead finds the iwad you want it to use.

To record Final Doom demos, if you use -complevel 2, then this is like using Doom2.exe with Final Doom as a pwad. If you use -complevel 4, then this is like using Final Doom's own Doom2.exe. For playback of Final Doom demos, you need to use the equivalent complevel. If the demo was recorded with Doom2.exe, then you need to use -complevel 2 to play it back. Or use the auto-loading patterns.

You can enter the command line via Start->Run... (rather than a command prompt box) as long as you include the full path to the exe. You don't need to give paths for other files as long as they are in the same folder.

You may wish to disable emulation of intercepts overflows completely. There is only one known demo that has ever made successful use of this "allghosts" bug to which this type of overflow often leads. In every other case, it has either made no difference, or has trashed the recording attempt. Most people would rather have a demo that plays back only with PrBoom+ rather than an amusing but useless failed attempt.

When updating to a new version, I suggest you simply keep your old cfg files (which you will no doubt have spent some time customizing in line with your preferencs), and run the program. If there are new or changed options, then these can be changed from the in-game menus or be editing the cfg manually.

thanks, etc. I hope this is helpful, and that I haven't muddied anything that had been clear! Thanks to Opulent, Kristian Ronge, myk and entryway for some helpful suggestions on what to include here. However, any shortcomings in these notes are my responsibility, and if you wish to suggest any corrections or improvements, please contact me.

2. About PrBoom+. It is very long and very technical, even I don't get everything ("recommended intercept overflow emulation: no"). I leave it for later, but some minor edits, highlighting some parts may be necessary. Also, personal nitpick, I am against writing "hr.wad" etc. in the command line as it is not vanilla and "hr" is accepted by the engine...

3. FAQ, PrBoom+, useful links. Many links are dead, I will get into it.

4. Attachments. I am about to remove this post totally

Spoiler

Here is a quick run-down of how to use the attachments feature.

You can attach demos only in a zip file (please include a txt too), and they must not be more than 200K. For larger zip files than that, split them or upload them to your own webspace (or wherever) and link to them from there. Please avoid file-hosting services that will nuke the link after a short period of time: we want the demos to remain available to people browsing the Demos forum in the future.
 

Start making your post as normal, and use the "Attach file:" window to browse for the file you want to attach.
 

Do not make your post and then try to edit an attachment onto it. That does not work. Once a post has been made without an attachment, it stays that way. If you make too many "Whoops! Forgot the attachment" posts that need fixing, the moderators' patience may start to wear thin.
 

If you wish to replace an attachment with a new one (e.g. to fix an error in the txt), do not "Delete current attachment". Use the "Upload new attachment:" line instead.
 

Do not abuse the attachment feature.

 

 

@GarrettChanYes sure. I think nowadays new people will rather watch a tutorial than read long texts. This would be included.

 

 

Edited June 17, 2021 by vdgg

[baja blast rd.]

The most consistent newcomer incidents, which involve people placing (mostly e1m1) demos with fancy improvised filenames in the wrong threads, suggest that having a minimalist guide is paramount for the "welcome" thread: 300-500 words, cleanly formatted, outlining what you really need to know to record demos and post the right way in the subforum. I've always thought of that as glaringly absent. 

 

That basic guide can reference, or nest, lengthier texts when elaboration is useful. But the first, easiest to spot piece of reference material shouldn't be an intimidating wall of text.

[vdgg]

I can redact what exists and remove stuff which is not extremely important. I don't feel competent enough to write a minimalist guide from scratch. Who is willing to do it?

[GarrettChan]

26 minutes ago, vdgg said:

I can redact what exists and remove stuff which is not extremely important. I don't feel competent enough to write a minimalist guide from scratch. Who is willing to do it?

I can do it this weekend, but isn't supposed that Daerik thread did the similar things? Although I am not really good at English writing either, it could be a good chance to practice :P

Edited June 17, 2021 by GarrettChan

[BoxY]

From the perspective of someone relatively new to recording who had to piece all this information together in little bits I think a good welcome thread for quick-starting people would be something like this:

 

First of all a clear eye-grabbing title at the very top of the page e.g. "Halt! New to posting demos? Read this thread NOW!!!!!11".

 

Followed by a step-by-step inside a single post that will hopefully turn MyE1M1Demo-00001.lmp into a properly formatted zip:

 

-explanation that naming and packing your demo incorrectly will cause it to be rejected from the archive and make Zero-Master personally disappointed in you

-how to name your demo (with the demo naming format in a nutshell and how to check your demo's name against an existing demo)

-how to write a txt containing the minimum required info, including a template

-how to pack your demo into a .zip with the correct naming and file structure, including an example

-how to find the thread your demo goes in (can link to the other sticky), with an explanation that non-records go in the PB thread only

-how to actually attach and post your demo

 

Then at the bottom some links to any other existing tutorial stickies for other questions. All of this information is already in various stickies and on the DSDA main page, but you have to click around a lot and scroll through a lot of TLDR to find it all, it just needs collating. I think all this could be fit into a short enough post that people could actually read it without their eyes turning into little spirals.

Edited June 17, 2021 by BoxY

[vdgg]

Thank you @GarrettChanand wow, if you are willing to do it, I will help as much as I can.

 

Possible points which may be included apart from what @BoxY mentioned

• Introduction, what's the forum about. The first paragraph from Lüt's post, starting from "This forum is now the place..." can be used for reference
• basic complevels 2,3,4,9 which are surprisingly missing in the dsda port thread
• about bumping threads, you are allowed if you post a demo
• TAS should be clearly marked

[GarrettChan]

@vdggI still remember what I was looking at when I joined here first, so I probably used some of my instinct to write those, and of course I'll send you a draft to make sure you think it's good enough.

 

I personally think rd's minimalist approach is what's in my mind. You can insert welcome paragraph or such later, but I want to keep the meat as simple as possible. For example, probably I would only write about DSDA-Doom as a sourceport because it can run everything, but only mention something like Crispy Doom if the player is willing to explore.

 

TAS is something that I don't have knowledge of. I probably will finish the part I can handle first. Then we can discuss how do we move on later.

[Daerik]

I can prepend a brief tl;dr at the top of my existing post so we don't have clutter with another pinned thread, if wanted.