Chocolate Doom

[Jon]

On 22/05/2017 at 6:14 PM, Quasar said:

That would likely be in relation to the Medusa emulation, and whether or not it was worth it to try to have the effect slow down the computer.

 

I think we agreed that we would slow down the renderer, but not try to artificially tax the CPU. We want rendering framerate control for framerate interpolation support, so we could use the same mechanism to artificially drop the framerate when medusa was in view. I'd been intending to look at adapting the stuff that's in crispy doom (but haven't got very far)

[Linguica]

Is framerate interpolation really something you guys are considering? It seems very "unchocolatey".

[Csonicgo]

3 hours ago, Linguica said:

Is framerate interpolation really something you guys are considering? It seems very "unchocolatey".

 

That is one of my unanswered questions: Was Doom reduced to 35Hz clock due to DMX, or was that a coincidence that happened to work? A lot of Doom's behavior relies on that.

 

On 5/24/2017 at 8:15 AM, chungy said:

Capping the engine to only run at 15fps, for example, to "simulate" the vanilla 386DX experience might be possible, but it won't account for anything remotely similar to the 386's actual performance when it comes to handling certain amounts of things or map sizes.

 

This also depended on your VGA card. I had a 486DX2 during DOOM II's heyday, and my friend in elementary school had a 386 - and still had better performance in some areas than I did, because my VGA card simply wasn't fast enough. A 486DX2-66 system with PCI ATI Mach64 would blow the doors off of anything else at that time. the High-end Mach64 cards had 8 MB VRAM, which was overkill in every sense of the word.
 

[Graf Zahl]

1 hour ago, Csonicgo said:

Was Doom reduced to 35Hz clock due to DMX, or was that a coincidence that happened to work?

35 Hz was the best compromise of using the video refresh to sync the game and achievable performance on 1993's hardware.

Don't forget: All the play code would have had to run twice as much for a game with a tic rate of 70 Hz and considering that many computers even struggled with maintaining 35 Hz that would have left even less time to the renderer.

[kb1]

19 hours ago, Jon said:

 

I think we agreed that we would slow down the renderer, but not try to artificially tax the CPU. We want rendering framerate control for framerate interpolation support, so we could use the same mechanism to artificially drop the framerate when medusa was in view. I'd been intending to look at adapting the stuff that's in crispy doom (but haven't got very far)

I would argue against slowing it down when you look at Medusa. I mean, it's purely opinion on my part, but that's not much of feature that helps anyone. How much would you slow it down? Would you have settings to emulate a 386, 486, Pentium, i7? I'd say just draw some colored lines and be done with it, myself.

 

If you really have to slow it down, render every 4th frame or so: if (gametic & 3) == 0, or something. Again, just an opinion. Are there any WADs with a "time-bending alien super ray" that slows down time when you look at it? A seizure-inducing row of flashing lights room? It seems kinda silly.

[Jon]

4 hours ago, kb1 said:

I would argue against slowing it down when you look at Medusa. I mean, it's purely opinion on my part, but that's not much of feature that helps anyone. How much would you slow it down? Would you have settings to emulate a 386, 486, Pentium, i7? I'd say just draw some colored lines and be done with it, myself.

 

The main reason to do something more drastic than draw some ugly lines (like tutti frutti) is one of the reasons chocolate emulates old bugs is to for mappers to know whether their map will work on vanilla, or not. Tutti frutti is pretty benign and sometimes unnoticeable. We could make sure medusa was much more visible, but it might still be something that a mapper may leave in, or ignore; whereas in vanilla it's something that you absolutely must address.

 

I'm actually starting to wonder if slowing down just the renderer is a good idea. Imagine an imp fireball travelling towards you as you turn the viewpoint to incorporate a patch of medusa. With vanilla, the fireball's travel (and all other game logic) would also slow down; with my proposal, you could dance a jig in front of the fireball, all at normal speed, but just not see it.

 

4 hours ago, kb1 said:

 

If you really have to slow it down, render every 4th frame or so: if (gametic & 3) == 0, or something.

 

Not a bad suggestion, thanks.

[Quasar]

It's totally inaccurate to do it like that and thus not doing it at all is better from my POV. Medusa didn't slow down the renderer, it slowed down your entire CPU by making it try to draw what it thought was a gigantic several-megabytes large patch graphic.

[Linguica]

I sort of agree that it would be the best to do Something when there is a Medusa error on screen, it's just not clear what that Something is, since intentionally pegging the CPU is obviously out of the question and wouldn't even cause the same result anyway.

[axdoomer]

What about adding this feature in Chocorenderlimits instead? It is specifically designed to playtest levels for vanilla Doom. I read a lot about CRT monitor emulation and CPU emulation in this thread. I feel like all of this would make Chocolate-Doom scope creep. Where do you stop?

[kb1]

8 hours ago, Quasar said:

It's totally inaccurate to do it like that and thus not doing it at all is better from my POV. Medusa didn't slow down the renderer, it slowed down your entire CPU by making it try to draw what it thought was a gigantic several-megabytes large patch graphic.

Exactly - this was my biggest opposition. To emulate it "properly", you'd have to read invalid memory, and try to "render" it like Medusa did. And, which invalid memory do you use? It depends on the current layout of memory, in DOS, right? So, there is no real proper way. Sure, you could fake it. I'd be inclined to show a sprite when Medusa happens. How about showing patch Doom SW2_4, when Medusa occurs? That would not be original, but you cannot do original. I think that would be kinda cool! You could pop it up like the Disk In Use sprite does, off to one corner.

 

For the wall itself, I would do a fix-up on the texture - maybe not a proper fix-up, but just make it valid, so it can be rendered without a crash. Or you could do a dedicated drawer that mixes pieces of the texture with pink (255) and black (0) lines. You could do just about anything here. It's like some C operations: It is implementation specific, and undefined.

 

Another idea is to just HOM the wall. Or, paint it black (0), or even better, pink (255).

 

With a lot of effort, yes, you could emulate the DOS effect, including the slowdown, to the point of making the slowdown realistic. But, what does this gain? I can;t see the slowdown being a benefit to anyone. Ugly rendering? Maybe. Slowdown? No - no benefit at all. Wow, it's really difficult for me to know what I would do in this situation. I guess, if it were me, I would emulate the look of Medusa, but ditch the slowdown.

 

On 6/6/2017 at 5:07 PM, Csonicgo said:

That is one of my unanswered questions: Was Doom reduced to 35Hz clock due to DMX, or was that a coincidence that happened to work? A lot of Doom's behavior relies on that.

I'm not sure if it's what Doom did, but using the sound card is a very reliable way to handle timing, since sound timing must be accurate, if you expect it to sound correct!

Edited June 10, 2017 by kb1 : Added some ideas

[Graf Zahl]

I think the best course of action would be to draw the wall with something that immediately looks wrong - but emulating the real effect sounds like total overkill because so much of it depends on undefined or system specific behavior. The important thing is to make clear that something is not working correctly, right?

[Gez]

Draw random noise.

[Jon]

I think this is why you guys are off doing interesting ports with new features rather than working on chocolate, because we see things so differently ;)

[axdoomer]

On 6/10/2017 at 4:14 PM, Gez said:

Draw random noise.

Random noise is not accurate at all. When there is a medusa in vanilla Doom, you can see patterns inside the texture. Things like opening the menu will change these patterns. 

[Gez]

3 hours ago, axdoomer said:

Random noise is not accurate at all. When there is a medusa in vanilla Doom, you can see patterns inside the texture. Things like opening the menu will change these patterns. 

And?

 

How important are the patterns in the garbage? Are there any mod out there where the medusa patterns are an essential part of the gameplay? Is there any reason why replicating the visual output of vanilla when medusa glitching would need to be pixel-accurate? Is it even possible to do so?

[Jon]

It's pretty important to me, at least, that a PWAD that would make doom unplayable on vanilla has a similar effect on chocolate. Replicating the *look* of medusa is not the hard part anyway, and Quasar has basically already implemented that.

[Doomkid]

I genuinely love that there's a discussion about how to get Medusas to fuck up your experience as badly as they did back in the old times. When Doomers say they want the experience authentic, they mean it!

[Jon]

FWIW I care much more about getting HOM right :)

