Still haven't found what makes the OPL music volume low, I've checked that the volume levels get into the Apogee Sound System library fine, but haven't found yet how the library uses that volume with OPL data.
* Add executable filename to benchmark (CSV)
* Fix wrong fps display if 0XX after decimal point (@RamonUnch #145)
* New invisible column renderer: Flat Sega Saturn (@RamonUnch idea)
* Small code optimizations
* Sound Blaster MIDI support (for Sound Blaster 1.0, 1.5, 2.0, Pro 1.0 and Pro 2.0)
* Add executable filename to benchmark (CSV)
* Fix wrong fps display if 0XX after decimal point (@RamonUnch #145)
* New invisible column renderer: Flat Sega Saturn (@RamonUnch idea)
* Small code optimizations
* Sound Blaster MIDI support (for Sound Blaster 1.0, 1.5, 2.0, Pro 1.0 and Pro 2.0)
I have a question, i was testing PCM music, i make 8bit, 44khz, mono PCM , select 44khz pcm.in setup,and sound fine, but quality is not good, like too much noise. But same wav in a wave player sound much better
tested fastdoom pcm in two computers, DX266 and pentium 2 333, both awe64, same problem
I came here to say THANK YOU! one of my dreams came true, doom in DOS with music and sound in my old Toshiba T2130CS
This nice 640x480, DX4/75mhz 486 dont have any sound card, of course i can use a pcmcia sound, external opl or serial midi, but my dream was just using pcspeaker or a home made covox in real DOS (not a port in windows/linux)
Now using fastdoom i can enjoy my toshiba again, thanks man!!!! i upload a youtube video, covox sound amazing, pcspeaker more or less tolerable, maybe is possible to make pcs sound better?
Yeah PC Speaker it's not that great, don't know if there is any way to make it sound better (both PWM and 1-bit modes). I'm not that good at sound programming, it still gives me lot's of headaches. For now I'm focusing on performance improvements, next release will have multiple codepaths for some architectures (386SX, 386DX, Intel 486, Cyrix 486, UMC Green 486...) which will increase framerate a bit depending on each CPU, plus more optimizations for all architectures.
The 320x240 idea is good, my Toshiba has the same issue. The aspect ratio won't be right, but at least it will be fullscreen on those devices. I'll try to implement it.
* Sound Blaster MIDI support (for Sound Blaster 1.0, 1.5, 2.0, Pro 1.0 and Pro 2.0)
Thanks for this! It was always mildly annoying in the 1990s that there was essentially no support for SBMIDI in games (not that it mattered much, I didn't own an external General MIDI device until 2008 or so).
I was under the impression that the MIDI DSP commands couldn't be used while DMA-mode PCM audio was playing (I'm not sure where I got that from)... maybe this is true of earlier DSP versions, but both are working perfectly fine at the same time on an SBPro2 (CT1600, DSP version 3.xx).
On the other hand, attempting to use both SBMIDI and Direct Mode PCM freezes my system right after S_Init...
Ooops forgot to try the SB Direct mode + SB Midi, I'll take a look. Don't know if it will work though, both devices use the DSP so maybe they are conflicting.
BTW it would be great if someone try the new SB Midi support with older cards, as I only have SB16 cards and I had to emulate on 86Box the rest
Ooops forgot to try the SB Direct mode + SB Midi, I'll take a look. Don't know if it will work though, both devices use the DSP so maybe they are conflicting.
BTW it would be great if someone try the new SB Midi support with older cards, as I only have SB16 cards and I had to emulate on 86Box the rest
Please @CODOR try this bugfix executable, I've tried it on my SB16 and it works now.
BTW this executable includes a new configurable option, now it's possible to use render code for each CPU architecture. This allows for more performance on the selected CPU. The available command lines are:
-umc486
-intel486
-cyrix486
-386dx
-386sx
-cyrix5x86
-k5
-pentium
So any benchmark with these options is welcome as I'm tuning each architecture.
ViTi95wrote on 2023-05-25, 15:09:Please @CODOR try this bugfix executable, I've tried it on my SB16 and it works now. […] Show full quote
Please @CODOR try this bugfix executable, I've tried it on my SB16 and it works now.
BTW this executable includes a new configurable option, now it's possible to use render code for each CPU architecture. This allows for more performance on the selected CPU. The available command lines are:
-umc486
-intel486
-cyrix486
-386dx
-386sx
-cyrix5x86
-k5
-pentium
So any benchmark with these options is welcome as I'm tuning each architecture.
How do you need the test to be done?
Without and with switch to check the performance difference?
I can take care of testing the 486 cpus.
BTW this executable includes a new configurable option, now it's possible to use render code for each CPU architecture. This allows for more performance on the selected CPU. The available command lines are:
Fantastic! Is this automatically detecting CPU and only being overridden by command line? or runs generic path unless manually selected?
For now you have to select it manually, don't know if i'll add autodetection.
@Nemo1985 try multiple architectures for each single type of CPU with a single benchmark:
fdoom -timedemo demo3 -umc486 (-386sx, -intel486... and so on)
The idea is to find the best path for each architecture so I can optimize even further. Changing between types of CPU is kinda shitty with 486 cpu's, everytime I have to change lots of jumpers. Also I still have to make Ken Silverman's ideas to work (https://github.com/viti95/FastDoom/issues/143), so any help with this would be awesome.
EDIT: Base path will be Intel 486, it will work on any architecture properly
>Do aligned 32-bit writes to video memory. Easy for ceilings. Yes it's possible for walls (which are rendered in the vertical direction) too! The trick is: you render 4 vertical wall lines simultaneously.
Please @CODOR try this bugfix executable, I've tried it on my SB16 and it works now.
It works on my SBPro2, thanks!
BTW this executable includes a new configurable option, now it's possible to use render code for each CPU architecture. This allows for more performance on the selected CPU.
This also interests me as this machine happens to have a Cyrix 486DLC.
Tested system: 486DLC@33MHz, 8MB RAM, MS-DOS 6.22, Trident TVGA9000i, SBPro2 CT1600
fdoom.exe (from supplied fdoomtest.zip), doomu.wad, demo1 (1710 gametics), size 10, using DMA-mode SB and SBMIDI
The following are with HIMEM and EMM386 running:
potato
default: 2529 (23.665)
-386dx: 2529 (23.665)
-intel486: 2543 (23.535)
-pentium: 2556 (23.415)
-umc486: 2566 (23.324)
-k5: 2576 (23.233)
-386sx: 2613 (22.904)
-cyrix486: 2613 (22.904)
low
-cyrix486: 4253 (14.072)
-386sx: 4253 (14.072)
-umc486: 4261 (14.045)
-k5: 4274 (14.003)
-cyrix5x86: 4299 (13.921)
-pentium: 4300 (13.918)
-386dx: 4394 (13.620)
default: 4394 (13.620)
-intel486: 4405 (13.586)
high
default: 7454 (8.029)
-386dx: 7455 (8.028)
-umc486: 7429 (7.988)
-cyrix5x86: 7516 (7.963)
-pentium: 7517 (7.961)
-intel486: 7524 (7.954)
-k5: 7558 (7.918)
-cyrix486: 7731 (7.741)
-386sx: 7732 (7.740)
-cyrix486 wins at low detail but loses at potato and is 1 realtic away from the bottom at high (it ties or comes close to -386sx each time). The results seem odd to me so to rule out EMM386 I tried it again with only HIMEM (too lazy to try all the tests, just the default renderers and -cyrix486):
potato
default: 2459 (24.339)
-cyrix486: 2460 (24.329)
low
default: 4145 (14.439)
-cyrix486: 4147 (14.432)
high
default: 7296 (8.203)
-cyrix486: 7299 (8.199)
These are so close that I'm wondering if I remembered to type -cyrix486 in 😜
I probably won't have a chance to try again until after the weekend but I can build it from source and will test fdoom13h.exe then, too.
Here are the tests with 486, I used the very same pc of last time(MB: Biostar MB-8433UUD-rev2, 256kb cache, 32mb, s3 virge dx 4mb) results in realticks (lower score more fps), used the switch as following fdoom -timedemo demo3 -*cpuswitch*:
I still don't understand why the intel 486 dx4 cpu performs better than amd and cyrix (100 mhz), they shouldn't be the very same? At least with amd 486?
Also are you willing to write a data path for the amd 5x86? It's always the faster 486 fake cpu, it surely deserve it more than cyrix 5x86.
If anyone is willing to do the tests with 386 and socket 7 cpu it would be nice otherwise I will be able to do them too.
Do you need to be tested just the Pentium and k5? No k6 or some weird cpu like mp6?
As for 386 I just have those cpus:
Intel i386 A80386DX-33 IV ΣΣ version
Amd Am386 DX/DXL 40
TI TX486DLC/E-40GA
Could you please add the render code used in the benchmark result screen, just to be sure I used the right switch. Thanks.
PS: On my previous round up vs vanilla doom I used the 13h version if it matters.
Intel doubled the L1 cache when they launched the DX4 chips. AMD (and I assume Cyrix as well) did not AFAIK, it was only with the 5x86 that the cache was doubled, which should explain the performance discrepancy.
Intel doubled the L1 cache when they launched the DX4 chips. AMD (and I assume Cyrix as well) did not AFAIK, it was only with the 5x86 that the cache was doubled, which should explain the performance discrepancy.
I didn't know. So we have Amd and Intel with the very same architecture but different cache amount and then Cyrix with a different architecture and cache, is that right?
The Cyrix 486 architecture is a little worse compared to the Intel 486, there are multiple instructions that are slower, that's why is usually slower. And the difference between Intel and AMD 486 comes when AMD had to remove the ICE code, I've seen slower performance on those "N" cpu's. Also the 8kb vs 16kb L1 cache makes a difference, but even with the same amount of cache the AMD is a little slower.
One question, are you executing the benchmarks with sound/music enabled? I've discovered that enabling sound makes the benchmark results a bit unstable, if possible execute the with sound and music disabled.
ViTi95wrote on 2023-05-26, 07:48:The Cyrix 486 architecture is a little worse compared to the Intel 486, there are multiple instructions that are slower, that's […] Show full quote
The Cyrix 486 architecture is a little worse compared to the Intel 486, there are multiple instructions that are slower, that's why is usually slower. And the difference between Intel and AMD 486 comes when AMD had to remove the ICE code, I've seen slower performance on those "N" cpu's. Also the 8kb vs 16kb L1 cache makes a difference, but even with the same amount of cache the AMD is a little slower.
One question, are you executing the benchmarks with sound/music enabled? I've discovered that enabling sound makes the benchmark results a bit unstable, if possible execute the with sound and music disabled.