If there is no sound card installed then there is no need to disable sound and music, it's already disabled. The issue comes when a sound card is installed and sound or music device selected. Sound cards use interrupts in order to work, and that causes sound code to be executed whenever the sound card requires it, adding more variability to the results. Here I'm testing only game and rendering code, so better with sound/music disabled.

ViTi95 wrote on 2023-05-26, 08:23:

If there is no sound card installed then there is no need to disable sound and music, it's already disabled. The issue comes when a sound card is installed and sound or music device selected. Sound cards use interrupts in order to work, and that causes sound code to be executed whenever the sound card requires it, adding more variability to the results. Here I'm testing only game and rendering code, so better with sound/music disabled.

I see, no worries then, I'm using the motherboard with the bare minimum hardware to run the tests.
For what i matters I ran some test twice and as always with dos results are consistent, very same ticks.

Tested system: OPTI495slc, 386DX@40MHz, 32Mb RAM, 128kb cache, OAK OTI87.
Sound disabled, doom2.wad, demo3 (4471 gametics), screenblocks 8, full detail.

default: 12761 (12,262)
386sx: 12754 (12,269)
386dx: 12757 (12,266)
intel486: 12724 (12,298)
cyrix486: 12790 (12,234)
umc486: 13279 (11,346)
cyrix5x86: 13637 (11,475)
k5: 13641 (11,471)
pentium: 13752 (11,376)

ViTi95 wrote on 2023-05-26, 07:48:

I've discovered that enabling sound makes the benchmark results a bit unstable, if possible execute the with sound and music disabled.

Enclosed are results with sound disabled; my original thinking was that the average user would be using sound so I should test it that way, but yeah with interrupts happening in the background I can see where that wouldn't be desirable while benchmarking.

Note 1: this is with commit a59723e, not the latest since I built it a few days ago and didn't check for updates until now. But it seems to support removal of some of the Cyrix optimizations in commit 5131989.

Note 2: the first 3 runs were without any arch argument. It seems to default to cyrix5x86? Or maybe selectedCPU isn't initialized and that value just happens to be in memory (from a previous run)?

Note 3: the DOS command line is limited to 127 bytes so some lines in bench.bat get truncated when they're run. I discovered this when I let it run unsupervised and only the K5 benchmark ended up in the csv file (i.e. "-csv" was being dropped). Occasionally it would get stuck playing all the demos when the timedemo option got truncated, too. (It also explains why the cyrix5x86 potato mode benchmark was missing from my previous results.) Does FastDoom support the @<response> option?

CODOR wrote on 2023-05-30, 01:27:

Note 1: this is with commit a59723e, not the latest since I built it a few days ago and didn't check for updates until now. But it seems to support removal of some of the Cyrix optimizations in commit 5131989.

Yeah I removed the Cyrix DR0 register use optimizations, they ended up being slower compared to the 386sx (CR2 register) codepath. Which is strange since the datasheets shows that moving data from DR0-3 registers is faster than moving data from CR2 register on the Cyrix processors.

CODOR wrote on 2023-05-30, 01:27:

Note 2: the first 3 runs were without any arch argument. It seems to default to cyrix5x86? Or maybe selectedCPU isn't initialized and that value just happens to be in memory (from a previous run)?

For now I haven't deal with default settings, as there isn't a generic codepath set for now, so better to test with an architecture selected.

CODOR wrote on 2023-05-30, 01:27:

Note 3: the DOS command line is limited to 127 bytes so some lines in bench.bat get truncated when they're run. I discovered this when I let it run unsupervised and only the K5 benchmark ended up in the csv file (i.e. "-csv" was being dropped). Occasionally it would get stuck playing all the demos when the timedemo option got truncated, too. (It also explains why the cyrix5x86 potato mode benchmark was missing from my previous results.) Does FastDoom support the @<response> option?

