Ok, finally I managed to produce .lnk script file for "wlink" with right directives, linked all the object files into single DOS 32 bit DOS/4GW .exe, tried it in DOSbox and... it starts "DOS4GW.EXE" and then hangs. I'm giving up on this OW compiler and all this cross-compiling bullsh*t under Linux. Maybe another day I'll try old Watcom C/C++ for DOS/windows... or maybe not.

Sorry to hear that. At least you can use my working copy of the benchmark for testing old machines. 😀

I'm going to include it in all my future comparisons and if somebody else also wants to adopt it as a benchmark for their retro adventures... I'm happy to have given my little contribution.

I'm sure he'll give it another go after sleeping on it. Not much software would get done if people just gave up when it doesn't work.

Shameless plug: Super Trace VESA Benchmark

thp wrote on 2024-12-04, 19:49:

Shameless plug: Super Trace VESA Benchmark

😁
Interesting... I'll give it a try, although it's no raytracer. 😉 Thanks

I still can't find a way to make it work with 24bpp modes. That would open up the benchmark to older systems with cards that don't support 32bpp (ie. many ISA/VLB cards) I've never worked with vbe before so I'm really going blind in here. Any help would be appreciated 😀

MSxyz wrote on 2024-12-12, 17:36:

I still can't find a way to make it work with 24bpp modes. That would open up the benchmark to older systems with cards that don't support 32bpp (ie. many ISA/VLB cards) I've never worked with vbe before so I'm really going blind in here. Any help would be appreciated 😀

It should support 32bpp, 24bpp (RGB888 for both) and 16-bpp (RGB565) modes. It currently doesn't support 15bpp (RGB565) mode.

Can you run vesainfo from this thread on your card and post the output?

In some cases, for old cards, running UNIVBE might help expose more VESA modes. Oh, and the tracer only supports VESA 2.0, maybe that's the issue? (you having VESA 1.2 or something) In any case, a fallback to VGA should be offered with the latest version.

MSxyz wrote on 2024-12-12, 17:36:

I still can't find a way to make it work with 24bpp modes. That would open up the benchmark to older systems with cards that don't support 32bpp (ie. many ISA/VLB cards) I've never worked with vbe before so I'm really going blind in here. Any help would be appreciated 😀

Actually the current version is working somewhat in 24bpp modes but the colors are inverted (ie. red and blue color components are switched).
Here is a modified version that fixes this problem and allows to set 24bpp or 32bpp modes explicitly by adding '-b <bpp>' command line option.
The logic to automatically substitute 24bpp with 32bpp and vice versa is temporarily disabled for testing but can be re-enabled in the end (in GFX.C -> SAME_BPP macro).
Wrong video memory size display is also fixed.

@Edit:
Additional modifications:
After rendering the image the program waits for a keypress before switching back to text mode. It's not fair that you cannot see the beautifully rendered final image at all 😀.
The rendering time is still calculated properly regardless how long the program waits at the end. Moreover the rendering time is shown with millisecond precision.

Falcosoft wrote on 2024-12-13, 15:32:

