MSxyz wrote on 2024-12-01, 10:25:

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.

Understood. I was never heard of these demos/tests/benches or whatever they are. Ray tracing became a "big thing" recently with modern videocards that have nothing in common with their grand-grandparents from the DOS times. Because of pure curiosity I just tried POVRay in DOS and it "renders" some numbers, maybe I missed the real-time scene 😁

It seems POVray DOS is just a command line utility with a text based log. It creates a .tga file with the output rendering.

C-Ray was created in 2005, when DOS was already dead. At any rate it's code is compact and straightforward enough that can be ported to anything. The original author even created a port for a Game Boy Advance! (seems it takes around 11000 second to render the scene, although I don't know details like resolution, rays per bench, etc...)

MSxyz wrote on 2024-12-01, 11:15:

It creates a .tga file with the output rendering.

Aha, now I see the newly created "laser.tga" graphic file. At least GIMP opens it without errors. Well, this POV-Ray thing is not my type of DOS bench software. I'll try C-Ray.

P.S. Nah, I don't know how to cross-compile DOS executable with DOS-extednder under Linux. Can you share your compiled cray32.exe here?

analog_programmer wrote on 2024-12-01, 11:44:

MSxyz wrote on 2024-12-01, 11:15:

It creates a .tga file with the output rendering.

Aha, now I see the newly created "laser.tga" graphic file. At least GIMP opens it without errors. Well, this POV-Ray thing is not my type of DOS bench software. I'll try C-Ray.

P.S. Nah, I don't know how to cross-compile DOS executable with DOS-extednder under Linux. Can you share your compiled cray32.exe here?

I attach here "my" version of the benchmark along with the source code and everything...

Simply unpack and run CRBENCH.BAT It needs a graphic card with VBE 2.0 extensions; Scitech's SDD53a is probably better than the later 7.0 version because it supports many more older chips. You need a card that supports 32bpp modes. Support for 24 bpp is spotty at best. I still need to investigate if I can tweak the code to support more graphic modes (having 15/16 bpp would be nice for older ISA cards... not many of them support 32bpp, but 24 bpp was somewhat more common).
The benchmark can run with and without an FPU. The compiler generate 387 code but an emulator should be present. I've enabled certain specific optimizations in the compiler that boosts performance quite a bit (like loop unrolling, making the code 'branch prediction' friendly) but should remain compatible with all 386 class processors and I avoided any architecture specific optimization (i.e. fpu code tailored for the Pentium / P6).

Running the benchmark without any option will default to 640x480 with 1 ray/pixel. I included two more BAT files: CRBENCH1 will configure the .exe to use 320x240 resolution with 4 rays per pixel. Its running time should be the same (+/-1 sec max) as using 640x480 with 1 ray per pixel. This benchmark scales nicely and linearly with the number of rays calculated. CRBENCH2 will configure the .exe to use 320x240 with 16 rays per pixel. A bit overkill, but looks very nice.

On my test system, a Cyrix 5x86-120 ,CRBENCH will complete in 137 seconds without Cyrix specific optimizations, and in only 100 seconds with certain optimizations enabled (BTB_EN=On, FP_FAST=On, LSSER=Off ).

Thank you, MSxyz! I'm struggling to manually get OpenWatcom 2 to work under my Debian based distro, 'cause I don't like to use snaps and there's no repo or .deb package 🙁 Maybe it will be much easier if I just switch and try to compile under win7, but for years I've become "allergic" to more recent products of m$, so I'll keep trying the hardest way 😁

You're welcome. Let me know if it works for you, and -if you can- test it on some old hardware. I'm not really good with C++, plus I haven't touched it in more than 20 years. I wish I could really add a nicer interface or tweak it so it can use more video modes, but it's something beyond my current abilities.

MSxyz wrote on 2024-12-01, 11:15:

C-Ray was created in 2005, when DOS was already dead. At any rate it's code is compact and straightforward enough that can be ported to anything. The original author even created a port for a Game Boy Advance! (seems it takes around 11000 second to render the scene, although I don't know details like resolution, rays per bench, etc...)

The text-mode tracer I wrote over there was a quick adaptation of a GBA tracer I wrote a while back. If performance doesn't matter then the only difference to PC I remember is how video memory is accessed. But like I said earlier, for basic ray tracing, you don't need much code, even current-gen AI should be able to tailor something to spec.

MSxyz wrote on 2024-12-01, 17:10:

You're welcome. Let me know if it works for you, and -if you can- test it on some old hardware. I'm not really good with C++, plus I haven't touched it in more than 20 years. I wish I could really add a nicer interface or tweak it so it can use more video modes, but it's something beyond my current abilities.

Yes, your cray32.exe works fine in DOSbox and there's no problems after your seconds counter modification 👍🏻 I like this kind of visual tests and I'll try it on a real old hardware as soon as possible (right now I have one s.7 AMD K6 system on the workbench, but I can assemble some 486DX2 system just to test with even older CPU+FPU). For my convenience I replaced the DOS/4GW stub with DOS/32A in your cray32.exe and it still works just fine.

I have some idea for "rays per second" counter, but still can't set working OpenWatcom cross-compile environment under freakin' Linux 😁

A bit of warning, I wasn't able to compile it using Open Watcom. It gave me many errors and missing dependencies. For some reason, using WCC 11 instead, everything went smooth without any change at all. One would think that Open Watcom would be 100% backward compatible and using the same libraries...

Also, I've been using a real DOS machine as developing environment for the sake of authenticity 😉

