386SX wrote on 2021-12-07, 16:26:

A question, considering the latest ISA cards already had the BitBLT engines and quite optimized for Win GUI where there's a huge improvement using those early accelerators, couldn't that engine be used somehow to offload some of the Doom gfx rendering calculations?

It's possible to use the BitBLT engines to accelerate the HUD and text messages drawing, but not for 3D acceleration. If the BitBLT supported scaling operations, it could be use to accelerate the 3D rendering. Some videocards also implemented more advance operations like line fill and patterned polygon fill. Those functions could be used to accelerate the flat visplane rendering, but this will require a custom build for each videocard, as those are non-standard and each manufacturer did implement them in different ways.

GigAHerZ wrote on 2021-12-08, 14:00:

2.666

I really love the idea of Doom being 2.666D

0x90 wrote on 2021-12-08, 17:05:

I converted (hand-conveted since I couldn't get some kind of automated tasm2nasm tool I found to work properly) linear.asm from […]
Show full quote

I converted (hand-conveted since I couldn't get some kind of automated tasm2nasm tool I found to work properly) linear.asm from TASM to NASM 2.1x.x compatible a few months ago, to cross-compile a quick hacky little Doom port for testing stuff w/o requiring any tools which don't run natively on my "work" laptop.

I could attempt to do the same for the other ASM files in this project. Interested? Or is TASM preferable for this project and the maintainers? Note that even the newest versions of NASM are still available for DOS so the ability to also build it on DOS wouldn't be lost.

For the same reason (easier cross-compiles) I think porting the SETUP program from Borland to 16-bit Watcom C would be good, but not sure if I personally want to attempt that...

edit: also, NASM can generate object files which are compatible with GNU tools (djgpp) which I don't think TASM can do, yet could be useful since gcc can optimize better than Open Watcom even for older CPUs (though certainly it can also be significantly slower and more memory hungry while compiling, if you're compiling on target hardware)

This is very interesting!! TASM is only used because planar.asm can only be compiled with the 3.1 version, also the Apogee Sound System also requires TASM to build it's ASM files. TASM is propietary software, which I don't really like to use. I've been looking to convert all the project to DJGPP (it's much much better optimizing code) but those TASM files need to be converted first.

I also want to remake the setup program from scratch, as it requires the Laughing Dog Screen Maker program to build the screens, and it's a big pain in the a** to use. But again, the main problem here is to have enough time available to do these things. If you want to port the ASM files to NASM it will very welcome.

EDIT:

I've been busy adding a custom palette for 16 color modes in VGA cards. This is a little example of the VGA 160x200 mode using an optimized palette. This will be used also for the text mode 80x50, and later i'll add a custom palette for EGA modes.

https://www.youtube.com/watch?v=viV7FdibWKE

EDIT 2:

I've been interviewed recently about FastDoom in the MS-DOS CLUB (spanish), you can listen the podcast here: https://msdos.club/ms-dos-club-vol-19-el-efec … stdoom-parte-1/ (minute 1:57:50 onwards)

ViTi95 wrote on 2021-12-09, 09:27:

If you want to port the ASM files to NASM it will very welcome.

It's done now, though I'm unable to test the 16-bit sound mixing code. It SHOULD work, I just made the exact same changes as to 8-bit. I can also go create a github account and make a pull request if you'd prefer that. WATCOM_BUILD must be defined to use Watcom compatible segments and symbol names (otherwise gcc/djgpp compatible ones are used) , I'm using "nasm -DWATCOM_BUILD -f obj -o $[*.obj $[*.asm" as the build command in my test makefile.

edit: also, I noticed only '/' as command line switch char instead of '-' in makefile, and '\' used as path delimiter linker script paths prevented a cross-build using Open Watcom for Linux after converting the asm code to NASM compatible. I gotta test later if '/' in .lnk also works on DOS... I know Windows has supported '/' as path delimiter since a long time ago at least and even allows mixing '\' and '/' (I'm pretty sure '-' for args to wcc386 on DOS does work even without testing)

0x90 wrote on 2021-12-11, 12:55:

It's done now, though I'm unable to test the 16-bit sound mixing code. It SHOULD work, I just made the exact same changes as to […]
Show full quote

