Compet-n Resurrected

Well, at least I myself could make demos COMPET-N would accept:

http://sites.google.com/site/kaptinkurk/Win98SE.JPG

There's also: http://sites.google.com/site/kaptinkurk/DualPCs.JPG a nice pair of Dooming machines.

An insane amount of memory of 384MiB.
High speed CPU clocked in at some speed above 550Mhz (100MHz FSB).
ATI Radeon 9200SE (slower but cheaper)
Aureal Vortex SQ5000 for awesome sounds.
I believe the systems utilize CF cards for storage and possibly a hard disk.

The systems are packed away though.

But in all points, I could see not accepting PrBoom(+) but not accepting Chocolate Doom? And if you cancel out DOSBox and DOSEmu then your player base is now next to nothing these days.

Pretty much all guys except Hegyi who recorded a lot for c-n back in the day have at least one demo each done with dosbox. Not sure if Johnsen's one is dosboxed or done with old PC.

Gez said:

And you can use a modified client to retrieve that seed and reuse it as often as you want.

Nope. You have not understood how the scheme I propose would work.

fraggle said:

Pray tell, why is it that using PrBoom+ or Chocolate Doom is unacceptable, but using DOSbox somehow is? Once you reach this level of pedantism and attention to detail, the hardware and operating system have just as much effect as the choice of whether to use a source port or not. Vanilla Doom's mouse behavior depends on the mouse driver you use, for example. If you really want to be that pedantic then you should play on hardware from the '90s, operating systems and drivers from the '90s, and with a '90s keyboard and mouse. It's pretty clear nobody wants to do that, though.

Again, DOSBox does not change the principle software, and COMPET-N players have regularly been running Doom in an emulated DOS environment since the release of Windows 95. If we ban DOSBox, we should also ban Windows 95 & 98. I don't think we should ban either of them, as both where legal in the first place.

While people's hardware and drivers and such certainly affect the game way more than the difference of Vanilla and Chocolate Doom, it is still fair because each player still has the exact same potential, while with Chocolate Doom, there are a few changes, and even if not humanly noticeable, they are changes non the less.

Also, finding if someone's a cheater or not is easy. Invite them to a co-op game and constantly move around. This would continuously randomize how the Random Number Generator affects the game, and thus anything pre-set would be useless. Obvously, in co-op they can't use slow-motion either because it would be noticeable to the other player. This is a simple and reliable solution. I have yet to hear a better solution besides having the player move the Republic of Croatia and have fx02 watch him every second of his gameplay.

I'm currently working on a "Vanilla Doom over the internet" tutorial. I thought I had figured it all out but then this happened:

Archy said:

Anyways, about software not working, earlier today I was trying to get a multiplayer Vanilla Doom deathmatch up and going with Toxic Barrel, who lives in Finland. I used the same method that has worked on so many people's computers, and it was a complete fail. Hours of frustration (he was up till 3:40 AM his time) and nothing came of it. Still don't know what was wrong.

I'll make a thread later about this, and see if any of you guys know any solutions.

j4rio said:

Offtopic - there are still things that bother me, like when I start doom with recording parameter on, the game is in semi-frozen state and I have to press 'strafe on' or turn to sides to unfreeze it. If I do it too soon, while doom loads, and press strafe on/turn too soon while screen wiping happens, it can twist you to random angle. I wonder if it can be fixed as it's fairly annoying.

I discussed this problem before here
In short DOSBox uses SDL, SDL has a problem, it doesn't capture the input perfectly during the text startup, because of internal resolution change or something.
The lock on then the sudden mouse twitch is also because of too much input during text startup, the best you can do at startup in DOSBox is (forward + turn) (strafe left/right + turn) or maybe (strafe50), you can't do (straferun + turn), although you could in DOS/Win95/98/2000/XP

Archy said:

You say -complevel 2 Source Ports should be accepted, but they shouldn't. Why? Because they are NOT equal and kimo_xvirus explained that. Every small difference affects the game, it may be that absence of the one tic start is a differance, but that one tic of difference is still a difference, an inequality.

The one wait tic changes the RNG, it also possibly makes demos under prboom+/choco impossible to ever replicate tic by tic in Vanilla. It can also be disadvantageous when people compete for ticks in nomonster runs, for example dew's map01 NoMo run in 05.20 is deserving to be equal to 5.17, because he starts moving one tick late, than all the runners who ran the map in Vanilla.

kimo_xvirus said:

