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

Chocolate Doom

Recommended Posts

Lemonzest said:

yeah because you drop below 35fps?

I'm not exactly sure what you're trying to say. If you're saying that v-sync in general causes lower framerates, that's only with double-buffered v-sync. Triple-buffered v-sync does not reduce framerate whatsoever.

Share this post


Link to post
AlexMax said:

I have noticed an odd issue. If you alt-tab in Chocolate Doom on Windows, and then navigate back to Choco by any means, the automap (or whatever you have bound to Tab) goes haywire. For some reason, Odamex exhibits the same behavior, but Eternity and pr+ do not.

Are the exact conditions and game behavior the same as in this earlier bug report? If so, I can definitely confirm it happening on my system also. And fraggle commented it probably being a Windows or SDL issue beyond his control.

Share this post


Link to post
AlexMax said:

I have noticed an odd issue. If you alt-tab in Chocolate Doom on Windows, and then navigate back to Choco by any means, the automap (or whatever you have bound to Tab) goes haywire. For some reason, Odamex exhibits the same behavior, but Eternity and pr+ do not.

Try tapping Alt.

Share this post


Link to post

SDL event handling is broken (re: alt-tab). Dump events to console (or log them) to discover the hell you're descending into.

Share this post


Link to post
Ladna said:

SDL event handling is broken (re: alt-tab). Dump events to console (or log them) to discover the hell you're descending into.


I did, which is how I figured out when Odamex was getting what events. I was not amused.

I am also not quite sure how Eternity handles it because its input handling at the SDL_Event -> Event level looks much simpler, but then it descends into Eternity-specific functions fairly quickly thereafter.

Share this post


Link to post

Hey I'm trying to get Chocolate Doom running on Macos X 10.6.8 and no luck : it loads to a blank screen, waits a few seconds and then crashes to the desktop with an 'unexplained error'. So I ran it from the terminal to see what error it spat back at me and this is what I found.


2012-09-14 01:38:50.737 chocolate-doom[1331:910f] *** __NSAutoreleaseNoPool(): Object 0x22e370 of class NSCFString autoreleased with no pool in place - just leaking
2012-09-14 01:38:50.742 chocolate-doom[1331:910f] -[__NSCFType objectForKey:]: unrecognized selector sent to instance 0x21a120
2012-09-14 01:38:50.743 chocolate-doom[1331:910f] *** __NSAutoreleaseNoPool(): Object 0x407a40 of class NSCFString autoreleased with no pool in place - just leaking
2012-09-14 01:38:50.744 chocolate-doom[1331:910f] *** __NSAutoreleaseNoPool(): Object 0x231940 of class NSException autoreleased with no pool in place - just leaking
2012-09-14 01:38:50.745 chocolate-doom[1331:910f] *** __NSAutoreleaseNoPool(): Object 0x407990 of class _NSCallStackArray autoreleased with no pool in place - just leaking
2012-09-14 01:38:50.746 chocolate-doom[1331:910f] *** __NSAutoreleaseNoPool(): Object 0x407a00 of class _NSCallStackArray autoreleased with no pool in place - just leaking
2012-09-14 01:38:50.747 chocolate-doom[1331:910f] An uncaught exception was raised
2012-09-14 01:38:50.748 chocolate-doom[1331:910f] -[__NSCFType objectForKey:]: unrecognized selector sent to instance 0x21a120
2012-09-14 01:38:50.749 chocolate-doom[1331:910f] *** __NSAutoreleaseNoPool(): Object 0x22e2f0 of class NSCFString autoreleased with no pool in place - just leaking
2012-09-14 01:38:50.751 chocolate-doom[1331:910f] *** __NSAutoreleaseNoPool(): Object 0x846e00 of class NSCFString autoreleased with no pool in place - just leaking
2012-09-14 01:38:50.752 chocolate-doom[1331:910f] *** __NSAutoreleaseNoPool(): Object 0x407a20 of class NSConcreteMutableData autoreleased with no pool in place - just leaking
2012-09-14 01:38:50.753 chocolate-doom[1331:910f] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[__NSCFType objectForKey:]: unrecognized selector sent to instance 0x21a120'
*** Call stack at first throw:
(
0 CoreFoundation 0x955466ca __raiseError + 410
1 libobjc.A.dylib 0x950a55a9 objc_exception_throw + 56
2 CoreFoundation 0x9559390b -[NSObject(NSObject) doesNotRecognizeSelector:] + 187
3 CoreFoundation 0x954ecc06 ___forwarding___ + 950
4 CoreFoundation 0x954ec7d2 _CF_forwarding_prep_0 + 50
5 CoreFoundation 0x9548c2b7 CFDictionaryGetValue + 71
6 libSDL-1.2.0.dylib 0x00106aeb QZ_ThreadFlip + 235
7 libSDL-1.2.0.dylib 0x000e2956 SDL_RunThread + 54
8 libSDL-1.2.0.dylib 0x001089b1 RunThread + 17
9 libSystem.B.dylib 0x93c19259 _pthread_start + 345
10 libSystem.B.dylib 0x93c190de thread_start + 34
)
Trace/BPT trap



