The DelphiDoom family source ports

Thank you ketmar!

Of course if  you prefer OpenGL rendering, please do not try DelphiDoom, I highly recommend you to use K8Vavoom!

Tried it out for the first time since 2018-ish.

Startup takes a VEEEEEEERY long time. It seems to stall for over 5 seconds on "DEH_Init", then around a second on something about parsing ACTORDEF lumps, then a function called something like "R_Init_Transparent8tables". After that's done, you get a grey screen for another 5 seconds until the main menu shows up. All in all, 15-20 seconds from double clicking doom32.exe to the main menu. This already disqualifies Delphi Doom from being a serious competitor, in my view at least. For comparison, ZDoom takes around 5 seconds, Doom Retro with its sexy fade-in animations takes 10, not counting the initial "launcher" both of those have.

But let's keep going:
I couldn't figure out how to turn off mouselook. You can turn down the Y axis sensitivity all the way down, but that completely disables the vertical axis, I don't want that, I want classic Doom mouse control. Once again a literal non-starter for me.
Changing the resolution doesn't change the aspect ratio (changing to 1024x768 just stretches it over my whole 1080p screen). You can solve this by switching to "Exclusive Fullscreen" mode but ugh do we really have to do that in %current_year%.
The doom bitmap font is weirdly horizontally stretched in widescreen mode (1920x1080).
And lastly why the hell is the exe called doom32.exe anyway? What kind of name is that? I thought the port's called DelphiDoom?? Are we doing Doom Legacy's "doom3.exe" thing again??

Questionable choices: ENDOOM is on by default, crosshairs are on by default, vulgar exit messages are on by default. I don't really mind this, but I think most people will turn the first two off right away, and some might dislike the third one.

And I haven't even started playing yet.

Don't misunderstand me, I'm not trying to get you down or something but... I just don't like this port at all in its current state.

Also DoomXS is neat but no resolution change option... into the Recycle Bin it goes. However, if I could set it to 4:3 aspect ratio (NOT stretched to 16:9), I'd like it.

Much respect for pushing software rendering to do advanced things. I have already used this to play with RDVOX mod in the past, but I did not know that you managed to have so much projects in Delphi. You are programming machine and don't deserve harsh feedback some users above have given.

However, the experience with RDVOX was not flawless back then, my problems are documented in this post: doomer.boards.net/post/29703/thread

Will look at the newest version hopefully soon. Maybe that issue was fixed at last?

Indeed there is room for loading optimization, I couldn't realized it since you've mention it. Load times in my main dev system is was at 7-8 seconds (5 years old hardware).  
I've made some changes and I've managed to drop it below 4 seconds. 



So far, I've made some progress:

The DEH_Init() loads all the game logic inside the GAMEDEF lump (a 26,000 lines DEHACKED lump). Now, it first checks the GAMEDEF lump and only loads it if it detects a modification compared to the internal game definitions.
I did some speed optimizations in string manipulation that makes ACTORDEF parsing faster, still it is a work in progress and I hope for more speed-up in near future.
The R_InitTransparent8tables() function pre-calculates all the LUTs the software renderer needs for fast color blending in 8 bit color mode. Now it utilizes multiple threads to finish the task giving a significant speed-up.
Also I've made significant speed optimizations the PascalScript compiler initialization.

Additional loading speed-up opportunities are under investigation in order to complete the overall effort.

What king of hardware do you use to have 15-20 seconds loading time? I can make some tests if I can access a similar system.

The mouselook can be turned off from the Menu (Options|Advanced|Camera|Look Up/Down). I thought the default value was false, but probably I've missed it since in other branches (DelphiHeretic, DelphiHexen & DelphiStrife) defaults to true anyway. Fixed to the repository.


I'll try to make customizable pillarbox and letterbox effect, like FPCDoom, but I can't be 100% positive for appropriate results since in OpenGL mode seems tricky.

Thanks for mentioning, fixed to the repository.


Is it really a problem? Renaming the exe will not affect gameplay and it can be easily done by the user. The name was kept as my first big goal was 32 bit color in software rendering mode. 

Crosshairs and vulgar messages will not be on by default on next version. Especially the vulgar messages will be hidden in just a console command so enable them will need more effort that just picking a menu option. I still have second thoughts for the ENDOOM screen, since DelphiDoom displays it appropriately in the main drawing canvas without using an additional text-based console as other ports. 



Yeap, the right tools make all the difference!



Thanks!


I 'd call it constructive criticism Besides, harsh or not, any feedback is welcome. Praise and harshness have the same effect: They both give you the motive to make things better!



The latest version has been tested with latest RDDVOX mod and works fine (some warning messages may appear). Did you use the DelphiDoom version? The ZDoom version (RDVOX) is not compatible with DelphiDoom.


Thanks!

Pretty much the same horsepower with my i7-7700HQ, both 4C/8T, slightly better multitasking for AMD, slightly better single thread for the i7.  I'm running on SSD, probably caching (or let me guess, HDD?) makes some difference here. I doubt if RAM of GPU makes any good to loading times. I'll try from external HDD drive with reboot to eliminate possible cache hits to see the difference.


Oooh, the mouse move just as DoomXS. No problem, it will be added as an option to the Options|Controls menu.


I'll check it.

Can confirm the startup time is down to 7ish seconds, a roughly 60% reduction compared to the previous build. Great job!

Tried this port. Texture automap rules, I always found the original one confusing.

And my usual disappointment with this or that port: I don't like the ouch face fix, or more specifically the lack of option to revert it. I use PrBoom-Plus for all my dooming because it has an option to toggle back the "buggy" behavior Doom released with. I just can't stand playing with the fix applied.

jval,
in the release version of Irkalla ( www.doomworld.com/idgames/levels/doom2/Ports/g-i/irkalla ), map07 on HMP and above the teleport (sector 881) doesn't lower itself when pressing a tiny switch (linedef 3386, action 71 S1 Floor Lower to 8 Above Highest Floor), because those difficulties have a chaingunner in that sector. The sound of platform lowering can be heard, but platform doesn't move. Prboom-plus works ok. Version 2.0.7.734, software mode (Doom32.exe). ITYTD also works ok in Delphi-Doom as well.

Irkalla's target compatibility is Boom (-complevel 9 in Prboom-plus). Maps map01, map02 and map10 of Irkalla worked fine, so I expected that Delphi Doom can play Boom-compatible wads, hence why I am posting this. Or could it be option-dependent or else?

P.S. I verified these without RDDVOX, using only base game, although originally discovered with it. RDDVOX doesn't impact the bug one bit: the bug happens on UV with or without RDDVOX, and it doesn't happen on ITYTD (since no monster in that sector) with or without RDDVOX. Just has something to do with sector with ceiling equal to the floor hosting a monster apparently, that gets in the way of sector lowering in Delphi-Doom but not in Prboom-plus.

The -file is only for wad files or single lump entries. If you load a single zip/pk3 file you can optionally use the -pakfile. Files with extension "zip", "pk3" and "wad" are automatically detected from the command line, so you don't have to specify neither -file nor -pakfile.