Import new PSG noise generation code from Neko Project II

[joncampbell123]

https://twitter.com/yksoft1/status/1166599394407395329

[yksoft1]

Newer Neko Project II forks can be found at: https://github.com/AZO234/NP2kai https://github.com/mrhso/np21w

[cracyc]

Something to check is Hanafuda de Pon! which uses the psg volume trick to play pcm samples.

[joncampbell123]

I tried importing the psggen*.c files from NP2Kai but it completely changes the sound of the noise channel.

All noise becomes a quiet hiss with no variation in pitch that I can hear, at least compiled to x86_64.

Are you sure NP2Kai didn't break the PSG generation?

[yksoft1]

I did this and didn't hear any big difference in noise channel. https://github.com/yksoft1/dosbox-x-vanilla-sdl/commit/35042840bb69f7ce271815f726de789ed87a6b99

[joncampbell123]

Try it with a game that varies the PSG noise pitch, like Touhou Project 1 (level start, and getting hit with your own ball).

[joncampbell123]

I also just confirmed the noises on real hardware match what DOSBox-X currently renders for PSG noise given the same game and sound effects.

[joncampbell123]

I applied your commit to DOSBox-X and it still sounds different from before and from what real hardware sounds like given those sound effects. It sounds higher pitched than real hardware.

[joncampbell123]

https://www.youtube.com/watch?v=kDnNeXI-ehU

[yksoft1]

I found the original change about PSG noise from np2. https://github.com/aliaspider/np2/commit/e1c04f0f174a3d9f31499aacdd52969457feec45 https://github.com/aliaspider/np2/commit/7ead1dd09556277e2158075d1ba7ed22adac0f39

[joncampbell123]

@yksoft1 Go ahead and apply those changes, then try the same part of TH01 as I did in those tests and see if it sounds like the DOSBox-X and real hardware cases shown in the video.

[yksoft1]

@yksoft1 Go ahead and apply those changes, then try the same part of TH01 as I did in those tests and see if it sounds like the DOSBox-X and real hardware cases shown in the video.

I confirmed that directly applying the changes from np2's author will make the noise channel generate noise of much higher pitch, different from my own commit.

However it didn't break in np2 itself. Why?

[joncampbell123]

What are the data types of UINT and other data types in that code when np2 is compiled, and is it compiled 32-bit or 64-bit?

[joncampbell123]

Also know that on 64-bit, Linux and Windows have different definitions of long vs long long. Linux treats long and long long as 64-bit, Windows treats long as 32-bit and long long as 64-bit.

[yksoft1]

What are the data types of UINT and other data types in that code when np2 is compiled, and is it compiled 32-bit or 64-bit?

I always build np2 (including np21w and NP2kai) on 32-bit Windows. compiler.h (for the win9x target) says:

#if !defined(__GNUC__) && !defined(__MINGW32__)
typedef signed int          SINT;
typedef signed char         SINT8;
typedef unsigned char       UINT8;
typedef signed short        SINT16;
typedef unsigned short      UINT16;
typedef signed int          SINT32;
typedef unsigned int        UINT32;
typedef signed __int64      SINT64;
typedef unsigned __int64    UINT64;
#define INLINE              __inline
#define QWORD_CONST(v)      ((UINT64)(v))
#define SQWORD_CONST(v)     ((SINT64)(v))
#define snprintf            _snprintf
#define vsnprintf           _vsnprintf
#else
#include <stdlib.h>
typedef signed int          SINT;
typedef signed char         INT8;
typedef signed char         SINT8;
typedef unsigned char       UINT8;
typedef signed short        INT16;
typedef signed short        SINT16;
typedef unsigned short      UINT16;
typedef signed int          SINT32;
typedef signed __int64      SINT64;
#define INLINE              inline
#endif
#define FASTCALL            __fastcall