DOOM relies on undefined link behavior

Simply clearing an mobj_t's snext/sprev/bnext/bprev and, for BOOM, the old secnode list pointer in P_RemoveMobj, so that gamecode cannot attempt to remove an object from these lists more than once, causes some 1.9 demos to desync, including DEMO3 in doom2.wad, even though this is preventing a completely invalid action from taking place.

I guess I shouldn't be surprised. Really I am more disgusted than anything.

Well, what did you expect?

It has been known for ages that demo compatibility and a stable engine are mutually exclusive.

Graf Zahl said:

Well, what did you expect?

It has been known for ages that demo compatibility and a stable engine are mutually exclusive.

Well like I said, not really surprised. The bad thing is, BOOM team totally missed the fact that objects can be manipulated into corrupting (or at least improperly "tweaking") the sector and blockmap link lists after having been removed, and so BOOM and up demos also rely on this broken behavior. In fact I dare say if anything, they probably made it worse.

Quasar I know I said this on IRC but maybe it's time to rethink demo compatibility. Let's face it, EE isn't ever going to do it nearly as well as PrBoom(+), or probably even Chocolate Doom (for vanilla demos only, of course), mostly because these projects have made a huge point to maintain compatibility, whereas EE is about new stuff, not retaining old stuff. Besides, you trying to keep track of demo compatibility is frustrating to you because its time consuming and tedious, frustrating to us because it gets us new features much more slowly, and is in general just all around not enjoyable. So honestly if needed fixes like this (and it sounds pretty needed to me, from what you said on IRC) are going to break demo compatibility, then chuck that shit in the bin and get on with life.

Is this the reason I occasionally and randomly encounter crashes when playing SDL family Boom, WinMBF or MBF (or JDoom 1.8.6, whichever is the last nonbeta), marked by "Segmentation violation: SDL parachute deployed"? Crashes seemed to happen more often than in vanilla Doom.

John Smith said:

Quasar I know I said this on IRC but maybe it's time to rethink demo compatibility. Let's face it, EE isn't ever going to do it nearly as well as PrBoom(+), or probably even Chocolate Doom (for vanilla demos only, of course), mostly because these projects have made a huge point to maintain compatibility, whereas EE is about new stuff, not retaining old stuff. Besides, you trying to keep track of demo compatibility is frustrating to you because its time consuming and tedious, frustrating to us because it gets us new features much more slowly, and is in general just all around not enjoyable. So honestly if needed fixes like this (and it sounds pretty needed to me, from what you said on IRC) are going to break demo compatibility, then chuck that shit in the bin and get on with life.

This means it would have the same level of freedom as ZDoom. I don't know what to say about this without possibly making some people mad... But hopefully with this freedom it will have more time to implement original features, rather than mimic (bad word... let's say implement) ZDoom's features and stay in shadow. Here, I said it.

printz said:

Is this the reason I occasionally and randomly encounter crashes when playing SDL family Boom, WinMBF or MBF (or JDoom 1.8.6, whichever is the last nonbeta), marked by "Segmentation violation: SDL parachute deployed"?

Unlikely. BOOM/MBF have a number of easily-triggered bugs which are much more instantly fatal than this one.

printz said:

This means it would have the same level of freedom as ZDoom.

People have been saying that for a long time but, really, I don't spend that much time on demo sync. It's only when some new undefined behavior like this rears its ugly head that I have to stop and deal with it for a while, and then it's *usually* as simple as adding some demo_compatibility checks. The thing that bugs me is that this behavior is wrong and can crash the program, and having to make it conditional is icky.

Here's what happens BTW:
When a missile with S_NULL deathstate strikes an object in P_XYMovement, it can loop around the do { } while(xmove|ymove) loop an additional time (or more) depending on its momenta. Because it was removed by setting its state to S_NULL, it no longer has valid snext/sprev links.

On the next call to P_TryMove inside the second loop iteration, P_UnsetThingPosition is called again, and the thing is "detached" from a list that it is no longer in. What precisely this does to the list seems to vary and is difficult to even figure out, but rest assured it's not left in a valid state. msecnodes may also be corrupted, as it tries to release nodes to the freelist which were already placed there previously. In this instance, the blockmap is safe, but only because the thing is MF_NOBLOCKMAP - note that Lost Souls would corrupt this also if they removed themselves during P_XYMovement.

In Eternity, this can cause one of three things to happen:

