Re: Clive Barker's Undying is unplayable due to stuttering

Posted on 2021-07-13, 20:40

by

by hail-to-the-ryzen

in Windows

in Windows

Is it just the family of unreal engine games? It is possible to test with alternate sound settings, such as for UT99: [Galaxy.GalaxyAudioSubsystem] UseDirectSound=False UseFilter=False UseSurround=False UseStereo=True UseCDMusic=False UseDigitalMusic=False UseSpatial=False UseReverb=False …

---

Re: System requirements O2EM or MESS for dos?

Posted on 2021-07-13, 04:50

by

by hail-to-the-ryzen

in DOS

in DOS

A Pentium 1 should work for 1.16. It is also possible a fast 486 will run it, too. I believe mess is based on o2em and o2em is recommended.

---

Re: DOSBox ECE (for Windows & Linux)

Posted on 2021-06-10, 07:13

by

by hail-to-the-ryzen

in DOSBox Development

in DOSBox Development

The enthusiasm about the different dosbox forks reminds me of 3dfx voodoo code I have. It may work on the ECE port in addition to all the forks listed above. I think I still have the code, if so I can try to post it.

---

Re: Fastest emulators period

Posted on 2021-06-06, 07:45

by

by hail-to-the-ryzen

in Console & Arcade Emulation

in Console & Arcade Emulation

Gameboy: NO$GB (req 386DX33) Megadrive: KGEN98 (req 486DX4100) NES: LoopyNES (req 486DX266) / NESticle (req 486SX40) SNES: ZSNES (req 486DX4100 for some games, PentiumMMX 150 for most) Further tested the above in a 486 environment, except for the Gameboy. The NES emulator NESticle seems the best by …

---

Re: DOSBox-X branch

Posted on 2021-05-16, 04:47

by

by hail-to-the-ryzen

in DOSBox Patches

in DOSBox Patches

I think this would better meet the implementation recommended by jmarsh and krcroft. Tested the values for unsigned 8-bit mono sound only. This saves the xor operation, but one report suggests that the xor may use less than a cpu cycle. I think that the data value should have a casting operator, but …

---

Re: DOSBox-X branch

Posted on 2021-05-16, 00:10

by

by hail-to-the-ryzen

in DOSBox Patches

in DOSBox Patches

If that was set to >127 instead of 128, then i = 128 would access the path for correcting the bias in the conversion. The way it is currently written, the i = 128 results in a table value of 0 which is expected.

---

Re: DOSBox-X branch

Posted on 2021-05-15, 23:17

by

by hail-to-the-ryzen

in DOSBox Patches

in DOSBox Patches

That is a good analysis. The table function runs at the start of emulation only, so it is not as crucial to optimize there. And as you said, the compiler may help where optimizing. I also had verified that function for accuracy in its calculation and then moved to the other part. That avoids the …

---

Re: DOSBox-X branch

Posted on 2021-05-15, 22:11

by

by hail-to-the-ryzen

in DOSBox Patches

in DOSBox Patches

Here is an updated version because the previous version of the code seemed to have lower performance than expected. I noticed this where patching pcem with the same. This version was additionally tested against the boundary values of -128, 127, and all testing was for the signed 8-bit mono sound …

---

Re: DOSBox-X branch

Posted on 2021-05-14, 04:08

by

by hail-to-the-ryzen

in DOSBox Patches

in DOSBox Patches

Thank you, krcroft, for the help with the use of a second array to handle the 8-bit values. I wonder whether that would show better performance than the use of the xor operations that are used in the version below. I think that this code is now functional. I had to fix the dereferencing of the …

---

Re: DOSBox-X branch

Posted on 2021-05-14, 02:16

by

by hail-to-the-ryzen

in DOSBox Patches

in DOSBox Patches

That is great news, krcroft. Thank you for your work. I think there is a possible way, as I think jmarsh suggested, to avoid the xor operation on the data values. Something like this: tablePtr = signeddata ? &Sample_16_Table[128] : &Sample_16_Table[0]; I verified that the values are correct, but I …

---

Re: DOSBox-X branch

Posted on 2021-05-13, 23:47

by

by hail-to-the-ryzen

in DOSBox Patches

in DOSBox Patches