ViTi95 wrote on 2021-12-09, 09:27:

If you want to port the ASM files to NASM it will very welcome.

It's done now, though I'm unable to test the 16-bit sound mixing code. It SHOULD work, I just made the exact same changes as to 8-bit. I can also go create a github account and make a pull request if you'd prefer that. WATCOM_BUILD must be defined to use Watcom compatible segments and symbol names (otherwise gcc/djgpp compatible ones are used) , I'm using "nasm -DWATCOM_BUILD -f obj -o $[*.obj $[*.asm" as the build command in my test makefile.

nasm_asm.zip

edit: also, I noticed only '/' as command line switch char instead of '-' in makefile, and '\' used as path delimiter linker script paths prevented a cross-build using Open Watcom for Linux after converting the asm code to NASM compatible. I gotta test later if '/' in .lnk also works on DOS... I know Windows has supported '/' as path delimiter since a long time ago at least and even allows mixing '\' and '/' (I'm pretty sure '-' for args to wcc386 on DOS does work even without testing)

OMG this is f*cking awesome!! I think it's better if you create a pull request, i'll test it and add it as soon as possible. Removing the Borland Turbo Assembler requirement is a huge step, it'll make this project much more open source friendly. This way will allow us to create a fully open source dev environment (at least for the game part).

I don't quite understand the significance of this, but great! 😁

ViTi95 wrote on 2021-12-13, 10:18:

OMG this is f*cking awesome!! I think it's better if you create a pull request, i'll test it and add it as soon as possible. Removing the Borland Turbo Assembler requirement is a huge step, it'll make this project much more open source friendly. This way will allow us to create a fully open source dev environment (at least for the game part).

While doing my own testing I noticed a little problem: under real MS-DOS 5.0, wmake calling nasm can cause the whole machine to hang or reboot with certain memory configs. Himem alone seems to work, but himem+emm386 noems doesn't. As a shotgun debugging measure I tried adding more and larger STACKS via config.sys but it doesn't help. I'll test under MS-DOS 6.22 later but my guess is result will be the same. I'll also guess that Win9x and WinNT will work fine (even if using DOS versions of the tools).

I guess this might be somehow related to NASM for DOS being compiled using DJGPP and using go32/CWSDPMI, while all the Open Watcom tools are using DOS4GW or DOS32A? So using NASM will break building under DOS itself for some people. Is this okay with you? I could also look into using FASM...

Setting stacks in config.sys to the max (64,512) seems to have fixed it. 8,256 and 9,512 weren't sufficient. No idea what the minimum required would be to call nasm via wmake reliably.

