Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Janizdreg

Chocolate Doom

Recommended Posts

Ajapted said:
The medusa effect is painfully slow for me (no difference between chocolate and vanilla).

Well, that made me learn some behavoral aspects of the medusa effect; the slowdown depends on the initial point of perspective, and some changes can alter the effect. After opening and closing the menu while viewing a medusa, it changed color and the slow-down practically went away. Still tends to be slower for me on Doom for some reason. Maybe it was all coincidence...

Share this post


Link to post
myk said:

the slowdown depends on the initial point of perspective


Could you elaborate on that any?

While you're all on the topic, does anyone know what actually causes medusa, from a technical standpoint?

Share this post


Link to post
EarthQuake said:

While you're all on the topic, does anyone know what actually causes medusa, from a technical standpoint?

Composite textures are converted from runs of posts into a flat chunk of pixels , but the mid-mask rendering code assumes it is still a run of posts and keeps drawing posts until it finds a post-end byte (0xFF), which could mean hundreds or thousands of junk posts drawn. Perhaps not as many junk posts as in E.E though :).

Share this post


Link to post

I was playing STRAIN with 0.1.2 and I noticed that most of the sounds weren't working. A little bit of investigating revealed that they were set to weirdass frequencies. Does this happen with Vanilla Doom as well? I would have tried it on my Win98 box, but it has a shitty sound card that doesn't appear to be compatiable with anything supported by Vanilla Doom.

Share this post


Link to post
deathz0r said:

I was playing STRAIN with 0.1.2 and I noticed that most of the sounds weren't working. A little bit of investigating revealed that they were set to weirdass frequencies. Does this happen with Vanilla Doom as well? I would have tried it on my Win98 box, but it has a shitty sound card that doesn't appear to be compatiable with anything supported by Vanilla Doom.

Sound effects which are not at 11025Hz or 22050Hz are not played by Vanilla Doom. Chocolate Doom behaves in the same way.

Share this post


Link to post

Not really; keep in mind that back when they made STRAIN there was nothing but Doom2 to test it on. Of the 24 sounds they added, only 3 have a rate of 11025 Hz, 1 of 15591 Hz, 1 of 16518 Hz, 1 of 18542 Hz, 1 of 20812 Hz, 7 of 22050 Hz, 1 of 27781 Hz, and 9 of 44100 Hz. Doom2 plays all of them. In Sci2 there are issues with a couple weapon sounds that don't work, but they seem to be corrupt, since they are apparently 11,025 Hz (XWE extracts them and then you can play them with Media Player at 11,025 without problems.)

Doom has issues with WAVs mainly if they aren't 8-bit mono files.

Share this post


Link to post

I like Chocolate Doom to be as precise as the original in terms of crashing and everything. Apart from maps for limit removing engines, I also plan to start making few maps that have to run in the old doom engine, just to restrict myself (challenge?). When I made some older regular maps with too much detail at few places, I was using Zdoom to test them so I didn't knew. It was a dissapointed to find out later that they crashed the classic doom engine in DOS :P. Now, I can test my maps from windows with this port. So, I want it to be as precise as it gets..

..and btw, a newer map I am still building crashes the classic doom engine (I think, because I use many linedefs with length less than 4 in a case) but not chocolate doom (at least visplane errors appear as they should ;). I hope this will be fixed, I'll see if there is a newer version of this port and try again, perhaps it's already fixed. Else, I'll consider contacting the programmer of this soon..

p.s. How funny, there is a new definition of "fix/works" in my post. This time, it HAS to crash so that it's true! =)

Share this post


Link to post

Instead of visplane overflow causing a fatal error, I'd rather it displayed a black screen with something like:

Visplane overflow (138)
Press F1 key to continue playing
Similarly for savegame buffer overflow, show a screen saying that the buffer would have overflowed in original Doom, but allow it to work.

Share this post


Link to post

That kind of stuff gives a different twist to the project. I read it was "a Doom source port which aims to behave as closely as possible to the original DOS Doom executables." If those were to be added, as options of course, I don't see how they shouldn't be left at the very bottom of the list after other things that need to be implemented of fixed (MultiPlayer, sound code, initial mouse response, etc.)

Optimus said:
..and btw, a newer map I am still building crashes the classic doom engine (I think, because I use many linedefs with length less than 4 in a case) but not chocolate doom (at least visplane errors appear as they should ;). I hope this will be fixed, I'll see if there is a newer version of this port and try again, perhaps it's already fixed. Else, I'll consider contacting the programmer of this soon..

What version of Doom are you using, what OS is it running on, and what error or error effect is displayed?

Share this post


Link to post
myk said:

That kind of stuff gives a different twist to the project. I read it was "a Doom source port which aims to behave as closely as possible to the original DOS Doom executables." If those were to be added, as options of course