• An access violation will occur with 100% guarantee if the thing's memory is released back to the system. This does not always happen, of course, because it's up to the Windows heap to decide when memory is returned to the system or kept in the reusable block pool.
  
• An infinite loop will occur in R_Subsector.
  
• A semi-infinite loop will occur involving R_ProjectSprite which is bounded by the amount of memory that Windows will allocate to the process in a single pointer. Under current conditions on Windows 7 this seems to be exactly 800 MB. Once the realloc call on vissprites exceeds this size, Z_Realloc will throw an error.
  

The fix is simple: nullify all expired links when removing an object, and then give it MF_NOSECTOR and MF_NOBLOCKMAP flags to guarantee that it cannot be linked back to the world again. Too bad this busts demo sync completely, though. I don't even want to think what kind of monkeyisms are going on behind the scenes during situations like DEMO3...

Not to mention vanilla Hexen which happily goes about moving mobjs and linking/unlinking from the map and/or blockmap without going through the expected sequence of events.

Bizarrely we have DOS's basically unprotected "memory model" to thank for these games working as "well" as they did.

@printz No thats most likely due to zone heap corruption; there are several old vanilla bugs which miraculously managed to persist in Doomsday until I addressed them (post 1.8.6).

There are some very valid reasons to attempt to maintain original demo sync:

First, the obvious: It's nice to see a demo play when the game starts. But there's others which are, arguably, more important:

1. A demo-faithful port will, alomst by definition, feel like vanilla.

2. Once the work is done, you can *verify* the accuracy of your code, by making sure an original demo stays in sync. This is perhaps the best test of all. In other words, if you want to add some conditional features/options, you can always check your work against a "baseline" - vanilla demos. Otherwise, that baseline is an arbitrary, moving target.

3. Demo-syncability leads to network-syncability. You can certainely get networking to stay in sync without demo compatibility, but, it's almost free once you've created a demo-compatible system.

The Doom demo format is absolutely beautiful from and engineer's standpoint. In essence, it captures the state of hundreds to thousands of monsters, missiles, lifts, doors, etc, in less than 1K/sec. At least, it simulates this ability.

But, it has one even more-brilliant aspect: It demands absolute symmetry. This statement is more easily understood when the concept is applied to networked games, but, it's the same concept, nonetheless. The game must recalculate each monster sight, missile hit, player step, etc. *exactly* as it did when the demo was made.

In other words, when a demo goes out of sync, it is 100% conclusive that either:
1. The source port/wad is different than it was when the demo was made.
2. The recording exe has 'undefined' behavior - bugs that prevent the calculations from being exact across multiple runs.

So...

Writing a port that supports demo compatibility forces these 'undefined behavior' bugs out in the open, and leaves you with a extremely powerful tool to make sure the ENTIRE port as bug-free as possible. The bug in question was understood because of the desire to make original demos sync. It also uses the same technology required to synchronize net games.

And, you get cool demos to watch too! So, the Doom demo format is your friend...

kb1 said:

3. Demo-syncability leads to network-syncability. You can certainely get networking to stay in sync without demo compatibility, but, it's almost free once you've created a demo-compatible system.

Is that still true in C/S ports with some kind of clientside prediction?

Spleen said:

Is that still true in C/S ports with some kind of clientside prediction?

I don't claim to have studied everyone's methods, but here's a generalization:

First of all, demos. The theory is that, given the same map, same monster ai, same timings, etc., if the player could move EXACTLY the same way across multiple plays, the monsters will respond exactly the same way, and the player will end up with exactly the same health, items, etc. at a given point in time.

Thus, when a demo is recorded, it's the player movements that are being recorded - that's the only information the game cannot "recreate". In other words, the player movements are ALL that is required to completely replay the demo (game options like Fast Monsters not withstanding).

Don't believe these Back to the Future movies and the like - if you could go back in time, kick a pebble, and come right back to today, the world would be COMPLETELY different - Doom demos proved that to me...heh.

Now, net games. The same demo theory applies here. Of course, the goal is to have, say, 4 computers showing a different view of the EXACT same game - same monsters in the same positions, same healths, etc. Instead of saving player movements to a file, those movements are transmitted to all other nodes on the network. And, just like demo recording, this information is sufficient to keep the game in-sync.