Also, even if you set the DOSBox resolution to 320x200, it still has that bug, it has to do with internal resolution or something.

Wouldn't the solution be to run a 320x200 program that then launches doom? Someone should make a command line interpreter that's exactly the same as DOSBox's command.com but is 320x200. Would this fix the problem? I don't think that would be too hard to create.

Archy said:

Again, DOSBox does not change the principle software, and COMPET-N players have regularly been running Doom in an emulated DOS environment since the release of Windows 95. If we ban DOSBox, we should also ban Windows 95 & 98. I don't think we should ban either of them, as both where legal in the first place.

I'd argue on the same lines: using PrBoom+ or Chocolate Doom does not change "the principle software": you're still playing the same game. It behaves in precisely the same way. If the behavior was different the demo would desync.

While people's hardware and drivers and such certainly affect the game way more than the difference of Vanilla and Chocolate Doom, it is still fair because each player still has the exact same potential, while with Chocolate Doom, there are a few changes, and even if not humanly noticeable, they are changes non the less.

In what ways? I'd like to hear your specific objections and the actual ways you think using a source port gives an advantage and affects the gameplay. Not just some vague notion of "vanillaness" that is "not humanly noticeable". If you can't cite specific examples, then I argue that there is no difference.

Also, finding if someone's a cheater or not is easy. Invite them to a co-op game and constantly move around. This would continuously randomize how the Random Number Generator affects the game, and thus anything pre-set would be useless. Obvously, in co-op they can't use slow-motion either because it would be noticeable to the other player. This is a simple and reliable solution.

I'd say that the "constantly moving around" part isn't even necessary. Also, this is still vulnerable to all the same things that my proposed scheme is: to re-use exp(x)'s list from earlier in the thread: "enemy counters, aim bots, wall hacks, SR-50 key bindings, etc.".

I'd also contend that using a multiplayer game would be a significant handicap to anyone trying to actually perform a speedrun due to the lag it would add to the controls (especially if you're trying to use Vanilla, which doesn't work too well on long-distance networks). I doubt you could accurately assess someone's performance in a single player game by observing them in a multiplayer game.

Archy said:

Wouldn't the solution be to run a 320x200 program that then launches doom? Someone should make a command line interpreter that's exactly the same as DOSBox's command.com but is 320x200. Would this fix the problem? I don't think that would be too hard to create.

I think the problem is the resolution change from Doom's text to the game, so your suggestion wouldn't solve it as still the command line interpreter would run Doom's text then the splash screen. The only solution it seems is to fix the SDL code, or hack vanilla doom.

Archy said:

I'm currently working on a "Vanilla Doom over the internet" tutorial. I thought I had figured it all out but then this happened:

<Inner Quote>

I'll make a thread later about this, and see if any of you guys know any solutions.

For Vanilla over the internet without DOSBox, you need Windows 95, 98, or 98SE along with the TCP VXD and some utilities. Or you can use Kai or whatever to wrap IPX but that would put a nice bunch of spyware on your system. Or you could make some virtual serial/modem/IPX over TCP wrapper to play on other systems.

If you are using DOSBox, then you can just say wrap serial or modem (probably easier than IPX) over the network.

kimo_xvirus said:

I think the problem is the resolution change from Doom's text to the game, so your suggestion wouldn't solve it as still the command line interpreter would run Doom's text then the splash screen. The only solution it seems is to fix the SDL code, or hack vanilla doom.

I thought Doom's text screen used what ever resolution the command line interpreter was using but I may be wrong.

GhostlyDeath said:

If you are using DOSBox, then you can just say wrap serial or modem (probably easier than IPX) over the network.

I've been focusing a lot on IPX and for most people it's worked fine, but for a 3rd of the people I've worked with, it's been disastrous.

I'll try out the serial or modem wrapping thing. Since people like you recognize potentially better ways to run Doom online, I'll make a threat later today title "Tutorial: How to play Vanilla Doom over the Internet - BETA stage - help wanted!" [or something like that] so that way the community will be able to contribute better ideas.

I know if I work hard enough, I'll be able to develop a way that the average user can get Vanilla Doom working online without hassle and with ease and user friendly-ness. It's a long ways to go but it's perfectly possible.

Archy - how do players play vanilla in Win95/98? Isn't the emulated DOS environment actually part of the operating system? You didn't need DOSbox for that, right? All Chocolate Doom does is make the original game not require DOS at all.

