Release DooM 64 EX


Game is fluid, with the notable exception of the Intro, where it's stutering (it's because of the sound, to many polyphony going on and fuildsynth can be cpu hungry with more than 64 voices for midi and 64 others for sfx).
Instead of fluidsynth, you could use BASS+BASSMIDI for midi playback using soundfont (if it's possible here). It's much faster on Pandora than fluidsynth.

(BASS is free for non-commercial use. If you are a non-commercial entity (eg. an individual) and you are not making any money from your product (through sales, advertising, etc), then you can use BASS in it for free.)
How is the API change to go from Fluidsyth ->BASS+BASSMIDI ? Not too many thing to change in sound code?

Runs great, but is really dark.
Yep. I'll setup brighter default settings.
 
How is the API change to go from Fluidsyth ->BASS+BASSMIDI ? Not too many thing to change in sound code?
Things are done differently, but it should be too difficult. (I didn't work much with fluidsynth or bassmidi, so take it with a grain of salt).
For comparison, here are my simple test programs for playing midi file.

Fluidsynth:

#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include "fluidsynth.h"

int main(int argc, char *argv[])
{
fluid_settings_t* settings;
fluid_synth_t* synth;
fluid_player_t* player;
fluid_audio_driver_t* adriver;
settings = new_fluid_settings();

/* Set the synthesizer settings, if necessary */
fluid_settings_setstr(settings, "synth.sample-rate", "22050");
fluid_settings_setstr(settings, "synth.polyphony", "64");
synth = new_fluid_synth(settings);


player = new_fluid_player(synth);
fluid_settings_setstr(settings, "audio.driver", "alsa");
adriver = new_fluid_audio_driver(settings, synth);


fluid_synth_sfload(synth, "GeneralUser GS FluidSynth v1.44.sf2", 1);
fluid_player_add(player, "sequence-00.mid");

/* play the midi files, if any */
fluid_player_play(player);
/* wait for playback termination */
fluid_player_join(player);
/* cleanup */
delete_fluid_audio_driver(adriver);
delete_fluid_player(player);
delete_fluid_synth(synth);
delete_fluid_settings(settings);

return 0;
}
BASSMIDI:

Code:
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include "bass.h"
#include "bassmidi.h"

int main(int argc, char *argv[])
{
    HSOUNDFONT sfont;
    HSTREAM midi;

    BASS_Init(1, 22050, 0, 0, NULL));

    atexit((void (*)(void)) &BASS_Free);

    sfont = BASS_MIDI_FontInit("GeneralUser GS SoftSynth v1.44.sf2", 0);

    {
        BASS_MIDI_FONT fonts[1];
        fonts[0].font=sfont;
        fonts[0].preset=-1; // all presets
        fonts[0].bank=0; // default banks
        BASS_MIDI_StreamSetFonts(0, fonts, 1);
    }

    midi = BASS_MIDI_StreamCreateFile(0, "sequence-00.mid", 0, 0, BASS_STREAM_AUTOFREE, 0);

    BASS_ChannelPlay(midi, 1);

    while (BASS_ChannelIsActive(midi) == BASS_ACTIVE_PLAYING) {
        sleep(1);
    }

    return 0;
}
 
How is the API change to go from Fluidsyth ->BASS+BASSMIDI ? Not too many thing to change in sound code?
Things are done differently, but it should be too difficult. (I didn't work much with fluidsynth or bassmidi, so take it with a grain of salt).

For comparison, here are my simple test programs for playing midi file.


Fluidsynth:

#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include "fluidsynth.h"

int main(int argc, char *argv[])
{
fluid_settings_t* settings;
fluid_synth_t* synth;
fluid_player_t* player;
fluid_audio_driver_t* adriver;
settings = new_fluid_settings();

/* Set the synthesizer settings, if necessary */
fluid_settings_setstr(settings, "synth.sample-rate", "22050");
fluid_settings_setstr(settings, "synth.polyphony", "64");
synth = new_fluid_synth(settings);


player = new_fluid_player(synth);
fluid_settings_setstr(settings, "audio.driver", "alsa");
adriver = new_fluid_audio_driver(settings, synth);


fluid_synth_sfload(synth, "GeneralUser GS FluidSynth v1.44.sf2", 1);
fluid_player_add(player, "sequence-00.mid");

/* play the midi files, if any */
fluid_player_play(player);
/* wait for playback termination */
fluid_player_join(player);
/* cleanup */
delete_fluid_audio_driver(adriver);
delete_fluid_player(player);
delete_fluid_synth(synth);
delete_fluid_settings(settings);

return 0;
}
BASSMIDI:



#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include "bass.h"
#include "bassmidi.h"

int main(int argc, char *argv[])
{
HSOUNDFONT sfont;
HSTREAM midi;

BASS_Init(1, 22050, 0, 0, NULL));

atexit((void (*)(void)) &BASS_Free);

sfont = BASS_MIDI_FontInit("GeneralUser GS SoftSynth v1.44.sf2", 0);

{
BASS_MIDI_FONT fonts[1];
fonts[0].font=sfont;
fonts[0].preset=-1; // all presets
fonts[0].bank=0; // default banks
BASS_MIDI_StreamSetFonts(0, fonts, 1);
}

midi = BASS_MIDI_StreamCreateFile(0, "sequence-00.mid", 0, 0, BASS_STREAM_AUTOFREE, 0);

BASS_ChannelPlay(midi, 1);

while (BASS_ChannelIsActive(midi) == BASS_ACTIVE_PLAYING) {
sleep(1);
}

return 0;
}



Oh, thanks for the samples :) !

