Release DooM 64 EX

[Magic Sam]

Hi all

@ptitSeb : thanks for this new release, it's really appreciated !

Cheers, Magic Sam

 

[atari_afternoon]

Doom always is

 

[Magic Sam]

Hi all

@ptitSeb : wouldn't this launcher be great with DooM 64 EX (and your other DooM ports) ?

https://github.com/FreaKzero/ssgl-doom-launcher

Cheers, Magic Sam

 

[ptitSeb]

Well, it's a node.js app, so not sure Pandora is a good target. Maybe Pyra.

 

[Magic Sam]

@ptitSeb : OK, I understand

DooM 64 is such a great game: the graphics still look amazing today, the music really sets the mood, and I really like the overall design (levels, monsters, weapons, etc...) !

It sometimes plays a little bit like Quake 1, and prefigures what DooM 3 would be like years later IMHO.

I wish I would have known about this game back in the days, instead of focusing only on the PC versions...

Thanks again for porting it to the Pandora !

Cheers, Magic Sam

 

[Magic Sam]

Hi all

I rebuild the sources but I don't have updated them (still SDL1.2). It seems to works fine and fast anyway.

@ptitSeb : well, speed really depends on the level. Levels 8 and 9 were pretty slow for example on my Rebirth with OC @ 600MHz. I can provide you with saved games if need be.

I had a quick look at the configuration file, see if there's some kind of FPS-o-meter I could turn on, but it seems there's not, so I can't really tell you how much the Pandora struggles at times with this game.

EDIT: @ptitSeb : sorry for being stupid I forgot your port uses glshim, thus making it compatible with @notaz ' Live System Info... So... FPS dips well below 10 in level 8, in some room where you battle against 3 barons at the same time (just before the exit).

EDIT 2: overclocking to 825 MHz doesn't help...

Cheers, Magic Sam

 

[ptitSeb]

Yes, send me a savestate so I can see if I can improve framerate.

 

[Magic Sam]

@ptitSeb : here you go, I'm attaching my .doom64ex directory to this post

One of the saved game is labelled "Level 8 slow" IIRC.

Cheers, Magic Sam

 

[ptitSeb]

@Magic Sam : here is a test version: doom64ex (link removed, that test is over)

I haven' treally found anything special on my Gigahertz. It's still over 20fps, but it seems the GLES part was slowing it down a bit.
So I enabled Batch mode in this release, and recompile fluidsynth + neoninzed 1 function (I hope I didn't broke anything in the process). Still smooth on my side, and didn't really noticed anything broken du to the batch mode (maybe on the savestate Load screen, but that minor). Please test and report, so I upload it or not to the repo.

 

[Magic Sam]

Hi all

@ptitSeb : thanks for this new version ! Unfortunately, level 8 is as slow as before on my Rebirth @ 600MHz. EDIT: and GPU driver 4.10.

I'm now in level 10 or 11 (can't remember which exactly), and the game is getting slower as it progresses (larger maps, more monsters, etc...)

EDIT 2: @ptitSeb : level 11 speed ranges from ~10 to ~15 FPS. The game reaches 20 FPS only in simple, closed rooms... It's still playable, but hardly enjoyable.

Cheers, Magic Sam

 

[Magic Sam]

Hi all

@ptitSeb : I'm almost mid-way through the game (level 15 out of 32). I've been playing the last few levels with your new version from Saturday, and I didn't notice any obvious bugs or regressions. I'd say it's safe to upload it to the Repo

Btw, have you any further plans regarding this port ?

Cheers, Magic Sam

 

[ptitSeb]

I haven't found any obvious spot to optimise exept libfluidsynth itself.

So, I may update it with newer glshim or fresh compile from time to time, but unless I (or someone else) write alibfluidsynth based on integer, don't expect much from it.

 

[Magic Sam]

@ptitSeb : OK, I understand.

On a side note, I have just found the following Fluidsynth forks on Github:

https://github.com/Neonking/FluidSynth-lib
https://github.com/atsushieno/android-fluidsynth
https://github.com/VolcanoMobile/fluidsynth
https://github.com/atsushieno/fluidsynth
https://github.com/julbouln/lfluidsynth
https://github.com/divideconcept/FluidLite

Is there anything worth a look in there ?