I'd argue on the same lines: using PrBoom+ or Chocolate Doom does not change "the principle software": you're still playing the same game. It behaves in precisely the same way. If the behavior was different the demo would desync.

I'd agree with Chocolate Doom, but PrBoom+ has more features. It wouldn't be fair to suddenly accept new features for compet-n after all these years. Just on paper, these features look like they would be an advantage, but:

playing in PrBoom+ is like 30 times easier, not because you have slow motion, but because you have uncapped frames, SR50 all time, much much better mouse (smoother), and almost EVERYTHING is visually different and it's EASIER to achieve then in Vanilla.

I like prboom's features, but when it comes down to recording I think a vanilla pro and a prboom pro would produce the same demo. If you play prboom all the time, it will take some time to get used to vanilla doom, but not much time. It's the same exact game. I've seen prboom players play vanilla and succeed, to help prove that point. Playing prboom isn't going to magically make your demos faster. As was already said, permanent sr50 is off by default and is detected easily just by looking at the demo data.

You should refrain from talking about prboom if you are clueless about it. The points I mentioned are barely notable. The only significant difference for me is just the timer/monster counter not present.

For the timer, you can use the map's music. Pick "checkpoints" in the map and pick spots in the music (like the beginning of a verse or the chorus, etc.) to compare the checkpoints to. If the music checkpoint starts before the map checkpoint, you are too slow. :)

For the monster counter, I think it depends on the map. The maps I played in choco weren't dependant on the monster counter at all. Even though I would look at the counter if I was playing prboom, not looking in choco made no difference for me on those maps.

TimeOfDeath said:

For the timer, you can use the map's music. Pick "checkpoints" in the map and pick spots in the music (like the beginning of a verse or the chorus, etc.) to compare the checkpoints to. If the music checkpoint starts before the map checkpoint, you are too slow. :)

I do this very often but sometimes it annoys me because it takes away the excitement of not knowing if you're doing good. I like to be surprised by the intermission screen. :) And I get very nervous when I realize that my current attempt is good.

TimeOfDeath said:

Archy - how do players play vanilla in Win95/98? Isn't the emulated DOS environment actually part of the operating system? You didn't need DOSbox for that, right?

The emulated DOS environment is part of the operating system, but it is still an emulated DOS environment. Are you trying to say that your opinions of DOSBox would be different if DOSBox was part of the Windows NT (2000, XP, Vista, 7, ect) operating system? [sorry if I sound hostile.] Whether it's part of the Operating System or not shouldn't change our views on it, both are emulated, false, DOS environments and if one is allowed, so should the other.

TimeOfDeath said:

All Chocolate Doom does is make the original game not require DOS at all.

Not exactly. If we're talking code for code, tic for tic, it is not a NT/Linux Vanilla Doom, but something different. An example of difference is that the fast start is impossible on Chocolate-Doom. That's just one difference, and it's a very small difference, but any difference equals and inequality.

Chocolate-Doom is definitely the closest port to Vanilla Doom though, but the only way to made a perfect port would be to make a program that launches true, 100% vanilla Doom in an DOS emulator. That would be different that starting Doom in DOSBox because you have two programs when using that method, DOSBox.exe & doom2.exe, but the nonexistent port I'm talking about would be one program [let's say WinDosDoom.exe] that has doom2.exe within it's self, and then uses an emulator also with it's slef that starts that doom2.exe that lives within it's self. (It's self refers to an executable file.)

This is the method used to make N64 games work on the Wii.

Now of coerce since DOSBox exists, making a port like WinDosDoom.exe would be an utter waste of time and just downright stupid and unproductive (outside of experimental fun-stuff), but I hope you now understand why Chocolate-Doom is not a program that makes "the original game game not require DOS at all." because it is not quit the original game, but it's downright close.

TimeOfDeath said:

It's the same exact game. I've seen prboom players play vanilla and succeed, to help prove that point. Playing prboom isn't going to magically make your demos faster.

It isn't about the fact that PrBoom/Chocolate-Doom/WhateverPort isn't easier/harder, it's about the fact that they're different. Because of inability to do the fast start with Chocolate-Doom, a Choco player actually has a disadvantage against a Vanilla Player.

Archy said:

It isn't about the fact that PrBoom/Chocolate-Doom/WhateverPort isn't easier/harder, it's about the fact that they're different. Because of inability to do the fast start with Chocolate-Doom, a Choco player actually has a disadvantage against a Vanilla Player.