Will look at that.
 
Another vote for BASS here - I use it for PandaBAS's sound handler and it's great. It does however have some bugs in it under ARM - small samples on the Pandora tend to get the first few Ms clipped before being brought up to full volume. I've reported it, but as the Pandora is the only ARM platform affected, it's likely the Pandora at fault rather than BASS... that's not to say that it's not still annoying though.

Would be nice to see it used in other ports too, for a small performance boost.

D.
 
Hi,

- Bug report #1: while in game, if you go into the options menu (to save your progress for example) then back in game, it'll be much more brighter than before. You have to go back into the options menu, then back again in game to restore the usual darkness of DooM 64 (on a Rebirth Pandora, Super Zaxxon 1.60, default drivers)

- Bug report #2: when you exit the game, dark squares remain visible on parts of your desktop (XFCE)

- Sound gets laggy when using the machinegun.

- Could someone send a feature request upstream, to be able to skip the intro with a new option in config.cfg ?

Cheers, Magic Sam
 
Hi,

- Bug report #1: while in game, if you go into the options menu (to save your progress for example) then back in game, it'll be much more brighter than before. You have to go back into the options menu, then back again in game to restore the usual darkness of DooM 64 (on a Rebirth Pandora, Super Zaxxon 1.60, default drivers)

- Bug report #2: when you exit the game, dark squares remain visible on parts of your desktop (XFCE)

- Sound gets laggy when using the machinegun.

- Could someone send a feature request upstream, to be able to skip the intro with a new option in config.cfg ?

Cheers, Magic Sam
Hi,

#1 I have seen that yesterday. Quite a strange bug, I'll try to fix it (I think it's an upstream bug)...

#2 Yes, I have seen, but I have considered it to be minor (I think the destruction of the EGL Context is not perfect and I should take a deeper look there).

Sound with Machinegun is OK on a Gigahertz, so I didn't notice. I'll look at switching to BASS (but that will take some time).

Ah yes, why not a "No Intro" option yes. I'll take a look.
 
Regarding the softsynth, you could also have a look at TiMidity++ and WildMIDI. Both projects are licensed under GPL / LGPL. 

EDIT: WildMIDI compiles like a charm on the Pandora ;)
 
Last edited by a moderator:
Timidity is very fast in Euke nukem for example and can use the samplepacks from the timidity installer.


Edit: Also there are doom samplebanks available online.
 
Last edited by a moderator:
I took a look at Kex Engine sourcecode and switching from Fluidsynth to BASSMIDI is more work than I thought (but not impossible, I think). That's because the engine isn't giving Fluidsynth a midi file to play(convert), but it's parsing the midi file and giving individual midi events to Fluidsynth at appropriate times.
 
Last edited by a moderator:
wow ... never really played Doom64 before. I don't think it's the best version, it is by far the creepiest version though!

It looks and feels like a cross between Duke Nukem 3D and Quake.

Unfortunately it entirely lacks the "Doom-feeling". Probably some good music instead of creepy background noise would have helped here. So far I find it rather unpleasant to be in the game ... the port is good though, I especially like the feature of just pointing it to the .rom file and everything is done for you.

