viti95 / fastdoom Goto Github PK

Apologies if this is user error. Getting this message when trying to run fastdoom.exe. I've dropped fastdoom.exe into my DOOM folder (contains the shareware .wad and game files)

Hopefully I'm just doing something dumb! Thanks

Using the 0.8.10 binary release and my own compile of the commit aa80208 , Fastdoom consistently desyncs when trying to play back demo3 of Plutonia with no sound or with sound and no music, causing the player to fail to kill the third imp, but will consistently crash when music is enabled regardless of whether sound is enabled. The 0.8.10 binary release crashes immediately with music, but my compile of aa80208 using the latest NASM, DOS32/A and Open Watcom C 2.0 2022-03-12 Build will crash within a few seconds of starting the demo. This happens on DOSBox and on real hardware - tested on a 386DX-40 with an ISA Cirrus Logic GD-5429 and a Creative Sound Blaster 16 CT2290 and Ensoniq Soundscape S-2000, but this is 100% consistent so I don't believe that the hardware configuration matters.

This happens with both the Steam and GOG releases of Final Doom, which use slightly different IWADs (the GOG release is also known as the id Anthology version - https://doomwiki.org/wiki/Versions_of_Doom_and_Doom_II) but it does not affect the outcome of demo3.

Consider re-adding code that was removed from this commit to be enabled only through a command-line parameter.

I propose -mousey

Tested by maxtherabbit on VOGONS. Release 0.8.11, 486DX-33 and 16Mb RAM. Western Digital WD90C31 video card.

Launching Doom I shareware is taxing enough on my PC's hard drive. Once it finally loads, it then has to load and attempt to play the demo ⌛. This seriously slows down everything when I just wanna start the game!

Is it possible to disable the auto-demo at all? If so, could a switch be included to disable it?

Thanks!

I did the test under DOSBox 0.74-3.
If you do:
> FDOOM -timedemo DEMO1
then quit with the menu before the demo playback has finished.
Then start > FDOOM just by its name and you will see fdoom start then quit immediatly with the message:
Timed 14 gametics in 15 realtics. FPS: 32.22
Probably you will get different numbers but you get the idea. I had this problem before but needed some time to reproduce it.

It seems that when quitting via the menu then some memory is not erased and when fdoom starts it must lack some variable initialization that makes him think he is playing a demo when he is not.
It is not a big problem as the solution is to specify the -warp parameter with a map name and everything works fine.

The bug appeared at 0.8.1, and was not present for 0.8.0 (from what I tested)
Probably there is some randomness in this one and it would depend on the DOS version

I was started playing the 4th episode using FastDoom and I was bugged for some time trying to press the first swithc (SW1GARG).
Pressing this switch does not change the texture and does not makes the "klong" sound. same problem with SW1CMT and SW1GSTON.

Some other switches works as expected like SW1STRTN and SW1COMP

I did not check systematically all switches textures, but you get the point.

Multiple sound cards are not working correctly

• Sound Blaster Vibra16XV (fixed, works with IRQ 2 and DMA 1)
• Gravis Ultrasound (fixed, memory allocation problem solved)
• Avance Logic ALS100+ (fixed, works with IRQ 5 and DMA 1 / HDMA 1)
• VIA VT8231 (HP T5710 thin client, VIAFMTSR (OPL) crashes when initializing sound card, sounds are OK)
• ESS1688/ESS688 (Direct mode is not working on PCMCIA cards)
• SBEMU

Just a small thing - I can't find any way to identify the exact FastDoom version number from the downloaded/unzipped files.

For example, this is v0.8.10:

Would be useful to check what version my DOS machine is running and if it's the latest and greatest. Cheers!

I saw there're some functions referring to opl3lpt, and I would love to use my device.

How I could activate them? (even recompiling, if required to)

Hi,

There's a "compatible" SIGIL PWAD that just replaces the fourth episode of Ultimate DOOM with the titular episode, but the normal IWAD just adds it as a fifth. There's a DOS version of SIGIL floating around somewhere that leads me to believe that it wouldn't be too difficult to add support for it, and while it's obviously not targetted at such slow machines, it does run pretty playably on my DX4, and I presume the optimizations of FastDoom, while not targetted to Pentium-class hardware, would help those machines run SIGIL even better.

I remember playing around a while back with min and max function that had to be used a lot. in the end I used branches because on modern CPU well predicted branches are often faster than branch-less equivalent. For min and max I remember using those old funcs I read somewhere...

inline int Imin(int a, int b) { return b ^ ((a ^ b) & -(a < b)); }
inline int Imax(int a, int b) { return a ^ ((a ^ b) & -(a < b)); }

On 386/486 the following will be maybe faster:

inline int Imin(int a, int b) { return b + ((a-b) & (a-b)>>31); }
inline int Imax(int a, int b) { return a - ((a-b) & (a-b)>>31); }

In Doom those min and max functions are not common, however with a bit of rewriting, branches can often be avoided like in the case of your last commit (just checked after having started to write) where the line:

     return dx + dy - ((dx < dy ? dx : dy) >> 1);
could be written:
     return dx + dy - (min(dx, dy) >> 1);

With a branchless min you get some potential benefit.

Of course you have to be careful because on 386/486 the branch is always assumed NOT to be taken which can lead to faster code. but for the cases where you have 50:50% odds then this kind of tricks are really worth it.

WC default min and max are just min(a,b) (((a) < (b)) ? (a) : (b)) and max(a,b) (((a) > (b)) ? (a) : (b)) in stdlib.h, like usual.
EDIT I just found a third version:

int min3(int a, int b) { return (-(a<=b) & a) | (-(b<=a) & b); }
int max3(int a, int b) { return (-(a>=b) & a) | (-(b>=a) & b); }

The sound isn't working using any Sound Blaster AWE64 in my test bench, but my Aztech AZT2320 is working without problems. Maybe it's broken since commit #33c7b44 ?

With the Apogee Sound System fully working, it's possible to add support for more sound cards:

• PC Speaker PWM digital audio (Wolf3D uses a simpler idea that may also work well, 1 bit resolution audio at XXX KHz)
• Covox Speech Thing / LPT DAC / Stereo LPT DAC
• AC97 (JUDAS Apocalyptic Softwaremixing Soundsystem)
• Game Blaster
• Tandy 3-voice
• IBM PS/1 Audio card (DAC)
• Sound Blaster Direct Mode (doesn't require DMA, works like Covox, up to 23KHz)
• Windows Sound System
• Roland RAP-10
• OPL2 (Adlib) PCM digital audio

This library is used for Gravis Ultrasound support, but there is no documentation about it and it isn't included in the Gravis Ultrasound SDK 2.10 or 2.22.

Gravis Ultrasound support in Doom isn't great, causes lot's of troubles and the performance is low compared to the Sound Blaster. Maybe we can replace it with the latest Gravis Ultrasound SDK and fix those problems

FastDoom could benefit from the optimisation of the modulo % operation. Internally WC generates an idiv operation.
The optimization is similar to the divisions by a constant because it is almost the same thing:
ie:

Modulo 10 for signed ints, according to GCC (fastcall convention)
int Mod10(int x)
    mov    eax, 1717986919
    imul   ecx
    mov    eax, edx
    mov    edx, ecx
    sar    edx, 31
    sar    eax, 2
    sub    eax, edx
    lea    edx, [eax+eax*4]
    mov    eax, ecx
    add    edx, edx
    sub    eax, edx
    ret
; Unsigned version:
unsigned ModU10(unsigned eax)
    mov    eax, ecx
    mov    edx, -858993459
    mul    edx
    mov    eax, edx
    shr    eax, 3
    lea    edx, [eax+eax*4]
    mov    eax, ecx
    add    edx, edx
    sub    eax, edx
    ret

There are very few places where the x % constant is used and it would almost not affect much performances.

Also there are some missing optimizations: signed and unsigned divisions should be separated and when you are dividing a value you know to be positive (ie: monster damage), then an unsigned variant of the division should be used:
example for unsigned Div10:

; Again fastcall convention:
unsigned Div10u(unsigned x)
	mov	eax, ecx
	mov	edx, -858993459
	mul	edx
	mov	eax, edx
	shr	eax, 3
	ret

unsigned versions save a few instructions and mul is faster than imul (presumably?)
I simply use GCC with -O2 -march=i386 and -mtune=generic
Those should not be hard to inline with OpenWatcom.
EDIT: I did not check properly all instances of DivXX() clls, maybe you never need unsigned versions...

• Freedoom 2 crashes randomly on MAP15. Bug discovered by MrFibble (VOGONS).
• #52
• #66
• #92

System:
Biostar 8433UUD-A
IBM Cx5x86-100@120MHz
Macronix MX86200 2MB
Sound Blaster 16 (A220 I5 D1 H5 P300)
PCMIDI MPU-401 I/O (P330)
2GB Sandisk Ultra CF-IDE
LG 16x DVD-RW

Bug
Game sometimes (randomly) locks up at Doomguy screen at startup when General MIDI or Sound Canvas is selected.

When i am playing fastdoom, i noticed that the OPL music is way too quiet, compared to vanilla doom. i can hardly hear it.

I got curious about running Hacx : Twitch 'n Kill inside Chrome/Firefox/Edge thanks to FastDoom + JS-DOS.

Right now I'm testing with regular DOSBox 0.74-3 on Windows 10 x64.

What I found is that while the vanilla DOOM2 IWAD has music & sound with FASTDOOM, and HACK.WAD has music and sound with GZDOOM, HACK.WAD with FASTDOOM has sounds, but no music.

The music is in MIDI format.
I'm using the lastest FastDoom release (v7 RC1).

All is attached below:

HACK_IWAD + FastDoom + config file.zip

DOSBox config: default (sblaster = sb16, irq = 7 dma = 1, hdma = 5, SET BLASTER at A220 I7 D1 H5 T6

FastDoom config:

mouse_sensitivity		5
sfx_volume		8
music_volume		8
show_messages		1
key_right		77
key_left		75
key_up		72
key_down		80
key_strafeleft		51
key_straferight		52
key_fire		29
key_use		57
key_strafe		56
key_speed		54
use_mouse		1
mouseb_fire		1
mouseb_strafe		1
mouseb_forward		2
screenblocks		10
detaillevel		0
showfps		0
uncapped		0
flatsky		0
near		0
nomelt		0
flatShadows		0
saturnShadows		0
untexturedSurfaces		0
flatSurfaces		0
vsync		0
monosound		0
snd_channels		3
snd_musicdevice		3
snd_sfxdevice		3
snd_sbport		220
snd_sbirq		7
snd_sbdma		1
snd_mport		330
usegamma		0

Thank you very much for this very interesting project ! :)

Sometimes the game crashes for no apparent reason. No error is shown, just video garbage.

A Cacodemon bit can instakill you with a single bite, even with IDDQD cheat enabled. Only in FastDoom 0.7 RC1.

https://youtu.be/HMeeCtv4StI

Reported by @shock__ (Vogons), bulletpuffs appear while using the chainsaw against any stair. Vanilla Doom doesn't have this problem, and only happens with the chainsaw, the punches are working right.

This bug occurs with FastDoom 0.66 upwards.

• VBE2: Matrox Millenium II PCI (4Mb, UniVBE 5.3). Very distorted image.
• Text mode 80x50: Cyrix MediaGX. Screen flickering.
• Text mode 80x25: IBM Color Graphics Adapter. Heavy snow bug -> Won't fix, use the 40x25 or 40x50 modes. The fix makes the game totally unplayable.
• Hercules: Tidalwave TM6310, some parts of image on top and bottom are missing and shows weird stripes
• ATI Small Wonder v2: Text mode 40x25 + CGA fix doesn't work properly. CGA 320x200 doesn't set palette correctly.
• CGA 160x100 16 colors and 80x100 122 colors modes suffers from heavy snow on the IBM Color Graphics Adapter.

I think I found a bug, if you collect some items, then save, then load that save, the items you collected will of respawned. This seems to include health vials, armour shards, ammunition, even key cards.

I tested with 0.66 and 0.666, on doom 1 and 2 (full versions).

I've been dabbling in qbasic recently and had a crack at a "launcher" for FastDoom!

Could be improved by allowing user to set command-line options as well!

I was playing with -flatsurfaces and I realized that teleporters pads were brown and not red.
From reading the source it seems that the R_DrawPlanesFlatSurfaces*() procs use the first pixel of the flat as well as the R_DrawSpanFlat function.
I tried with an offet somewhere in the middle of 4096 ie:1993 and I think it gives beter results, see below.
Maybe someone would like to look through all the flats in doom and decide which is the best offset to have the most representative color out of each flat.
Original FDoom flat reference offset = 0

Flat reference offset = 1993

I started an episode 4 run, and I encountered this bug in E4M4:
To exit you are supposed to press two switches (lines 416 and 462) with the 102 action: S1 Floor Lower to highest floor.

• Switch L462 Lowers successfully Sector 43 as expected, same for the bars that are in half circle around the exit. However it FAILS to lower Sector 61 for the caco cabinet.

• Switch L416 Lowers successfully Sector 41 as expected, However it FAILS to lower Sector 67 for the other caco cabinet. and also fails to lower the big exit bars, except Sector 64, that lowers as expected. A continuous floor lowering sound is played but the other bars are not moving.

Also in some cases when pressing those switches it seems the klong sound does not come from the switch (not reproducible though).

I am playing with FDOOM.EXE (0.8.2) and using DOSBox 0.74-3.

The Apogee Sound System uses software mixing instead of hardware mixing, which is slower but provides more functionality. Add the option to use hardware mixing.

7/24/95

• Changed GUS code to use software mixing instead of hardware mixing.
  GUS purists will hate me (if they found out), but it makes a lot more
  sense this way since I only have to maintain one playback method, plus
  it allows GUS owners to hear reverb and gives better control over panning.
  There may be other benefits, but I can't think of them right now.

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.

Hey there, weird one - I can't seem to go backwards by using the down arrow ⬇.

• Using latest v0.8.7
• Note that it works fine in the menu, just not in gameplay
• All other controls seem to work fine
• NumLock key works for going backwards during gameplay 🤷‍♂️
• I can't be sure if this worked in previous versions of FastDoom
• Vanilla Doom (doom.exe) has no such issue
• Also tried fastdoom.exe with no parameters, same result

Thanks for the -disabledemo parameter too, killer feature 💪!

I see you are using:
/omaxet /zp4 /3r /ei /j /zq

Typically I use these ones, which should get a better perfomance.
-oneatx -ohirbk -ol -ol+ -oi -ei -zp8 -3r -fpi -mf -s -ri -zm /fhwe

You might want to update the title to something more intelligent sounding 😁

Basically, (this could be a DOOM issue), if I remove my soundcard (when machine off of course) or REM out UNISOUND (sound card driver), FastDoom gets stuck when trying to load a game/episode.

I have to hard reset my machine to recover. Occassionally I'm fiddling with autoexec.bat/config.sys which is why I bypass some drivers and forget until I try to play Doom.

Obviously an edge case, it just seems to not like any changes to soundcard environment. Hope that made sense!

There is an off by 1 error in game rendering when the screen size is smaller than fullscreen. Tested with low and potato resolution.

Full video: https://www.youtube.com/watch?v=2ZEFqE3E7Ic

VGA Planar Mode 13h should be faster than Mode-Y in some cases, for example Rendition Verite cards doesn't like this mode at all. Same happens for Cyrix MediaGX SOCs. Maybe it's also possible add support for VESA modes.

• Text 80x25 (double height, 16 colors, CGA, EGA, VGA)
• Text 80x50 (16 colors, VGA)
• CGA 320x200 4 colors
• EGA 320x200 16 colors
• CGA 640x200 B&W
• Hercules 640x400 B&W
• VGA Planar Mode 13h
• VESA (2.0, 320x200 Banked & LFB)
• MDA 80x25 (double height, 4 monochrome levels)
• MDA 80x25 (double height, 8 colors, only for some IBM MDA cards)
• ATI Small Wonder, 640x200, 16 colors, dithered
• EGA 640x200 16 colors, dithered
• Add support for 64 colors on EGA cards
• IBM 8514/A (Wireframe?, Automap?)
• IBM Professional Graphics Controller (Maybe only usable for the automap)
• IBM XGA / XGA-2
• Yamaha v6366 (CGA compatible card with 320x200 and 256 color support)

Hello I'm having an issue with Fast Doom where when I beat an episode in Doom 1 the ending text only displays a single number. Its not locking up or anything it appears to just be an issue with the text. It will display the single number for a bit then move on to the next screen. I've confirmed the doom.wad I use works in vanilla Doom, the ending text will display fine there. Below is a screenshot from the ending screen of episode 2. It did this on the episode 1 ending as well and I'm guessing it will do this for the ending of other episodes. I am playing on AO486 (mister fpga) using Dos 6.22. Below is a screenshot of the issue:

https://i.imgur.com/TpwHDxQ.png

John Carmack wrote about that in ReadMe of the Doom open-source release:
https://github.com/id-Software/DOOM/blob/77735c3ff0772609e9c8d29e3ce2ab42ff54d20b/README.TXT#L37-L45

Just curious: would it help gather some speedup advantage?
Changing collision method will definitely cause desync in demos / multiplayer, but speedup would be useful for singleplayer, so it could be optional.

Supposedly it's much faster than the BSP traversal routines from later versions, although it also requires some bug-fixing to prevent monsters from seeing obstructed things.

https://www.doomworld.com/vb/source-ports/56441-sunder-wad-map11-fps/

Spectre and invisible objects are drawed as a flat color if it's enabled potato detail instead of a fuzzy one. Maybe there is something wrong with outpw(GC_INDEX, GC_READMAP + (15 << 8)); code.

Current video cards with this problem:

• Trident TVGA8800CS (less pink pinky)
• Video Seven V7 VEGA, GD-410 + GD-420. (black pinky)
• Realtek RTG3105 (white pinky)

Other videocards such as OTI-037 and Paradise PVGA1A shows invisible objects without problem.

Hi there, I have a 386 with 640x480 VGA display (Toshiba T5200). Like many games/DOS apps, Doom is letterboxed (computer doesn't do "scaling").

This is a long shot - do you think it's possible for FastDoom to run in VGA mode/640x480?

Really keen to try fastdoom as vanilla doom is almost playable at postage stamp 🤏settings on the Toshy!

Thanks!

I'm using an ICOP Vortex86DX SOM304RD-VI SOM module that has a built-in XGI Volari Z9s Chipset running MS-DOS 6.22.

According to SciTech Display Doctor (6.53 for DOS), this chip supports VBE 3.0:

However, when I launch FDOOMVBR.EXE or FDOOMVBD.EXE it crashes with a corrupt screen or a stack trace (?):

I can't use UNIVBE because this chip isn't supported but according to VBETEST the card already supports VBE 3.0? (other games such as Duke3D and Quake seem to be working in VBE modes)

Hi, CarlosTex from VOGONS here. The issue i'm presenting here is not a FastDOOM bug. I use a CT1920 AWE upgrade card with a Orpheus Sound card prototype (Sound Blaster 2 Pro compatible). On the majority of games i can get AWE music from the AWE Upgrade card. Unfortunately there are 3 games i know that for AWE music to play one must have a real Sound Blaster 16 in the system for the AWE Upgrade card to play AWE music. Those games are:

• Raptor: Call of the Shadows
• DOOM
• DOOM 2

There's no technical reason for AWE not playing without a SB16 card, the EMU synth is accessed natively by its HW I/O port (620h is default) so there must be a dependency in the code, some kind of check that won't allow EMU8000 to play if a SB 16 card is not found.

So i'm just requesting for that dependency to be removed, which would be useful for people who use AWE Upgrade card who use SB or SB Pro 2 or compatibles, allowing them to hear AWE music even if a SB 16 is not present.

This would be an enhancement vs the original executables. If you manage to achieve this, maybe you could go into detail on what was needed to be done, and then maybe with that info i could try to patch Raptor: Call of the Shadows.

Divisions are quite slow on x86 cpu.
For division by a constant optimization is very simple, however it is possible to make the same inverse multiplication with a dynamic value as soon as the division by this value will be used more that a few times. For example if you had to make a division in a loop, then calculate the inverse outside the loop, then perform the simpler multiplication operation in the loop.

There is a library developed by ridiculousfish, that contains helper functions to make this very simple.
Have a look at http://libdivide.com/

This might be useful for fdoom.

Fdoom has made some modifications to the config file, I think it would be wiser to save them to a different config file, such as fdoom.cfg so that a user could keep fdoom in the same folder than doom without interferances.

Found by MrFlibble (Vogons):

"Playing with the shareware 1.9 IWAD does not display the third episode's title for some reason on the episode selection screen"

Hello,

I've been using hr2final.wad MAP32 as a benchmark for testing various FastDoom v0.8.7 EXEs with the TAS UV-Max demo that is at dsdarchive.com, h232x423.lmp - I have converted this into a WAD to bypass FastDoom's demo compatibility check, and it plays to completion successfully. I've attached the WAD:

h232x423.zip

I have a BAT file that I use for easy checking:

%1 -nosound -file hr2final.wad h232x423.wad -timedemo demo1

I've noticed when playing back the demo that it will crash when certain screen sizes/modes are used:

Potato quality with screenblocks <= 8
Low quality with screenblocks <= 4
High quality with screenblocks <= 2 (via editing fdoom.cfg)
FDOOMT1
FDOOMT12

Using the demo WAD with vanilla doom2.exe has no issues, even when setting to low quality and screenblocks to 1. The key difference between vanilla and FastDoom that I can see is that FastDoom does not have a sprite rendering limit, though I can not say if that will have any influence on why FastDoom crashes.

It is easy enough to reproduce without the demo WAD by warping to MAP32 on hr2final.wad with potato quality and screenblocks set to <= 3, it will crash before you can leave the starting sector.

I have tested this on a Super Socket 7 and a Socket 370 motherboard with various CPUs and video cards with no other expansion cards or anything else plugged in except the keyboard, and the results are consistent.

Build instructions reference running make.bat, which does not exist.

Please update the instructions with the correct steps.

Most settings in fdoom are saved in the config file except this one.
it is strange given that it was unofficially available on vanilla (I always used joyb_speed 29 in vanilla).
I made my own build with autorun always on but it would be nice to have the setting saved.

Root42 from Vogons discovered that savegames are currently broken in FastDoom 0.6