Render some 3D Studio 4 scenes? I don't know how it casts shadows and draws reflections in the scene, but maybe it's raytracing them?

I never used 3D studio extensively; I would prefer something self contained as a benchmark.

Speaking of which, I discovered that a rather popular benchmark, C-Bench, was also made for 16 and 32 bit DOS, although the author page lists only the source files: https://github.com/jtsiomb/c-ray

I've tried to look around for a compiled version but, so far, I didn't have any luck tracking it down.

Hi, not sure. Here are some graphics demos for early 3D accelerators.
3D Accelerated Demoscene Demos for DOS/Windows List (Proprietary APIs - including 3DFX)

I remember also a 3D demo with flying objects, Countdown by Realtech. Has S3 option.
Re: S3 video card
https://www.pouet.net/prod.php?which=1524

Not sure if they have a benchmarks/fps feature.
I'm just a layman here.

I'm trying to compile the C-Ray 1.1 benchmark for DOS using the source posted here: https://github.com/jtsiomb/c-ray

However, even when using the provided Makefile, I'm encountering some errors... It's been too long since I've coded anything and C/C++ has never been my forte anyway, so I'm pretty swamped.

Does anybody wants to give it a try? C-Ray benchmark is still used up to this day, so it would be nice to have a working DOS benchmark that allows us to put things into perspective.

C-Ray is going to be an FPU benchmark. The 32-bit version is supposed to be compiled with Watcom, so I'm guessing OpenWatcom can be used to cross compile. The entire code is just 4 source files. You don't need a make file if it's not working for you.
Just invoke the compiler on each file to get an obj, then invoke the linker on all objs to get the exe.. That's what the makefile is doing anyways... You can see the compiler flags used in the makefile also (-fp5 -ot).

wbahnassi wrote on 2024-11-26, 16:32:

C-Ray is going to be an FPU benchmark. The 32-bit version is supposed to be compiled with Watcom, so I'm guessing OpenWatcom can be used to cross compile. The entire code is just 4 source files. You don't need a make file if it's not working for you.
Just invoke the compiler on each file to get an obj, then invoke the linker on all objs to get the exe.. That's what the makefile is doing anyways... You can see the compiler flags used in the makefile also (-fp5 -ot).

That's what I did. I downloaded Open Watcom 8.9, installed it on a machine running DOS and invoked vmake. The process stops after creating two of the OBJ intermediate files. It seems several dependencies are missing, plus there are a couple of types mismatch. I've also tried to compile the four .c files one by one. So far only one compiles correctly into an OBJ file.

I checked that Open Watcom was installed correctly, the PATHS environment variables were correctly set up in the Autoexec and other stuff like that to make sure wcc386 was finding all the required .h files. That doesn't explain the other errors.

As I said, my knowledge of C is rather rudimentary and 20+ years old, so I cannot really explain what is going on besides checking for the obvious missing dependencies in the "include" statements and stuff like that. That's why I asked for help, because it could be something I've not foreseen with my limited knowledge of this specific environment.

A quick update... it turns out the source code is not compatible with Open Watcom C++

Since it was made in 2005, back then the most recent Watcom C++ environment was release 11 of 1997. So I've tried compiling it with the older compiler and... it worked! 😁

Now it draws a raytraced scene... Nice! Too bad the benchmark is not a benchmark at all, it just draws some reflecting spheres and then it waits for ESC to go back to DOS. There's no stop clock at all, so it's pretty useless as a benchmark, unless I add some timer. Seems I'll have to dig out of my memory whatever coding knowledge there is left 😁

I have some vague recollection of encountering a benchmark oriented rendering test in the mid 90s, think it drew a helicopter. It was kinda quirky about what it ran on though, which was why I think it didn't catch on. If a benchmark only runs on a few system configurations, then those system configurations are known, then yeah, don't need to do any more benchmarking because it either does the same as those with the same few supported parts, or it doesn't work.

Also there were early DOS versions of POVray, where if you didn't want to use your only computer for a number of hours you could run the test scene.

It should be fine to use the standard C time() function to measure this benchmark, provided the render takes time on the order of seconds or more. time() should have a resolution of the system's clock (32Khz was it?).. which is fine enough for comparing lengthy renders.

MSxyz wrote on 2024-11-24, 10:08:

I found here on Vogons mentions of a benchmark named Path_Bench, but if it's the one I already have (PATHB.EXE) it just draws some monochrome spheres at sub vga resolution. Something more... pleasant to the eyes wouldn't hurt. 😀

I wrote it and I think it looks good to the eyes. Anyway it shouldn't be too hard to write one that you like. There's plenty of ray tracing code around, AI can probably write you one without too much trouble. Another guy's contemporary DOS tracer, with dithering, here: https://bisqwit.iki.fi/jutut/kuvat/programmin … es/raytrace.cpp, and you might also google for any smallpt ports to DOS.

wbahnassi wrote on 2024-11-29, 01:55:

It should be fine to use the standard C time() function to measure this benchmark, provided the render takes time on the order of seconds or more. time() should have a resolution of the system's clock (32Khz was it?).. which is fine enough for comparing lengthy renders.

Thanks. I came to the same conclusion and sampled the timer before and after the render routine call.