Anyway, since it is available as a port an brings all the benefits of easily customizing the controls and saving where you want and so on I will try to finish it. Not using headphones though, unlike Doom I&II totally not worth it :p

- Bug report #1: while in game, if you go into the options menu (to save your progress for example) then back in game, it'll be much more brighter than before. You have to go back into the options menu, then back again in game to restore the usual darkness of DooM 64 (on a Rebirth Pandora, Super Zaxxon 1.60, default drivers)

[...]
Hi,

#1 I have seen that yesterday. Quite a strange bug, I'll try to fix it (I think it's an upstream bug)...
I encountered the same bug, but something else must be wrong here:

On the first level I saved the game, and suddenly everything looked like you're wearing Night Vision Goggles in Doom I&II. In the last room of the first level, the one with the door to the exit room, there is a column in the room. A Demon is standing to the left and another one to the right, behind the column when you enter the room (playing default difficulty-level). While I had the brightness-bug, a light was circling around that column.

Later I decided to load that save game again. The brightness was now correct, but there is no longer a light circling around that column. It is just static pointing about where the second demon is waiting.

I don' know if the light is circling when you reach there without triggering the bug?

Anyway, maybe this helps to pin down the problem ...
 
I took a look at Kex Engine sourcecode and switching from Fluidsynth to BASSMIDI is more work than I thought (but not impossible, I think). That's because the engine isn't giving Fluidsynth a midi file to play(convert), but it's parsing the midi file and giving individual midi events to Fluidsynth at appropriate times.
Yes, that will surely render things more difficult.

Also, is BASS really that efficient? By default in the engine, Fluidsynth is configured with 80 midi channels and a total of 256 channel polyphony (quite a lot !). In the intro, I tried to lower the number of midi channel but get "out of channels" warning, and I must keep max polyphonie at 128 also to avoid (most) out of channels warning. So that's a lot of voices at the same time (and fluidsynth eat something like 50~60% cpu at this moment on my gigahertz). Do you think BASS can do better (cpu wise) ?

wow ... never really played Doom64 before. I don't think it's the best version, it is by far the creepiest version though!

It looks and feels like a cross between Duke Nukem 3D and Quake.

Unfortunately it entirely lacks the "Doom-feeling". Probably some good music instead of creepy background noise would have helped here. So far I find it rather unpleasant to be in the game ... the port is good though, I especially like the feature of just pointing it to the .rom file and everything is done for you.

Anyway, since it is available as a port an brings all the benefits of easily customizing the controls and saving where you want and so on I will try to finish it. Not using headphones though, unlike Doom I&II totally not worth it :p

- Bug report #1: while in game, if you go into the options menu (to save your progress for example) then back in game, it'll be much more brighter than before. You have to go back into the options menu, then back again in game to restore the usual darkness of DooM 64 (on a Rebirth Pandora, Super Zaxxon 1.60, default drivers)

[...]
Hi,

#1 I have seen that yesterday. Quite a strange bug, I'll try to fix it (I think it's an upstream bug)...
I encountered the same bug, but something else must be wrong here:

On the first level I saved the game, and suddenly everything looked like you're wearing Night Vision Goggles in Doom I&II. In the last room of the first level, the one with the door to the exit room, there is a column in the room. A Demon is standing to the left and another one to the right, behind the column when you enter the room (playing default difficulty-level). While I had the brightness-bug, a light was circling around that column.

Later I decided to load that save game again. The brightness was now correct, but there is no longer a light circling around that column. It is just static pointing about where the second demon is waiting.

I don' know if the light is circling when you reach there without triggering the bug?

Anyway, maybe this helps to pin down the problem ...
Thanks for the report (yes, that "music" is really creepy, and I miss the DooM II music !). Will look at this brightness buf this WE I think...
 
Hi,

Just to say I'm enjoying this game a lot :) OK, that's quite a departure from "traditional" DooM, but I don't think it's an issue here. Midway has done a hell of a good job IMHO: the music is really creepy, the graphics are gorgeous, the levels are very well designed, etc...

That's amazing what one can do with that good old DooM engine !

Cheers, Magic Sam
 
