Chocolate Doom - Doomworld Forums

Doomworld Forums : Powered by vBulletin version 2.2.5

Doomworld Forums > Classic Doom > Source Ports > Chocolate Doom

Pages (52): « First ... « 46 47 48 [49] 50 51 52 »

Author

All times are GMT. The time now is 07:42.

Lemonzest
Mini-Member

Posts: 62
Registered: 09-06

Sodaholic said:
How difficult would it be to implement triple-buffered V-sync?

yeah because you drop below 35fps?

09-10-12 11:53 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Sodaholic
Banned

Posts: 2204
Registered: 04-07

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.

09-10-12 20:41 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Janizdreg
Member

Posts: 333
Registered: 07-02

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.

09-10-12 23:15 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

exp(x)

Posts: 2466
Registered: 04-04

FYI: My SVN builds for trunk and v2 are now at (respectively):
http://www.tc.umn.edu/~delbe001/chocolate-doom/
http://www.tc.umn.edu/~delbe001/chocolate-doom-v2/

I only have 20MB allocated to me here, so I won't be keeping previous versions around like I used to. As usual, if the situation changes, I'll post here.

09-11-12 23:45 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Janizdreg
Member

Posts: 333
Registered: 07-02

The Chocolate Doom master server doesn't work and gives me "500 - Internal Server Error". Why is this?

EDIT:
Oh, it's back already. That was fast!

Last edited by Janizdreg on 09-12-12 at 01:48

09-12-12 01:09 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

DuckReconMajor
Forum Legend

Posts: 4190
Registered: 01-09

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.

09-12-12 03:10 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Ladna
Junior Member

Posts: 245
Registered: 04-10

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

09-12-12 03:21 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Sodaholic
Banned

Posts: 2204
Registered: 04-07

Sometimes when I alt-tab out, the black screen borders start flashing between black and my desktop.

09-12-12 04:09 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

AlexMax
Senior Member

Posts: 1076
Registered: 01-03

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.

09-13-12 00:06 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Phil1984
Junior Member

Posts: 157
Registered: 12-02

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?

09-13-12 16:43 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Sodaholic
Banned

Posts: 2204
Registered: 04-07

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.

10-09-12 03:33 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Lemonzest
Mini-Member

Posts: 62
Registered: 09-06

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?

10-09-12 23:44 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Sodaholic
Banned

Posts: 2204
Registered: 04-07

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.

10-16-12 21:57 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Randy87
Mini-Member

Posts: 81
Registered: 05-05

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.

10-16-12 22:39 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Xaser
Forum Staple

Posts: 2140
Registered: 07-03

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

10-16-12 22:53 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

fraggle
Filled with the code of Doom

Posts: 6607
Registered: 07-00

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.

10-20-12 19:14 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

marineController
Warming Up

Posts: 11
Registered: 08-12

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

10-20-12 19:42 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Sodaholic
Banned

Posts: 2204
Registered: 04-07

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...

10-22-12 21:50 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Dragonsbrethren
Senior Member

Posts: 1516
Registered: 03-09

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.

10-24-12 07:17 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

marineController
Warming Up

Posts: 11
Registered: 08-12

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.

10-24-12 19:26 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Dragonsbrethren
Senior Member

Posts: 1516
Registered: 03-09

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.

10-24-12 19:47 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

_bruce_
Senior Member

Posts: 1057
Registered: 11-07

Don't see how this one fits the vanilla bill.

10-24-12 19:47 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

myk
volver� y ser� millones

Posts: 14833
Registered: 04-02

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).

10-24-12 20:51 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Gez
Why don't I have a custom title by now?!

Posts: 9278
Registered: 07-07

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:

code:	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.

10-24-12 21:12 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

kb1
Junior Member

Posts: 234
Registered: 11-06

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...)

code:
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.

10-24-12 22:31 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

marineController
Warming Up

Posts: 11
Registered: 08-12

Yep, that's basically what I was thinking (same as doom2+).
I've posted my hack here pastebin.com/7vazKE3e.
I don't think the gamemode is needed just detection of the missing TITLEPIC.
Edit: Oops fixed a copy paste error.

Last edited by marineController on 10-24-12 at 23:07

10-24-12 22:55 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Dragonsbrethren
Senior Member

Posts: 1516
Registered: 03-09

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?

10-24-12 23:26 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

hex11
Forum Staple

Posts: 2062
Registered: 09-09

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).

10-24-12 23:44 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

kb1
Junior Member

Posts: 234
Registered: 11-06

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.

10-25-12 00:15 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Ladna
Junior Member

Posts: 245
Registered: 04-10

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+.

10-27-12 05:11 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

All times are GMT. The time now is 07:42.

Pages (52): « First ... « 46 47 48 [49] 50 51 52 »

Doomworld Forums > Classic Doom > Source Ports > Chocolate Doom

Show Printable Version |

Email this Page |

Subscribe to this Thread

Forum Rules:

You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

HTML code is OFF
vB code is ON
Smilies are OFF
[IMG] code is ON

< Contact Us - Doomworld >