In Original Doom, each node (pc) sends a player movement packet to each other node, each frame. For 2 nodes, that's 2 packets X 35 fps. For 3 nodes, it jumps to 6 packets. For 4 nodes, it skyrockets to 12 packets X 35 fps. The formula is packets_per_frame = count(n - 1) * n, where n is the number of nodes. In this peer-to-peer scenario, a frame will not advance until ALL packets have been received. This can saturate a LAN, especially at 1993 speeds. Now, imagine 5 players. How about 8? How about, on an unpredictable internet connection?

That's where C/S architecture comes into play. The idea is that, instead of all nodes talking to all nodes, each node communicates to the server node only, and the server node then updates all the clients. In this scenario, the 8-player game goes from 56 packets/frame to 16 packets/frame. The server combines all the node's packets and sends the result to each one. The server can be 'dedicated', meaning that it is not a player in the game, or, the server could also be a node itself, hosting a local game as well. Still, with this scenario, the nodes will not advance until ALL packets have been sent and received.

Now, client prediction is a totally separate thing. Even with the Client/Server packet reduction happening, each client still is frozen until all packets are sent and received. Client prediction allows the game to continue without waiting, by guessing what would be in those packets before actually receiving them.

For example, say I'm Player #1 playing a net game. If, during the previous update, player #2 was moving northwest, then let's 'pretend' player #2 is STILL moving northwest, and update his position accordingly on MY local game. Meanwhile, on Player #2's computer, let's assume that I, Player #1, am still camping beside the plasma gun, like I was 2 frames ago.

Once the packets actually arrive, my pc realizes that, Player #2 infact IS still moving northwest. But, Player #1's pc realizes that I, player #2, actually grabbed the plasma gun and started moving south. So, Player #2's view of Player #1 is corrected locally.

As long as packets arrive fairly quickly, this can provide the illusion that we are playing the exact, lag-free game, which is somewhat less than true. It can work farily well, as long as there's no interaction with monsters, but gets nasty very quickly as you add monsters, because you create "alternate dimensions" that must be "rolled back" to a common state across all computers to remain synchronized.

If I were designing a prediction system, I think I would make the monsters experience the lag instead of the players - by feeding the monsters the true, transmitted, lagged player position, so the monsters would stay in sync across all games. Very tricky to get right.

Wow, that was a long post...

kb1 said:

Now, client prediction is a totally separate thing. Even with the Client/Server packet reduction happening, each client still is frozen until all packets are sent and received. Client prediction allows the game to continue without waiting, by guessing what would be in those packets before actually receiving them.

The client can also mispredict, which causes desynchronization. Letting the client think for itself more will complicate resynchronization.

kb1 said:

It ... gets nasty very quickly as you add monsters, because you create "alternate dimensions" that must be "rolled back" to a common state across all computers to remain synchronized.

Yeah, and it even gets nastier when you also throw moving sectors and scripts into the mix!

[quote]kb1 said:
If I were designing a prediction system, I think I would make the monsters experience the lag instead of the players - by feeding the monsters the true, transmitted, lagged player position, so the monsters would stay in sync across all games. Very tricky to get right.Very interesting, but this will require a bit of thought on my part. I don't understand these things as fast as you do. :P

kb1 said:

Wow, that was a long post...

Yes, and very informative. Thank you!


This is a very interesting discussion but I realize we are derailing the thread; apologies. Would be really nice if a moderator could split it.

Spleen said:

The client can also mispredict, which causes desynchronization. Letting the client think for itself more will complicate resynchronization.


Yeah, and it even gets nastier when you also throw moving sectors and scripts into the mix!


Yes, and very informative. Thank you!


This is a very interesting discussion but I realize we are derailing the thread; apologies. Would be really nice if a moderator could split it.

Nah it's fine. The original discussion has pretty much run its course anyway. There's only so much you can say about the fact that DOOM doesn't clear its pointers properly :P

John Smith said:

Quasar I know I said this on IRC but maybe it's time to rethink demo compatibility. Let's face it, EE isn't ever going to do it nearly as well as PrBoom(+), or probably even Chocolate Doom (for vanilla demos only, of course), mostly because these projects have made a huge point to maintain compatibility, whereas EE is about new stuff, not retaining old stuff. Besides, you trying to keep track of demo compatibility is frustrating to you because its time consuming and tedious, frustrating to us because it gets us new features much more slowly, and is in general just all around not enjoyable. So honestly if needed fixes like this (and it sounds pretty needed to me, from what you said on IRC) are going to break demo compatibility, then chuck that shit in the bin and get on with life.