Also, is BASS really that efficient? By default in the engine, Fluidsynth is configured with 80 midi channels and a total of 256 channel polyphony (quite a lot !). In the intro, I tried to lower the number of midi channel but get "out of channels" warning, and I must keep max polyphonie at 128 also to avoid (most) out of channels warning. So that's a lot of voices at the same time (and fluidsynth eat something like 50~60% cpu at this moment on my gigahertz). Do you think BASS can do better (cpu wise) ?
I tried playing one midi file with one soundfont using Fluidsynth and using BASSMIDI (on original CC Pandora at 600 MHz).With Fluidsynth the music was stuttering - 100% CPU utilization, load average was higher than 1.

With BASSMIDI the music was OK - CPU utilization was around 15% if I remember correctly.

This was when using frequency 22050.

I think the main difference in speed is because Fluidsynth uses floats and BASSMIDI uses fixed point ints (on ARM).

You can test it yourself using the test programs in post #22.
 
Last edited by a moderator:
Also, is BASS really that efficient? By default in the engine, Fluidsynth is configured with 80 midi channels and a total of 256 channel polyphony (quite a lot !). In the intro, I tried to lower the number of midi channel but get "out of channels" warning, and I must keep max polyphonie at 128 also to avoid (most) out of channels warning. So that's a lot of voices at the same time (and fluidsynth eat something like 50~60% cpu at this moment on my gigahertz). Do you think BASS can do better (cpu wise) ?
I tried playing one midi file with one soundfont using Fluidsynth and using BASSMIDI (on original CC Pandora at 600 MHz).
With Fluidsynth the music was stuttering - 100% CPU utilization, load average was higher than 1.


With BASSMIDI the music was OK - CPU utilization was around 15% if I remember correctly.


This was when using frequency 22050.


I think the main difference in speed is because Fluidsynth uses floats and BASSMIDI uses fixed point ints (on ARM).


You can test it yourself using the test programs in post #22.
Oh, impresssive difference ! Fuildsynth use float yes. Ok, will do some testing with your code this W.E. (or before) and I'll report my results here.
 
Hi, this is MP2E, one of the two Lead Maintainers of Doom64 EX. The project's homepage can be found here if you'd like to keep up with recent developments or post on our forums. Kex is currently looking to take over the world! Kaiser and I are planning to release binaries for Win32, Win64, Linux x86 and x64, Raspberry Pi, Mac OS X, Mac OS 9, and now probably the OpenPandora port! Android is planned sometime in the future as well, as soon as I start to get over my Java-phobia ;)

Doom64 is an incredibly dark game, and since EX strives to emulate the original you may need to turn gamma and brightness up. I know I do :p Kaiser and I have considered switching the sound system time and time again, as we *really* despise FluidSynth(to the point of considering writing an in-house solution) but Kaiser was skeptical of all of the alternatives I showed him because of the particular way that D64 handles midi events.

I'm sure you've noticed, but *EVERYTHING* is a MIDI in D64, including things like monster sounds! A midi "file" isn't typically played, per se, a set of MIDI events are streamed to fluidsynth. Any code is appreciated to help us get around this roadblock.

Unfortunately, if you port it to BASSMIDI I will not be able to accept that contribution as, that code is inherently incompatible with our codebase. Kex, and therefore my branch "kexplus" are available under the GPLv2 which does not allow for linking of components unless they are under a more permissive license than the GPLv2 itself. Since BASSMIDI is non-commercial, it takes away one of the rights the GPL guarantees and is therefore incompatible. I'm sorry, I cannot do anything about this because our code is derived from the Doom engine, and all copyright holders(including everyone involved at ID Software) would need to be notified AND give Kaiser and I permission to add a clause to allow non-free linking.

Please use something that is BSD, GPLv2, zlib, or some other similarly permissive license and I will work with you to ensure your work is incorporated upstream :)
 
oh, so ALL sounds are midi?? I guess that explains a lot about the way it sounds. Actually now I'm really impressed.
 
