FastDoom
FastDoom copied to clipboard
viti95
Other compilers being considered ?
Hello,
This page https://github.com/leikareipa/dccb seems to indicate than Microsoft Visual C (version 5) produces the fastest code (at least for their benchmark) :
Sample results
The following table provides results for various compilers. The table is sorted from best to worst by the performance (number of >frames rendered per second) of the compiled executable running in DOSBox (cycles = 67000).
Result (FPS) Compiler Compiler version 57 Microsoft C/C++ 8 41 Digital Mars C/C++ 8 37 Open Watcom ? 33 Borland Turbo C 2 32 Borland C++ 2 32 Microsoft C 5 31 Microsoft QuickC 1 30 HI-TECH Pacific C 7 14 Mix Power C 2.2
Microsoft Visual C version 5 is available on winworldpc.
Considering that there is already a lot of ASM produced by GCC for performance-critical code, would it be worth it to try it ? And if the performance boost is proven and sufficiently different, switch to it ? Another question would be is the build process compatible/rewritable for this compiler easily enough.
Anyway, this is just some curiosity the VOGONS forums sent me to. In case this wasn't already discovered.
I'm still on my sound problem before considering looking into what's described above. But still, every FPS counts when DOOM runs inside DOSBox compiled for WASM (JS-DOS).
I think Visual C is only able to generate 16-bit executables, DOOM requires 32 bit support (DOS extender). Porting to other compilers is not that easy, but i'll try to update the builds with new versions of OpenWatcom, and see if that way is faster. I was also considering port the whole code to GCC, but as you said, there is a lot of ASM code that has to be ported (GCC doesn't support Borland TASM objs).
Anyway thanks for posting this information, any new ideas are always welcome!
If the only problem for switching to gcc is Tasm assembly then there are converters around here. such as a somewhat old perl script: http://www.devoresoftware.com/nomyso/ Tasm -> nasm I have never tried them for myself though.
Yes but not exactly GCC but DJGPP that is a GCC for MsDOS and is 32bit only. It uses CWSDPMI instead of the DOS/4GW extender.
Someone managed to build the original Doom using DJGPP: https://virtuallyfun.com/wordpress/2017/07/29/null-doom-gcc-1-39-go32-dpmi/
Someone managed to build the original Doom using DJGPP: https://virtuallyfun.com/wordpress/2017/07/29/null-doom-gcc-1-39-go32-dpmi/
This is really interesting, i will analyze that port and see how did they port it. I'm really curious how did they port the sound library.
If the only problem for switching to gcc is Tasm assembly then there are converters around here. such as a somewhat old perl script: http://www.devoresoftware.com/nomyso/ Tasm -> nasm I have never tried them for myself though.
I tested that script trying to convert the code but it was generating errors due to the self-modifying code that it's used in the R_DrawColumn functions.
I was thinking about another solution: Use GCC to generate assembly language from the .c files or at least some critical c routines. link them all with Watcom. Someone was doing this with Yasm (that supports GAS syntax) but wanted to generate 16bit code that Yasm cannot do. in Doom this should not be an issue. and it should work. https://stackoverflow.com/questions/30191000/how-do-i-assemble-gas-assembly-and-link-it-with-the-open-watcom-c-library EDIT: Also Yasm claims to have partial TASM support...
Actually when reading OpenWatcom changelog it seems they support COFF so it means that DJGPP object files could be linked with Watcom? I probably misunderstood something, it seems too nice to be true.
I build FastDoom using Open Watcom 2.0 and there is no speed differences compared to version 1.9 Is there any reason you use only one pass for tasm in your makefile? Do you use any other flags than those in the makefile? I still have a very slightly slower build after removing /d2 flag, compared to the release 0.7. I am testing under DOSBox.
For FastDoom 0.7 I'm using Open Watcom 2.0, there is no difference in performance. The /d2 flag is used to generate .obj files that can be disassembled better (IDA Pro) so I can see where the compiler makes better code or not. The extra debugging information is later discarded so it doesn't make the executable bigger.
I'll check the YASM assembler, if it can build correctly the self-modifying code it will be awesome. My idea is to use the latest version of DJGPP (GCC 10) and YASM (or other assembler) for the TASM code.
EDIT:
Tested YASM and it doesn't compile none of the assembly TASM files 😭
I think you could then compile the asm with tasm and then convert the OMF32 generated .obj files in COFF32 .o files using objconv. (I had to build objconv for my Win32 but it is easy and you should be able to build it using djgpp under DOS). I tried to do the opposite: compile with gcc then convert COFF32 to OMF32 ant link with watcom, however the name mangling is different, gcc puts underscore prefixes and wcc puts suffixes, It should not be hard to convert but I had no time yet. Converting obj files like this should work but you have to be careful that about the calling convention matches.
I've found a way to convert the OMF objects to COFF without problem. There is a converter called Object to Coff (O2C) that supports the TASM created objects and converts them. I've created a new branch (djgpp), with all the ASM files converted to the new format. The idea is to convert the project to DJGPP (GCC 10), as i've checked that it generates much much better code than the old OpenWatcom.
Well I've discovered another big problem while converting all the code to DJGPP. The sound library (Apogee Sound System) uses two libraries prebuilt external libraries (PAWE32.LIB and GF1_OSF.LIB), but those can't be converted to COFF format as they aren't built for a flat model (O2C only supports flat code). So for now it's impossible to convert all the code, we need a new sound library that supports DJGPP.
I think Boom used Allegro. https://liballeg.org/old.html For you only the sound library would be useful for you. Allegro can be compiled with both Watcom and djgpp. Latest DOS version seems to be 4.2.3.1 (2009) I also found this Git to get started: https://github.com/msikma/allegro-dos-example EDIT: the GIT contains almost nothing... Doc: for Allegro 4: http://www.glost.eclipse.co.uk/gfoot/vivace/
Maybe you could first compile FastDoom without sound support with djgpp, then add back sound support with Allegro. This way if djgpp migration ends up being a dead-end you will not have lost so much time.
MSC would require something like PharLap TNT. I have a copy of 6 in the box. I gutted it to scan the manuals. MSC + TNT could totally be a thing.
Well I've discovered another big problem while converting all the code to DJGPP. The sound library (Apogee Sound System) uses two libraries prebuilt external libraries (PAWE32.LIB and GF1_OSF.LIB), but those can't be converted to COFF format as they aren't built for a flat model (O2C only supports flat code). So for now it's impossible to convert all the code, we need a new sound library that supports DJGPP.
PAWE32.LIB is for the AWE32. it can be omitted, just as GF1_OSF is for part of the Gravis Ultra Sound. I forget what exactly.
DMA is the thing that always tripped me up, but interrupt and IO is usually straight forward to port.
I worked on another project that uses djgpp so I think I can try to port this over, but I think it's gonna be quite a slog, The first attempt might just be a proof of concept, but I think it would be really interesting to take on and will be my next FastDOOM related project
@FrenkelS ported Doom to multiple compilers, DJGPP included: https://github.com/FrenkelS/djdoom