EDIT: @ptitSeb : some of those forks refer to OpenSL ES. Is this something we could use on the Pandora ?

EDIT 2: and here is an interesting post about Fluidsynth on the Pandora:

https://lists.nongnu.org/archive/html/fluid-dev/2011-08/msg00055.html

Cheers, Magic Sam

 

[ptitSeb]

Yeah, nothing new here. You can find a lot of message about fluidsynth eating all cpu of various arm devices...
(OpenSL ES is the sound subsystem of Android, nothing interresting for us).

 

[emu3211]

Have you tried modifying the source for possibly lower cpu utilization:

+        fluid_settings_setnum(settings, "synth.sample-rate", 48000);  // or another rate
+        fluid_settings_setnum(settings, "synth.gain", 1);  // loudness
+        fluid_settings_setstr(settings, "synth.reverb.active", "no");  // for testing
+        fluid_settings_setstr(settings, "synth.chorus.active", "no"); 
+        fluid_settings_setint(settings, "synth.polyphony", 256);
+        fluid_settings_setnum(settings, "synth.cpu-cores", 1);
+        fluid_settings_setnum(settings, "audio.periods", 2);
+        fluid_settings_setnum(settings, "audio.period-size", 256);

Also, this would apply to the fluidsynth library for possibly a better sounding output, but not for cpu usage:

-#define FLUID_REVERB_DEFAULT_ROOMSIZE 0.2f      /**< Default reverb room size */
-#define FLUID_REVERB_DEFAULT_DAMP 0.0f          /**< Default reverb damping */
-#define FLUID_REVERB_DEFAULT_WIDTH 0.5f         /**< Default reverb width */
-#define FLUID_REVERB_DEFAULT_LEVEL 0.9f         /**< Default reverb level */
+#define FLUID_REVERB_DEFAULT_ROOMSIZE 0.61f      /**< Default reverb room size */
+#define FLUID_REVERB_DEFAULT_DAMP 0.23f          /**< Default reverb damping */
+#define FLUID_REVERB_DEFAULT_WIDTH 0.76f         /**< Default reverb width */
+#define FLUID_REVERB_DEFAULT_LEVEL 0.57f         /**< Default reverb level */

and:

-#define FLUID_CHORUS_DEFAULT_LEVEL 2.0f                         /**< Default chorus level */
+#define FLUID_CHORUS_DEFAULT_LEVEL 1.2f                         /**< Default chorus level */

 

[Magic Sam]

Hi all !

@emu3211 : wow, great first post ! Welcome to the boards by the way

I hope @ptitSeb will implement those modifications in Fluidsynth

Cheers, Magic Sam

 

[ptitSeb]

I already changed a lots of things on the fluidsynth side.
On doom64ex, I put polyphony to 160 (lower value break doom64ex) and reduced sample rate too.

        Seq_SetConfig(&doomseq, "synth.polyphony", 160);
        Seq_SetConfig(&doomseq, "synth.sample-rate", 22050);

On fluidsynth itself, I put some neon code in fluid_revmodel_processmix, I forced the interpolation to FLUID_INTERP_NONE and removed fluid_iir_filter_calc

Fluidsynth is heavy, you don't mix 160 voice with reverb and all with no cpu...

 

[Magic Sam]

Fluidsynth is heavy, you don't mix 160 voice with reverb and all with no cpu...

One of the Fluidsynth forks I told you about yesterday uses some kind of DSP IIRC. Could something similar be achieved easily on the Pandora ?

EDIT: https://github.com/julbouln/lfluidsynth

DSP is ARM Cortex-M4 if I'm not mistaken

Cheers, and thanks @ptitSeb for all the time and efforts you already put into this port, it's really appreciated

Magic Sam

 

[ptitSeb]

It's a very old version of the lib, not sure it's compatible with doom64ex. The empahsis is on memory space, not much cpu power, and it can be compiled for DSP, but I haven't seen specific DSP code. All math are still float based inside.

I'll see if I can make an (mostly) Interger only build of fluidsynth and if it helps. But not sure when I'll strat working on that, and how long will it take...

 

[Magic Sam]

@ptitSeb : thanks for trying

On a side note, could you please build a DooM 64 EX release with sound processing completely turned off ?

This way, one could see how an optimized build would be like (mostly).

Cheers, Magic Sam