Any ideas guys?

Share this post


Link to post

I wanted to request a feature. Since it was never intentional that sound pitch effects were removed (only broken due to changes in sound code implementation), and since for similar reasons with network code rewrites the -left and -right functions were broken as well, can you guys consider reimplementing the pitch effects? Obviously, it should be off by default, since this wasn't the actual behavior of 1.9, but it'd be nice to be able to set it in the configuration.

Share this post


Link to post

Seems OPL pass through breaks BAD on NO_HZ kernels, confirmed in RHEL based distro's (Scientific Linux) and Mageia 2 with the tmb flavour kernel.
Sound is all stuttery and out of tune/timing problems. Works as normal on standard 1000HZ Kernels (As reported earlier in the thread with my 8738)
Maybe the timing loop depends on regular irq or something?

Share this post


Link to post

Are we going to see any support for the XBLA IWADs, now that they're the most recent official PC releases of the classic games? After all, there was support for Hacx 1.2. If not, I can understand, these IWADs came long after the fact, and are by no means contemporary to Vanilla Doom 1.9.

Share this post


Link to post

I've added No Rest for the Living support to my own Chocolate-Doom build. One problem (for compatibility) is that the NRFTL maps will not all function with vanilla limits.

Share this post


Link to post

Yeah, NR4TL requires a limit-removing port, so that's a no-go unless Fraggle wants to add a lot of hacks and exceptions. :P

As for the existing wads, they run just fine in Choco with the exception that Doom2.wad is missing a TITLEPIC for some reason. That and you can't access Betray without warping to it, but it's debatable whether or not supporting that map is actually worthwhile. :P

Share this post


Link to post

In an ideal world it would be nice to support but in practise the fact that the levels exceed Vanilla limits makes it too much of a detour from Chocolate Doom's design goals. It's not really the same as Hacx where the majority of the game is designed to run with Vanilla.

Share this post


Link to post

Basic support for NRFTL would probably only need two changes i.e. increasing MAXVISPLANES and MAXDRAWSEGS (like doom2plus does).

The titlepic problem can be resolved on some ports with a DEHACKED patch i.e.
TEXT 8 8
TITLEPICDMENUPIC
or
TITLEPICINTERPIC

Share this post


Link to post
marineController said:

Basic support for NRFTL would probably only need two changes i.e. increasing MAXVISPLANES and MAXDRAWSEGS (like doom2plus does).

This would be nice to have just to support NRftL. Chocolate Doom already has different executable behavior options based on what IWAD it detects is loaded, so why not have a specific behavior for NERVE.WAD? I'd imagine that perhaps it could load it as if it were an IWAD, in the same vain as HEXENDD.WAD.

NRftL was designed with Vanilla features and engine in mind, just not its technical rendering limits, so I personally believe that it's close enough, but I'm not the developer, so...

Share this post


Link to post

No Rest for the Living is not a vanilla wad and playing it in Chocolate Doom is no more authentic than playing it in PrBoom-plus -complevel 2 (or Eternity, which supports the 360 .disk file natively, with -vanilla). It was designed to be played in 720p in an engine with higher limits. It's no different from any of the other limit removing wads in the archive. You wouldn't suggest compromising Chocolate Doom's vanilla only philosophy to support those.

Share this post


Link to post

Chocolate Doom's 'vanilla only philosophy' already includes optional savegame and demo limit removal.
With the release of Doom 3 BFG Edition the landscape of what's officially Doom has changed.
If a similar option for render limits was introduced which would extend / preserve the original vanilla limits and allow users to play No Rest for the Living I personally cannot see how this would be a problem.

Share this post


Link to post

That's up to fraggle. Were I in his place, I probably wouldn't have included the option to break those other limits or record longtics demos.

But really, why do you want to play a modern wad in a recreation of an executable that can't run it in the first place? Play it in id's official Windows port or PrBoom-plus/Eternity.

Share this post


Link to post

This is fraggle's last call, obviously, although it's certainly stuff that's debatable and there's no one answer to what vanilla elements an engine like Chocolate Doom could support or leave aside. Doom can run the Nerve levels just fine with the Doom+ hacks, so they're compatible with vanilla as long as you download the hack. That's not much different from needing GothicTx to run some WAD, or needing an infinite ammo DeHackEd patch to play some level set properly. If a binary hack like Doom+ is "not vanilla", neither is DeHacked.

Leaving Doom+ out enhances and strengthens Chocolate's role as a "within the original limits" engine, only raising some optionally for ease of use purposes, which is a fair enough development choice. That way it sustains and promotes pure (as opposed to "limit removing") vanilla editing and is closest to the game out of the box. Occasional demands to add Doom+ support are to be expected, because it's certainly Doom compatible, but they're less critical with the availability of DOSBox and PrBoom+ (which you can set up to look and behave almost indistinguishably like vanilla).

