FastDoom

ZDoom LE, Pentium 133's, Windows 98, and DOS 3.1 all go here! A bygone era, of particular interest to some folks.

FastDoom

Postby leileilol » Mon Jul 13, 2020 5:18 am

https://github.com/viti95/FastDoom

I'd like to point out this recent project that's attempting to optimize Doom (PCDoom by NukeYKT, a very recreation of the original DOS executables' source) and add further options to turn off/down some additional details/texturing to go even faster. It's already faster than doom.exe by default. It's mostly intended for the lower 486s and 386s (think about two digit MHz stuck on ISA video, around the 33MHz mark)
User avatar
leileilol
ダークエルフ!!!!!!!!!!
 
Joined: 30 May 2004
Location: GNU/Hell

Re: FastDoom

Postby drfrag » Mon Jul 13, 2020 7:49 am

I've had a look at the commit history... crazy stuff.
Why not just add a triple horizontally low detail mode in ASM? Quad aka potato looks too bad and the author says that "ASM is so f*cking hard to understand" so it's in C.
Then he removed a lot of stuff for the sake of it such as multiplayer, joysticks and gamma correction to assign autorun to F11 likely breaking the engine.
Hey but if i were better at asm i'd add the triple mode, may be you could do it yourself? :)
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

Re: FastDoom

Postby leileilol » Mon Jul 27, 2020 8:28 pm

3's not evenly divisable for 320 (and smaller viewports) :|


Anyway 0.4's released
User avatar
leileilol
ダークエルフ!!!!!!!!!!
 
Joined: 30 May 2004
Location: GNU/Hell

Re: FastDoom

Postby InsanityBringer » Mon Jul 27, 2020 9:20 pm

This is very cool. There's been a lot of grumbling about things that slow down the original Doom like Doom II doing an expensive search over all wad lumps every frame... Seeing a project make an actual attempt to speed the game up on the original hardware is definitely neat.
User avatar
InsanityBringer
 
Joined: 05 Jul 2007
Location: opening the forbidden box
Discord: InsanityBringer#9908

Re: FastDoom

Postby Redneckerz » Tue Jul 28, 2020 1:46 pm

leileilol wrote:3's not evenly divisable for 320 (and smaller viewports) :|


Anyway 0.4's released

Just when you thought you found every interesting port on the planet, there comes Lei with the comeback punch. :3:

No wonder i couldn't find it -Its not publically searchable.

But reading through the logs... this is brilliant. I love a pure optimized DOS port that renders as fast as possible on below-Doom spec standards.

This needs some more interest.
User avatar
Redneckerz
To it's ports i may have seen
Spotlight Team
 
Joined: 25 Nov 2019
Discord: Redneckerz#8399
Operating System: Windows Vista/7/2008 64-bit
Graphics Processor: nVidia (Legacy GZDoom)

Re: FastDoom

Postby drfrag » Tue Jul 28, 2020 5:01 pm

leileilol wrote:3's not evenly divisable for 320 (and smaller viewports)

And does it matter? I don't know how but i added a 3x2 mode in ZDoom LE (worked in 320x240) and must be doable in ASM too, i should have added 3x1 instead. Do 106x3 and fill the rest with the last column.
The potato mode looks like shit and it's made in C, for most changes performance impact will be neligible IMO. He removed gamma correction (says it's a bit faster) and floors and ceilings without textures look pretty bad. BTW on slow isa cards mode 13h is much faster than mode X. And you can't use potato and regular low detail at the same time.

I've found some videos:


The Mister ao486 is a low performance 486 FPGA core and must be equivalent to a 386DX, that's high detail.
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

Re: FastDoom

Postby Rachael » Tue Jul 28, 2020 10:59 pm

Pixel tripling is not as simple as you say it is and I don't understand the insistence that the author should do it.

For what it's worth - the video mode being indivisible by 3 does matter quite a lot, particularly in assembly. Since Doom uses vertical-major addressing it matters way way less, though, but it still affects the way the assembly functions are written.

