Yep, the Master Levels came with DOOM-IT. Maybe you could rename the FastDoom executable and use this launcher. I haven’t tried it myself (and it’s essentially not supported).

ViTi95 wrote on 2025-01-08, 11:07:

Yep, the Master Levels came with DOOM-IT. Maybe you could rename the FastDoom executable and use this launcher. I haven’t tried it myself (and it’s essentially not supported).

For that to work, I think FastDoom would have to be able to launch an arbitrary WAD file, but I can give it shot.

EDIT: I tried to rename FDOOM to DOOM2 and DOS frontends will use the FDOOM executable, but it ignores the maps changes applied by the frontend and just starts Doom2 normally.

New release! FastDoom 1.1.0:

* Add hicolor/truecolor support for VBE2 backbuffered modes (15-bit, 16-bit, 24-bit and 32-bit)
* ASM optimized routines for linear VBE2 backbuffered modes (hicolor and truecolor)
* Better initialization for VESA modes (use linear modes whenever possible)

https://github.com/viti95/FastDoom/releases/tag/1.1.0

Support for HiColor/TrueColor VBE backbuffered modes is mainly intended for newer systems with modern GPUs. For example, AMD GCN+ cards do not support 8bpp modes at all.

ViTi95 wrote on 2025-02-27, 09:41:

Support for HiColor/TrueColor VBE backbuffered modes is mainly intended for newer systems with modern GPUs. For example, AMD GCN+ cards do not support 8bpp modes at all.

Ah interesting, so it's less about adding coloured lighting (or whatever), more about increasing compatibility?

Yep, this release doesn’t add native hicolor or truecolor rendering; it simply converts the original 8bpp backbuffer to whatever bit depth the video card supports. I assume this also applies to newer NVIDIA RTX cards, though I haven’t tested it since I don’t have one.

ViTi95 wrote on 2025-02-27, 11:41:

Yep, this release doesn’t add native hicolor or truecolor rendering; it simply converts the original 8bpp backbuffer to whatever bit depth the video card supports. I assume this also applies to newer NVIDIA RTX cards, though I haven’t tested it since I don’t have one.

Thanks very much for having the insight into doing this. This now makes FastDoom playable in bare metal DOS on Ryzen systems with its (horribly crippled) onboard GPU, since it doesn't support either 8-bit VESA or any VGA resolution or bitdepth below 640x480x32 bit. Now at least system a system is able to play at least *one* game in bare metal DOS: FastDoom! (The original 1993 release of course fails miserable since it only uses 320x200x8bit VGA.

Now AMD Ryzens aren't any longer "useless" for DOS games in bare metal, thanks to your going the extra mile in "circumventing" the needless bastardization of its GPU's lack of 8-bit support and VGA resolutions in DOS.

ViTi95 wrote on 2025-02-27, 11:41:

I assume this also applies to newer NVIDIA RTX cards, though I haven’t tested it since I don’t have one.

I was able to run original dos doom on an RTX3080, I don't know if that counts as a "newer" card - https://youtu.be/MQR2LxR7VdM?t=417

Here's a crazy idea:

A PC booter port of FastDoom. 🤭

PC booter games only really were prevalent in the early IBM DOS PC and PCjr days, and in terms of graphics and sound, most of them didn't support anything beyond CGA or PCjr/Tandy graphics, let alone anything better than 3-voice sound.

Of course, in the later DOS gaming era, games became too big to fit on a single floppy, requiring hard drives, which pretty much necessitated that they run on DOS.

But there is something charming and almost "console-like" about a game on a floppy with its own low-level access to its data written on the disk in some proprietary way, being directly bootable without any OS, and only targeting a narrow range of hardware.

In the case of a booter edition of FastDoom, it would probably be practical to offer just VGA and Sound Blaster support, with a subset of levels crammed into a single high density boot floppy, perhaps with decompression routines to make the most of the limited space on such a floppy, and being able to boot and start completely independently from DOS. So no dependence on any INT 21h or other DOS API calls.

And as a "386 booter game", it would be perfectly okay to switch directly into 386 flat protected mode, without having to worry about EMM managers, DPMI hosts, etc. (It would probably complicate BIOS interrupt calls though, but by accessing VGA, Sound Blaster and the floppy controller through direct register-level access, BIOS calls from protected mode would technically not be necessary.)

It might just be a crazy idea, but it seems kind of fun to explore. Perhaps as a FastDoom fork? And perhaps something in that vein already exists? 🙂

I know Doom has already been ported to run as a UEFI payload, which technically could be considered a booter, but what I'm suggesting here is a 386 booter game that hypothetically could have been made and released back in the day.

