Ouchface
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 ... « 49 50 51 [52] 53 54 55 » ... Last »  
Author
All times are GMT. The time now is 02:39. Post New Thread    Post A Reply
exp(x)


Posts: 2595
Registered: 04-04


http://www.chocolate-doom.org/wiki/...Doom_on_Windows

Old Post 03-15-13 14:17 #
exp(x) is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
_bruce_
Senior Member


Posts: 1293
Registered: 11-07



Archy said:
Has someone made a Doom+ equivalent version of Chocolate-Doom? With the following changes:
code:
limit : old * k = new ------------------------------------------------------- visplanes[MAXVISPLANES] : 128 * 8 = 1024 drawsegs[MAXDRAWSEGS] : 256 * 8 = 2048 SAVEGAMESIZE : 180224 * 16 = 2883584 activeplats[MAXPLATS] : 30 * 256 = 7680 vissprites[MAXVISSPRITE] : 128 * 8 = 1024 linespeciallist[MAXLINEANIMS] : 64 * 256 = 16384 openings[MAXOPENINGS] : 16384 * 4 = 65536

(MAXVISSPRITE is the most important one for me, HR2 map 32 is getting annoying.)

I personally think this should be included as an option in the official release because increasing savegame limits, recording long ticks, and altering weapon keys (plus other things) have also been implemented as options but I'm not going to push for it beyond humbly stating my opinion. As long as a version exists, I'm fine.

PS. I took a look at this but I don't understand how to compile it into the Chocolate-Doom source code (sorry if I just said something stupid, I don't understand any of this programing business, anything more complex than QBASIC is completely foreign to me) or if it's even what I'm looking for. I have read the last 3-4 pages of this thread so I kinda understand the previous discussion that took place here.

Myk talked of Strawberry Doom but I don't like it's lack of Vanillaness.



My puristic ChocolorDoom is an offspring of ChocolateDoom - found here on the source forum though it may be more you've bargained for and it's not in it's final form yet.
I can compile/send a clean 1.6.0 with enhanced limits to you.

Btw, Fraggle - Fabien Sanglard has gone the Chocolate Duke route while reviewing the build/duke engine.
Chocolate is a truly inspirational port.

Old Post 03-16-13 00:30 #
_bruce_ is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Archy
Forum Regular


Posts: 672
Registered: 11-09



_bruce_ said:
I can compile/send a clean 1.6.0 with enhanced limits to you.

I would like that very much, and yes, I am aware of this. Also, not that it matters to me but I'm just curious as to why 1.6.0 when 1.70 exists? Any reason? Is it just for convenience?


_bruce_ said:
Btw, Fraggle - Fabien Sanglard has gone the Chocolate Duke route while reviewing the build/duke engine.
Chocolate is a truly inspirational port.


How wonderful. This is something that has been lacking from the Duke community.

Old Post 03-16-13 00:43 #
Archy is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Archy
Forum Regular


Posts: 672
Registered: 11-09


@exp(x)
code:
*** Your compiler (gcc) does not produce Win32 executables!


Here's the full text. (Lots of nos).

I selected the following packages:
code:
automake1.8 autoconf2.5 bash gcc-mingw-core gcc-mingw-g++ make python subversion wget w32api


During the installation, my DNS expired so I had to re-install. I don't know if that has anything to do with the error, but on some of the packages, it said "keep" instead of "install" so I just left it at "keep."

Old Post 03-16-13 05:32 #
Archy is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Randy87
Junior Member


Posts: 116
Registered: 05-05


You can switch cygwin between gcc3 and gcc4.
Try using /usr/bin/set-gcc-default-3.sh

I don't think cygwin's gcc4 will work for win32 executables.

Old Post 03-16-13 09:26 #
Randy87 is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Archy
Forum Regular


Posts: 672
Registered: 11-09


I read the documentation and all but I'm still a big confused, is "-gameversion final" the same as "-complevel 4?"

Old Post 03-16-13 20:34 #
Archy is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Springy
Senior Member


Posts: 1345
Registered: 09-12



Archy said:
I read the documentation and all but I'm still a big confused, is "-gameversion final" the same as "-complevel 4?"

Yes it is. When Grazza split the Plutonia 2 -nomonsters demo pack into it's own thread he said you can use the executable, PrBoom + with -complevel 4 OR Chocolate Doom with -gameversion final.

Old Post 03-18-13 17:09 #
Springy is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Archy
Forum Regular


Posts: 672
Registered: 11-09