Yeah I've been trying to avoid use configuration files for benchmarks (in order to not have lot's of configuration files on the main folder), but I think I'll change this idea due to this limitation. I think the best will be to add a "benchmark" option in the Doom executable, that executes benchmarks internally without having to reload the game each time.

I'll look also the @<response> command line parameter, don't remember if I removed it or not 😅

Playing PSX Doom lately, which has me wondering if it's feasible to do a 256 width VGA mode. ModeX should be able to do it (i.e. Nesticle and Zsnes). The real concern is what to do about 320-width graphics (maybe a load function that'll skip some columns evenly)

Probably most (S)VGA cards won't display 256-width modes in full screen. For example Dyna Blaster uses 256x200 mode and I've seen it running on few retro PCs and it was always with black bars on sides.

This is interesting though. While vertical resolution is important for CRT hardware and regular VGA monitors can only do 400 or 480 lines, horizontal resolution is irrelevant for CRT circuitry since it's only analog signal and in theory you can display any pixel count in single horizontal line (from 1 to 8K or higher) on VGA monitor at 480 lines.
Of course you're physically limited by the CRT dots themselves. While you can push any signal you want, you won't see additional details at some point.
Anyway while VGA cards could do 256 width modes full screen, for some reason they display them as a part of 320 mode.

I would say that we shouldn't go lower than 320x200, but it would be nice to have 320x400 and VESA modes. I would also love to see hi-color modes like Atari Jaguar had, but this isn't exactly what FastDOOM was meant to be.

You're also limited by the bandwidth of the drive transistors on the neckboard

It's doable, but it will require a lot of work to make the assets look good on that resolution. The only benefit is that video addressing is faster, but for now I prefer to use my time in other tasks. The next release will have some new cool optimizations included.

maxtherabbit wrote on 2023-06-18, 22:27:

You're also limited by the bandwidth of the drive transistors on the neckboard

I hate you for making me do math before coffee 🤣

Yeah, typical small signal general purpose transistors top out between 120ish and 180ish Mhz, so while you might be good for 1024x768 at 85hz, you prolly gotta drop refresh drastically to just make it at 2k, or upgrade transistors.

Of the resolutions, 320x400 is the most plausible one to support. Duke Nukem 3D did a good job in largely maintaining aspect ratio with that resolution on 4:3 CRT monitors.

maxtherabbit wrote on 2023-06-18, 22:27:

You're also limited by the bandwidth of the drive transistors on the neckboard

it can't be that simple though can it? Could one theoretically pump more horizontal lines out just by swapping the drive transistors with modern equivalents at a higher bandwidth? I would tend to assume that other components would need to be altered

It's not necessarily old vs new, it's the Transition Frequency spec... and beware of "equivalents" cheap 20 for a buck "2n2222" might work the same in a bleepy bloopy or light flasher soldering project, but ain't gonna come near the 300Mhz spec of a real 2N2222A. So get motorola, toshiba, GEC or major manufacturer parts that you can get the real datasheet for, when you are relying on a given spec being critical. (Same goes for current handling, if you've got a 650mA spec part handling 600mA don't go for "equivalents" unless you can check by datasheet of the place that actually made the part you're going to use that they really will handle the 600mA and not just 500mA etc etc. ... Blew up 3 "equivalents" for a voltage reg transistor once before I figured out the original part handled 5A and the "fully compatible" parts I was getting only handled 3A 🤣 )

7F20 wrote on 2023-06-20, 13:55:

maxtherabbit wrote on 2023-06-18, 22:27:

You're also limited by the bandwidth of the drive transistors on the neckboard

it can't be that simple though can it? Could one theoretically pump more horizontal lines out just by swapping the drive transistors with modern equivalents at a higher bandwidth? I would tend to assume that other components would need to be altered

I mean the mask pitch is of course still relevant, as well as the spot size. There was a whole big thread on shumps about this a while back I'm surprised you missed it

https://shmups.system11.org/viewtopic.php?f=6&t=67124

maxtherabbit wrote on 2023-06-20, 19:34:

I mean the mask pitch is of course still relevant, as well as the spot size. There was a whole big thread on shumps about this a while back I'm surprised you missed it

https://shmups.system11.org/viewtopic.php?f=6&t=67124

oh no, I didn't miss that thread, but I thought that was about wrapping extra wire around the flyback or something like that. I know in that case it's definitely dependent on the pitch/ spot size as you will get a moire pattern on your screen if you push the focus voltage too high. But I didn't stick around long, OP has a serious attitude problem and the thread title is a troll

Hi! Some news, I've implemented fully in-game benchmark support (able to execute multiple benchmarks without exiting and store result in a CSV file, also execute a single benchmark and show result live). This feature will be available on the next release (0.9.7). Is there any specific benchmark or feature that FastDoom should include? I want to hear your ideas

It would be nice to use such benchmark to automatically find best settings for current hardware. This could be done with custom recorded demo that lasts just 5 seconds, but it shows most demanding scenario. Maybe a small custom map with heavy geometry and a lot of enemies from the start.
Such automatic tool would start with lowest settings and if max FPS was reached it should start another test with larger window etc.

This could be used as a benchmark as well. Giving a score value for each settings. For example smallest window at 35 FPS should give 1 point. One step larger at 35 FPS, 2 points. If second window size would result in 25 FPS only, it could give 1.714 points (1 + 1 * 25/35).

Re: Cirrus Logic GD5429 VLB significantly slower than a TSENG ET4000

rasz_pl wrote on 2023-04-09, 23:57:

can you do individual frame times? 😀 The article that started serious discussion about benchmarking games was 2011 'Inside the second: A new look at game benchmarking' https://web.archive.org/web/20121031015421/ht … me-benchmarking This and the follow up in 2013 https://www.guru3d.com/articles-pages/fcat-be … g-review,1.html lead to invention of G-sync/Adaptive-Sync/FreeSync.
Frametime instrumentation will be able to tell you where the biggest bottlenecks are in Doom codebase on different hardware configurations. You could then go further by toggle skipping code blocks to look in more detail. Nop wall drawing, nop ceiling/floor drawing, nop screen output altogether, replay geometry instead of calculating it live etc. Poor mans profiling.

- 1% and 0.1% fps/frame times
- frame time graph

rasz_pl wrote on 2023-07-03, 12:29:

Re: Cirrus Logic GD5429 VLB significantly slower than a TSENG ET4000 […]
Show full quote

Re: Cirrus Logic GD5429 VLB significantly slower than a TSENG ET4000

rasz_pl wrote on 2023-04-09, 23:57:

can you do individual frame times? 😀 The article that started serious discussion about benchmarking games was 2011 'Inside the second: A new look at game benchmarking' https://web.archive.org/web/20121031015421/ht … me-benchmarking This and the follow up in 2013 https://www.guru3d.com/articles-pages/fcat-be … g-review,1.html lead to invention of G-sync/Adaptive-Sync/FreeSync.
Frametime instrumentation will be able to tell you where the biggest bottlenecks are in Doom codebase on different hardware configurations. You could then go further by toggle skipping code blocks to look in more detail. Nop wall drawing, nop ceiling/floor drawing, nop screen output altogether, replay geometry instead of calculating it live etc. Poor mans profiling.

- 1% and 0.1% fps/frame times
- frame time graph

I really like the idea of calculating frametimes in benchmarks but i'm having some issues getting enough timing precision on each frame. Clock() and ftime() don't go below 50ms, so those functions are pretty much useless for this. Also I'm trying to understand the PIT usage in https://github.com/Pixinn/FastDoom-Bench to get fine results, but don't know if this will have issues with the sound code (PC Speaker).

Quick question regarding a feature.

"New option to show only objects that are not far away from the player. All the enemies are still rendered as they're important"

Does that mean that Doom normally renders objects and/or enemies for a whole level? Or is there some limit to the distance each level is rendered?