Chocolate Doom

[natt]

Average said:

Is that the same for all MIDI players? Would it not work more consistently with Fluidsynth? I don't seem to have the volume problem while using that on any of my computers whereas, while using SDL_Mixer I can only change the volume on 1 of 3 computers...

If you're talking about fluidsynth as it's used in zdoom or prboom-plus, then no, no problem. In those cases, everything is handled inside the application itself. The problem comes when you try to use system midi output.

[Average]

So, what are the benefits of Choco Doom using system MIDI output, then? Sorry for all the questions but I'm just trying to get a handle on all this stuff.

[natt]

Average said:

So, what are the benefits of Choco Doom using system MIDI output, then? Sorry for all the questions but I'm just trying to get a handle on all this stuff.

The benefit is that you can connect any compliant midi device you have, including an advanced soundcard synth, external hardware devices, or oddball software synths.

But for most users these days, system MIDI output means Microsoft GS Wavetable SW Synth and nothing else, in which case there's no real benefit at all.

[Average]

I see. Thanks for replying. Well, to my mind everything should swap over to something akin to Fluidsynth (Timidty?). My aural experiences of Microsoft GS have been lacking to say the least... and isn't it pretty much dead these days in Win 7? :)

[_bruce_]

Big thanks to you Fraggle for your info and expertise!
The source magic worked.

p.s.: spectre monsters in idle action(faster but less health and more painchance)

[fraggle]

_bruce_ said:

Big thanks to you Fraggle for your info and expertise!
The source magic worked.

Great to hear! I'm glad you figured it out.

[tempun]

natt said:

But for most users these days, system MIDI output means Microsoft GS Wavetable SW Synth and nothing else, in which case there's no real benefit at all.

Speed. Fluidsynth is too slow.

[entryway]

tempun said:

Fluidsynth is too slow.

How much it is slow? I don't feel any differense. -timedemos are almost the same for fluidsynth and sdl midi

[Graf Zahl]

Fluidsynth is slow. But only on a single core CPU. On multi-core, if not disabled it won't affect the main program much, if at all.

[entryway]

Graf Zahl said:

Fluidsynth is slow. But only on a single core CPU. On multi-core, if not disabled it won't affect the main program much, if at all.

How did you test?

sysinternals\PsTools\psexec.exe -a 1 -realtime glboom-plus epic -timedemo epic

186 fps with sdl midi
184 fps with fluidsynth

The same with small level:
1060 fps with sdl midi
1045 fps with fluidsynth

p.s. "-a 1" means 1 core. Also I had "process_affinity_mask 1" in cfg

[natt]

Not really a good test though. The way -timedemo works in prboom is like this: regardless of what speed the video is going at, the audio is still only rendering at realtime. So if you do a 10 minute demo in 1 minute, while 10 minutes of game engine and 10 minutes of video rendering were run, only 1 minute of audio rendering was run, so the audio will appear to take 1/10th of the relative CPU time that it would take if you were playing normally.

[entryway]

Ok, IDRATE cheat on epic.wad map05, same position, process_affinity_mask 1:
119 fps with fluidsynth
122 fps with sdl midi

[Average]

ISn't the speed of things like Fluidsynth more dependant on the size of the soundfont? When using Fluidsynth with (I think it's called) GF2.sf2 on either PrBoom+ or ZDoom I notice next to no change in speed but when I use a bigger font such as WeedsGM things start to slow down (small freezes in the game during play). I get this on both single and dual core set ups...

[entryway]

Average said:

ISn't the speed

117 fps with 144 MB FluidR3_GM.sf2 (previous test was with 6 MB TimGM6mb.sf2)

Average said:

small freezes in the game during play

Ahh, probably.

[Janizdreg]

The Chocolate Doom wiki is loading awfully slow for me, it can even take tens of seconds to load a single page. And it has been this way for around a week now. Is anyone else getting this?

[axdoomer]

Janizdreg said:

The Chocolate Doom wiki is loading awfully slow for me, it can even take tens of seconds to load a single page. And it has been this way for around a week now. Is anyone else getting this?

I have dial-up and the Chocolate Doom wiki is loading like it always did before. It takes under two seconds before the text finishes to appear. The only page that is loading slow for me is the SourceForge page to report Chocolate-Doom's bug.

[Quasar]

I am curious what the future is for Chocolate Doom, because I haven't seen any commits go by in #doom-tech for what seems like an age, and certainly none of them have made even an iota of progress towards what I regard as the critical goal of merging the major branches back into trunk.