Now this happened:
code:
i_sdlsound.c:38:24: samplerate.h: No such file or directory i_sdlsound.c: In function `SRC_ConversionMode': i_sdlsound.c:122: error: `SRC_LINEAR' undeclared (first use in this function) i_sdlsound.c:122: error: (Each undeclared identifier is reported only once i_sdlsound.c:122: error: for each function it appears in.) i_sdlsound.c:124: error: `SRC_ZERO_ORDER_HOLD' undeclared (first use in this function) i_sdlsound.c:126: error: `SRC_SINC_FASTEST' undeclared (first use in this function) i_sdlsound.c:128: error: `SRC_SINC_MEDIUM_QUALITY' undeclared (first use in this function) i_sdlsound.c:130: error: `SRC_SINC_BEST_QUALITY' undeclared (first use in this function) i_sdlsound.c: In function `I_PrecacheSounds_SRC': i_sdlsound.c:488: error: `SRC_DATA' undeclared (first use in this function) i_sdlsound.c:488: error: parse error before "src_data" i_sdlsound.c:494: error: `src_data' undeclared (first use in this function) i_sdlsound.c:523: warning: implicit declaration of function `src_simple' Makefile:670: recipe for target `i_sdlsound.o' failed make[2]: *** [i_sdlsound.o] Error 1 make[2]: Leaving directory `/home/Archy/chocolate-doom/build/chocolate-doom-1.7.0/src' Makefile:377: recipe for target `all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/Archy/chocolate-doom/build/chocolate-doom-1.7.0' Makefile:289: recipe for target `all' failed make: *** [all] Error 2


Full text.

Old Post 03-30-13 04:50 #
Archy is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
fabian
Member


Posts: 318
Registered: 12-12



Archy said:

Full text.


Look at the first line:
build-chocolate-doom: line 365: sdl-config: command not found

You need to properly have the SDL development headers and libraries installed.

Old Post 03-30-13 11:42 #
fabian is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
fraggle
Filled with the code of Doom


Posts: 7605
Registered: 07-00



fabian said:

Look at the first line:
build-chocolate-doom: line 365: sdl-config: command not found

You need to properly have the SDL development headers and libraries installed.

That's irrelevant: the build script builds the SDL libraries for you. You can safely ignore that message.

It looks like it's trying to build against libsamplerate for some reason. Do you have that installed?

You can see that it detects the library:
code:
checking for src_new in -lsamplerate... yes

But it can't seem to find the header for it.

If that's not enough info to fix it, can you post the contents of build/chocolate-doom-1.7.0/config.log somewhere?

Old Post 03-30-13 15:05 #
fraggle is online now Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Archy
Forum Regular


Posts: 672
Registered: 11-09


build/chocolate-doom-1.7.0/config.log

Old Post 03-30-13 21:10 #
Archy is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
fraggle
Filled with the code of Doom


Posts: 7605
Registered: 07-00


Sorry, I meant to get back to you about this.

If you look here:

code:
configure:3953: checking for src_new in -lsamplerate configure:3978: gcc -o conftest.exe -O2 -g -Wall -I/home/Archy/chocolate-doom/install/include/SDL -I/usr/include/mingw -mno-cygwin -Dmain=SDL_main -I/home/Archy/chocolate-doom/install/include -I/home/Archy/chocolate-doom/install/include/SDL -Wl,-rpath -Wl,/home/Archy/chocolate-doom/install/lib -L/home/Archy/chocolate-doom/install/lib -L/home/Archy/chocolate-doom/install/lib -lmingw32 -lSDLmain -lSDL -mno-cygwin -mwindows conftest.c -lsamplerate >&5 configure:3978: $? = 0 configure:3987: result: yes

You can see that it successfully finds an install of the libsamplerate library. Did you install that in Cygwin setup or something like that? There might be a libsamplerate devel package that you need to also install - otherwise remove the non-devel package from your system.

Old Post 04-03-13 16:51 #
fraggle is online now Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Holering
Member


Posts: 323
Registered: 01-03


Any chance of implementing proper midi support in Linux? It'd be nice to select alsa midi ports or have timidity++ support (like zdoom or dosbox) instead of the not so good SDL mixer.

Old Post 04-24-13 10:55 #
Holering is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Janizdreg
Member


Posts: 343
Registered: 07-02


The game audio somehow goes mute whenever I launch a multiplayer game using the v2-branch r2591 build. What could be causing this?

Old Post 04-29-13 02:34 #
Janizdreg is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
ixfd64
Junior Member


Posts: 117
Registered: 10-02


I downloaded Chocolate Doom to my Windows XP laptop, and it works perfectly. However, the Mac version immediately crashes on my MacBook Pro.

Anyone have a solution?

Old Post 05-06-13 20:09 #
ixfd64 is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
fraggle
Filled with the code of Doom


Posts: 7605
Registered: 07-00


What version of OS X? Does it help if you run the game in windowed mode instead of fullscreen?

Old Post 05-07-13 00:13 #
fraggle is online now Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
ixfd64
Junior Member


Posts: 117
Registered: 10-02


Windowed mode works. I'm using Mac OS X 10.6.8.

