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

Chocolate Doom

Recommended Posts

axdoom1 said:

Is it me or there is frame skip every time Doom's palette changes?

It may be just an illusion.


It's laggy. I'm actually calling system() to exec "blinkstick", a user-space tool that talks to the blinkstick API, which is written in python: so every palette change is spawning a full python sub-process. That's ludicrous I Know, but good enough for this video. There is a blinkstick C library but it needs a lot of work and can't be used yet for this particular model. I've started hacking on that.

Share this post


Link to post
fraggle said:

Maybe just add a & to the end of your "system" command ;)


I figured a laggy choco was better than an out of sync blink.

Share this post


Link to post
Jon said:

I hacked blinkstick into my chocolate doom:

Nice. It's kinda like those TVs that backlight the room based on averaging the colors of the current TV frame. Very cool.

Now add a light detector that modulates a 48v power supply, attach wrist bands, and then you can really feel it when DoomGuy gets hurt :)

Share this post


Link to post
kb1 said:

Nice. It's kinda like those TVs that backlight the room based on averaging the colors of the current TV frame. Very cool.


You would be surprised the number of people who have said to me "hack in Philips Ambilight support!" I'd do it, if someone gives me an ambilight-capable TV to work with :)

kb1 said:

Now add a light detector that modulates a 48v power supply, attach wrist bands, and then you can really feel it when DoomGuy gets hurt :)


ouch!

Share this post


Link to post

I'm having some issues when using Chocolate Doom with the Steam client. The overlay won't show up.

I use Doom Explorer to play with my wads online and offline, and I added it to my non-steam games list so I can use the Steam overlay and the Steam controller's configuration. The overlay works when using Zandronum, whether in OpenGL as in Software. However, it doesn't show up when using Chocolate Doom. The fun thing is, it used to work before I replaced the .exe file to this guy's:

https://www.doomworld.com/vb/source-ports/34164-chocolate-doom/66/

I re-used the first .exe, extracted the main .zip again, deleted and added the .exe to the list of programs for Doom Explorer, and nothing seems to work. Any idea?

Share this post


Link to post

You aren't running Chocolate-Doom in a hardware surface for the Steam overlay to attach to. Remember the Steam overlay does not work on pure software rendering (the concept is beyond incompatible with how a software surface functions), that's why Strife: Veteran Edition uses OpenGL even under the software renderer.

Try using the SDL2 branch. https://www.chocolate-doom.org/wiki/index.php/V3.0_beta

Share this post


Link to post
Edward850 said:

You aren't running Chocolate-Doom in a hardware surface for the Steam overlay to attach to. Remember the Steam overlay does not work on pure software rendering (the concept is beyond incompatible with how a software surface functions), that's why Strife: Veteran Edition uses OpenGL even under the software renderer.

Try using the SDL2 branch. https://www.chocolate-doom.org/wiki/index.php/V3.0_beta


It worked!!! Thanks a lot.

Share this post


Link to post

(mini rant)

the "official" build instructions for chocolate-doom on windows are worthless. The point of the official route on windows being cygwin is for it to be identical to, or at least close to, the environment fraggle uses for releases (cross-compiling from OS X). But it's not, the instructions are broken and have been for at least a year. The new chocpkg IMHO doesn't really improve matters at all. It's geared towards building all the dependencies from source too: necessary if you are cross compiling, but not for every other windows developer (or potential developer) out there.

On a fresh win7 VM, with current cygwin, I have failed to build choco either using the official old instructions or chocpkg.

Prior to AlexMax's PR for cmake I was keen on getting the VS stuff fixed up and working again and to try to suggest that as the blessed route on windows. There's at least prior art from Linguica on trying to get the docs updated. But now I'm going to take a look at AlexMax's PR more closely.

Share this post


Link to post

Since a few pages ago, I have actually managed to get a build environment working through Cygwin. The link to the build script was broken, but I eventually figured it out.

  1. The names of some of the packages have completely changed. I can't recall what exactly I installed, but if you think you've found something that was "close enough" via intuition, you're probably right.
  2. I do not use SDL2 libraries from the package manager. I download them, and I put them precisely where their internal pkgconfig files expect them to be: /usr/local/cross-tools/i686-w64-mingw32/. I then export PKG_CONFIG_PATH="/usr/local/cross-tools/i686-w64-mingw32/lib/pkgconfig/" so they can be found.
  3. I run autogen.sh with --host i686-w64-mingw32
This results in a working build.

Share this post


Link to post

You guys should probably try out MSYS2. It's a breeze to set up, it has a huge pool of pre-compiled binary packages and "autoreconf && ./configure && make" simply works out-of-the-box (once you have installed the corresponding packages, that is).

Share this post


Link to post

I think the official build instructions once did recommend msys, but Fraggle switched away for some reason I'm not sure about. It was before I started paying attention to the Windows build.

Share this post


Link to post

I only ever used MSYS in the very early days of the project and very quickly gave up on it. The main thing is that you need a functional Unix environment to do a build - that's what Cygwin aims to do (and does reasonably well). MSYS tries to provide something similar but it's a lot further off because by design it (and MingW) are far closer to the plain Win32 APIs. If I have to build on Windows then I use Cygwin and "cross-compile" to MingW - last time I used it, Cygwin has packages for the MingW gcc compiler that make this fairly straightforward.

Jon said:

(mini rant)

the "official" build instructions for chocolate-doom on windows are worthless.

This all seems like a reasonable criticism. I've mentioned this before, but I don't have any machine that runs Windows that I can use to test this stuff. I believe chocpkg should be usable with Cygwin if you have the right Cygwin packages installed but I haven't tested it at all.

A quick note on chocpkg - I only started writing it a relatively short time ago and while it works it's by no means finished. If someone would like to put in some work to make this work better on Windows (ie. fixes, and also documentation) it would be most appreciated.

