Attempting to make a custom version of Chocolate Doom...

[entryway]

fraggle said:

Unix shell scripts don't work well with paths that have spaces in them. There's a note about this on the wiki page for building Chocolate Doom, with a workaround.

SDL compiles fine on the same computer. PrBoom-Plus with SDL compiles fine. So I think something is wrong in configure script for SDL_mixer. Or probably I do something wrongly (there are no any problems with compiling SDL_mixer with MSVC)

Maes said:

I would rather find the place where you got C:\Program Files\ bla-bla defined and wrap that in quotes first, rather than chasing spurious errors that are caused a-posteriori

Do you really think it is possible? I think 'configure' script is not supposed to be editable by user, because it is generated by tool from configure.in which is only 21kb of crap.

[Maes]

entryway said:

Do you really think it is possible? I think 'configure' script is not supposed to be editable by user, because it is generated by tool from configure.in which is only 21kb of crap.

Then start from there.

That being said, I share fraggle's feelings about makefiles/automated builds: I've yet to see one (outside of those bundled with recent Linux distros) to work flawlessly as intended from the very first time. The makefile system has to be the most braindead concoction ever. I cringe whenever I have to work with some shit-old C package where the dreaded "makefile" makes an appearance.

[fraggle]

entryway said:

SDL compiles fine on the same computer. PrBoom-Plus with SDL compiles fine. So I think something is wrong in configure script for SDL_mixer. Or probably I do something wrongly.

Certain scripts may handle spaces correctly, but don't count on it.

I think 'configure' script is not supposed to be editable by user,

That is correct.

[natt]

hmm

I never bothered compiling sdl_mixer in mingw because it's a shitty library and I want nothing to do with it, but reading this thread now I got it.

After unzipping, this is exactly what I did:

./configure SDL_CONFIG=
make

I pass "SDL_CONFIG=" to all configure scripts because for some reason without it they look for SDL_CONFIG script in a weird place, never figured that one out. Your configure found sdl_config fine, so no need to worry about that one.

I received warnings that flac, mikmod, and smpeg were not installed, as expected, but other than that, everything went fine.

Don't bother trying to edit an automatically generated build script though, that's doomed to fail.

Anyway, my question would be, where did these CFLAGS come from?

EXTRA_CFLAGS='C:\Program Files\Microsoft SDK\Include\.;C:\Program Files\Intel\Compiler\C++\9.1\IA32\Include;C:\Program Files\Intel\Compiler\C++\9.1\EM64T\Include -D_GNU_SOURCE=1'

Never mind the spaces; those aren't even valid options to GCC even if they were properly quote escaped. The only things that you get to pass without a -something in front of them are the names of your input files. Are those supposed to be include locations? That doesn't sound right, but even if it was, each would have a -I before it. Figure out how those options came to be.

[Blastfrog]

So I got wget, and it appears to be working correctly now. (it's in the middle of building it atm)

EDIT: Oh crap, what's this at the end with "command not found"?

[entryway]

natt said:

Anyway, my question would be, where did these CFLAGS come from?

From my environment variable

view:<set

...
INCLUDE=C:\Program Files\Microsoft SDK\Include\.;C:\Program Files\Intel\Compiler\C++\9.1\IA32\Include;C:\Program Files\Intel\Compiler\C++\9.1\EM64T\Include
...

set INCLUDE=
set C_INCLUDE_PATH=D:/andre/prg/doom/prboom-plus/branches/prboom-plus-24/!/sdl/include

^^^ fixes configuring. Thanks.

[natt]

entryway said:

From my environment variable

view:<set


set INCLUDE=
set C_INCLUDE_PATH=D:/andre/prg/doom/prboom-plus/branches/prboom-plus-24/!/sdl/include

^^^ fixes configuring. Thanks.

glad to hear it. if it's an environment variable, i think you can just force off for running config

./configure INCLUDE=

the same way i switch off my faulty SDL_CONFIG variable

[Randy87]

Soda, you need the cygwin make package lol

Edit: Make sure you get all the required cygwin packages listed here http://www.chocolate-doom.org/wiki/index.php/Building_Chocolate_Doom_on_Windows

[exp(x)]

Sodaholic said:

Oh crap, what's this at the end with "command not found"?

It says that you're missing make.

EDIT: beaten to it

[Blastfrog]

Heh, I was wondering why it wasn't working, I was thinking "but I installed everything!". Well, stupid me, I did, but it was on an old install back when I used XP, so it was on the wrong drive. I've got everything installed in my current install now, and it should work. Sorry about that.

Anyway, now to use this thread for what I intended to use it for: getting help adding custom features.

How can I replace the existing viewheight and hud weapon bobbing with one that very closely (if not exactly) resembles the bobbing from the 0.4 alpha of Doom? There is only one difference from that that I would like to have, and that is to have the viewheight bobbing be halfway lower than it is in the alpha (in the alpha, it only goes higher than the standing viewheight, never lower).

[Randy87]

There's a few references to bobbing in p_user.c. Line 50 and 78 may help.

Edit: Weapon bob can be made faster.
p_pspr.c - Line 330
angle = (128*leveltime)&FINEMASK; to
angle = (256*leveltime)&FINEMASK;

[Blastfrog]

How would I be able to change how the fog is handled to be more like the 0.5 alpha? In the final version, the fog "contrast" is so high that things appear as fullbright when they are right next to the player, but in the alpha, the fog is "flatter" in that things don't end up fullbright when you were next to them.

I suppose it's basically equivalent to changing the R_visibility CVAR in ZDoom.


Can anyone familiar with the internal workings of the alpha versions confirm if the alpha's lighting was equivalent to R_visibility being 4 (my best guess)? If not, what was it equivalent to?

[andrewj]

How is the fog effect implemented in the alpha? If it is done via a lookup table lump like COLORMAP, then changing how it looks will "merely" be a matter of creating a new colormapping lump.

[esselfortium]

Sodaholic said:

How would I be able to change how the fog is handled to be more like the 0.5 alpha? In the final version, the fog "contrast" is so high that things appear as fullbright when they are right next to the player, but in the alpha, the fog is "flatter" in that things don't end up fullbright when you were next to them.

Actually, this exaggeration in close-range lighting contrast is a ZDoom oddity. In vanilla, dark surfaces are generally still dark when you're standing face-to-face with them.

[Blastfrog]

esselfortium said:

Actually, this exaggeration in close-range lighting contrast is a ZDoom oddity. In vanilla, dark surfaces are generally still dark when you're standing face-to-face with them.

Huh, weird, they should fix that.

So, is the lighting between the 0.5 version and the final vanilla version identical?

[Blastfrog]

How would I modify the viewheight bobbing ramp to speed up towards the bottom, then yank back up when it hits the bottom? (see the alpha for what I'm talking about) In the final version, the fast end of the ramp is in the middle (thus giving it a smooth bobbing effect) whereas in the alpha, the fast end it as the bottom (giving it a footstep-like effect).