fraggle

Interesting! Heads up that wadptr is now on GitHub and I've been doing a bunch of cleanups to the codebase (your comment may have inspired me a bit). If you have improvements like this I would certainly be interested in merging them upstream now.

This is kind of a tangent, but since we're talking about this kind of really early stuff - a while back I went digging through old stuff from textfiles and Usenet myself and collected as many versions of the different Doom FAQs that I could find. The result is here - each of the files has Git history, so you can look at the old versions and even use Blame to see when particular parts were changed. Maybe at some point I'll see if I can find the time to collect some of the source code from these early tools and do the same thing. It really sucks that all his posts are gone. I even went digging through the dumps on archive.org to see if I could find copies of them, but they aren't there either. Particularly frustrating because obviously it was him that posted the old versions of the FAQ.

You can still contribute! I'm reasonably convinced that there are a lot of people who tried Freedoom once 10 years ago, formed a strong opinion about it as a project and haven't tried it again since. For those people, I recommend trying one of the daily builds because the project has changed a LOT.

There's literally a Discord with people working on it every day. Version 1.0 of Freedoom has not yet been released. I'm confused?

That's not the point of Freedoom. I recently added this section to the Freedoom manual. Take a look and maybe it will help to better explain the purpose of the project.

Doom internally represents sidedefs with the side_t type, and the X offset is stored in the textureoffset field. The game then, once per tic, goes through all scrolling linedefs and adds one pixel to the offset (here). Effectively it's exactly the same as if a mapper uses the X offset on a texture to line up neighboring textures, it's just that the game changes it automatically while you're playing. However, there's a discrepancy in what I've just said. It's the sidedefs that store X position but the linedefs that do the scrolling. In the case of packed sidedefs, multiple linedefs share a sidedef, so every tic, the texture offset will be adjusted multiple times. Instead of moving at one pixel per tic, it'll be scrolling at N pixels per tic, where N is the number of linedefs sharing that sidedef. WADptr doesn't do anything to prevent this happening - it just sees multiple identical sidedefs and merges them. However, it *could* do something, which is that it could identify sidedefs used by a linedef of type 48 and ensure they don't get merged. That would fix the problem, but it would require a bugfix to the WADptr codebase. I'm not sure how much work that would be, because I haven't looked at the codebase in quite a while (and it's not particularly great code either) As a workaround, if people have maps where this is happening they can prevent sidedefs from different linedefs from getting merged by making them differ slightly. A simple example would be that you could adjust the X offset on each line so that each one gets a unique value.

Curious where on Earth you learned this nonsense.

It would be a good idea to add a gameplay video to the original post. Bit of a confusing name since it's the name of the Steam package containing the original games.

Probably everyone's following Doomkid already hehe. I have no idea. But they ought to be Some other channels I'm following: https://www.youtube.com/@THEBaratusII https://www.youtube.com/@Dwars https://www.youtube.com/@4shockblast https://www.youtube.com/@tatsurdcacocaco

@Doomkid's channel definitely deserves more attention than it gets. https://www.youtube.com/@DoomKid

... are you serious? Why?

Ho ho ho! Santa fraggle here, back (after a 20 year hiatus) to bring you the first release of The Vanilla Utilities, a set of DOS APIs and command line tools for doing unusual things with vanilla Doom (and other Doom engine games). It's rather niche but there may be others out there who find some of these useful. Download v1.0.0 here. Included in this first release are: ipxsetup and sersetup - bugfixed and expanded versions of the IPX and serial/modem drivers originally included with Doom. parsetup - parallel port network driver, derived from the version from the idgames archive metanet - networking driver that combines other networking drivers into a packet forwarding network. This allows, for example, three players on an IPX network to be joined by a fourth on a serial cable. solo-net - null/standalone network driver that starts a network game without any real connection. Replicates the -solo-net parameter found in many Doom source ports. (Updated version of the one I released on idgames). analogjs - PC joystick driver with analog control that is more precise than Doom's built in joystick support. replay - demo replay tool that uses the external control API, so that demos can be "continued" by recording a new demo from an old one. statdump - external statistics driver that can dump a text summary. (Updated version of the previous tool I wrote) Full Turbo C source code for all of the above, including C APIs for Doom's networking, statistics and external control APIs. I have plans for further expansion of the set of utilities and I'll be curious to hear people's suggestions.