Share this post


Link to post
marineController said:

Basic support for NRFTL would probably only need two changes i.e. increasing MAXVISPLANES and MAXDRAWSEGS (like doom2plus does).

The titlepic problem can be resolved on some ports with a DEHACKED patch i.e.
TEXT 8 8
TITLEPICDMENUPIC
or
TITLEPICINTERPIC


Logically, there would be something like this:

	if ( gamemode == bfgedition )
	{
		pagename = "INTERPIC";
	}
	else
	{
		pagename = DEH_String("TITLEPIC");
	}
Of course, the "if ( gamemode == commercial )" throughout the code would have to become "if ( gamemode == commercial || gamemode == bfgedition )".

As for supporting NERVE.WAD, that's a bit more complicated. Increasing MAXVISPLANES and MAXDRAWSEGS selectively only in BFG Edition mode is not easily possible. It means either making the visplanes[] and drawsegs[] arrays dynamic instead of static; or duplicating them (so there's a "bfgvisplanes[]" and a "bfgdrawsegs[]" arrays in addition to the normal ones), and having the functions that use these arrays to have conditional switches depending on game mode.

Share this post


Link to post
Gez said:

As for supporting NERVE.WAD, that's a bit more complicated. Increasing MAXVISPLANES and MAXDRAWSEGS selectively only in BFG Edition mode is not easily possible. It means either making the visplanes[] and drawsegs[] arrays dynamic instead of static; or duplicating them (so there's a "bfgvisplanes[]" and a "bfgdrawsegs[]" arrays in addition to the normal ones), and having the functions that use these arrays to have conditional switches depending on game mode.

Could you not just increase the static allocation, then test the index for being out-of-bounds, against a variable? (I might be missing something here...)

maxvisplanes = (is_bfg_edition ? 256 : 128);

if (visplane_count >= maxvisplanes)
{
  I_Error("visplane overflow\n");
}
I don't think it would screw up demo/record/net sync, at least not until fatal overrun had occurred.

Yeah, I think NERVE.WAD is not really "vanilla" either, but it *is* considered "official". Tough call. If it were me, I'd probably support it, and here's why:

1. It's not much deviation from the philosophy - it's 1 WAD file.
2. For new users, there's lots of advice out there to "just use Chocolate Doom" for that "vanilla" experience.
3. New users won't understand what makes NERVE.WAD different than, say, PLUTONIA.WAD.

Share this post


Link to post
kb1 said:

1. It's not much deviation from the philosophy - it's 1 WAD file.

If you're going to put in the effort to support this one wad file, you might as well support all (maybe I should say "most" here to be reasonable) limit removing wads. Why does this one's official nature make it an exception? It wasn't intended to be played in the DOS executable, even if it can be if you hack that executable.

Look, I love Chocolate Doom and it's convenience features (built-in Dehacked, Deutex, NWT, Novert support) are what make me choose it over running the original executable in DOSBox (which runs just as well on my PC). Supporting this wad would mean a huge departure from what the port has done up to now, though. If you're bumping up the limits, why not the resolution too? After all, this wad was designed to be played in something much higher than 320x200. Why not make Chocolate Doom replicate the behavior of the BFG edition engine completely?

Share this post


Link to post

According to the wiki, XBox Doom is really a port, like the ones released for various other game consoles. Chocolate Doom tries to faithfully emulate the behavior of DOS Doom 1.9, with some concessions made for a couple mods that also got released for PC/DOS platform (Chex Quest, Hacx). So to me it doens't sound like this XBox episode really fits the bill. You'd be better off just forking Chocolate Doom and creating a general purpose limit-removing vanilla engine that can play all limit-removing stuff (including Blasphemer).

Share this post


Link to post
hex11 said:

According to the wiki, XBox Doom is really a port, like the ones released for various other game consoles. Chocolate Doom tries to faithfully emulate the behavior of DOS Doom 1.9, with some concessions made for a couple mods that also got released for PC/DOS platform (Chex Quest, Hacx). So to me it doens't sound like this XBox episode really fits the bill.

Technically, it probably "doesn't fit the bill", but, we're talking about one specific case - a file that id is including as "official".

There's 3 ways to go:
1. Be absolutely faithful, and make this "official" id file play poorly, and potentially confuse novice users who have heard about using Chocolate Doom to faithfully play id's official Doom games.

2. Be 99.9% faithful, but make this very special case work. Once again, this is most helpful to a novice user who, won't try to run NERVE.WAD on DOS Doom anyway.

3. Make a command-line option /break_nrftl, or even /fix_nrftl. I would probably lean towards the first one, citing my "novice user" thoughts.

Hell, I can easily see both sides.

Share this post


Link to post

I'm no mapper, but isn't the fact that Choco respects Vanilla's limits kind of a feature? I understand fixing the savegame/demo limits (which I would argue are bugs, especially the savegame limit), but the other limits kind of enforce a Doom-i-ness.

Plus come on, just get Pr+.

Share this post


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