Yeah, I read your comment about OpenWatcom compiler problems, but I'll give it a try if I manage to make it work as expected under Linux. My other options are to set Watcom C/C++ compiler in DOSBox or try OpenWatcom in win7, and I don't prefer both.

P.S. Finally sеt OW working environment. Cross-compiling tested with some short C code and DOS/4GW stub and DOS/32A - OWCC compiler works fine. Tomorrow I'll try with the C-Ray source code...

A bit surprised that you are not considering POVRay before other options. : )
The linked above ancient version is already a mature codebase that builds easily on different platforms and offers plenty of ways to be extended and conformed to different needs.
But i believe that all of what was discussed in this thread can be achieved without any code changes.
For example - there was a desire for interactive display during rendering - just add the "+D0T" argument to the command line.

MSxyz, you're 100% right. Cray32's code is not compatible with OpenWatcom and the compiler gives me a bunch of errors:

1:~$ wcc386 -c -o gfx.obj gfx.c
2Open Watcom C x86 32-bit Optimizing Compiler
3Version 2.0 beta Nov 28 2024 02:28:42 (32-bit)
4Copyright (c) 2002-2024 The Open Watcom Contributors. All Rights Reserved.
5Portions Copyright (c) 1984-2002 Sybase, Inc. All Rights Reserved.
6Source code is available under the Sybase Open Watcom Public License.
7See https://github.com/open-watcom/open-watcom-v2#readme for details.
8Error! E1139: Command line contains more than one file to compile
9Error! E1139: Command line contains more than one file to compile
10gfx.c(81): Error! E1011: Symbol 'CHAR_BIT' has not been declared
11gfx.c(82): Warning! W131: No prototype found for function 'dpmi_mmap'
12gfx.c: 153 lines, included 1868, 1 warnings, 3 errors

analog_programmer wrote on 2024-12-02, 08:43:

MSxyz, you're 100% right. Cray32's code is not compatible with OpenWatcom and the compiler gives me a bunch of errors.

Quite funny, right? If you need to review/rewrite all your old code, might as well go to another, supported compiler! 😁

MSxyz wrote on 2024-12-02, 15:44:

Quite funny, right? If you need to review/rewrite all your old code, might as well go to another, supported compiler! 😁

Actually it's quite sad story, 'cause OpenWatcom 2 claims Watcom C/C++ compiler inheritance/compatibility. I don't know if some older OW version will do the job or the only way will be to use Watcom C/C++ ver. 11.0 for DOS/windows.

Does build on my Open Watcom 1.9 on Linux. Use wcl386, give it -dCHAR_BIT=8, maybe -bt=dos -l=dos4g, set the environment variables as needed, and either change the couple of unsigned int vs int declarations or maybe there's some laxer compiler option.

vvbee wrote on 2024-12-02, 19:59:

Does build on my Open Watcom 1.9 on Linux. Use wcl386, give it -dCHAR_BIT=8, maybe -bt=dos -l=dos4g, set the environment variables as needed, and either change the couple of unsigned int vs int declarations or maybe there's some laxer compiler option.

Thanks! I didn't knew that "wcl386" is more compatible for older source code than "wcc386" compiler. Also I didn't knew that I need to set character type length by env. variable. I changed two data types from "int" to "unsigned int" in "vbe.c", 'cause they were defined as "unsigned int" in "vbe.h". Using "wcl386 -c -dCHAR_BIT=8 -o <object>.o <source>.c" now I have three object files ("dpmi.o", "gfx.o" and "vbe.o"), but "cray32.c" still gives me one error and refuses to compile:

1cray32.c(344): Error! E1071: Type of parameter 3 does not agree with previous definition
2cray32.c(344): Note! N2003: source conversion type is 'int'
3cray32.c(344): Note! N2004: target conversion type is 'struct spoint *'
4cray32.c(344): Note! N2002: 'ray_object' defined in: cray32.c(477)

I have no idea how to unify the type of this pointer in "cray32.c".
Ok, changed the line 344 in "cray32.c" from "if(ray_object(iter, shadow_ray, 0)) {" to "if(ray_object(iter, shadow_ray, &sp)) {" and now I have "cray32.o" object file.

I don't know how to manually link all four object files into one 32 bit linear DOS executable file with embedded DOS extender stub...

You shouldn't need to change anything in-code but function signatures. I recommend going to claude.ai and pasting the problem there. I believe they offer the 3.5 Sonnet (new) model for free on there, it should be able to answer these questions without trouble and tailored to your specifics.

Paste? We're living in the 21st century, isn't it time someone put a Pi5 in a Rubber Duckie with speech recog and synth hooked up as a client to AI in the cloud and could just tell you the answers instead of letting you humiliate yourself by explaining it wrong to it? Or 3D print a rat to sit on your head and scrape it off the screen with a camera and OCR so it can rip your hair out when you go wrong.

vvbee, thanks for your suggestion. I'm not a fan of all those "ai" things at all, plus this code improving site needs registration, so I'll pass. Ok, I can change function definition in header files instead, this is not a problem at all.

The problem is simple, but I have zero experience with Watcom C/C++ & OpenWatcom compilers. I tried to edit "makefile" from the project in order to work for OW, but there's something specific that I'm missing. At least I managed to manually produce all the object files needed from the code.

Still I can't understand how to use "wlink" linker with parameters needed to produce 32 bit linear DOS .exe with DOS/4GW stub embedded, but I'm stupidly stubborn and keep trying 😁 Seems like it needs some .lnk file with "directives".

I'm an experienced developer and an experienced AI user and I can assure you you want to be a fan of Claude. But it's up to you, I rarely use AI for coding either but then again I enjoy coding. Not so much fighting the compiler.