This thread has been dormant for quite a while now, and there have been a whole bunch of changes since the last update, particularly this year. Version 1.2.0 added support for the xttl IPXSETUP extensions, improved PARSETUP's performance and added support for response files and baked-in command line arguments (so you can for example make a driver always run doom2.exe, like the original sersetup and ipxsetup) Version 1.3.0 added SIRSETUP (a network driver for Serial Infrared / IrDA ports) and added background call answering to SERSETUP, so you can launch the game before the other player has called. Took a while, but I released Vanilla Utilities 2.0 last night. There's a new utility named udpsetup that is essentially this (here's a thread about it).

udpsetup is a new Doom network driver that allows Internet play under Windows 9x and DOS. It does the same thing as ipxsetup or sersetup, but it communicates over the UDP protocol. I've just done the first full release of it (it's part of a suite of Doom engine programs that I call Vanilla Utilities). The program supports multiple network stacks. Most importantly, it supports the Winsock interfaces used on Windows 9x, so if you have a vintage machine running 95 or 98, you can use it on that (it even supports Windows 3.1!). But you can also play it under pure DOS using the MSClient TCP/IP stack. But the key feature here that I think people will find interesting is that I made a design decision to use the DOSbox IPX protocol. When you use this driver you're essentially running an "emulated" IPX game internally, just like if you were using ipxsetup. The result is that DOSbox can connect to udpsetup servers, and udpsetup can connect to DOSbox servers, so people with vintage/retro machines can play with people who just want to use emulation. You can see this in the video above (window at the top right is a DOSbox client) It works with all Doom engine games (Heretic, Hexen, Strife, Chex Quest, etc.) and most DOS source ports. If you want to play Rise of the Triad or BUILD engine games like Duke3D, there are also adapters so that you can use it with those (example video). Download and instructions Vanilla Utilities 2.0 (contains UDPSETUP.EXE; you may also need to use WS2PATCH.EXE on Windows 98) UDPSETUP-HOWTO: Detailed instructions on how to set up games

👀

Good news, you can now: udpsetup is a new DOS Doom network driver that communicates over the Internet using the UDP protocol. It works under Windows 9x (both Winsock 1 and 2) and even works on WfW 3.11 and under DOS if you use the MS Client TCP/IP stack. It uses the same protocol that DOSbox uses, so you can also play against people using emulators (the video above shows an example of this). It also means you can play against people using Dali to network their DOS machines, or people who want to use Chocolate Doom's experimental vanilla networking support. There's more work still to be done but the basics are now all in place.

I'm not aware of any other source ports that support the DOSbox protocol. In theory I guess you could adapt PrBoom+ or one of its descendants to add support for it, since you need identical behavior to keep the game in sync between peers (it's the same problem as demo sync).

Yes, exactly. Though you have to use a special version from the vanilla-net branch.

I have a quiet, unofficial mission to connect as many things as possible with the DOSbox server protocol: https://github.com/fragglet/dali https://github.com/fragglet/ipxbox (it also allows Win9x machines to connect using either the native bridging or PPTP dial-in features) https://www.chocolate-doom.org/wiki/index.php/IPX_protocol_support https://github.com/fragglet/vanilla-utilities (I'm currently working on a UDP-based equivalent of IPXSETUP, but the protocol it will use is the DOSbox protocol)

I hate to be the cynic here but how well do you really know this person? Maybe he really is the love of your life, but there are also people out there who will say these kinds of things to you to manipulate you. In particular you should be very skeptical if this person starts asking you for money for any reason whatsoever, including to buy plane tickets to come and see you. Here's a list of reasons they might give.

This is a mess and I'd like to give my position here as a mod: Here on Doomworld you're expected to be civil. That means not insulting other members and it also means that you shouldn't be tearing down other people's work. That doesn't mean that things can't be criticised but there's a big difference between constructive criticism and acting like a jerk. It's also not acceptable to break this rule because you saw someone else breaking it. "He started it" isn't a legitimate defence on the school playground, and isn't here either. You're expected to behave like an adult here. Use the report button, not the reply button. Thank you and we now return you to your regular Dooming.

Chocolate Doom is a conservative, historically accurate source port that recreates the experience of playing vanilla Doom on modern machines. For common questions, read the FAQ To report a bug, file an issue on Github. But be aware that your bug might be intended behavior. For latest bleeding-edge builds, check out http://latest.chocolate-doom.org. See the first thread for older posts on Chocolate Doom.

He's describing the coordinate translation that happens as part of the rendering process. It's a silly way of describing it - nothing really moves around, it's just that an offset gets added to the world coordinates when the screen is rendered.

good to know