The whole point of assembly is to keep things as simple as possible, at least for the CPU at any rate, and dividing by a non-factor complicates things quite a bit to the point where writing it in assembly is honestly really not worth it. If you're going to do pixel tripling like that you really are better off sticking to C.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Location: This post
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: FastDoom

Postby drfrag » Wed Jul 29, 2020 3:12 am

I suggested it to leileilol.
Sorry i was wrong and i've deleted the rest of the post.
From the game engine black book:
With direct access to the VGA banks, "low detail mode" is a completely free optimization without the need to write the same pixel column twice, since the VGA mask is set up to write the same pixel to two banks simultaneously.

But you'd need to use the Mode X (planar) for that which is usually slower than mode 13h (chunky). From Wikipedia:
Planar memory arrangement splits the pixels horizontally into groups of four. For any given byte in the PC's 64 KiB video memory aperture, four pixels can be accessed on screen by selecting the required plane(s).
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

Re: FastDoom

Postby leileilol » Thu Aug 13, 2020 5:59 pm

0.5's released and re-adds gamma correction and has faster potato.
User avatar
leileilol
ダークエルフ!!!!!!!!!!
 
Joined: 30 May 2004
Location: GNU/Hell

Re: FastDoom

Postby Redneckerz » Sat Aug 15, 2020 11:56 am

leileilol wrote:0.5's released and re-adds gamma correction and has faster potato.

I took your initial thread to make the DoomWorld version. :)
User avatar
Redneckerz
To it's ports i may have seen
Spotlight Team
 
Joined: 25 Nov 2019
Discord: Redneckerz#8399
Operating System: Windows Vista/7/2008 64-bit
Graphics Processor: nVidia (Legacy GZDoom)

Re: FastDoom

Postby leileilol » Sat Aug 22, 2020 6:36 pm

0.6's released and is faster, lets you skip the melt (which was slow on 386s as you'd only see 2 frames of it) and also has light diminishing for flat surfaces.
User avatar
leileilol
ダークエルフ!!!!!!!!!!
 
Joined: 30 May 2004
Location: GNU/Hell

Re: FastDoom

Postby leileilol » Thu Sep 03, 2020 5:37 pm

0.66's released. This fixes the savegame regression, integrates potato detail into the F5 hotkey, early uncapped framerate support (note: no interpolation), among other minor things
User avatar
leileilol
ダークエルフ!!!!!!!!!!
 
Joined: 30 May 2004
Location: GNU/Hell

Re: FastDoom

Postby leileilol » Tue Sep 15, 2020 6:25 pm

0.666 has some optimizations and more benchmarker's features for forcing settings by parameter, and logging results, since it's become quite a nice benchmark tool for ye olde computers
User avatar
leileilol
ダークエルフ!!!!!!!!!!
 
Joined: 30 May 2004
Location: GNU/Hell

Re: FastDoom

Postby leileilol » Fri Oct 23, 2020 7:28 pm

0.7 RC1 needs some real machine testing love. Adds Disney(R) Sound Source(TM) sound support and General Wireless OperationsTandy(R) Sound Source(TM) support, fixed a bunch of bugs, adds OPL3, and fasters the potato.
User avatar
leileilol
ダークエルフ!!!!!!!!!!
 
Joined: 30 May 2004
Location: GNU/Hell

Re: FastDoom

Postby Redneckerz » Sat Oct 24, 2020 5:31 am

Lei, thanks for providing updates on this. :)
User avatar
Redneckerz
To it's ports i may have seen
Spotlight Team
 
Joined: 25 Nov 2019
Discord: Redneckerz#8399
Operating System: Windows Vista/7/2008 64-bit
Graphics Processor: nVidia (Legacy GZDoom)


Return to Legacy Discussion

Who is online

Users browsing this forum: No registered users and 0 guests