Old Post 05-07-13 03:13 #
ixfd64 is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
marineController
Mini-Member


Posts: 58
Registered: 08-12


The Aliens (v2) UV Speed demo on DSDA (atcude2-801.lmp) makes chocolate-doom 1.7.0 freeze half way through E2M5.

Old Post 05-28-13 17:06 #
marineController is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Holering
Member


Posts: 323
Registered: 01-03


Could portmidi please be added to chocolate-doom? It's not funny but, sdl_mixer is so fubar'ed (literally) that midi playback is completely broken and has been for way too long (we're talking years here). It's a shame too considering chocolate-doom is so good at behaving similarly to vanilla doom (there's so many wads out there that have unique midi music it's just not right to avoid portmidi).

There's been countless threads about prboom-plus's midi problems in the past and they've all been due to sdl_mixer's midi code. Prboom-plus with portmidi was such a fantastic refreshment and improvement when they added it (you could finally send midi data to a software or hardware module properly without any bs whatsoever). Portmidi makes everything wonderful on every platform (Windows, Mac OS and Linux). I personally use Linux and can say portmidi does wonders for midi playback and it doesn't seem bloated with dependencies.

See my post here for examples and reference; beware however, sdl_mixer is sad and gruesome:
http://www.doomworld.com/vb/eternit...-pretty-please/

Last edited by Holering on 06-12-13 at 18:42

Old Post 06-12-13 07:54 #
Holering is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
hex11
Senior Member


Posts: 2237
Registered: 09-09



Holering said:

Portmidi makes everything wonderful on every platform (Windows, Mac OS and Linux).



That's only a few platforms... On others, it doesn't even exist.

But let me suggest that there is another solution than trying to jump onto yet another library-du-jour. Check out the old musserver code that someone hacked-up for the old LinuxDoom binaries. It's a simple architecture: the game spawns a mussserver child process and sends it some music data via a pipe, which it plays in a loop until it gets a signal to stop playing. Those days it only handled midi/mus lumps, and only real midi hardware (even if just OPL chip). You can use a similar but more flexible architecture, by making it detect what format the music lump is in. Chocolate Doom only understands MUS/MIDI format and plays them internally. You can let that stand as default behavior, but override those if the user has configured other players. Example musserver configuration file:
code:
MIDI = /usr/local/bin/timidity -l -Od -id -s 44100 %s MOD = /usr/local/bin/xmp -l %s

The config details above aren't important, it's just an illustration. The only thing that matters is that the external players can loop the music file, and can be killed by the musserver when the map ends (or intermission music ends...) And the sdl_mixer code that's now in Chocolate Doom would just be in the musserver instead (to act as default internal player).

I think you would have better luck implementing something like that as a Chocolate Doom hack than trying to find a single library that works 100% across all platforms. You could also try to fix the SDL bugs that are causing issues on your platform (or at least keep reporting them, and work with the developers to test out their new builds so they can get feedback).

Old Post 06-13-13 01:11 #
hex11 is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Holering
Member


Posts: 323
Registered: 01-03


So basically you're saying it'll probably be easier to hack musserver into chocolate-doom, or tell chocolate-doom how to call musserver?

Sounds great but a problem with me is that I'm a fresh newb with programming. I've written some Linux scripts and hacking something like musserver on my own would be pretty hard I think. That doesn't mean I won't try but damn... Can't even get musserver to compile on 64-bit (Slackware).

I'm wondering if midi code in source ports generally suck because everyone needs windows (something about large latency). Heard odamex may have better code to follow in their recent release.

The problem just aint chocolate-doom either. My favorite source port eternity (besides prboom-plus) also depends on sdl_mixer for midi playback which is kind of why I suggested a library such as portmidi. Sdl_mixer for midi should just be tossed IMO... Hopefully it'll improve for Linux and Mac users in the long run...

Last edited by Holering on 06-13-13 at 01:49

Old Post 06-13-13 01:42 #
Holering is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
hex11
Senior Member


Posts: 2237
Registered: 09-09


That musserver code from 1996 is quite useless as-is. It's just an architecture example. But something similar wouldn't be terribly difficult to make. Of course there are a few details to iron out, like for example how to control the volume? These days there are many music player front-ends that call upon separate programs to do the dirty work of actually playing an audio file, so it's a reasonable expectation. But there is also the matter of having separate streams for music and soundfx. So you can't just control a single mixer. Either the OS has to have some kind of server that allows multiplexed audio, or you have to fake it somehow in the musserver.

Some might not like this idea, because it sounds "dirty". It means people would have things configured in many different ways. But that flexibility is also its strength, because it means that a reasonable, working configuration should be possible for any system. Throwing away SDL to go with PortMidi or FMOD, or whatever else will just move the problem around a bit. Now maybe your machine will have good music, but someone else's won't. And those other things aren't even as portable as SDL. You'd be better off just fixing the SDL bugs if you wanted a "clean" one-size-fits-all solution.

Of course, in my example, you'd want to fix the SDL bugs anyway, since it would make a good default internal player for the musserver.

Old Post 06-13-13 03:01 #
hex11 is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
fraggle
Filled with the code of Doom


Posts: 7605
Registered: 07-00


Sounds like there are bugs in SDL_mixer. Rather than trying to convince the maintainers of every Doom source port that uses it to convert to a different sound library, it would be easier to just fix SDL_mixer's MIDI playback to be better. You can file a bug at www.libsdl.org.

Old Post 06-13-13 12:29 #
fraggle is online now Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Quasar
Moderator


Posts: 6037
Registered: 08-00



fraggle said:
Sounds like there are bugs in SDL_mixer. Rather than trying to convince the maintainers of every Doom source port that uses it to convert to a different sound library, it would be easier to just fix SDL_mixer's MIDI playback to be better. You can file a bug at www.libsdl.org.

Been trying that for a few years now, myself >_>

I am probably going to try implementing portmidi; Odamex has some good clean looking code to make use of it and, looking at the comments and the source of the library itself, it's immediately clear the author has a very solid sense of the serious issues in the Win32 MMSYSTEM API and of how to work around them.

IMO the best thing for SDL 2.0 to do would actually be to integrate portmidi directly.

Old Post 06-13-13 13:44 #
Quasar is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
exp(x)


Posts: 2595
Registered: 04-04



fraggle said:
Sounds like there are bugs in SDL_mixer. Rather than trying to convince the maintainers of every Doom source port that uses it to convert to a different sound library, it would be easier to just fix SDL_mixer's MIDI playback to be better.

*cough*

Old Post 06-13-13 15:03 #
exp(x) is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Holering
Member


Posts: 323
Registered: 01-03



Quasar said:

Been trying that for a few years now, myself >_>

I am probably going to try implementing portmidi; Odamex has some good clean looking code to make use of it and, looking at the comments and the source of the library itself, it's immediately clear the author has a very solid sense of the serious issues in the Win32 MMSYSTEM API and of how to work around them.

IMO the best thing for SDL 2.0 to do would actually be to integrate portmidi directly.



That is so awesome that you're going to try that! Seriously! SDL_mixer has such fubar'ed midi (at least on linux) it's not even funny. It makes GUS pats appear worse than they are too (I have custom pat sets over several gigs in size that blow away many soundfonts; they're much easier to edit unlike soundfonts that need bloated and expensive software (you can't even choose which bank to use with soundfonts; most probably don't even know they only use one out of possibly dozens of instrument sets when they use a soundfont for games). Someone even made extensions to gus pats so they can have missing features only soundfonts provide, and timidity++ can use compressed pat sets which is unlike sdl_mixer). It's a real shame not being able to use my pat sets with a favorite source port.

