Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
DuckReconMajor

Can't open Options menu in Chocolate Doom

Recommended Posts

Whenever I try to open the options menu Chocolate Doom crashes and I get a message that says "Bad V_DrawPatch". I've replaced Chocolate Doom and the IWAD and it's keeps doing the same thing.

Share this post


Link to post

In Doom, this happens when your mouse sensitivity is over 9 because the engine tries to draw the sensitivity lever off the screen. Chocolate Doom handles it the same way, it appears.

Share this post


Link to post

Yeah, I was a bit imprecise or vague above. If the lever doesn't go (at least partially) off the screen, it'll work. In your case, the lever just appears in an odd location to the right of its slot graphics.

Share this post


Link to post

Chocolate Doom sure does a good job when it comes to vanilla compatibility. This one is silly, though. It shouldn't hard to fix this behavior without affecting any other aspect of the game in any way.
Maybe add a crash option in the setup, just in case someone really wants the game to crash.

Share this post


Link to post

Oh wow. I wish I'd seen that.

But now I'm having another problem :( I tried playing Ultimate Doom. When I finished E1M1 the name "HANGAR" wasn't there, just the red "FINISHED" in its place. Then when I finished E1M2 the game just crashed, giving me the Bad V_DrawPatch message again.

So I restarted the game and this time when I finished E1M1 the game crashed and gave me Bad V_DrawPatch.

EDIT: Never mind, I was using an outdated version of Chocolate Doom, it's fixed now.

Share this post


Link to post

LogicDeLuxe said:
This one is silly, though. It shouldn't hard to fix this behavior without affecting any other aspect of the game in any way.

It may seem silly, but the crash is telling the player that the setting is unusual. Changing this makes it less intuitive when switching to and from the DOS executable. You don't have an "enable autorun" option, either.

Mouse sensitivity also appears in the setup application (unlike in the original), so it can be edited there. Maybe autorun could appear there, too (if you choose "yes" the app sets joyb_speed to 29).

Still, Chocolate Doom already has some input differences (like disabling double-click use or lifting the savegame limit), so such a fix could be argued for. Maybe making it terminate with a more explicit message could be a solution, too. The error could say something like what's one the FAQ. This would have the benefit of not confusing people (informing them) yet retaining functionality.

It's also a global type of behavior, so, if implemented, a fix would have to be an exception for the little lever. That is, any graphic drawn off the screen like that will cause that Bad V_DrawPatch termination.

Share this post


Link to post

I have considered adding a "be annoyingly compatible" option to disable this crash and other things (eg. IDCLIP only working in Doom II). I'm keen to avoid having too many compatibility options though - I specifically want to avoid ending up with something like the Boom compatibility options menu.

Share this post


Link to post

I have another problem. Sometimes when I pick up an item or take damage, the border flashes non-stop (yellow for items, red for damage). I'm using version 1.2.1.0 but it did it with other versions too.

Share this post


Link to post
fraggle said:

I specifically want to avoid ending up with something like the Boom compatibility options menu.

Since Chocolate Doom isn't supposed to be a Boom clone, I don't think that this is an issue.
I don't think there is a need for logic fixes like stair building, inverse invulnerability sky, Lost Souls outside map and the like.

But bugs which have no influence for game play and the feel of it, but are just annoying really are a different thing. There is an option for avoid the savegame limit, so I see no reason not to have an avoid crashing due to invalid slider positions as well.

And combining all those annoyance compatibility options into one is fine for me. I can't really think of a reason to disable just some and keep other bugs of this kind. It's either all for testing for vanilla compatibility, or none for convenient playing.

Share this post


Link to post
myk said:

You don't have an "enable autorun" option, either.

Not sure what you consider "an option". But strictly speaking you have the option of using autorun in Vanilla Doom. Only that you need to know how to set it on and you need to edit the cfg file to do it.

But the same can be said about many things concerning modern games as well.

Share this post


Link to post
fraggle said:

I have considered adding a "be annoyingly compatible" option to disable this crash and other things (eg. IDCLIP only working in Doom II). I'm keen to avoid having too many compatibility options though - I specifically want to avoid ending up with something like the Boom compatibility options menu.

How many annoyances are there to fix anyway? At least ones that don't really affect gameplay/demo compatibility (even then, lifting demo/savegame limits affect compatibility in a minor way).

It would actually be kind of nice to have some things in the Compatibility menu of chocolate-setup besides the two that are there already. IDCLIP/IDSPISPOPD working only in one game and not the other, no cheats in Nightmare, crash on the Options menu, and maybe some others I'm thinking of (perhaps various sound/graphics quirks whose fix wouldn't break compatibility, like the double-door-close sound?). Of course the default should be just like vanilla Doom, and it'd probably be best to add a "Reset to Defaults" in the setup so that users can revert back to a "do everything like vanilla" game easily.

Just an idea, and I admit that even I don't feel like this would be necessarily a good idea, but I'm throwing it out there.

Share this post


Link to post

Having the autorun option in Chocolate Setup is one thing, but changing the engine behavior itself seems to be a slippery slope. Then again, I'm not entirely sure I like the savegame limit removal option.

Share this post


Link to post

Well there's two ways to tackle the problem:

1. Chocolate Doom itself incorporates the compatibility options (including savegame/demo limit removals) and possibly compromises the goal of the project.

