Re: WinHexen/WinHeretic

Posted on 2021-10-04, 02:44

by

by hail-to-the-ryzen

in Windows

in Windows

Can test compatibility of this port with hexen and heretic: https://github.com/drfrag666/ZDoom-CL/releases I believe that uses directdraw version 3. The PCX1 is probably a dx3-compatible video card.

---

Re: FastDoom. A new Doom port for DOS, optimized to be as fast as possible for 386/486 personal computers!

Posted on 2021-09-30, 12:04

by

by hail-to-the-ryzen

in Release Announcements

in Release Announcements

Thanks for the helpful instructions. A custom map set with less detail, like WolfenDoom, may also compress well to the lower resolution mode.

---

Re: FastDoom. A new Doom port for DOS, optimized to be as fast as possible for 386/486 personal computers!

Posted on 2021-09-30, 07:31

by

by hail-to-the-ryzen

in Release Announcements

in Release Announcements

I wonder whether a script, perhaps with the help of ImageMagick, could convert the textures to a scheme that conforms to the above CGA mode.

---

Re: Armored Fist 2 ctd in dosbox

Posted on 2021-09-15, 05:03

by

by hail-to-the-ryzen

in DOSBox Games/Apps

in DOSBox Games/Apps

As a test of last resort for the use of the dynamic x86 core, it is possible to change a cache block setting from 32 to another value. I have not tested it, but a value of 16 may work. Here is one of the locations of the setting in core_dyn_x86.cpp: block=CreateCacheBlock(chandler,ip_point,32) If …

---

Re: Unreal vs Unreal Gold (UT engine) Performance

Posted on 2021-08-01, 06:43

by

by hail-to-the-ryzen

in Marvin \ Software

in Marvin \ Software

Unreal itself however has had many, many rendering changes throughout the history of patches, including GlideDrv. I believe it was around 226 that they synced the renderers with UT 420 In Unreal version 226, including 224v, there is the non-mmx software renderer lighting bug as seen in UT 400 and …

---

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 …

---