1start_time = clock();
2render(xres, yres, pixels, rays_per_pixel);
3end_time = clock();

vvbee wrote on 2024-11-29, 03:03:

I wrote it and I think it looks good to the eyes. Anyway it shouldn't be too hard to write one that you like. There's plenty of ray tracing code around, AI can probably write you one without too much trouble. Another guy's contemporary DOS tracer, with dithering, here: https://bisqwit.iki.fi/jutut/kuvat/programmin … es/raytrace.cpp, and you might also google for any smallpt ports to DOS.

Sorry, I didn't want to sound mean or disrespectful. 😀 It's just that prefer my benchmarks also to show some rather complex output for aesthetic reasons and because I take a lot of screenshots.

I've studied the code and tweaked it a bit despite my limited knowledge of C++, making some minor QoL adjustments. The core of the code is untouched. I'm thinking about making two versions, one with the default compiler optimizations and one with an in-line FPU emulator to test 486SX processors and similar units (386DX, 486SLC, UMC U5, Nx586...). Since this benchmark is distributed under GPL v3 license, I should be allowed to redistribute the source with my modifications along with the executables. It may be useful for 486 or 586 cross comparisons like this: The Ultimate 486 Benchmark Comparison and this: The Ultimate 686 Benchmark Comparison

MSxyz wrote on 2024-11-29, 08:52:

It's just that prefer my benchmarks also to show some rather complex output for aesthetic reasons and because I take a lot of screenshots.

It's not clear whether you want something that looks old or new. The title says OLD, you say you remember the old ray tracing benchmarks with simple spheres and low resolutions, but then you say that's too simple and mention Cinebench, and now you seem to have settled on spheres again. If you just want reflective spheres then that's easy enough to do.

For better looks, path tracing is the way to go, ray tracing often ends up looking sterile and old-fashioned. But path tracing is more compute heavy so you need simple scenes and low resolutions for DOS-era machines, and ideally better optimized code. But you could do something like pre-computed photon mapping and/or coarse volumetric path tracing to exchange scene complexity for complexity of light.

Pure DOS ray/path tracer, for those generally interested. Stresses FPU. Tested in DOSBox, 80 x 25 mode only. Optional CLI argument sets sample count, default 40.

vvbee wrote on 2024-11-30, 05:20:

Pure DOS ray/path tracer, for those generally interested. Stresses FPU. Tested in DOSBox, 80 x 25 mode only. Optional CLI argument sets sample count, default 40.

Thanks. If you had to draw the same scene as c-ray (see pic above) using path tracing, at the same resolution, how much more computing intensive would be?

If oldschool ray casting 3D (2.5D) game engines qualify for "pure DOS software ray tracing benchmarks", you may try WOLF_286.EXE (Wolf3D for 80286 CPUs) with FPS counter. Mind that it needs data files from paid full game.

try this: https://www.povray.org/ftp/pub/povray/Old-Ver … s/Official-3.1g
look inside the ms-dos directory.
check the "command line" section of the pdf documentation.
it is as simple as:

1povray.exe +Ilaser.pov +Linclude +Lscenes\lights

where

1laser.pov

can be any of the included example scenes or something you made.

analog_programmer wrote on 2024-11-30, 22:18:

If oldschool ray casting 3D (2.5D) game engines qualify for "pure DOS software ray tracing benchmarks", you may try WOLF_286.EXE (Wolf3D for 80286 CPUs) with FPS counter. Mind that it needs data files from paid full game.

I already use wolf286 and doom for benchmarking old systems but I think those don't really count as 'raytracing' engines. Yes, they share some similarities in the way they draw a scene, but that's all.

pshipkov wrote on 2024-12-01, 02:31:

try this: https://www.povray.org/ftp/pub/povray/Old-Ver … s/Official-3.1g look inside the ms-dos directory. check the "command l […]
Show full quote

try this: https://www.povray.org/ftp/pub/povray/Old-Ver … s/Official-3.1g
look inside the ms-dos directory.
check the "command line" section of the pdf documentation.
it is as simple as:

Copy code to clipboard

1povray.exe +Ilaser.pov +Linclude +Lscenes\lights

where

Copy code to clipboard

1laser.pov

can be any of the included example scenes or something you made.

Thanks. This may be what I'm currently looking for.

MSxyz wrote on 2024-12-01, 09:06:

I already use wolf286 and doom for benchmarking old systems but I think those don't really count as 'raytracing' engines. Yes, they share some similarities in the way they draw a scene, but that's all.

Doom uses BSP 3D (2.5D) engine and I'm not sure if there's anything in common with ray tracing rendering. I don't know what you exactly mean under "DOS ray tracing bench", but for me the closest thing from DOS times (pre-win95 years) seems to be the ray casting 3D renderer. Those old 3D games using ray casting engines don't have any benching options, that's why I suggested modified WOLF_286 with demo mode FSP counter.

For dos raytracing bench, I exactly mean a program that renders an image using raytracing techniques. C-Ray does that (and now I've been able to compile and modify it to display a stopwatch), Povray does that too (and much more!), although it's not as "interactive" as C-Ray, where you can see the scene being drawn in real time.