[kb1]

On 6/13/2017 at 9:06 AM, Doomkid said:

I genuinely love that there's a discussion about how to get Medusas to fuck up your experience as badly as they did back in the old times. When Doomers say they want the experience authentic, they mean it!

Heh - yeah, it's as ridiculous as it is important, which can't be said about very many things. There can be a lot of nostalgia involved. I know that first time I saw Medusa was almost a creepy experience. Preserving such a strange thing preserves the possibility of someone else experiencing that same feeling - that makes it important. And cool. And, of course, Chocolate and friends are supposed to recreate everything possible, for vanilla mappers and players alike.

 

But, yeah: Don't tread on my Doom!

[Jon]

On 6/15/2017 at 3:07 AM, kb1 said:

I know that first time I saw Medusa was almost a creepy experience. Preserving such a strange thing preserves the possibility of someone else experiencing that same feeling - that makes it important.

 

This is a really good way of expressing what I feel about it.

[Quasar]

I won't be merging or working on the feature at all in the future if we're going to insist that it be marred with a grossly overcomplicated and inaccurate slow-down effect. It wasn't going anywhere anyway because I couldn't get good enough feedback on how to do it. Let it rot I guess. You'd think the most important thing would be making wads that WERE playable in vanilla NOT crash Chocolate, which is what they do now. But I guess not???

[printz]

I think it's dumb to slow down the game like it was in the early years, considering that vanilla Doom can still be run today and runs at top speed. I think it's much easier to tune down DOSBox or an equivalent emulator to act like an old PC, and run vanilla Doom.

 

All that should somehow be done is simulate the vanilla Doom visual glitch, but it's probably something ugly and approximative to do.

[Jon]

