ViTi95 wrote on 2024-07-09, 09:54:

Finally I've added this, it's indeed faster but gameplay gets compromised. Most switches now are not visible, so you have to rem […]
Show full quote

tigrou wrote on 2024-06-22, 10:17:

Is there any plan to disable walls texturing ? (eg: to render "flat walls", just like visplanes).
Same about sprites.
Yes the game would looks like potato, but on a very slow computer that might be a good tradeoff vs playing the game in small viewport.

Finally I've added this, it's indeed faster but gameplay gets compromised. Most switches now are not visible, so you have to remember the maps to be able to play them.

Untextured walls with diminished lightning

The attachment dos4gw_000.png is no longer available

Untextured walls without diminished lightning

The attachment dos4gw_001.png is no longer available

As a side effect, also sprites can be draw untextured:

The attachment dos4gw_002.png is no longer available

The attachment dos4gw_003.png is no longer available

This will be available on the next release 😁

Thanks for adding support. It really helps with slow CPUs.

Are there any plans for WinFastDoom with 3D acceleration support, like OpenGL supported FastDoom or for this there are other ports, like glDoom?

https://gldoom.sourceforge.net/
https://gldoom.sourceforge.net/ftp/gldoom_094e.zip

marxveix wrote on 2024-08-19, 10:16:

Are there any plans for WinFastDoom with 3D acceleration support, like OpenGL supported FastDoom or for this there are other ports, like glDoom?
https://gldoom.sourceforge.net/

i think prboom is the best sourceport for windows, it has excellent compatibility, plenty of features, and is also the fastest port that i know of, so there is no need to spent time on another imitation.

noshutdown wrote on 2024-08-19, 10:30:

marxveix wrote on 2024-08-19, 10:16:

Are there any plans for WinFastDoom with 3D acceleration support, like OpenGL supported FastDoom or for this there are other ports, like glDoom?
https://gldoom.sourceforge.net/

i think prboom is the best sourceport for windows, it has excellent compatibility, plenty of features, and is also the fastest port that i know of, so there is no need to spent time on another imitation.

Thank you, i check brBoom out.

3D accelerating Doom in another API has never been faster. There's work that happens to polygonize the levels (and the new bsp /nodes required), expensive clipping calculations for sprites, approximating the light diminishing (by fog or some other vertex color technique that won't look good), and 3D cards can't handle the overdraw of Doom maps that Doom's renderer can. There's also a lack of pixel functions that would be hard to implement for old 3d cards, like the invisibility effect, the grayscale inversion for invincibility (while keeping the skies intact), the buffer melt...

Back in the day, '3d' doom ports had to do stupid things to grab attention away from rendering accuracy/performance deficiencies, like gratuitous lens flares, colored lights and translucent lost souls and some of this cruft still linger as defaults on some of today's surviving source ports...

I was thinking of adding very very basic Linux support (X11 and only x86 cpu's), but only for developing/debugging reasons. This includes minimal keyboard/mouse and display support, it shouldn't be hard as we already have a backbuffer rendering codepath, and OpenWatcom supports Linux executables.

Regarding 3D acceleration, I don't know if it's possible to use it to accelerate Doom's column and visplane renderers (basically as a simple 2D scaler). Maybe it's doable with 8-bit palleted textures.

leileilol wrote on 2024-08-19, 16:34:

3D accelerating Doom in another API has never been faster. There's work that happens to polygonize the levels (and the new bsp /nodes required), expensive clipping calculations for sprites, approximating the light diminishing (by fog or some other vertex color technique that won't look good), and 3D cards can't handle the overdraw of Doom maps that Doom's renderer can. There's also a lack of pixel functions that would be hard to implement for old 3d cards, like the invisibility effect, the grayscale inversion for invincibility (while keeping the skies intact), the buffer melt...

Back in the day, '3d' doom ports had to do stupid things to grab attention away from rendering accuracy/performance deficiencies, like gratuitous lens flares, colored lights and translucent lost souls and some of this cruft still linger as defaults on some of today's surviving source ports...