I'm throwing my hat in this corner of the ring.

Quasar, don't take this the wrong way, but I'm never, ever, going to watch or record a vanilla demo with Eternity. PrBoom+ already does that stuff too well. I'm going to play mods that use portals with Eternity.

Creaphis said:

I'm throwing my hat in this corner of the ring.

Quasar, don't take this the wrong way, but I'm never, ever, going to watch or record a vanilla demo with Eternity. PrBoom+ already does that stuff too well. I'm going to play mods that use portals with Eternity.

Opposite* for me; Eternity's got some wonderful features for playing the vanilla game. Stuff like the recently announced Master Levels support, something that one of the other ports probably should have implemented years ago. Not the mention it's got a more vanilla-like configuration out of the box, runs a new software renderer that fixes a lot of the ugliness of high resolutions on the original, and has plenty of useful features for enhancing otherwise vanilla wads. I'd hate to see Eternity go the ZDoom route and abandon vanilla compatibility. Especially with Heretic, Hexen, and Strife support coming in the future.

I have a few nitpicks with Eternity right now, there are some annoyances that I want to see go away, and some features added. But the -vanilla parameter was definitely a huge step towards it replacing PrBoom+ for me. A port with plenty of new features, starting to rival the most mod-friendly port of them all, but I can still load up my Ultimate Doom iwad and watch someone really suck at E4M2 whenever I want.

(*Okay, not really the opposite. I want to play wads that use portals, too.)

kb1 said:

But, it has one even more-brilliant aspect: It demands absolute symmetry. This statement is more easily understood when the concept is applied to networked games, but, it's the same concept, nonetheless. The game must recalculate each monster sight, missile hit, player step, etc. *exactly* as it did when the demo was made.

Whether that's a good or bad thing is left to discussion. Fact is, that for demo compatibility you need to leave a lot of cruft in the source base that ultimately make your life harder rather than easier.

In other words, when a demo goes out of sync, it is 100% conclusive that either:
1. The source port/wad is different than it was when the demo was made.
2. The recording exe has 'undefined' behavior - bugs that prevent the calculations from being exact across multiple runs.

... both of which are close to irrelevant in most situations.

Writing a port that supports demo compatibility forces these 'undefined behavior' bugs out in the open, and leaves you with a extremely powerful tool to make sure the ENTIRE port as bug-free as possible. The bug in question was understood because of the desire to make original demos sync. It also uses the same technology required to synchronize net games.

Well, sorry to burst your bubble here, but that statement is utter crap. In the case that the demo was recorded with an older version it's almost safe to assume that there was a change and in case it was recorded with the same version you don't need demo compatibility to come to the conclusion that there's an inconsistency in the engine - but that's also true if each version's demos are only compatible with that version alone.

And, you get cool demos to watch too! So, the Doom demo format is your friend...

... or you could install more than one port - one for playing the game and one for watching demos. I still prefer the one playing 99% of all demos to the one only playing 95% so my demo playback engine of choice is PrBoom+.


So to conclude: I understand why Quasar wants to maintain demo sync. After all he has put a lot of work in there but to be honest, I also think that for Eternity's bigger picture it's more of an obstacle than an asset.

At least, please keep the internal demos from the IWADs running. I find it most sad when I load Doom with a new port and instead of teaser demos I just see the credits and titlepic looping, and an apology that "Sorry, demos no longer supported :(".

'at least'?

If these need to work you need to go all the way with demo compatibility, that's the big problem here.

Anyway, I'm glad that I don't have to suffer watching them anymore... :P

The thing that annoys me with EE's demo playback is that I can't change options while they do. I try and it tells me "no can do, sir, there's a demo playing and it should not be disturbed!" Granted, I don't change settings often so it's not a frequent annoyance, but I don't like having to start a game just so as to be able to change the settings I want -- including whether mouselook is on or off -- in peace. It seems more logical to me to change the settings before starting the game. But if I try that, the demo starts while I'm navigating the menus and I have to just abort everything, start a game, and try again.

Yeah, that's one of the annoyances I was referring to in my post.

Gez said:

The thing that annoys me with EE's demo playback is that I can't change options while they do. I try and it tells me "no can do, sir, there's a demo playing and it should not be disturbed!" Granted, I don't change settings often so it's not a frequent annoyance, but I don't like having to start a game just so as to be able to change the settings I want -- including whether mouselook is on or off -- in peace. It seems more logical to me to change the settings before starting the game. But if I try that, the demo starts while I'm navigating the menus and I have to just abort everything, start a game, and try again.