Thank you. I think that the code could be verified and possibly extended to save a few more instructions at the machine level. It is simpler now to read, but I think that xr can be removed and another set of table entries added (as per jmarsh's recommendation), but I think that it requires an …

---

Re: DOSBox-X branch

Posted on 2021-05-13, 23:07

by

by hail-to-the-ryzen

in DOSBox Patches

in DOSBox Patches

This is not yet compiled, but I followed your suggestion as best that I could and tried to fix the calculations. Sample_16_Table[] holds the sorted values, from low to high of the "scaled" 16-bit signed integer. static Bit16s Sample_16_Table[256]; // call function during mixer init void Mixer_ …

---

Re: DOSBox-X branch

Posted on 2021-05-13, 11:47

by

by hail-to-the-ryzen

in DOSBox Patches

in DOSBox Patches

That is a better idea. Thanks. I will try that tomorrow if someone else does not implement it first.

---

Re: DOSBox-X branch

Posted on 2021-05-13, 10:17

by

by hail-to-the-ryzen

in DOSBox Patches

in DOSBox Patches

This code is untested, but it seems like it is structured correctly for inclusion in the mixer.cpp file: static Bit16s Sample_16_Table[256]; // call function during mixer init void Mixer_SetSample16Table(void) { for (Bitu i=0;i<256;i++) { if (i > 128) Sample_16_Table[i]=((i-128) << 8) | (2 * (i-128) …

---

Re: DOSBox-X branch

Posted on 2021-05-13, 09:21

by

by hail-to-the-ryzen

in DOSBox Patches

in DOSBox Patches

That is a powerful tool, krcroft. Thank you for the instructions, too. A look-up table is a great idea. Below is a modification of krcroft's code to output the look-up table in human readable format. // gcc convert-8bit-16bit.c -o convert-8bit-16bit.exe short scale_uto16(unsigned char val) { if (val …

---

Re: DOSBox-X branch

Posted on 2021-05-13, 04:49

by

by hail-to-the-ryzen

in DOSBox Patches

in DOSBox Patches

Given the overflow does not occur, would this work: if (sizeof(Type) == 1) { const Bit8u xr = signeddata ? 0x00 : 0x80; + Bit8s d; len--; - current[0] = ((Bit8s)((*data++) ^ xr)) << 8; + d = (Bit8s)((*data++) ^ xr); + current[0] = d > xr ? (d << 8) | (2 * d + 1) : d << 8; - if (stereo) + if (stereo) …

---

Re: DOSBox-X branch

Posted on 2021-05-10, 23:26

by

by hail-to-the-ryzen

in DOSBox Patches

in DOSBox Patches

Thank you for the insight.

---

Re: DOSBox-X branch

Posted on 2021-05-10, 21:06

by

by hail-to-the-ryzen

in DOSBox Patches

in DOSBox Patches

Shifting negative values results in undefined behavior: https://github.com/dosbox-staging/dosbox-staging/pull/1005 if (sizeof(Type) == 1) { const Bit8u xr = signeddata ? 0x00 : 0x80; len--; - current[0] = ((Bit8s)((*data++) ^ xr)) << 8; - if (stereo) - current[1] = ((Bit8s)((*data++) ^ xr)) << 8; - …

---

Re: AUDIO Patch supporting FLAC, Opus, and MP3 audio tracks

Posted on 2021-04-11, 04:40

by

by hail-to-the-ryzen

in DOSBox Patches

in DOSBox Patches

A review of the commit history of the dynamic_x86 core is here: https://github.com/joncampbell123/dosbox-x/commits/master/src/cpu/core_dyn_x86 The commit history shows that some of the SVN patches for the dynamic_x86 core occurred after the non-recursive page fault handling was added. That means it …

---

Re: AUDIO Patch supporting FLAC, Opus, and MP3 audio tracks

Posted on 2021-04-10, 18:59

by

by hail-to-the-ryzen

in DOSBox Patches

in DOSBox Patches

Reverting the dynamic_x86 core to current SVN will likely break functionality in the dosbox-x dynrec core. There was also some merging of code between the dynrec and dynamic core (SVN) which may obfuscate future changes to the dynrec core. In any case, any changes or reversions should also be tested …

---