The most major obstacle to that being the fact that there's still no netplay in raven-branch or its child, my own body of work, strife-branch. I can't actually finish Chocolate Strife until that underlying architecture is in place, so I feel like now I'm really only spinning my wheels as far as its further progress.

It is also frustrating to me that there has never been a proper release of it with linux support, and the configuration program, and other Chocolate niceties. I'm not myself equipped to build any of that stuff so the betas haven't included it. As a result I feel, especially with beta 2, that they have been underutilized and under-exposed. I have never received even one bit of feedback about the 2nd beta, and that's kind of disappointing.

Anyway my question is if Chocolate Doom is officially in sunset, or if its development is only going through something that could be called a dry spell, and if it IS coming to an end, if it'll be necessary to fork the Strife project in order to effectively finish it.

[fraggle]

Definitely a dry spell, and I'm not abandoning Chocolate Doom by any means. I've had a lot going on recently - moving house, starting a new job, etc. I've also been hacking on another project of mine. But I haven't forgotten about Chocolate Doom.

The problem with the network code is that it's currently very tightly coupled to the Doom code (it reads directly from variables like 'deathmatch'). I need to split that apart and refactor it so that there is no dependency in that direction (game code can depend on network code, but not the reverse). I did some preliminary work in that direction a while back but I need to finish it off. Once that's done it *should* be a fairly small amount of work to extend the netcode to support Strife as well.

Regarding your other concerns, I've certainly been building strife-branch on Linux (and Mac OS X!) and playing it without any problem. If you want, I can build some binaries of beta2 and put them up for download. While you were developing the Strife code I also did some work on the setup tool so as far as I know that ought to be working appropriately as well.

I'm sorry if I didn't give you any feedback about beta 2, and I didn't realise that I hadn't made my feelings well known. It's great to see Strife support effectively finished (in so far as all the features are there). You and Kaiser have done some really great, impressive work and I'm sorry if I didn't tell you that. I guess the fact that I'm not on IRC any more can be problematic.

I have been thinking about the future of the project and what should come next. Obviously the next major task is to integrate raven-branch and strife-branch into trunk, and the first release after that is going to be a major change compared to the previous versions. I think that ought to become "Chocolate Doom 2.0". With that in mind I'm also wondering if it's worth the hassle of maintaining two separate branches: perhaps it would be best to make a "chocolate-doom-2.0" branch, merge everything we have into there and continue development together. I was originally anticipating that strife-branch would take much longer to finish, but as you've obviously outpaced my development it doesn't really seem worth maintaining two separate branches now.

[Quasar]

Cool, thanks for the updates, fraggle. I look forward to the future developments.

If you could do a proper release of the current strife-branch I think that would be awesome, whenever you have the time.

We did finish the project pretty quickly once we started importing the code, but that was mainly due to the additional time - almost a year - that we spent doing more reverse engineering after the branch was initially created in the repo. I knew at that time that we really weren't ready to be putting down code yet and so Kaiser and I really buckled down and got the IDA database detailed down to the line-of-code level in many places.

My bedroom walls were covered with printed-out flow charts bearing ink pen scribbles there for a while ;)

[kb1]

Quasar said:

...I have never received even one bit of feedback about the 2nd beta, and that's kind of disappointing.

I think Chocolate Strife is awesome, and massively impressive - you even got the IWAD demos to sync (even though you didn't need my demo sync report hack apps :( man, that was a lot of work!) Anyway, yeah it's awesome - thanks to everyone involved.

[exp(x)]

This is probably a good place for me to announce that my win32 subversion builds are back. Let me know if you find any problems.

[RestlessRodent]

What will happen to Choco when all the goals are completed?

[exp(x)]

GhostlyDeath said:

What will happen to Choco when all the goals are completed?

Maintenance mode?

[esselfortium]

GhostlyDeath said:

What will happen to Choco when all the goals are completed?

?

[fraggle]

It's worth pointing out that "all goals" includes quite a few crazy pie in the sky ideas

[natt]

Test on and fix for architectures where ((-2) >> 1) != -1

What architectures would this be?

[fraggle]

I seem to remember reading that there are some, though they're obscure CPU architectures. Point is that it's undefined behavior.

[entryway]

>> and << for signed is UB

[Graf Zahl]

natt said:

What architectures would this be?

Probably those on which no software works... :D

Undefined or not, I'm dead certain that 99% of programmers expect it to behave like it does almost everywhere so any architecture that does something different would have some serious problems.

[natt]

I was mistaken; I thought it was implementation defined behavior.