You understand why it has to work that way right?

There's no grand engine to remember changes you want to make during a demo, store them in a huge set of temporaries, and then propagate their values to the real variables after the demo finishes.

Creating such a thing would open up the hairiest kind of issues I could imagine as it wedges a layer of abstraction between the input layer and the game's state. This is hardly unique to Eternity; all of its ancestor ports, and many other ports which allow such things to be changed at run time, cannot tolerate doing it in the middle of demo playback.

Also, and while maybe it's still not ideal, one does not have to start a new game to stop a demo. Just bring down the console and type "stopdemo". You'll drop to GS_CONSOLE gamestate and remain there until you do something that starts a new game or exits.

Quasar said:

You understand why it has to work that way right?

Not really to be honest. :/

The demo plays in exactly the same way regardless of settings. So what happens? Aren't said settings ignored or overridden by the demo? If not, how does it even work?

What does it matter that mouselook be turned on or off since user input is disabled anyway? And if it is really impossible to change that during demo playback, then why not make the the game stop the demo (you're not actually watching it anyway since it's completely hidden by the menu screens) and let the user change what he's trying to change? I'd would put user commands at a higher priority than automatic demo looping in such conditions, personally.

If you clear a mobj_t's snext/sprev/bnext/bprev in P_RemoveMobj this can cause a side effect that prevents the player picking up more than one item in a single game tick.
This can happen because in the block things iterator the next mobj = mobj->bnext and P_RemoveMobj will have just set mobj->bnext = NULL.
If the links aren't cleared the iteration continues to the end of the current blocks thing list.

Edit: 'block list' changed to 'current blocks thing list'

Gez said:

Not really to be honest. :/

The demo plays in exactly the same way regardless of settings. So what happens? Aren't said settings ignored or overridden by the demo? If not, how does it even work?

What does it matter that mouselook be turned on or off since user input is disabled anyway? And if it is really impossible to change that during demo playback, then why not make the the game stop the demo (you're not actually watching it anyway since it's completely hidden by the menu screens) and let the user change what he's trying to change? I'd would put user commands at a higher priority than automatic demo looping in such conditions, personally.

It doesn't play in exactly the same way regardless; when a demo is playing, the user-specified values of sync-critical variables are retained in their "default_" version; however, for the console/menu to function as expected, it needs to modify both the active and default value, and the active value cannot be modified during a demo.

It MIGHT would be possible to modify only the default_ location for such variables, but I'd have to be super sure that it sticks. I'll look into it.

4mer said:

If you clear a mobj_t's snext/sprev/bnext/bprev in P_RemoveMobj this can cause a side effect that prevents the player picking up more than one item in a single game tick.
This can happen because in the block things iterator the next mobj = mobj->bnext and P_RemoveMobj will have just set mobj->bnext = NULL.
If the links aren't cleared the iteration continues to the end of the current blocks thing list.

Edit: 'block list' changed to 'current blocks thing list'

Oh god 9_9 I knew changing any of this stuff would begin a shitstorm of side-effect-related problems.

One of the primary reasons for wanting native Hacx support in EE is for demo support, though it's a weak argument considering how little's been done in that regard on my end. :P

As long as it stays demo-compatible with itself in the future, it wouldn't even matter anyway. May as well make this an option, problematic as it is, with the warning that things might screw up if left in compatibility mode.

Gez said:

Not really to be honest. :/

The demo plays in exactly the same way regardless of settings. So what happens? Aren't said settings ignored or overridden by the demo? If not, how does it even work?

What does it matter that mouselook be turned on or off since user input is disabled anyway? And if it is really impossible to change that during demo playback, then why not make the the game stop the demo (you're not actually watching it anyway since it's completely hidden by the menu screens) and let the user change what he's trying to change? I'd would put user commands at a higher priority than automatic demo looping in such conditions, personally.

Agreed 100%. This is something I'd really like to see changed in EE. If a demo-sensitive menu option is changed while a demo is running, automatically stop the demo. If the user is in the menu trying to change it, they weren't watching the demo to begin with. It's just an unnecessary extra hassle that makes the menus less useful.

That reminds me of Quake 2 or something, where the game bombs to the console if you ESC to the menu.