You missed ToD's point here. Fx says prboom demos are 30x easier to manage than vanilla ones, to which what you quoted was a response to. Nothing else besides that has been implied within that response.

@j4rio, after a very confusing look through of this thread I see that you're saying and agree. This thread is becoming a mess with all these quotes.

I'll still leave my post there though, because it still proves a point.

Archy said:

Not exactly. If we're talking code for code, tic for tic, it is not a NT/Linux Vanilla Doom, but something different. An example of difference is that the fast start is impossible on Chocolate-Doom. That's just one difference, and it's a very small difference, but any difference equals and inequality.

The fast start issue is something I consider a bug and I've already started looking at to resolve. But a more important question is: does it make any difference?

You can make an argument that a difference that gives some kind of advantage would be unfair. If it doesn't give any advantage, why does it matter? Your argument that "any difference equals [an] inequality" is nonsense. Some differences might potentially equal an inequality, yes, but not all.

Plus you've contradicted yourself: playing in DOSbox is different to playing on a real DOS machine (mouse behavior is different). If "any difference equals [an] equality" then that is different too.

It isn't about the fact that PrBoom/Chocolate-Doom/WhateverPort isn't easier/harder, it's about the fact that they're different. Because of inability to do the fast start with Chocolate-Doom, a Choco player actually has a disadvantage against a Vanilla Player.

In my previous comment I gave you this challenge:

In what ways? I'd like to hear your specific objections and the actual ways you think using a source port gives an advantage and affects the gameplay. Not just some vague notion of "vanillaness" that is "not humanly noticeable". If you can't cite specific examples, then I argue that there is no difference.

With this comment you've not only failed to answer this challenge, but clarified that it doesn't matter to you. You've basically admitted that your desire to exclude source ports does not serve any rational purpose.

fraggle - Prboom+ has uncapped framerate, higher resolutions, monster counter, timer, removed limits (sprites, visplanes, etc), slightly taller viewing area when using HUD instead of status bar, probably more.

Pr+ also allows custom keys for weapons, but apparently so does DOSbox.

On paper, it looks like a lot of differences, but like my other posts say, I think a vanilla pro will produce the same demo as a prboom pro, but I don't think Compet-N should accept prboom demos because it's been vanilla-only forever.

fx02 said:

Ok, so you say that you can achieve permanent SR50 while playing Vanilla or Chocolate doom? Show me please.

Here's how. Enjoy!

TimeOfDeath said:

fraggle - Prboom+ has uncapped framerate, higher resolutions, monster counter, timer, removed limits (sprites, visplanes, etc), slightly taller viewing area when using HUD instead of status bar, probably more.

Those are potentially-valid reasons to dismiss PrBoom(+), but they do not apply to Chocolate Doom.

fraggle said:

You can make an argument that a difference that gives some kind of advantage would be unfair. If it doesn't give any advantage, why does it matter? Your argument that "any difference equals [an] inequality" is nonsense. Some differences might potentially equal an inequality, yes, but not all.

Of coerce "any difference equals [an] inequality," no matter how small, irrelevant, or subliminal the difference is, these all affect our psychological response to input (video & sound in the case of doom) which then create a difference in our physical response (the way we move the controller, mouse ect). If someone was to use a foreign computer (a computer other than my own) and load Chocolate-Doom on it and launched the game, I would not be able to tell if it was Vanilla or Chocolate-Doom because they're so similar. Let's say I played through map 1 of Doom 2. Now, let's say the God of the universe made the world go back in time and then changed one thing, Vanilla Doom was loaded on the foreign computer instead. When I sat down and started playing though map 1, I can guarantee you that I would have played a few tics differentially. This is because of the small differences which caused my mind to react differentially, and thus causing a different physical response.

You'll probably say that that's an insane example and making a fuss about the small differences in action during each tic is ridiculously extreme and does not qualify as any rational reason to disallow source ports at COMPET-N. I see your view but when things are taken to their extreme, you found out their truths, and it is true that Chocolate-Doom will give off a slightly different psychological response than Vanilla Doom.

fraggle said:

Plus you've contradicted yourself: playing in DOSbox is different to playing on a real DOS machine (mouse behavior is different). If "any difference equals [an] equality" then that is different too.