On 6/16/2017 at 7:52 PM, Quasar said:

I won't be merging or working on the feature at all in the future if we're going to insist that it be marred with a grossly overcomplicated and inaccurate slow-down effect.

 

That's fine, nobody should be expected to work on something they're not interested in their spare time.

 

On 6/16/2017 at 7:52 PM, Quasar said:

It wasn't going anywhere anyway because I couldn't get good enough feedback on how to do it. Let it rot I guess. You'd think the most important thing would be making wads that WERE playable in vanilla NOT crash Chocolate, which is what they do now. But I guess not???

 

That's not fine, nobody should be shamed from working on what they want in their spare time.

 

In terms of priorities for chocolate doom I think the blockers for v3 are all relating to building on Windows. If you think we should be focussing on that, then I'd love your input on those, especially as you are the only windows-using developer on the project. But to be clear, if you don't want to work on that that's fine from my POV, because, to restate, I don't think anyone can expect or demand any volunteer to spend their free time on something they're not interested in.

 

Edit: actually I'm mistaken and the windows build issues are not marked as blockers for v3. (the actual blockers)

Edited June 19, 2017 by Jon

[KVELLER]

I have a question about Chocolate Hexen: is there any way to play with the music CD? I have a WAD with the music as well, but I'm guessing the source port won't allow anything that isn't a MIDI.

[chungy]

I don't believe there's a way to use the CD directly, but if you rip the tracks and encode them as FLAC or Ogg Vorbis files, you can use those in place of the MIDI tracks. If you're using Windows, that'll probably mean using the v3.0.0-beta

[PVS]

I found an interesting situation for me with Heretic when recording demo for E1M1 map from this wad:
https://www.doomworld.com/idgames/levels/heretic/g-i/irvel

I'm recording on Heretic 1.3, vvHeretic4, Chocolate Heretic 2.3.0 - no one engine can not playback its own demo recorded on this map, they are all in desync. It's easy to check, for example, record demo 2-3 minutes long for this E1M1 map and try to playback it. For me they always go to desync around the first minute of playback.

I think, I just do not know something, but I'm really interested - what's wrong in this map, that the original Heretic engine can't correctly reproduce game-world situation while playback its own demo for this map?
 

[fraggle]

18 hours ago, KVELLER said:

I have a question about Chocolate Hexen: is there any way to play with the music CD? I have a WAD with the music as well, but I'm guessing the source port won't allow anything that isn't a MIDI.

Chocolate Hexen 2.x should support CD playback but I haven't tested it in forever. The functionality has been removed with the 3.x series because SDL2 no longer has a CD playback API, but digital music packs should provide the same functionality in a far more convenient form (ie. no need to waste time messing around with physical CDs any more). I'm planning to provide a rip of the Hexen CD music as a downloadable pack.

[axdoomer]

On 7/4/2017 at 3:38 PM, PVS said:

I found an interesting situation for me with Heretic when recording demo for E1M1 map from this wad:
https://www.doomworld.com/idgames/levels/heretic/g-i/irvel

I'm recording on Heretic 1.3, vvHeretic4, Chocolate Heretic 2.3.0 - no one engine can not playback its own demo recorded on this map, they are all in desync. It's easy to check, for example, record demo 2-3 minutes long for this E1M1 map and try to playback it. For me they always go to desync around the first minute of playback.

I think, I just do not know something, but I'm really interested - what's wrong in this map, that the original Heretic engine can't correctly reproduce game-world situation while playback its own demo for this map?
 

If your demos don't desync the same way when played back in Heretic vs Chocolate-Heretic, then open a bug report and people will try to find what's different between both engines.

[VGA]

Where can I find more info about this vvHeretic4 port?

[PVS]

axdoomer
I mean, if you record demo for this map on Chocolate Heretic - it will be playback with desync on Chocolate Heretic. Similarly, if you record on vanilla Heretic 1.3 - vanilla Heretic can't playback this demo without desync.

I checked the rest of the maps from this author and found one more:
https://www.doomworld.com/idgames/levels/heretic/s-u/sym

I'm open this maps in Doom Builder 1.68 and Eureka 1.21 -> check for any errors -> these editors do not show errors for these maps. Now I have 2 Heretic maps for which it is impossible record demos in vanilla format. Custom demo format is possible, I'm tested on old Doomsday - this port normally playback it own demos for this maps.

This is a new situation for me, I did not know before that there could be such Heretic maps (old vanilla compatible PWAD's) for which it is not possible to record a vanilla demos. At the moment I do not know what's wrong in this maps for Heretic engine, for this reason I asked my question, maybe someone knows the answer. I attach my test demos, if anyone will be interested in this technical issue.

VGA
I've never seen web page or site with detailed information about vvHeretic patch, I think, all we are have is his txt file. I regularly use vvHeretic, maybe I can help if you have specific questions. Send me PM or you can use this topic for this, perhaps it will be more correct:
https://www.doomworld.com/forum/topic/39179-heretic-demos-non-demopack-and-nm/
 

HereticProblem.zip