Kaiser and I have considered switching the sound system time and time again, as we *really* despise FluidSynth(to the point of considering writing an in-house solution) but Kaiser was skeptical of all of the alternatives I showed him because of the particular way that D64 handles midi events.
As I see it you need a softsynth which uses soundfonts to play midi. I'm only aware of Fluidsynth, BASSMIDI and maybe Timidity++, so you don't have many options.
I'm sure you've noticed, but *EVERYTHING* is a MIDI in D64, including things like monster sounds! A midi "file" isn't typically played, per se, a set of MIDI events are streamed to fluidsynth. Any code is appreciated to help us get around this roadblock.
Maybe you could play multiple midi streams simultaneously. Both Fluidsynth and BASSMIDI support this.
Unfortunately, if you port it to BASSMIDI I will not be able to accept that contribution as, that code is inherently incompatible with our codebase. Kex, and therefore my branch "kexplus" are available under the GPLv2 which does not allow for linking of components unless they are under a more permissive license than the GPLv2 itself. Since BASSMIDI is non-commercial, it takes away one of the rights the GPL guarantees and is therefore incompatible. I'm sorry, I cannot do anything about this because our code is derived from the Doom engine, and all copyright holders(including everyone involved at ID Software) would need to be notified AND give Kaiser and I permission to add a clause to allow non-free linking.

Please use something that is BSD, GPLv2, zlib, or some other similarly permissive license and I will work with you to ensure your work is incorporated upstream :)
I admit I didn't check the licence of Kex before suggesting BASSMIDI, but you could use BASSMIDI with your codebase if you use it as a plugin.
BTW do you know how the midi playing was handled on N64? Did the game also use a softsynth or was it sending midi events to the OS / MIDI hardware ?
 
Hi, this is MP2E, one of the two Lead Maintainers of Doom64 EX. The project's homepage can be found here if you'd like to keep up with recent developments or post on our forums. Kex is currently looking to take over the world! Kaiser and I are planning to release binaries for Win32, Win64, Linux x86 and x64, Raspberry Pi, Mac OS X, Mac OS 9, and now probably the OpenPandora port! Android is planned sometime in the future as well, as soon as I start to get over my Java-phobia ;)

[...]

Unfortunately, if you port it to BASSMIDI I will not be able to accept that contribution as, that code is inherently incompatible with our codebase. Kex, and therefore my branch "kexplus" are available under the GPLv2 which does not allow for linking of components unless they are under a more permissive license than the GPLv2 itself. Since BASSMIDI is non-commercial, it takes away one of the rights the GPL guarantees and is therefore incompatible. I'm sorry, I cannot do anything about this because our code is derived from the Doom engine, and all copyright holders(including everyone involved at ID Software) would need to be notified AND give Kaiser and I permission to add a clause to allow non-free linking.

Please use something that is BSD, GPLv2, zlib, or some other similarly permissive license and I will work with you to ensure your work is incorporated upstream :)
Good luck getting it to run at any kind of framerate on the Raspberry PI then - floating point performance there is even worse than on the Pandora. Running the Pandora port is quite flakey at 800Mhz on my CC pandora framerate-wise, and a non-FP sound lib would really help.

D.
 
oh, so ALL sounds are midi?? I guess that explains a lot about the way it sounds. Actually now I'm really impressed.
Yep, everything! I believe it is because of the way that the N64's DSP for sound processing works, everything is handled as an "event" that was very similar to MIDI, except with MOD style samples provded by the cartridge.

As I see it you need a softsynth which uses soundfonts to play midi. I'm only aware of Fluidsynth, BASSMIDI and maybe Timidity++, so you don't have many options.



Maybe you could play multiple midi streams simultaneously. Both Fluidsynth and BASSMIDI support this.


I admit I didn't check the licence of Kex before suggesting BASSMIDI, but you could use BASSMIDI with your codebase if you use it as a plugin.


BTW do you know how the midi playing was handled on N64? Did the game also use a softsynth or was it sending midi events to the OS / MIDI hardware ?
Those are all we know of, as well. The issue is converting it into a monolithic file because the midi events we are using are custom in a few instances, so a vanilla MIDI wouldn't work completely. Perhaps with some review we could write a format derived from MIDI that can handle these special events.

I wouldn't mind BASSMIDI support as an optional backend, I just don't want to *depend* on it since it's a bit trickier to destribute. If it is the only practical way to get sound to run on the OpenPandora at decent speeds, then I am all for either distributing them in 2 seperate packages or perhaps a disclaimer could pop up(similar to RetroArch) and prompt the user to delete BASSMIDI, if they want.

Such a shame that all of the MIDI libraries available have some inherent problem, though.

TL;DR BASSMIDI is fine as long as fluidsynth code can coexist with it, I'd rather see a polished port than a crippled port because of silly idealisms. I'm a practical open source advocate, not a zealot.
 
Last edited by a moderator:
Back
Top