Both the player on the real DOS machine, Windows 98, and DOSBox, all have the same potential because they're using the exact same executable (Vanilla Doom). Yes the fact that they're all using different systems causes a massive difference in the psychological response, way different than the difference between Vanilla and Chocolate Doom, and in an ideal world, we would have everyone competing against each other on the exact same EXE and system, but there's no way we can get everyone to go and buy the exact same system. We can however have everyone use the same EXE. It's not an absurd thing to say that everyone must use Vanilla Doom in they want their demos to be valid. It is absurd to say that everyone must use the exact same system.

fraggle said:

With this comment you've not only failed to answer this challenge, but clarified that it doesn't matter to you. You've basically admitted that your desire to exclude source ports does not serve any rational purpose.

I already admitted to that a long time ago...

Archy said:

Anyways, I understand that my opinions and beliefs are in many ways unrealistic and and irrational, but they are my opinions and I will state them and defend them, as they [,perhaps irrationally,] mean very much to me. COMPET-N's been a big part of my life, and I'd like to keep C-N as it always has been. If COMPET-N's old rules are just ridicules by today's standards, then let's not change C-N, but create a new organization of competition; however, I think DSDA suits that just fine.

Why are we trying to change COMPET-N? If this Source Port issue is so serous, let's make a new competition organization... but again, we do have DSDA...

c-n has always been strict when it comes to rules to get the most equal possible comparisions between demos, and a known issue of a single tic difference between choco and vanilla might be enough for a dismiss. If it gets solved, there'd be most likely no argument unless there are other issues. I'd say this matter requires a point of view of those involved with c-n back in the day, as this'd end in endless loop of arguments between those who after all are not really in position to decide future of c-n.

Gez said:

Those are potentially-valid reasons to dismiss PrBoom(+), but they do not apply to Chocolate Doom.

They sound like hypothetically valid reasons to dismiss PrBoom+, but such is just snake oil. Good players will not need them, and such features are unlikely to make anybody better.

In seriousness this thread is already done. fx02 and Archy seem to make it clear that compet-n isn't truly resurrected; they are missing the original goals of Compet-N and reading into the old rules as a kind of infallable dogma, rather than trying to understand what the original rationale was.

Just one note to Archy: DOSBox is far more "changing the principles of the software" than any source port is. Your attempts to compare with Windows 9x are a little bit futile since those OSes did not contain CPU emulators (they thinly wrapped around some direct hardware control, but otherwise ran it just on DOS itself), built-in keyboard remapping or mouse control. it is probably way easier to cheat on vanilla doom via DOSBox than having to deal with Doom's source code.

chungy said:

Just one note to Archy: DOSBox is far more "changing the principles of the software" than any source port is. Your attempts to compare with Windows 9x are a little bit futile since those OSes did not contain CPU emulators (they thinly wrapped around some direct hardware control, but otherwise ran it just on DOS itself), built-in keyboard remapping or mouse control. it is probably way easier to cheat on vanilla doom via DOSBox than having to deal with Doom's source code.

I talked about that here.

Archy said:

psychological response

Every time you say that I want to scream bullshit.

At that rate I could argue your morning coffee or getting laid last night had more of an effect than DosBox.

Archy said:

Of coerce "any difference equals [an] inequality," no matter how small, irrelevant, or subliminal the difference is, these all affect our psychological response to input (video & sound in the case of doom) which then create a difference in our physical response (the way we move the controller, mouse ect). If someone was to use a foreign computer (a computer other than my own) and load Chocolate-Doom on it and launched the game, I would not be able to tell if it was Vanilla or Chocolate-Doom because they're so similar. Let's say I played through map 1 of Doom 2. Now, let's say the God of the universe made the world go back in time and then changed one thing, Vanilla Doom was loaded on the foreign computer instead. When I sat down and started playing though map 1, I can guarantee you that I would have played a few tics differentially. This is because of the small differences which caused my mind to react differentially, and thus causing a different physical response.

You'll probably say that that's an insane example and making a fuss about the small differences in action during each tic is ridiculously extreme and does not qualify as any rational reason to disallow source ports at COMPET-N. I see your view but when things are taken to their extreme, you found out their truths, and it is true that Chocolate-Doom will give off a slightly different psychological response than Vanilla Doom.

No offence, but yeah, I do think that's an insane example. Sorry if I sound slightly pissed off in the comments I'm making here but the fact is that I've spent several years now crafting what, if you love Vanilla Doom so much, ought to be your favorite source port. To see it casually dismissed as an option, based on some bullshit argument like this that doesn't even make any sense, or reasoning that essentially amounts to "just because", is more than slightly infuriating.

Chocolate Doom ought to be seen as a combo DOSBox+vanilla Doom all-in-one.