Actually the current version is working somewhat in 24bpp modes but the colors are inverted (ie. red and blue color components a […]
Show full quote

MSxyz wrote on 2024-12-12, 17:36:

I still can't find a way to make it work with 24bpp modes. That would open up the benchmark to older systems with cards that don't support 32bpp (ie. many ISA/VLB cards) I've never worked with vbe before so I'm really going blind in here. Any help would be appreciated 😀

Actually the current version is working somewhat in 24bpp modes but the colors are inverted (ie. red and blue color components are switched).
Here is a modified version that fixes this problem and allows to set 24bpp or 32bpp modes explicitly by adding '-b <bpp>' command line option.
The logic to automatically substitute 24bpp with 32bpp and vice versa is temporarily disabled for testing but can be re-enabled in the end (in GFX.C -> SAME_BPP macro).
Wrong video memory size display is also fixed.

The attachment CRAY32_mod.zip is no longer available

@Edit:
Additional modifications:
After rendering the image the program waits for a keypress before switching back to text mode. It's not fair that you cannot see the beautifully rendered final image at all 😀.
The rendering time is still calculated properly regardless how long the program waits at the end. Moreover the rendering time is shown with millisecond precision.

Thanks! Trying it now...

Falcosoft wrote on 2024-12-13, 15:32:

Actually the current version is working somewhat in 24bpp modes but the colors are inverted (ie. red and blue color components a […]
Show full quote

Actually the current version is working somewhat in 24bpp modes but the colors are inverted (ie. red and blue color components are switched).
Here is a modified version that fixes this problem and allows to set 24bpp or 32bpp modes explicitly by adding '-b <bpp>' command line option.
The logic to automatically substitute 24bpp with 32bpp and vice versa is temporarily disabled for testing but can be re-enabled in the end (in GFX.C -> SAME_BPP macro).
Wrong video memory size display is also fixed.

@Edit:
Additional modifications:
After rendering the image the program waits for a keypress before switching back to text mode. It's not fair that you cannot see the beautifully rendered final image at all 😀.
The rendering time is still calculated properly regardless how long the program waits at the end. Moreover the rendering time is shown with millisecond precision.

Hi, Zoltan,
I tried the benchmark from your attachment, but seems like you messed something and uploaded wrong version or not your last modified version. The 32-bit rendering works, but the uploaded code lack these "additional modifications". I know you're mainly focused on your own software projects like Soundfont Midi Player, so such a mistakes may happened.

I like the C-Ray benchmark and the idea for these modifications and tried to recreate them in a slightly different way. Also I changed the option to save the rendered scene in "image.ppm" image file through new command line switch instead of a keypress. I used int16 for keypress capturing through bios.h instead of conio.h functions. Fixed the command line switches, so the program now accepts the traditional DOS "/" syntax plus the original *nix "-" syntax (also for convenience no matter if upper or lowercase switches). And not in last place I added the missing GPL 3.0 license file in the zip-archive as we have to respect and keep the original creator's license. There are detailed comments in the modified code about my changes.

I don't know why, but during my testing in DOSBox the 24-bit mode rendering is not supported. Maybe you can give me the answer or fix it the code.

Here is my version of C-Ray32 1.1 with the new modifications (the Watcom C/C++ 11C compiled executable and files needed for benchmark are in "bin" folder):
EDIT: The newer version of C-Ray32 1.1_mod3 based on latest Zoltan's 24-bit videomodes fixes is here.

aVd wrote on 2026-02-23, 12:00:

Hi, Zoltan, I tried the benchmark from your attachment, but seems like you messed something and uploaded wrong version or not yo […]
Show full quote

Falcosoft wrote on 2024-12-13, 15:32:

Actually the current version is working somewhat in 24bpp modes but the colors are inverted (ie. red and blue color components a […]
Show full quote

Actually the current version is working somewhat in 24bpp modes but the colors are inverted (ie. red and blue color components are switched).
Here is a modified version that fixes this problem and allows to set 24bpp or 32bpp modes explicitly by adding '-b <bpp>' command line option.
The logic to automatically substitute 24bpp with 32bpp and vice versa is temporarily disabled for testing but can be re-enabled in the end (in GFX.C -> SAME_BPP macro).
Wrong video memory size display is also fixed.

@Edit:
Additional modifications:
After rendering the image the program waits for a keypress before switching back to text mode. It's not fair that you cannot see the beautifully rendered final image at all 😀.
The rendering time is still calculated properly regardless how long the program waits at the end. Moreover the rendering time is shown with millisecond precision.

Hi, Zoltan,
I tried the benchmark from your attachment, but seems like you messed something and uploaded wrong version or not your last modified version. The 32-bit rendering works, but the uploaded code lack these "additional modifications". I know you're mainly focused on your own software projects like Soundfont Midi Player, so such a mistakes may happened.

I like the C-Ray benchmark and the idea for these modifications and tried to recreate them in a slightly different way. Also I changed the option to save the rendered scene in "image.ppm" image file through new command line switch instead of a keypress. I used int16 for keypress capturing through bios.h instead of conio.h functions. Fixed the command line switches, so the program now accepts the traditional DOS "/" syntax plus the original *nix "-" syntax (also for convenience no matter if upper or lowercase switches). And not in last place I added the missing GPL 3.0 license file in the zip-archive as we have to respect and keep the original creator's license. There are detailed comments in the modified code about my changes.

I don't know why, but during my testing in DOSBox the 24-bit mode rendering is not supported. Maybe you can give me the answer or fix it the code.

Here is my version of C-Ray32 1.1 with the new modifications (the Watcom C/C++ 11C compiled executable and files needed for benchmark are in "bin" folder):

The attachment C-Ray32 1_1_mod.zip is no longer available

Hi,
I have just checked the re-downloaded package from the above link and the 'additional modifications' are there. That is after rendering the image the program waits for a keypress before switching back to text mode, and the rendering time is shown with millisecond precision.
I have just tested in DosBox 0.74 and both 'additional modifications' work for me. You should find the relevant parts in CRAY32.C:

1        double ftime;
2       ...
3        start_time = clock();
4	render(xres, yres, pixels, rays_per_pixel);
5        end_time = clock();
6        ftime = (end_time - start_time) / (CLOCKS_PER_SEC * 1.0);
7        getch();
8	set_text_mode();
9        printf("C-Ray Benchmark v1.1 2005-2024\n");
10        printf("Task completed in %.3f seconds\n", ftime);

The getch() call ensures that the rendered image stays after the rendering and waits for a key press. Moreover as can be seen the rendering time calculations are made with double precision floating point data.

BTW, the emulated S3 Trio card of standard DosBox 0.74 does not support 24-bit VESA modes.

@Edit:
Actually I had made the 24-bit modifications on real hardware (ATI Radeon Express 1150) but I have just checked 24-bit modes on DosBox Staging. Interestingly 1024x768x24 bit is not supported by DosBox Staging but 1152x864, and 1280x1024 are supported and they work in 24-bit mode. 800x600 also works in 24-bit mode. But 640x480 does not work properly. It's hard to tell at first if it's a DosBox Staging or rendering code problem.

Falcosoft wrote on 2026-02-23, 13:37:

Hi, I have just checked and the 'additional modifications' are there. That is after rendering the image the program waits for a […]
Show full quote

Hi,
I have just checked and the 'additional modifications' are there. That is after rendering the image the program waits for a keypress before switching back to text mode, and the rendering time is shown with millisecond precision.
I have just tested in DosBox 0.74 and both additional modifications work for me. You should find the relevant parts in CRAY32.C:

Copy code to clipboard

1 start_time = clock();
2	render(xres, yres, pixels, rays_per_pixel);
3        end_time = clock();
4        ftime = (end_time - start_time) / (CLOCKS_PER_SEC * 1.0);
5        getch();
6	set_text_mode();
7        printf("C-Ray Benchmark v1.1 2005-2024\n");
8        printf("Task completed in %.3f seconds\n", ftime);

The getch() call ensures that the rendered image stays after the rendering and waits for a keypress as well as the rendering time calculations are made with double precision floating point data.

BTW, the emulated S3 Trio card of standard DosBox 0.74 does not support 24-bit VESA modes.

Sorry, I don't argue about the time precision in milliseconds, as it is there and it works. But there's something wrong with keypress capturing and now I know what is it. Your code misses the keyboard buffer cleaning fflush(stdin), so any unintentional keystroke before the "freezing" (keypress waiting) will cause the picture to not stay after the rendering is done. I forgot to mention, that I also added these keyboard buffer cleaning functions . One problem solved.

As for the default S3 emulation in DOSBox, thanks for your confirmation, that the problem is not in 24-bit code rendering. I have to test the benchmark on a real hardware.

I hope you'll find a couple of minutes to see my code - especially the parts with bios.h int16 functions. I don't know if they're the "right thing" for cpu-offloading during for cycles or some assebly code will be needed here for even lower level of int16 usage.

aVd wrote on 2026-02-23, 14:18:

...Your code misses the keyboard buffer cleaning fflush(stdin), so any unintentional keystroke before the "freezing" (keypress waiting) will cause the picture to not stay after the rendering is done. I forgot to mention, that I also added these keyboard buffer cleaning functions . One problem solved.

Actually it was intentional from me since many times when just want to benchmark I press a key during the rendering process, before the end. But of course if you always want to stop at the end then you should make sure of it.

@Edit:
The 640x480 24-bit problem is a rendering code problem. The code always assumes that the bytes per scanline value equals to (horizontal width in pixels) * (bytes per pixels). In most modes this is true but in case of DosBox Staging in 640x480x24 bit mode the bytes per scanline value is 2048 (instead of 640 * 3 = 1920).

Falcosoft wrote on 2026-02-23, 14:25:

Actually it was intentional from me since many times when just want to benchmark I press a key before the end. But of course if you always want to stop at the end then you should make sure of it.

Ok, I see and that makes sense. But I added <Esc> key option for breaking the rendering scene and one more "pause" after the "about screen" (a new addition), so had to modify the keypress handling.

As for 24-bit rendering I have to re-test everything on a real old 386 hardware with real (S)VGA videocard. Probably DOSBox and DOSBox-X are not 100% accurate in videocard emulations.

aVd wrote on 2026-02-23, 14:33:

Falcosoft wrote on 2026-02-23, 14:25:

Actually it was intentional from me since many times when just want to benchmark I press a key before the end. But of course if you always want to stop at the end then you should make sure of it.

Ok, I see and that makes sense. But I added <Esc> key option for breaking the rendering scene and one more "pause" after the "about screen" (a new addition), so had to modify the keypress handling.

As for 24-bit rendering I have to re-test everything on a real old 386 hardware with real (S)VGA videocard. Probably DOSBox and DOSBox-X are not 100% accurate in videocard emulations.

As I sdaid above:

The 640x480 24-bit problem is a rendering code problem. The code always assumes that the bytes per scanline value equals to (horizontal width in pixels) * (bytes per pixels). In most modes this is true but in case of DosBox Staging in 640x480x24 bit mode the bytes per scanline value is 2048 (instead of 640 * 3 = 1920).

So the code should be modified to always query for the bytes per scanline value from the VESA info structure for the given VESA mode (vbe_mode_info.scanline_bytes defined in VBE.H) and apply the padding when needed.

Sorry, I'm out of compatible 24-bit modes in DOSBox. Once more just tried 320x200, 320x240, 640x480, 800x600 and 1024x768 resolutions in 24-bit and there's always error message "Requested video mode (...x...) is unavailable". Most of these VGA modes (except 1024x768 32-bit) work perfectly fine in 32-bit mode. I don't want to mess with this part as I don't have deep knowledge in VESA DOS videomodes.

Anyway, the default 640x480 32-bit videomode is perfectly fine for getting the benchmark results.

aVd wrote on 2026-02-23, 14:58:

Sorry, I'm out of compatible 24-bit modes in DOSBox...

If you do not have real hardware that supports 24-bit modes you can still test such modes in DosBox Staging:
https://www.dosbox-staging.org/

Falcosoft wrote on 2026-02-23, 15:13:

If you do not have real hardware that supports 24-bit modes you can still test such modes in DosBox Staging:
https://www.dosbox-staging.org/

Ahaaa, you mean the "staging version" of DOSBox. I use latest official ancient 0.74-3 version and not the latest version of DOSBox-X. I'll have to check out this staging version DOSBox, thanks for the advice.

aVd wrote on 2026-02-23, 15:25:

Falcosoft wrote on 2026-02-23, 15:13:

If you do not have real hardware that supports 24-bit modes you can still test such modes in DosBox Staging:
https://www.dosbox-staging.org/

Ahaaa, you mean the "staging version" of DOSBox. I use latest official ancient 0.74-3 version and not the latest version of DOSBox-X. I'll have to check out this staging version DOSBox, thanks for the advice.

BTW, here is the modified version that works in both 32 and 24-bit modes regardless of the bytes per scanline value:

You can add your modifications to it as you like. The relevant changes are in GHX.H, GFX.C and CRAY32.C. All changes are related to the new function 'get_scanline_bytes()'.

Falcosoft wrote on 2026-02-23, 15:39:

BTW, here is the modofied version that works in both 32 and 24-bit modes regerdless of the bytes per scanline value:

The attachment CRAY32_mod2.zip is no longer available

You can add your modifications to it as you like. the relevant changes are in GHX.H, GFX.C and CRAY32.C. All related to the new function 'get_scanline_bytes(void)'.

Thank you for this new bugfix code.

The improved Cray16 1.1_mod version with some bugfixes and similar to Cray32 1.1_mod version is ready (it even runs on 8088 without FPU), but if no one needs it, there's no point to attach it here.