I agree that SDL should integrate portmidi. I think letting developers choose what dependencies they want to include would be the best choice. Having a built-in midi player that's based on a really old and limited piece of obsolete software is a bad way to develop a library IMO. Think the greatness of a library is to let developers make their own programs and add desired features at will; not include programs already made. Let alone a broken one.

Last edited by Holering on 06-19-13 at 03:02

Old Post 06-16-13 05:42 #
Holering is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
manny
Newbie


Posts: 4
Registered: 04-12


If the novert option was implemented to emulate novert.com's behaviour, shouldn't vertical mouse movement be disabled in menus too? Atm you can scroll through menu options by moving the mouse, with novert enabled.

Old Post 06-17-13 11:32 #
manny is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
fraggle
Filled with the code of Doom


Posts: 7605
Registered: 07-00



manny said:
If the novert option was implemented to emulate novert.com's behaviour, shouldn't vertical mouse movement be disabled in menus too? Atm you can scroll through menu options by moving the mouse, with novert enabled.
If this is true, please file a bug.

Old Post 06-17-13 12:27 #
fraggle is online now Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
manny
Newbie


Posts: 4
Registered: 04-12



fraggle said:
If this is true, please file a bug.


Done. For some reason I couldn't select 'None' as a milestone, only 'v1.0 (example)'. I hope that doesn't mess up your administration.

Old Post 06-17-13 14:32 #
manny is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
fraggle
Filled with the code of Doom


Posts: 7605
Registered: 07-00


Thanks, I just committed a fix. Sourceforge recently "upgraded" the project to (among other things) their new bug tracking system. The version field isn't really used.

Old Post 06-18-13 00:05 #
fraggle is online now Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
All times are GMT. The time now is 02:39. Post New Thread    Post A Reply
Pages (57): « First ... « 49 50 51 [52] 53 54 55 » ... 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.