2. A pseudo-fork (more like a patchset) is maintained to add the compatibility options outside of the official port. Chocolate Doom remains clean and players wishing to have deliberately-non-vanilla features could simply use the fork instead.

3. Is there a number three? If anyone else can think of yet another way to solve this problem, go right ahead :-)

Personally, given the choices, I would much prefer #2. That way, fraggle doesn't have to worry about the slippery slope when it comes to compatibility/behavior options.

Share this post


Link to post

It seems like a waste to spend effort adding more fixes, as PrBoom can already do them all. People who are really bothered by Doom quirks can easily run PrBoom at compatibility levels 2-4.

LogicDeLuxe said:
And combining all those annoyance compatibility options into one is fine for me.

Yeah, one thing that, in retrospect, I really dislike in MBF is how all sorts of fixes and options were made individual. In this aspect Boom's plain "try to behave as much as possible like Doom" was a much better choice.

kristus said:
Not sure what you consider "an option".

I meant in the game options menu, although I see now by what DuckReconMajor said that it is already in the setup thing (I'm so used to editing the CFGs that I missed it :p).

Share this post


Link to post

PrBoom in complevels 2-4 actually behaves a lot like Chocolate Doom, so it doesn't really solve anything in this regard. :/

The "fixes" are really all minor and there's not much effort that would be required to be done.

Share this post


Link to post
myk said:

Yeah, one thing that, in retrospect, I really dislike in MBF is how all sorts of fixes and options were made individual. In this aspect Boom's plain "try to behave as much as possible like Doom" was a much better choice.

No this is good because it means I can turn off bugs that annoy me (e.g. ghosts, monsters stuck on doortracks) but leave others on because the fixes annoy me (monsters don't fall off ledges, dead players can still exit levels)

Share this post


Link to post

MikeRS said:
PrBoom in complevels 2-4 actually behaves a lot like Chocolate Doom, so it doesn't really solve anything in this regard. :/

It behaves like Chocolate Doom without "annoyances" (even beyond some of the propositions, since you can raise screen resolution, apply OpenGL effects, it removes static limits, and so on), which is what some people are proposing to incorporate into Chocolate. If anyone is talking about changing Chocolate Doom to make Boom-like game-play fixes (that is, disrupt even demo compatibility) maybe they should get out of here :p

RjY said:
No this is good because it means I can turn off bugs that annoy me (e.g. ghosts, monsters stuck on doortracks) but leave others on because the fixes annoy me (monsters don't fall off ledges, dead players can still exit levels)

Why bother? It's easier and more consistent to play a vanilla level with Doom behavior and a Boom level with Boom behavior. Imagine sharing demos where each demo has different settings. Doom behavior is playable, Boom behavior is playable, once you play them enough the "annoyances" are irrelevant. Also, you don't know which fixes were applied when testing a map, and thus you might have to mess with the settings or consult (possibly inexistent) WAD documentation for necessary options to avoid bugs.

In Killough's defense, he did try making allowances by adding the OPTIONS lump, which, lo and behold, is not functional in PrBoom!

Share this post


Link to post
RjY said:

No this is good because it means I can turn off bugs that annoy me (e.g. ghosts, monsters stuck on doortracks) but leave others on because the fixes annoy me (monsters don't fall off ledges, dead players can still exit levels)

I don't think we are talking about gameplay fixes here. Any bugfix affecting gameplay or demo compatibility is out of question, I think. You would play PrBoom etc. if you need those fixed.

Share this post


Link to post

Yeah, he isn't saying that he'd like those particular options in Chocolate, just that he likes the possibility of making small changes (a ton of different options as opposed to, or in addition to, sets of changes that you enable with one choice).

Share this post


Link to post
exp(x) said:

Option 2 sounds good to me. Mint Chocolate Chip Doom?

Wasn't there a Strawberry Doom version of Chocolate Doom that removed some limits?

Share this post


Link to post
LogicDeLuxe said:

Since Chocolate Doom isn't supposed to be a Boom clone, I don't think that this is an issue.
I don't think there is a need for logic fixes like stair building, inverse invulnerability sky, Lost Souls outside map and the like.

But bugs which have no influence for game play and the feel of it, but are just annoying really are a different thing. There is an option for avoid the savegame limit, so I see no reason not to have an avoid crashing due to invalid slider positions as well.

And combining all those annoyance compatibility options into one is fine for me. I can't really think of a reason to disable just some and keep other bugs of this kind. It's either all for testing for vanilla compatibility, or none for convenient playing.

This is all basically the same view that I have.

I want to avoid unnecessary options where possible, but having options is a better solution than maintaining a separate forked version, which in my opinion would be rather pointless.

I consider things like savegame and demo limit removal to be in a different class to things like visplane overflows, because they're used differently. I don't mind bending the rules a bit here and there. The compatibility options are all things that I turn off when configuring my settings (of course, they're all on by default). Plus, it's useful to be able to generate large demos and savegames, because Vanilla Doom can still load them, even though it can't generate them.

exp(x) said:

Mint Chocolate Chip Doom?

Heh, I've heard lots of jokes about potential spin-off source ports based on ice-cream names - "Chocolate Peanut Butter Swirl Doom", etc. But the thought of someone actually making a source port with such a clumsy name makes me cringe and I hope nobody will actually do it. The one remaining good option - Strawberry Doom - was used by GhostlyDeath for his port, but the port itself was unstable and incoherent, and in my opinion a waste of a good name.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
×