Option? When chocolate-doom crashes here on Linux (e.g. savegame overflow), the system is left in an unusable state (320x200 mode, mouse pointer grabbed and won't move). Surely it's not too much to ask that this be handled more gracefully.

Share this post


Link to post

Heh, might as well have mentioned in your original post that it rapes your system, eh? Had I not said anything it would have looked like you presented your idea on a whim. My opinion was that if you're emulating something to the last detail (as far as possible), then that's what you do. And given that in DOS or Windows you don't have those mouse and video issues, it's clear that it's just not doing the right thing in Linux (at least in regard to your setup; I've no experience in Linux with Chocolate Doom.)

Share this post


Link to post

Nevertheless, the savegame buffer is certainly one of the things that should be expanded. Of all of Doom's limitations this was by far the most frustrating one.

There were some old levels I never played until late in 1998 because they were just too large for saving. 'Castle of Evil' comes to mind - probably the only 1994 level I had sitting on my HD for more than 4 years before finally playing it. This level is so large and complex that I found it quite tedious having to restart from scratch for each minor mistake I made so I never got through it.

Printing a warning that the savegame buffer would have overflowed in Doom2.exe is more than sufficient IMO.

Share this post


Link to post
myk said:

Heh, might as well have mentioned in your original post that it rapes your system, eh?

Oops, yeah. I thought you were advocating chocolate doom should crash whenever vanilla would crash. No application should crash if it can help it, even one closely emulating something else.

Share this post


Link to post

if (VisplaneOverflow) {

  printf("There has been a\n" \
  "vislane overflow. at %s" \
  "Press Enter to continue playing." \
  , plyr->coords);
getchar();
}

just an idea.

/slap me if this is wrong,. I spend too much time with the dosdoom code. And that is a mess.

Another question, the sound in chocolate doom in Linux sounds different to prboom. Is that to make it sound more like MSDOS doom.?

Share this post


Link to post

Showing up a message of the error that has appeared and let you continue would be ok for me, if you can de/select it as an additional option only for those who need it. I'd mostly want it to crash as exactly as the old version does..

>What version of Doom are you using, what OS is it running on, and
>what error or error effect is displayed?

It's Doom 2 v1.9 (or was it 1.666?) iirc, Dos. I ran it from Windows and I haven't seen the command line message :P. Sorry I don't remember now, but I think I am gonna try again and check the error message they produce. I'll send you my map(s) if needed. I think I had 1-2 smaller WADs (with 1 room only) with experiments that crashed the old Doom engine. I'll try to find them and try again..

Share this post


Link to post
bejiitas_wrath said:

Another question, the sound in chocolate doom in Linux sounds different to prboom.

I also find this to be the case, but under Windows XP: in Chocolate-Doom the sound effects are a lot tinnier, for want of a better word.

Share this post


Link to post

Unfortunatelly, I can't find the errors. I tried the WADs in old Doom engine again and now they surprisly work there too. How come did I remember that they didn't worked? Perhaps there were some errors I corrected in older versions of these WADs. I'll try to recreate the errors and I'll write here again if I ever find something..

Share this post


Link to post

Maybe you had been using v1.666? On my computer it's not stable, as described here in the first review.

Share this post


Link to post

Is there a way to run it in full screen without that black bar to the right of the screen? I don't know why it does but that bar bugs me.

Share this post


Link to post

Hi everyone. I've been working on some other stuff recently and haven't done much work on Chocolate Doom. This is why I haven't done a new release yet. I have been doing some work on it over the last few weeks, however, and I certainly haven't given up on it.

I'm currently working on new networking code, you can track my work via CIA.

myk said:

Not really; keep in mind that back when they made STRAIN there was nothing but Doom2 to test it on. Of the 24 sounds they added, only 3 have a rate of 11025 Hz, 1 of 15591 Hz, 1 of 16518 Hz, 1 of 18542 Hz, 1 of 20812 Hz, 7 of 22050 Hz, 1 of 27781 Hz, and 9 of 44100 Hz. Doom2 plays all of them. In Sci2 there are issues with a couple weapon sounds that don't work, but they seem to be corrupt, since they are apparently 11,025 Hz (XWE extracts them and then you can play them with Media Player at 11,025 without problems.)

Doom has issues with WAVs mainly if they aren't 8-bit mono files.

Thanks for the correction, you are right. I have corrected the sound code, so that sounds of any sample rate will play. I added some checks on the sound effect headers, to make sure that sound effects are valid before playing them. This ensures that the sound effects in Scientist 2 do NOT play (the same behavior as Vanilla Doom), but the ones in STRAIN do play correctly.

Janizdreg said:

I just remembered something (actually quite useful) which can be found in Doom 1.9 but not in Chocolate Doom: skill level 0 support.

I've fixed this, as well.