that sounds reasonable since doom doesn't really render in 3d. but glboom is somehow faster than software rendered prboom and also looks more colorful and smoother, maybe it just do 2d sprite mapping in opengl.

@marxveix:

Aren't PrBoom and PrBoom+ unmaintained ?

You might want to look at DSDA-Doom or Woof! instead.

leileilol wrote on 2024-08-19, 16:34:

3D accelerating Doom in another API has never been faster. There's work that happens to polygonize the levels (and the new bsp /nodes required), expensive clipping calculations for sprites, approximating the light diminishing (by fog or some other vertex color technique that won't look good), and 3D cards can't handle the overdraw of Doom maps that Doom's renderer can. There's also a lack of pixel functions that would be hard to implement for old 3d cards, like the invisibility effect, the grayscale inversion for invincibility (while keeping the skies intact), the buffer melt...

Back in the day, '3d' doom ports had to do stupid things to grab attention away from rendering accuracy/performance deficiencies, like gratuitous lens flares, colored lights and translucent lost souls and some of this cruft still linger as defaults on some of today's surviving source ports...

Yeah, GZDoom looks like crap by default with its bilinear filtering and tacky smoke trails... It takes me 10 minutes to remove everything. You have to work at it in order to get that vanilla look.
I guess I should use DSDA-Doom myself too. Too bad so much Doom mods require GZDoom...

xcomcmdr wrote on 2024-08-20, 08:33:

@marxveix:

Aren't PrBoom and PrBoom+ unmaintained ?

You might want to look at DSDA-Doom or Woof! instead.

I was looking OpenGL 1.1 Doom for my old ATi Rage3 - Rage Pro/RageXL, glDoom (v0.94e).