Share this post


Link to post

Last week I installed a windows virtual machine to start trying to sort this out. I had a spare license key from my last job. Afterwards, a friend pointed out to me that I could have used one of the VMs from modern.ie. they are much smaller (~3G? Whereas a fully patched but otherwise pristine win7 VM is ~25G, or measured another way 12 hours and counting).

The modern.ie VMs are only valid for 90 days at a time, but if you take a snapshot earlier on you can restore from that snapshot. I suspect that using a shared folder or similar to keep a build environment between resets, this is a fairly simple and free way for any of us to test windows stuff.

Share this post


Link to post

Hi, I've discovered something, I'm not sure if it should be fixed though.

(I'm still stuck on version 2.2.1, but I don't see this addressed in the 2.3.0 changelog, so it's probably there too.)

If you open the Strings section of Whacked4, you'll see some interesting strings, more specifically, the ones that are displayed when the engine crashes due to exceeding a static limit. "Visplane overflow", "Drawseg overflow", "opening overflow" and "No more planes!", I don't really remember all of them right now.

Well, if you change them, load the patch and crash the game, you'll still see the old message! At least I did.
Did vanilla Doom/DeHackEd behave like this?
Thanks!

Share this post


Link to post
bzzrak said:

Well, if you change them, load the patch and crash the game, you'll still see the old message! At least I did.
Did vanilla Doom/DeHackEd behave like this?
Thanks!


It's possible that these are strings that you can override with BEX but were not possible to override with the original DHE and vanilla Doom. There's a related issue open about some messages that chocolate *does* let you override at present, but shouldn't, but are used for Chex support.

Share this post


Link to post

I can't even post what I had to post. Doomworld makes an error (EX0). 

Here's my post: http://pastebin.com/0Np64gg4

EDIT: I've got it a little farther by defining the exports that it wanted

export CPPFLAGS='-I/usr/i686-w64-mingw32/include'
export LDFLAGS='-L/usr/i686-w64-mingw32/lib'

I can run make and it fails elsewhere:

http://pastebin.com/DnLcGJnR

Edited by axdoom1

Share this post


Link to post
On 3/14/2017 at 9:46 PM, axdoom1 said:

I've been trying to cross-compile Chocolate-Doom (SDL1) from Linux to Windows. 

If you're happy with using the SDL2 version (and I'd encourage you to use it), you might find that chocpkg makes this a lot easier - maybe give it a try. Basically, git clone that repository and edit buildenv.sh to uncomment this line:

BUILD_HOST=i686-w64-mingw32

Then run this command:

./chocpkg/chocpkg build chocolate-doom

If you have problems please let me know since it's a relatively new system and I want to hear about any bugs.

Share this post


Link to post

Hello,

on YouTube there is a video of Chocolate DOOM running with Don Allen's Timbres of Heaven Soundfont:

 

 

I think it's great and I'd like to use it (I'm on my Raspberry Pi).

I downloaded the 7zip archive that contains a .SF2 file, but I can't understand how to get it working with ChocoDOOM (ver2.3.0).

 

Any hint? Thanks! :)

 

 

Share this post


Link to post

To get a soundfont working in Chocolate Doom on Windows, you'll need to install a MIDI driver that supports the use of soundfonts. VirtualMIDISynth and BASSMIDI are two I've tried (ended up preferring the latter) that can be configured to use soundfonts in place of the Microsoft GS Wavesynth table. Just use "Native MIDI" as the music type and you're good to go!

Share this post


Link to post

I've got the infamous "can't change the volume of midi" issue with both Microsoft GS Wavesynth table and VirtualMIDISynth.

Share this post


Link to post
On 16/4/2017 at 6:55 PM, CapnClever said:

To get a soundfont working in Chocolate Doom on Windows, you'll need to install a MIDI driver that supports the use of soundfonts. VirtualMIDISynth and BASSMIDI are two I've tried (ended up preferring the latter) that can be configured to use soundfonts in place of the Microsoft GS Wavesynth table. Just use "Native MIDI" as the music type and you're good to go!

 

Thank you, but I'm on Raspberry Pi (Raspbian Jessie). It's the same?

 

Share this post


Link to post
On 4/16/2017 at 11:46 PM, Danfun64 said:

I've got the infamous "can't change the volume of midi" issue with both Microsoft GS Wavesynth table and VirtualMIDISynth.

 

@AlexMax wrote a fix for this which is pending to be merged.

Share this post


Link to post

Colleagues,

 

Thinking a little bit more about AlexMax's CMake project, I would like to suggest to don't remove completely Code::Blocks project files, created by Russell Rice.

Well, as I said, there is nothing awful hard in setting up CMake, but -- I have found that current CB project files is more comfortable for configuring, more portable and more easy than ones generated by CMake. Another huge benefit of portability - current CB project files are independent from strict system path of GCC, it can be unpacked anywhere, the only thing is necessary is to properly choose toolchain's path in Code::Blocks itself.

 

Maybe there is no need to keep them directly in Chocolate repository, but maybe it might be a good idea to keep them on the Wiki, for example in "Alternative build" section. I can take care about them in the future, there is nothing hard: just add new files to CB project (if they added in repository), and bump version (which is totally cosmetic action).

 

These files are valuable not only because of usability, but also saves a lot of time - no need to re-generate CB project after every new download of the source code.

Share this post


Link to post
14 minutes ago, bzzrak said:

 

Please take a look at this thread. Is it an idea worth implementing? It seems to work just like DEH.

Are there any WADs/mods that use this tool? If there are maybe a handful of them out there then it might be worth implementing just to support playing them. If there's nothing other than the tool then I'd say it probably isn't worth it.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×