The skill variable in Doom is an enumeration (skill_t), rather than a normal integer. When you use "-skill 0", it tries to set the variable to -1, which is not a valid value for the type. Apparently gcc treats this differently than the compiler used for Vanilla Doom. Nothing was ever changed in the code which altered this behavior (it was never "fixed"), it's just a result of the different compiler.

Share this post


Link to post

I just released a new version.

  • Imported the spechit overrun mulation code from prboom-plus. Thanks to Andrey Budko for this.
  • New show_endoom option in the chocolate-doom.cfg config file allows the ENDOOM screen to be disabled.
  • Chocolate Doom is now savegame-compatible with Vanilla Doom.
Bugs:
  • Fixes for big endian machines (thanks locust)
  • Fixed the behavior of the dehacked maximum health setting.
  • Fix the "-skill 0" hack to play without any items (thanks to Janizdreg for pointing out that this was nonfunctional)
  • Fix playing of sounds at odd sample rates (again). Sound effects at any sample rate now play, but only sounds with valid headers. This is the *real* way Vanilla Doom behaves. Thanks to myk for pointing out the incorrect behavior.

Share this post


Link to post
Grazza said:

http://sourceforge.net/project/showfiles.php?group_id=144368

fraggle: Are you planning to support more of the stuff in the "Text" section of dehacked? There's some fun entries in there - much more than just text.

Can do - there's a lot of them in there, though. There are some things I can think of which may be useful:

  • Strings which control the animated textures/flats
  • Strings which control sound/music lumps
  • Startup messages?
Can you think of any others?

Bashe said:

The downloads page appears to be showing 1.2 still...

This should be fixed now. I have the download link in two places, but I forgot to change one of them. Thanks.

Share this post


Link to post

fraggle said:
Can do - there's a lot of them in there, though.

It's probably best to go with what's established; but maybe supporting most of what DeHackEd can do unless it's very pointless or DOS specific. Making sure things that are widely supported (as far as ports and modified source builds are concerned) and used (in existing add-ons) work is most important, naturally.

Strings which control the animated textures/flats

I'm not sure animated textures and flats name changes are supported in DeHackEd itself, but the intermission text backgrounds surely are. Also, it's possible to change graphic resource names (e.g., TITLEPIC), though practically any add-on just adds a standard-named lump replacement instead of one with a new name.

Strings which control sound/music lumps

Yes, these are already supported by Boom and its offspring (annoyingly ZDoom doesn't support the music name hacks, requiring an additional MAPINFO no matter what if compatibility with it is wanted and these are messed with.)

Startup messages?

Some add-ons hack these, sometimes for kicks (I saw one with the init daemon string changed) but some for more practical reasons, changing the starup header and the PWAD warning note to name the add-on and say something specific (the Alien Vendetta DEH patch does this.)

Can you think of any others?

The names of the monsters at the end of DOOM II, if you haven't added those already. Some other stuff can be changed but is again usually just replaced by similarly named lumps; the DEMOs, for example.

Share this post


Link to post
myk said:

Yes, these are already supported by Boom and its offspring (annoyingly ZDoom doesn't support the music name hacks, requiring an additional MAPINFO no matter what if compatibility with it is wanted and these are messed with.)

Is there even one WAD which is changing the music names? I can't remember any.

Share this post


Link to post
fraggle said:

Can do - there's a lot of them in there, though. There are some things I can think of which may be useful:

  • Strings which control the animated textures/flats
  • Strings which control sound/music lumps
  • Startup messages?
Can you think of any others?

The following also strike me as worth supporting:
skies
status bar
iwad names
stats screen (maybe)

I've put some dehacked-related stuff that I've been looking into here. It includes:

  • deh_text.txt: a list of a few interesting-looking areas of DeHackEd's text section, with some comments on possible uses and support in various ports. (This gives details related to the features I list above, and others.)
  • text_deh.txt: a partial list of wads that use some of these non-standard DeHackEd "text" features. No systematic searching was used to generate this list, but it might give you an idea of some pre-existing wads you'd be supporting if you added certain features.
  • ouchetc.deh: a commented dehacked patch using a variety of "text" features, for illustrative and testing purposes. [The file-name is based on the changes it makes to the status bar. :o ]
  • maxhldeh.txt: a list of dehacked patches that use the Max Health setting. I believe this includes everything on my hard-disk that features a non-binary external deh file with this setting.
I've noticed that Boom and its descendents use a different logic from dehacked.exe for these text changes. For example, if you replace TROO with SARG, and then SARG with TROO, this results in no change in Boom. With dehacked.exe, this would actually swap these two - i.e. it based its search/replace on what the text was initially, and not what it may have been changed to by a previous search/replace.

Graf: In my list I have anadream, hyena, invasion, nmare2 and original [a Wolfendoom wad] as using dehacked to change the music entry names.

Share this post


Link to post
Guest
This topic is now closed to further replies.
×