Readme: glDoom seems to run ok on these cards
3Dfx Voodoo 1 (Monster 3D's and Obsidian 100SB-4440)
3Dfx Voodoo 2 (Monster 3D II's and Quantum3D X24)
3Dfx Rush
3Dfx Banshee
3Dlabs Permedia 2 (8Mb slow)
AccelGraphics Eclipse II (32 Mb)
ATI Rage Pro (4Mb)
Intel i740 (4Mb)
Intergraph RealiZm - Z25 (offsite)
Intergraph RealiZm II (offsite)
Matrox G200
nVidia Riva 128 (4Mb)
nVidia Riva 128ZX (8Mb) (offsite)
nVidia Riva TNT (16Mb) (offsite)
Rendition V2x00 (8Mb)
S3 Savage3D

It also runs on PowerVR PCX2 but it's quite ragged.

Bit newer, improved version of the glDoom:
https://github.com/REDPOWAR/glDoom

glDoom Resurrected
https://github.com/atsb/glDoom

noshutdown wrote on 2024-08-20, 06:53:

but glboom is somehow faster than software rendered prboom and also looks more colorful and smoother, maybe it just do 2d sprite mapping in opengl.

Prboom probably took out all the optimizations for portability. Prboom also isn't fastdoom

leileilol wrote on 2024-08-20, 14:58:

Prboom probably took out all the optimizations for portability. Prboom also isn't fastdoom

glboom(not gldoom) is a part of prboom, the only difference is using opengl in place of software renderer.
both are the fastest ports that i know of, for software and hardware rendering respectively, but glboom is even faster.

One speedy and effective sugestion is 320x200x16color but 16 shades of gray for VGA with monochrome monitor. It should be speedy, look pretty nice. And even on color moitors it would bring back some nostalgia.

The way Doom renders columns I wonder if 16bit mode wouldnt be faster. Most of the render loop is column strips anyway meaning single pixel transfers, should be no speed difference between 8 and 16 bit writes and might let you skip color lookups?

rasz_pl wrote on 2024-08-22, 12:06:

The way Doom renders columns I wonder if 16bit mode wouldnt be faster. Most of the render loop is column strips anyway meaning single pixel transfers, should be no speed difference between 8 and 16 bit writes and might let you skip color lookups?

Good question, I think a 16-bit video mode should be a bit slower, as you have to write twice the amount of data to VRAM compared to 8-bit video modes (125Kb/frame vs 62.5kb/frame). It's much faster to read/write from RAM than from video card on ISA/VLB bus.

Cyberdyne wrote on 2024-08-22, 09:15:

One speedy and effective sugestion is 320x200x16color but 16 shades of gray for VGA with monochrome monitor. It should be speedy, look pretty nice. And even on color moitors it would bring back some nostalgia.

Do you mean using planar modes? Or using the original mode Y with 256 colors but limited to 16 colors? In the first case, planar modes are slower compared to chunky modes. In the second case, I'm pretty sure the difference could be minimal, the only benefit is using a smaller LUT (dc_colormap) which reduces cache misses.

Exciting News! Doug has been working on frame interpolation and it's very close to be 100% finished. Now visuals update faster than 35 fps with this new option (options -> display -> uncapped fps ON). This feature works well on faster 486 systems or 5th generation CPUs (K5/K6/Pentium/Cyrix 6x86/...)

https://github.com/viti95/FastDoom/releases/tag/0.9.9g_test1

Please note that there are still a few known issues, such as the FPS counter and some quirks with application startup. We need user feedback as this is a significant change. If you encounter any bugs or unexpected behavior, please let us know!

i have a suggestion:
now that fastdoom has undergone several updates with various fancy video modes supported, maybe we need an updated info list of them, and a survey on how each mode performs. also to decide which modes to be preserved or deprecated: a video mode should be at least either fast or nice to be supported, or it would be a waste of work if its both ugly and slow.

leileilol wrote on 2024-08-19, 16:34:

3D accelerating Doom in another API has never been faster. There's work that happens to polygonize the levels (and the new bsp /nodes required), expensive clipping calculations for sprites, approximating the light diminishing (by fog or some other vertex color technique that won't look good), and 3D cards can't handle the overdraw of Doom maps that Doom's renderer can. There's also a lack of pixel functions that would be hard to implement for old 3d cards, like the invisibility effect, the grayscale inversion for invincibility (while keeping the skies intact), the buffer melt...

Back in the day, '3d' doom ports had to do stupid things to grab attention away from rendering accuracy/performance deficiencies, like gratuitous lens flares, colored lights and translucent lost souls and some of this cruft still linger as defaults on some of today's surviving source ports...

i found helion, a pretty new source port that i didn't know about before. it was intended to be the fastest doom port for modern computers, and was mostly rewritten from scrath, rather than basing on the official released source code(although they used it as a reference on what to do).
on modern computers, helion is 5~10 times as fast as dsdadoom(which was based on prboom), and ~15 times as fast as gzdoom, another popular port. it requires windows7 or newer, and a video card with opengl3.3 support or newer.
such speed exists because, extremely complicated maps were made by mappers to show off their skills, and can pull even prboom(which used to be a fast port compared to others) down to <30fps even on modern computers.

Dumb-Crazy question.

If AI can code , is it possible to setup an automated environment, take a piece of fastdoom source code and task the AI to make it perform better, let it do thousands of iterations and then come back and see the results?

I guess there are several constraints to this

noshutdown wrote on 2024-08-28, 10:20:

it requires windows7 or newer, and a video card with opengl3.3 support or newer.

then it is irrelevant to the question - which was about a "winfastdoom with 3d". You may notice Fastdoom doesn't raise platform targets...

MarmotaArmy wrote on 2024-08-28, 15:53:

If AI can code

plagiarizing code theft slop machines won't understand how doom works and brute force to make it faster. There's already compilers that try to do that.

AI can't code!

They are text generators, and are useless at anything but basic repetitive code completion.

Source: I subscribed to github copilot for one year, and unsubscribed lately because it sucks.