Btw. NASM also seems ridiculously slow in a PCEM 100MHz 486DX4 config, it's slower at assembling each of the project's asm files than wcc386 is at compiling many if not all of the C code files. 😁 How is this even possible? (it still doesn't take too long however, at least in my opinion)

Forward slashes in linker script paths do work under pure old DOS 5 (as I expected), as does using '-' for command line switches to wcc386 (it's even what the builtin help text uses), so I'd recommend these changes as well as specifying file extensions explicitly and using all lowercase filenames everywhere to allow cross builds using Open Watcom + NASM (or possibly FASM) on Linux. Mind if I put everything required to make cross-builds work into the same pull request?

edit: of course the build .bat files could just call nasm separately to always unconditionally (attempt to) rebuild the asm object files...

edit2: *sigh* even with max stacks running buildy.bat still reboots right at the end of the build process (I already have a fdoomy.exe which works, but DOS32A isn't bound yet), not sure if nasm related or not

edit3: and I think somehow whether nasm prints any warnings or not can affect this, and for whatever reason my MS-DOS 6.22 PCem setup with stacks=9,256 but both himem.sys & emm386 noems in use seems to work perfectly... (there are also other differences besides newer DOS between this and the DOS 5 setup since I use this DOS 6.22 setup regularly, for example command.com has been replaced with 4dos)

So bottom line is, seems NASM may not be a good choice after all if you want to guarantee the project can be built under pure DOS while using Watcom make.

0x90 wrote on 2021-12-14, 18:10:

...
Mind if I put everything required to make cross-builds work into the same pull request?
...

Yeah, cross-building support is great so feel free to add it in the pull request

0x90 wrote on 2021-12-14, 18:10:

...
So bottom line is, seems NASM may not be a good choice after all if you want to guarantee the project can be built under pure DOS while using Watcom make.
...

I use DosBox-X to build the project, for me it's no problem if it's a little bit slower or doesn't build under pure DOS. I prefer cross-building from Windows or Linux, as build times are much lower.

Ok, maybe it's too much to ask, but how about Doom on 286? I know there's a lot of 386 code to replace, but this will be one of the most important milestone in Doom porting ever. Countless people have upgraded their 286s in the past for one reason - Doom didn't run on them.

And we're all know that basically 286 has practically the same power than 386 at the same frequency, so with a fast VGA card it should be more than playable.

286 protected mode has issues. Why weren't they fixed? They were, intel called the new revision the 386.

Can Open Watcom even target 286 protected mode? DJGPP for sure can't.

Where to get the DOS extender? DOS/4GW & many compatibles are free to use, but they are for >=386 only. DOS/16M is the 286 pmode extender from the same company (Rational/Tenberry) as DOS/4G(W) but I don't think it was ever released for free use?

286 protected mode doesn't allow for linear memory addressing like >=386 does, it's still limited to 64kB segments like real mode. 32-bit registers also aren't available. These restrictions seem like they might be really bad for performance of a game like Doom (which is handling chunks of data larger than 64kB and variables larger than 16 bits all the time) even if the C code could be compiled for a 286 due to the workarounds the compiler would be forced to use.

"Protected mode also did not provide a significant enough performance advantage over the 8086-compatible real mode to justify supporting its capabilities; actually, except for task switches when multitasking, it actually yielded only a performance disadvantage, by slowing down many instructions through a litany of added privilege checks. In protected mode, registers were still 16-bit, and the programmer was still forced to use a memory map composed of 64 kB segments, just like in real mode." (from https://en.wikipedia.org/wiki/Intel_80286#OS_support)

(apologies ViTi95 for not submitting the pull request yet 😜 I promise this weekend at the latest)

Yes, that's why I said about a lot of code to replace, it's not just some 386 assembly tinkering here and there.
Still it should be way more easier than SNES or PlayStation/Saturn port, for example, as systems with completely different architecture and code.

Despite the non-linear memory model, it was quite common for late 286s to have 4 megabytes of SIMMs. And a possible drop in performance due to 64k chunks can be compensated by partial flat shading, etc.

So it's more than doable, it just needs a lot of work. I really hope somebody will have enough time and knowledge for this, sooner or later.

See if this hits the spot... http://www.kfhgames.com/projects.php?project= … _-_a_doom_clone

Edit: Though I'm looking into that more and have the suspicion that it's bloated out of 286 class, maybe out of 486 class too... but this one should be still 286 friendly..
http://www.areyep.com/RIPandMCS-Wolfendoom-Main.html

Yes, both are great, but these aren't Doom ports for 286.

Klooni requires Windows and a fast CPU, at least Pentium-3 I think.

Wolfendoom is not a Doom port at all, rather it falls under the "total conversion" of Wolf3D category. Honestly, even the ZX Spectrum "port" is more impressive, at least it's a game written from scratch that was inspired by Doom, and has completely custom code and graphics.

Doom is much easier to port to PlayStation and Saturn as those consoles have 32-bit registers, and have the same basic requirements as Doom (a framebuffer, lot's of RAM bandwidth and a fast CPU). The SNES version had to be written from scratch having 16-bit registers in mind, Doom for 286 would be exactly the same. And I think that the 286 version is even harder to port because of that 64kb segment limit and that bank switching. It would be very slow, as Doom requires lot's of bandwidth (the textures were very big for it's time). For example Doom on 386SX processors is utterly slow due to this fact, even on fast ones.

Of course it's doable, but maybe you'll be playing the game at resolutions lower than 80x50.

Maybe someone can build a basic version of https://github.com/ozkl/doomgeneric for 16-bit Real mode, all the source is C and requires only a few functions to be implemented.

Right, do a complete playthrough of Episode 1 on a 386sx16 and then tell us you want it for a 286, that's probably as good as it would possibly get on a Harris 25Mhz 286 (All that segment swapping is gonna halve performance, even if on small tasks and tiny pieces of benchmark code 286 is as fast as 386.)

As BitWrangler said:

BitWrangler wrote on 2021-12-21, 04:08:

286 protected mode has issues. Why weren't they fixed? They were, intel called the new revision the 386.

And if you want to be more precise, it's 386SX on a 286 chipset based motherboard. 😉 Go ahead. 😀

Aloha !

I really love this version of Doom ! Finally I can play Doom on some of my old Retro computers 😁
Tried it already on different machines and it goes very well. I do however have a small question.

When I start 'FDOOMHGC.EXE', I have a computer with a Hercules card, I get this :

1W_init: Init WADfiles.
2        adding doom.wad
3        couldn't open modebw.wad

Then the game seems to start, at least, I hear the sounds of the demo but I cant see anything.

Did I miss something, or did I fail to read instructions correctly ?
What am I doing wrong here ?

.

Cheeeeeeeeeeeeeeers and merry Christmas to all !

Jecepede

BitWrangler wrote on 2021-12-21, 16:29:

Right, do a complete playthrough of Episode 1 on a 386sx16 and then tell us you want it for a 286

Sadly I don't have such a machine currently, but I'm almost finished Wolf3D on a 8088 at 4.77 Mhz. Yeah, with a frame rates as high as 2-3 fps sometimes, and it's weird but really fun.

I think we can greatly reduce memory and speed requirements simply by using lower resolution textures, 32x64 for example. Of course, this will require a separate .wad file. Doom's main value is in a 3D FPS environment at different heights that no one has ever seen on 286. Plus, of course, overall gameplay and maps, monsters AI, etc. These things can be transferred without any loss.
SNES port code, by the way, was written just by one person, and within a really tight deadline. But now I don't think anyone would be interested in rewriting so much code for this slow CPU.

jecepede wrote on 2021-12-21, 19:47:

Then the game seems to start, at least, I hear the sounds of the demo but I cant see anything. […]
Show full quote

Copy code to clipboard

1W_init: Init WADfiles.
2        adding doom.wad
3        couldn't open modebw.wad

Then the game seems to start, at least, I hear the sounds of the demo but I cant see anything.

I have this message "couldn't open modebw.wad" on emulator too, but then game starts up without any problems. The same with FDOOMBWC.EXE for CGA 620x200.
I think this is just the remnants of some older monochrome version that used separate b/w resources instead of dithering existing ones. Also can't find any mention of modebw.wad anywhere in the repository.

As far as I know, 640x400 mode is actually undocumented HGC feature, and not every card and monitor can support that. 350 lines is a standard maximum for Hercules, or at least 400 interlaced.
Of course, resizing and dithering from 200 to 350 lines will require much more resources, that's why this 400-line mode was chosen.

UPD: Ok, I tried this .exe on a real Hercules card, late one with LPT port, and it's basically working but not quite. Some parts of image on top and bottom are missing and I got these weird stripes:

But everything else is fine, and it's possible to finish the game this way I guess.

Also FDSETUP isn't showing full screen too, only some parts so it's impossible to change any settings on this HGC card. I guess it's because of the different base memory address?

ujav wrote on 2021-12-21, 21:08:

Plus, of course, overall gameplay and maps, monsters AI, etc. These things can be transferred without any loss.
SNES port code, by the way, was written just by one person, and within a really tight deadline. But now I don't think anyone would be interested in rewriting so much code for this slow CPU.

The SNES port certainly didn't transfer overall gameplay and monsters AI without loss. 😜 Maps received less cuts than the other console ports at the time, but the game feel is completely diffrent and lots of things are just weird, buggy or both. Which is understandable because it's a total rewrite, but would another rewrite for 16-bit x86 CPUs fare any better? Well, I guess having no strict deadlines to worry about and access to the original source code which Randy Linden afaik didn't have could help...

ViTi95: I have submitted the pull request on github now, note that contrary to what I said in a previous post I decided to make Watcom compatible segs & symbols the default (so no need to pass any extra defines to NASM for Watcom builds, gcc/djgpp will need -DDJGPP_ASM)

The 32X port is recognizable as DOOM. The SNES "port" isn't.