The game logic is rigorously the same, the added features are there purely to emulate the original platforms better (OPL emulator, scaling, scanlines). Choco and PrBoom+ go as far as incorporating some static parts of system memory in DOS and Win9x to perfectly replicate the values read by Doom in some circumstances where it overflowed or underflowed or whatever and accessed memory it wasn't supposed to see -- I don't know if that happens in DOSBox as well.

There are important differences between DOSBox and the real hardware and software of the era. For example, you cannot get the Doom alpha high-color mode to work on DOSBox, it'll just look glitchy. Maes implemented a working version in MochaDoom. Sure, that example is not relevant since the high-color mode was long removed when Doom.exe v1.9 was finalized, but it's just one thing that shows that the original software on an emulated platform might not be as accurate as a careful recreation which actually made sure that each and every feature works as they did originally even on modern platforms.

fraggle said:

Sorry if I sound slightly pissed off in the comments I'm making here but the fact is that I've spent several years now crafting what, if you love Vanilla Doom so much, ought to be your favorite source port.

Archy said:
I always set up Chocolate-Doom for people when I install Doom on their computer

I think that means it is my favorite; I never install anything on anyone's computer unless I consider it top notch quality.

fraggle said:

To see it [Chocolate-Doom] casually dismissed as an option, based on some bullshit argument like this that doesn't even make any sense, or reasoning that essentially amounts to "just because", is more than slightly infuriating.

I'm sorry if it sounds like I'm insulting your source port, because that's not what I'm doing. I'm just defending the principles of COMPET-N, and one of those principles has been that Vanilla Doom is used and nothing else. If people don't like that rule, then they shouldn't try to change COMPET-N, they should start their own competition organization.

I regularly use your software on a daily basis, and I'm quite a fan. Just ask anyone what lives with me, they hear the name "Simon Howard" all the time. Statdump.exe has saved me quite a lot of time when I forgot what was on my stats screen.

Belial said:

Every time you say ["psychological response"] I want to scream bullshit.

At that rate I could argue your morning coffee or getting laid last night had more of an effect than DosBox.

My coffee does cause a much bigger difference in the way I play Doom than the difference between Chocolate and Vanilla Doom, and that's exactly why true equality is impossible. But why make the already unequal playing field even more unequal than it needs to be by allowing source ports? It's not like Vanilla Doom is impossible to set up, just ask j4rio.

Belial recorded some c-n stuff iirc, so I think he does get the picture.

Gez said:

There are important differences between DOSBox and the real hardware and software of the era. For example, you cannot get the Doom alpha high-color mode to work on DOSBox, it'll just look glitchy. Maes implemented a working version in MochaDoom. Sure, that example is not relevant since the high-color mode was long removed when Doom.exe v1.9 was finalized, but it's just one thing that shows that the original software on an emulated platform might not be as accurate as a careful recreation which actually made sure that each and every feature works as they did originally even on modern platforms.

The "the original software on an emulated platform might not be as accurate as a careful recreation which actually made sure that each and every feature works as they did originally even on modern platforms." part has got to be the best counter argument I've heard yet, very nice point. However let's use this scenario: Vanilla Doom has some weird bug that's so rare that only Lee Killough and John Carmack know about it. The bug would still be their in DOSBox, but it would not exist in PrBoom/Chocolate-Doom/Whatever until it was implemented. Using Vanilla Doom, whether with DOSBox or DOS, will still have all of it's bugs, known and unknown. PrBoom/Chocolate-Doom/Whatever only have the known.

Note that I'm only talking about bugs that happen internally within Doom, not bugs that can happen from the Operating Environment interacting with the exe.

Archy said:

Note that I'm only talking about bugs that happen internally within Doom, not bugs that can happen from the Operating Environment interacting with the exe.

Most of them have already been discovered really by people looking at the source release and reverse engineering of the executable itself.

Archy said:

I'm just defending the principles of COMPET-N, and one of those principles has been that Vanilla Doom is used and nothing else.

This is what I meant by assuming the old rules were an infallable dogma. Why did Compet-N demand this in the past? Fairly clearly in order to establish a well-known set of game rules for consistent comparisons. (If someone beats Doom 2 in GZDoom faster than Compet-N's record, it's clearly not a valid comparison since GZDoom modifies the game rules quite a lot.)

PrBoom+ and Chocolate Doom have gone to great lengths to preserve the original rules of the game, to where demo files are compatible between vanilla and them.