digger wrote on 2025-02-28, 14:48:

Here's a crazy idea:

A PC booter port of FastDoom.

I don't think that's crazy at all. I look forward to updates on your PC booter Doom digger!

It would be funny to have doom running from a set of floppies as a booter, and it would really only work if the game did zero loading during levels.

also, save and loads would be a pain.

Regarding v. 1.1.2 and 1.1.3, these are definite regressions in my mind. Why clutter up the directory with a /TEXT subdirectory? If these critical files are missing, there is now no way to exit FastDoom. In other words, it's broken now.

If "saving 15 kb" is that important so that it breaks the standalone executable, then this is very bad, indeed. The idea is that all necessary text strings and error messages should be in the binary of the executable. I've never seen another game that has resorted to 33 ridiculously small and cluttering seperate text files for quitting the game, telling you you don't have required VESA, etc! Remember with large cluster sizes (as high as 32 kb per file) on our drives now, those 32 miniscule files now WASTE a lot of disk space and are extremely inefficient.

Please for the love of optimization and unity, revert back to the old 1.1.1 executable where all text strings are included in that file! I hate having lots of small extraneous files in breadcrumbs of many directories.

If you want to save space, compress your FastDoom Archive with 7zip instead of ZIP. 7zip compresses it to about 1 MB, while ZIP takes over 15 mb. 90% of data is "shared" among the many binaries, and 7zip optimizes this very efficiently in its .7z archive.

Thanks kindly for listening to this which is meant to be constructive criticism. You've done wonders with FastDoom, and I'm eternally grateful for the project.

Or probably unite all that in one wad file

Versions 1.1.2 and 1.1.3 have been focused on optimizing the size of the executables and RAM usage. The executables had a lot of text that was only used once and took up unnecessary space, so I decided to extract it and place it in this /TEXT folder. The same thing was already done with the INTER (now unified into TEXT) folder and the intermission scene texts, and there were no complaints about it. Like with any game, if you delete the game files, it will eventually stop working, this is the same. It’s true that I could try to unify them so there are fewer separate text files.

There are also possibly other ways to optimize the .exe files such as different compilation options and optimization levels and / or different compilers (Watcom produces smaller compiled .exes than DJGPP, for example). However, the focus on FastDOOM is *speed* not necessarily optimization, which often -- seemingly paradoxically - reduces speed. As noted above, having many seperate files as adjuncts of the .exes now slows the loading of the game down, especially on older hard drives. Whereas before you had everything in one .exe file, once that and the .WAD was loaded, you didn't need to do any more seeking on the hard drive -- at the slow millsecond range verses the nanosecond range of pure RAM access.

I'd still urge you very strongly to reconsider putting all of the data in those other directories back into the exe. It will increase the .exe size by, at the most 50 kb or so. Well worth it. (I did notice the other /INTER directory of course, but if this directory is deleted, the game still runs, doesn't break and / or make it impossible to quit and return to DOS!).

I love minimalism and I can totally relate to ViTi95 efforts to make it as small as possible. Still I think zyzzle has a point here. fastdoom.wad?

There is dilemma small size or fast performance.
FastDoom about performance.
Lookup tables takes some size, you can drop them, but performance will be much slower since this will be task for cpu to calculate the values. It's much better to have all the values precalculated in lookup table.
It's like example than performance is more care than size.

I'm totally fine with extracting text from the executable, as long as it's only used once or in non gameplay related cases. A smaller executable and reduced RAM usage are big advantages on systems with very limited memory (i.e., 4MB or less), as this also lowers the number of in-game hard drive reads. I'm careful not to optimize anything that could negatively impact in-game performance.

For FastDoom 1.1.4, I'll be consolidating all these small text snippets into a single file, which currently takes up around 14KB. I'm not using an additional WAD file because I want to avoid increasing RAM usage due to extra file indexing.

ViTi95 wrote on 2025-04-14, 21:14:

For FastDoom 1.1.4, I'll be consolidating all these small text snippets into a single file, which currently takes up around 14KB. I'm not using an additional WAD file because I want to avoid increasing RAM usage due to extra file indexing.

Combining the small text files into one file is at least a compromise which should be acceptable, much better than having all of those small text files. Will you also do the same for the /INTER files and / or combine *all* of the files into one file which may reside with the executables in the main (root) directory where FASTDOOM is installed? That will be much more optimized and efficient.

I've combined all the text files from the TEXT folder, including the old INTER files. I still need to verify that everything works correctly with the new changes, and review more cases of suboptimal RAM usage.

if you let me say, i would say go all out for speed and executable size is not that important. djgpp generated executables are a bit bloated though.