Cacodemon
Register | User Profile | Member List | F.A.Q | Privacy Policy | New Blog | Search Forums | Forums Home
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Classic Doom > Source Ports > Chocolate Doom
Pages (57): « First ... « 46 47 48 [49] 50 51 52 » ... Last »  
Author
All times are GMT. The time now is 18:35. Post New Thread    Post A Reply
Lemonzest
Mini-Member


Posts: 61
Registered: 09-06



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


yeah because you drop below 35fps?

Old Post 09-10-12 11:53 #
Lemonzest is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Sodaholic
I feel justified yet disgusted with myself at the same time


Posts: 2704
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.

Old Post 09-10-12 20:41 #
Sodaholic is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Janizdreg
Member


Posts: 343
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.

Old Post 09-10-12 23:15 #
Janizdreg is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
exp(x)


Posts: 2595
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.

Old Post 09-11-12 23:45 #
exp(x) is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Janizdreg
Member


Posts: 343
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

Old Post 09-12-12 01:09 #
Janizdreg is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
DuckReconMajor
Forum Legend


Posts: 4223
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.

Old Post 09-12-12 03:10 #
DuckReconMajor is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Ladna
Member


Posts: 286
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.

Old Post 09-12-12 03:21 #
Ladna is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Sodaholic
I feel justified yet disgusted with myself at the same time


Posts: 2704
Registered: 04-07


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

Old Post 09-12-12 04:09 #
Sodaholic is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
AlexMax
Senior Member


Posts: 1114
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.

Old Post 09-13-12 00:06 #
AlexMax is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Phil1984
Junior Member


Posts: 189
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?

Old Post 09-13-12 16:43 #
Phil1984 is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Sodaholic
I feel justified yet disgusted with myself at the same time


Posts: 2704
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.

Old Post 10-09-12 03:33 #
Sodaholic is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Lemonzest
Mini-Member


Posts: 61
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?

Old Post 10-09-12 23:44 #
Lemonzest is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Sodaholic
I feel justified yet disgusted with myself at the same time


Posts: 2704
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.

Old Post 10-16-12 21:57 #
Sodaholic is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Randy87
Junior Member


Posts: 116
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.

Old Post 10-16-12 22:39 #
Randy87 is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Xaser
Forum Staple


Posts: 2578
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

Old Post 10-16-12 22:53 #
Xaser is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
fraggle
Filled with the code of Doom


Posts: 7483
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.

Old Post 10-20-12 19:14 #
fraggle is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
marineController
Mini-Member


Posts: 57
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

Old Post 10-20-12 19:42 #
marineController is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Sodaholic
I feel justified yet disgusted with myself at the same time


Posts: 2704
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...

Old Post 10-22-12 21:50 #
Sodaholic is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Dragonsbrethren
Senior Member


Posts: 2398
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.

Old Post 10-24-12 07:17 #
Dragonsbrethren is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
marineController
Mini-Member


Posts: 57
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.

Old Post 10-24-12 19:26 #
marineController is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Dragonsbrethren
Senior Member


Posts: 2398
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.

Old Post 10-24-12 19:47 #
Dragonsbrethren is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
_bruce_
Senior Member


Posts: 1283
Registered: 11-07


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

Old Post 10-24-12 19:47 #
_bruce_ is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
myk
volveré y seré millones


Posts: 15174
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).

Old Post 10-24-12 20:51 #
myk is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Gez
Why don't I have a custom title by now?!


Posts: 10996
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.

Old Post 10-24-12 21:12 #
Gez is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
kb1
Member


Posts: 327
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.

Old Post 10-24-12 22:31 #
kb1 is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
marineController
Mini-Member


Posts: 57
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

Old Post 10-24-12 22:55 #
marineController is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Dragonsbrethren
Senior Member


Posts: 2398
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?

Old Post 10-24-12 23:26 #
Dragonsbrethren is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
hex11
Senior Member


Posts: 2237
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).

Old Post 10-24-12 23:44 #
hex11 is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
kb1
Member


Posts: 327
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.

Old Post 10-25-12 00:15 #
kb1 is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Ladna
Member


Posts: 286
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+.

Old Post 10-27-12 05:11 #
Ladna is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
All times are GMT. The time now is 18:35. Post New Thread    Post A Reply
Pages (57): « First ... « 46 47 48 [49] 50 51 52 » ... Last »  
Doomworld Forums : Powered by vBulletin version 2.2.5 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 >

Powered by: vBulletin Version 2.2.5
Copyright ©2000, 2001, Jelsoft Enterprises Limited.