EDIT: close enough, it ends the demo if you press `

Uh, all this stuff is way over my head, but I know you can change options in zdoom while watching a demo. The demo will desync, but you can change options.

printz said:
That reminds me of Quake 2 or something, where the game bombs to the console if you ESC to the menu.

EDIT: close enough, it ends the demo if you press `

Quake keeps the demo running and lets you change settings, but it lowers the console and doesn't start a new demo if you're already in the menu when a demo ends. Once you leave the menu the console is raised and the next demo starts. Not sure what QuakeWorld or its offshoots do, as I always watch longer single demos that aren't followed by another, on those.

Quasar said:

You understand why it has to work that way right?

There's no grand engine to remember changes you want to make during a demo, store them in a huge set of temporaries, and then propagate their values to the real variables after the demo finishes.

Creating such a thing would open up the hairiest kind of issues I could imagine as it wedges a layer of abstraction between the input layer and the game's state. This is hardly unique to Eternity; all of its ancestor ports, and many other ports which allow such things to be changed at run time, cannot tolerate doing it in the middle of demo playback.

Also, and while maybe it's still not ideal, one does not have to start a new game to stop a demo. Just bring down the console and type "stopdemo". You'll drop to GS_CONSOLE gamestate and remain there until you do something that starts a new game or exits.

Yeah, that's basically how to handle it. You create a structure of game option variables. Then, make a array of those, and use one element for the engine's running set, and one for the menu set. When a demo's running, you use the menu set. When in a game, use the live set. When the demo quits, copy the 'menu' version to the live version. When a demo starts, set the live version as needed for the demo. It's not that bad to manage. Beefing up this structure can lend to easy option saving/loading, as well as live option changing across network games.

Graf Zahl said:

Well, sorry to burst your bubble here, but that statement is utter crap. In the case that the demo was recorded with an older version it's almost safe to assume that there was a change and in case it was recorded with the same version you don't need demo compatibility to come to the conclusion that there's an inconsistency in the engine - but that's also true if each version's demos are only compatible with that version alone.

No need to feel sorry if you don't agree. But, my statement still stands. Let me state it another way:

Say you get a complaint in ZDoom, something like "the player semms to be moving funky". What's your first response? "Which version did you notice the change?". How about, a complaint that lifts seem to move at the wrong speed? What is "wrong?" "Wrong" means "different than the original". Now, I know ZDoom's philosophy is to permanently correct original game bugs. So be it. But, you lose something in carrying out that philosophy. Namely, the ability to electronically detect that "something's wrong". With ports that maintain demo compatibility, it gets immediately obvious that "something's wrong"... and it occurs on or around Tic #x. But, with, for example, ZDoom, tracking down strange bugs involves: user complaints, digging through older versions, comparing mod's previous and new behaviors, etc. All of which is cool, but, still, in the end, how do you definitively say "The player is moving correctly"? Because it *feels* right? What is "right?".

No, demo compatibility does not automatically "fix" your port. And, yes, it involves a bit of additional mess, which includes the OP's initial frustration with having to support the bugs. But, no one gives a shit what's in the black box. Players just want to be able to play the game they know and love, and have things work as expected.

And, no, some demo compatibility fixes don't do much towards helping make the game "more fun.". For example, ZDoom's replacement of the original trig tables with on-the-fly computation does cause demos to desync, but really doesn't change gameplay in any noticable way (aside from demos going out of sync.)

However, the traversing changes that cause monsters to be hit more easily (correctly) absolutely changes gameplay. You can "prove" it's more correct by running around shooting monsters. But, what if there was, say, a damage calculation bug in ZDoom as well. How would you know? The "corrected" traversal stuff would certainely make more bullets hit...possibly obscuring this other bug. You'd probably have to either notice it, or wait for someone to complain. But, if you could play original demos, it would become immediately apparent that something was wrong.

My whole point in what I wrote, what to state that demo compatiblity was not just some nice additional feature, but, rather that demo compatibility provides a baseline, a "starting point", from which future expansion can be modeled after. in a manner that can be reduced back to that baseline, on demand. And, I can say from experience that this ability has helped me identify many problems with new features that would otherwise be very difficult to detect. I can say with confidence that any version I compile will be real damn close to bug free, as far as game mechanics are concerned, before unleashing it upon my "innocent customers", because I've verified that original demos play correctly. Think about it until it makes sense.