Jump to content

Tartar (EE-fork, DOS) - maintenance build available 05.05.24


Recommended Posts

This source port is a godsend. I have always been really interested in a DOS source port and this seems to be right up my alley. I will try it ASAP and get my thoughts out afterwards, in the meantime I hope that this thread gets more steam since I am very sure that there are many out there like myself who would absolutely love this :D

Share this post


Link to post
1 minute ago, TheWolfman00001 said:

I have always been really interested in a DOS source port and this seems to be right up my alley.

 

Thanks, @TheWolfman00001. If you are interested in playing Doom in DOS, be sure to also check out MBF 2.0.4 by user @Gerwin from VOGONS message boards as well as its derivatives (Tartar has pulled audio, video and some of system code from that port too). Actually VOGONS has a thread with a considerably comprehensive list of obtainable DOS source ports, that led me to discovery historic DOS betas of Eternity Engine (they were kind of in a plain sight, but still)!

 

Finally, I've only recently found out there was contemporary build of Russian Doom for DOS - something I am keen to explore and have it high on my retro gaming TODO list.

 

Still, please do share your feedback on Tartar if you try it, I'd be much obliged for that, and if you could share the system specs you ran.

Share this post


Link to post

Well I will check it out on DOSEMU.  I have not used actual DOS since the late 90's but this is great work all the same.  

Edited by Gibbon

Share this post


Link to post

Thanks a lot. Actually, motivated by this accomplishment I wondered, would be still possible to build a little newer version of EE in DOS? 

 

So a little more recent version (3.37.00 'Sekhmet'   -- 01/01/10):

cc1_000.png.e5f4a71be90d39a3269c96865e1954a0.png

gcc_000.png.4597b8181a3efb022ff0c232cb6bbb1d.png

ld_005.png.be5e270dea920d7a4b3ee14b65c1ca44.png

 

So of course, it crashes on linker and tons of unresolved/undefined references. But dir djobj/*.o is full of DOS-executable object files. Shame the DJGPP version has been abandoned in course of development. I believe it would work just perfectly fine.

Share this post


Link to post

Can't remember the specifics, but on VOGONS boards there's a long thread where a person was producing experimental builds of more recent EE for DOS. There was some rationale for that - like getting some code from EE work in DOS, so that it could be back-ported, and the the builds were mostly crashing, at least for me. Maybe something that could be of use for you though.

Share this post


Link to post
On 1/1/2022 at 11:42 PM, AnotherGrunt said:

Thanks a lot. Actually, motivated by this accomplishment I wondered, would be still possible to build a little newer version of EE in DOS? 

 

So a little more recent version (3.37.00 'Sekhmet'   -- 01/01/10):

cc1_000.png.e5f4a71be90d39a3269c96865e1954a0.png

gcc_000.png.4597b8181a3efb022ff0c232cb6bbb1d.png

ld_005.png.be5e270dea920d7a4b3ee14b65c1ca44.png

 

So of course, it crashes on linker and tons of unresolved/undefined references. But dir djobj/*.o is full of DOS-executable object files. Shame the DJGPP version has been abandoned in course of development. I believe it would work just perfectly fine.

Is there source for this?  I checked on Quasar's doomworld thread about that from 2010 but the link is down.  I could take a look at this for you?

Share this post


Link to post
  • 3 months later...

I may be regaining my spirits little by little and have recently again been tinkering with the PC I intended to use for retro gaming. So one day browing through the Pictures thread I had an idea that got me started with a 2022 Spring refresh project for Tartar.

 

So far the first "milestone" has been coding in on the fly palette switching via cycling through palette lumps of all loaded wads. Why? To add first-class Instadoom support as the second milestone!

 

One curious side effect of this is that with Instadoom filters auto-loading activated, Tartar will be loading older (pre 1.2) HACX pwads as iwads.

 

etrn07_bmp.png.13209a88c22745fb09235da416ec8360.png

 

 

Share this post


Link to post

It's really cool to see a new DOS source port! Any chance compatibility might be updated to support more modern "Boom-compatible" wads like Eviternity, Sunlust, Ancient Aliens, etc.? Also it should be noted that the time display on the automap resets to 0:00 when you load a saved game.

Share this post


Link to post
14 hours ago, Woolie Wool said:

It's really cool to see a new DOS source port! Any chance compatibility might be updated to support more modern "Boom-compatible" wads like Eviternity, Sunlust, Ancient Aliens, etc.? Also it should be noted that the time display on the automap resets to 0:00 when you load a saved game.

 

Off topic, but you might want to get in contact with @AnotherGrunt. He created a fork of MBF (MBF.zip) that can run Eviternity (well most of it, as some maps like 32 would not run due to it being too much for DOS). I expect it would perform similarly with running other Boom compatible wads.

 

Make sure to set RAM to atleast 64 MB in DOSBox to make stuff like Eviternity work.

Edited by ReaperAA
Link fixed

Share this post


Link to post
12 minutes ago, ReaperAA said:

 

Off topic, but you might want to get in contact with @AnotherGrunt. He created a fork of MBF that can run Eviternity (well most of it, as some maps like 32 would not run due to it being too much for DOS). I expect it would perform similarly with running other Boom compatible wads.

Your link is broken :)

Share this post


Link to post
4 hours ago, Woolie Wool said:

It's really cool to see a new DOS source port! Any chance compatibility might be updated to support more modern "Boom-compatible" wads like Eviternity, Sunlust, Ancient Aliens, etc.? Also it should be noted that the time display on the automap resets to 0:00 when you load a saved game.

 

Hey @Woolie Wool. While having Sunlust in DOS does seem a tempting goal, I must be honest feats like these are not on any immediate TODO lists. Let me share my line of thinking on this topic.

 

From what I gather - and I must admit I have not researched the topic enough and haven't really hacked at anything related, so will be speculating really - the source port / wads compatibility in these cases is not a question of formats, nor even resources but rather:

 - that node builder output included produces something the source port was ever tested with (i.e. what its developer's expected it to be able to render)

 - which source port bugs the the above plus map layout (surfaces, textures, actor placement) triggers: again a question of what "kind of layouts" it was initially expected to be run with and was tested with

From both perspectives Tartar, being a 2001 Eternity Engine make, is in my opinion very much obsolete. Even on Code Duo hardware with plenty or RAM and with maps were rebuilt by a then contemporary or a more compatible modern node builder, I wouldn't expect to the maps to play as intended on the scale of full wad. 

 

So thinking rationally: could source port changes (including minor ones) improve Tartar's compatibility with modern wads? Probably so. Would spending effort on making those changes and on diligent playtesting to claim compatibility be a reasonable thing? I doubt that. Moreover, to make a though experiment of a kind and bring things to an extreme (in a good sense), Tartar being an Eternity Engine make, would it be a reasonable thing for it to absorb enough upstream changes to run Heartlands? I, again, doubt it.

 

Less rationally and more emotionally, Tartar is born of very late 90s and seems like a more appropriate home for those things from back then that would not go away rather than those that have followed since. I was very much surprised recently to learn that Instadoom _was_ meant for things from back then, so am making a small homage to it.

 

The automap issue - thanks for letting me know; let me have a look.

 

 

 

 

 

Share this post


Link to post
On 4/19/2022 at 6:53 PM, ReaperAA said:

 

Off topic, but you might want to get in contact with @AnotherGrunt. He created a fork of MBF (MBF.zip) that can run Eviternity (well most of it, as some maps like 32 would not run due to it being too much for DOS). I expect it would perform similarly with running other Boom compatible wads.

 

Make sure to set RAM to atleast 64 MB in DOSBox to make stuff like Eviternity work.

Many thanks for uploading this permanently. This is likely the build from this post (where the link is broken), right?

 

Shame there is barely details.. if it can run Eviternity, it deserves a name change.

 

Id love to know more about this. @AnotherGrunt can you provide some details about your fork?

Edited by Redneckerz

Share this post


Link to post

This discussion got me curious to try Eviternity myself. The results are actually better than I would have expected, but confirm my expectation that getting modern wads to play on ancient code bases is laboursome.

 

Tartar built from HEAD can actually load the wad with -devparm (due to a very recent change in how the parameter is handled to be able to load TPD as iwad :) ). I was able to -warp into most levels, although some (e.g. 32) got me segfaulted immediately. 

I was able to -warp into more levels than I could ~map into, which is something I am curious to have a look at this spring, as I was running into the same with 3DO Doom conversion wad, that I wanted to eventually load with Tartar.

Demo playback was crazy (demos trying to save the game, what?!) and on some levels I was seeing unknown actor warning, but moving around with idclip after the level has loaded did not get me any segfaults and such.

 

Sharing some vistas.

 

etrn08_bmp.png.bc8dfd4f6475e74d670958c8a39db349.png

 

Spoiler

etrn17_bmp.png.1401f1c320cdeb1fb0cea4d0102dacae.png

 

PS. Was running from Windows 98 which seems to limit DPMI memory to 64Mb. Will also try in DOS at some point as I suspect CWSDPMI does not impose this limitation.

 

And so that I am not taken wrong - I do not shy away from modern wads. On the contrary loading Sigil (compat wad), Romero's E1 replacement levels and NERVE.WAD is what I normally do for every binary release, and NERVE is what I am testing the legacy mapinfo support against (Tartar distro even has the extra lumps for NERVE.WAD for proper map names, music and progression).

 

EDIT:

Still curious about the segfaults, so taking a diversion to experiment with allowing Tartar to load levels with more geometry elements than currently released binary supports. Hopefully will be able to load map31 of Eviternity, but not 29 nor 32 and not sure if actually rendering those bigger maps turns out a bit too much for this diversion...

 

Spoiler

1014154983_eviter1_bmp.png.8988d2fe7afde5959a214a32fb22c185.png

 

EDIT:

 

Yay! Some cleanup ahead to allow running this without -devparm, but so far seems to work, both ~map and -warp way. Have not checked any other maps, really. Have to get back to the insta-selfie-thing...

 

etrn22_bmp.png.2783207ca7aa0348eeff63af8d5615c8.png

Spoiler

etrn25_bmp.png.e8332ebc0547660c0e80c96b09545303.png

etrn24_bmp.png.6a7256499b1692f8b9b70f53b16951b0.png

 

Edited by ludicrous_peridot
update on map 31

Share this post


Link to post
  • 2 weeks later...

I've started documenting changes done as part of the spring refresh and have added a work in progress build to the distribution under TARTAR22 directory:

https://www.moddb.com/mods/tartar/downloads/tartar-distro

 

The build is still quite lightly tested, however it can load MAP19, MAP24 and MAP31 of Eviternity, progress to MAP33 after Iconic Sin is completed in D2TWWRI, use TPD as an IWAD and apply InstaDoom filters on the fly among other things. 

 

Sharing the bugfix and compatibility hilights from the CHANGES doc:

 

Spoiler

WADS compatibility

Doom 2 PWADs with more than 32 maps are supported

 

WADs with SS_/FF_START but no corresponding S_/F_START lumps are supported

 

Maps with empty REJECT lumps no longer crash the game

 

Maps with more that 32k sides or lines no longer crash the game (e.g. Eviternity Dehydration or Imperator can be loaded)

 

When loading a map that Tartar would not be able to handle it drops to console showing an error message rather than crashing

 

Texture definition checks are now more relaxed and Tartar would log the errors it detects rather than quit immediately; related error messages are now also more friendly

 

New command line argument -nodemo has been added for the player to suppress demo playback if it's found to be choppy or jittery for particular WADs

 

Commander Keen suffering sounds have been restored

 

Eternity TC actors would now be spawned only while in Eternity mode OR with Caverns of Darkness loaded; CoD actors would only be spawned when CoD is loaded with certain actors replacing Eternity TC ones in case the same Doomednum is used for them

 

Gameplay changes and bugfixes

 

Automap shows correct level time, not an arbitrary value like before

 

BEX-style string definitions without a space before equals sign are correctly processed

 

Mnemonically-specified flags (and flags2) for Things (bits and bits2 attributes to be exact) in DEH patches will now be applied

 

WADs found in FILTERS directory will be loaded automatically upon startup with all but PLAYPAL, COLORMAP and TRANMAP stripped from them. These have special treatment and will not override the lumps from WADs players may have loaded explicitly, but will be available for on the fly palette cycling with pal_next. Use pal_list console command to print the list of loaded palette WADs (both player-specified and extras). Players can simply unpack InstaDoom zip into the directory with TARTAR.EXE to see how this feature works

 

"Intelligent" blood recoloring has been adjusted:

Chex player bleeds yellow, not green

Players with Godmode cheat bleed yellow, not red

Roaches bleed green, not red

 

Starting the game with -devparm no longer locks it up at an early stage and allows game to run despite issues detected (up until the stage where it eventually crashes) rather then quit immediately

 

Edited by ludicrous_peridot

Share this post


Link to post

Updated TARTAR22 binary in the distro with the most recently built version with the following changes: 

  • New screen size (past fullscreen) that tries to the most screen estate available in 640x480 and 1280x1024 resolution
  • selfie.wad and and selfie.deh from InstaDoom are now autoloaded when found in the same directory as TARTEAR.EXE
  • Bindable selfie CCMD (not bound by default, see Extra Keys in options) lets players use the selfie stick; all of other weapons, including the BFG are still available to the players using normal weapon keys
  • Bugfixes to dehacked handling 

etrn3_pcx.png.8f60a0da2aed6fae337f14c264c425d2.png

 

Basically, what remains to be done for the Spring Refresh is documenting changes, testing, and fixing any bugs found/reported.

I may be publishing a DOSBox video demonstrating the above in action if I figure out settings for that soon.

 

EDIT: 

Spoiler

etrn13_pcx.png.37b035a1fa6e85c14642d3517fabf478.png

 

Edited by ludicrous_peridot
Added another selfie

Share this post


Link to post

Yesterday I was trying out the new TARTAR22 build with various PWADs and getting segmentation faults on pretty much all Boom wads, either on initial startup or when accessing the main menu. I tried:

 

doom2.wad (worked)

mm2.wad (worked)

uacultra.wad (segfault on startup, confirmed works in Boom v2.02 and MBF v2.04, and previous Tartar of Tartar)

earthless_pr.wad (segfault on mainmenu, confirmed works in MBF v2.04 and previous release build of Tartar)

Phobos: Anomaly Reborn (segfault on startup, confirmed worked in previous release build of Tartar)

Several more modern wads that don't work in MBF (all segfaulted on startup)

 

I plan to go through it with a bunch more pwads this evening. Does Tartar produce any sort of dump or error log when it segfaults? Also is it supposed to be using a custom CWSDPMI or anything like that?

Edited by Woolie Wool

Share this post


Link to post

Hey @Woolie Wool. First, thanks a lot for taking time to test the new Tartar of Tartar so early.

 

Secondly, Tartar does not produce a dump, but if you could share tartar.cfg, setup.cfg and run at least some of the pwads with -dehout dehout.txt -debugfile and share the resulting text logs I would really appreciate it!

 

As for CWSDPMI I am shipping the one from MBF 2.04 and was under impression there was nothing custom about it. Worth noting is that most of development happens in a Win 98 env, so I am mostly using Windows DPMI service. When not using Windows, I am running a stock DOSBox with a stock CWSDPMI from a ~1y old build of FreeDOS.

 

EDIT: It appears BEX-style string substitution is currently broken, so most of BOOM wads with embedded Dehacked patch will likely crash at load time. Will revert when this gets fixed and after I also look at the other type of crash you've mentioned.

Edited by ludicrous_peridot

Share this post


Link to post

I don't have a setup.cfg, I have a tartar.cfg and I've attached it, along with logs for loading Earthless, which does not cause the BEX crash. It appears setting the video mode to 320x200 seems to break TARTAR22 even though it was fine with the earlier version. This crash happens regardless of what wad is loaded, even with the bare iwad.

 

As far as my own environment, I'm playing on an AMD Athlon machine running IBM PC-DOS 7, which is a modified MS-DOS 5 with features from MS-DOS 6 backported and some IBM exclusive utilities. I might try it on my MS-DOS 6.22 boot card, but I don't expect it to be any different because PC-DOS and MS-DOS are almost identical.

LOGS.ZIP

Edited by Woolie Wool

Share this post


Link to post

Thanks a lot for your feedback, @Woolie Wool. Will be testing with the wads you've listed above and post a new build once the issues are fixed.

 

EDIT: One thing I've previously noticed and that has in a way bit me already was that Windows 98 was much more forgiving for 32bit DOS applications with memory management issues. I have, for example, loaded uacultra.wad under Windows, but doing the same in DOSBox gives the error you've encountered.

The reason I am loading Windows 98 graphical shell by the way is partly the convenience of the GUI and multitasking, partly more base memory and partly that I've switched to a BT keyboard recently and have tucked away my wired keyboard. I could obviously test with "MSDOS 7" on the same machine but for convenience end up rebooting into Windows 10 for DOSBox, that has strict CWSDPMI behaviour and all the segfaults I am after :)

 

EDIT2: Title screen crash for 320x200 and BEX string processing crash have been fixed in the updated dev build and I could load mm2, earthless_pr, uacultra and par with it.

 

I'm in (something fishy with the screenshot btw, will check that)

Spoiler

ETRN83_bmp.png.95c90c6093366ae562ceab5962de0fc2.png

 

Edited by ludicrous_peridot

Share this post


Link to post

Confirmed those bugs are fixed, but I found two more:

 

* The default 640x400 video mode is now letterboxed on my 4:3 CRT, while it previously displayed correctly (320x200 displays correctly)

* Rush crashes on startup so quickly the debug file doesn't even have anything in it.

Edited by Woolie Wool

Share this post


Link to post

@Woolie Wool, will have a look at Rush. If you enable Show FPS option in the video settings, and then load a level (e.g. start a new game) can you post what details are reported for you in the top left corener of the screen? This show show the exact video mode that is being set by Tartar, which I suspect is 640x480. 

 

I've been doing some testing myself and found that zoom (and probably some other) keys in automap did not work and that bmp format screenshots were inconsistent, so was resolving those.

 

EDIT: I think I know which change has caused the letter-boxed mode to be selected, so will revert that with next published build.

 

EDIT2: Rush can be loaded now and non-letterboxed mode is again preferred. Rush in an interesting beast in that it is referencing a CPosRefir codepointer that does not really exist. Not sure if this is in fact a valid name for a codepointer, but don't have time to research at the moment. CPosRefirdoes exist.

Spoiler

...

Processing pointer at index 205: Scream
 - applied 478e4 from codeptr[32] to states[205]
Processing pointer at index 206: Fall
 - applied 479e4 from codeptr[26] to states[206]
Processing pointer at index 973: NULL
 - applied 0 from codeptr[130] to states[973]
Processing pointer at index 976: NULL
 - applied 0 from codeptr[130] to states[976]
Processing pointer at index 977: NULL
 - applied 0 from codeptr[130] to states[977]
Processing pointer at index 978: NULL
 - applied 0 from codeptr[130] to states[978]
Processing pointer at index 979: CPosRefir
Invalid frame pointer mnemonic 'CPosRefir' at 979
Processing pointer at index 974: NULL
 - applied 0 from codeptr[130] to states[974]
Processing pointer at index 975: NULL
 - applied 0 from codeptr[130] to states[975]

...

 

EDIT3: The build still got some automap configuration file consistency woes (causing e.g. issues with Tab key assignment to automap toggle) I am looking into... should have been looking into, but instead did this:

 

ETRN10_PCX.png.42e140ecf9d757ccd15d3833ad202a1a.png

Edited by ludicrous_peridot

Share this post


Link to post
  • 2 weeks later...

Sick, is that UMAPINFO?

On 5/13/2022 at 11:58 AM, ludicrous_peridot said:

EDIT3: The build still got some automap configuration file consistency woes (causing e.g. issues with Tab key assignment to automap toggle) I am looking into... should have been looking into, but instead did this:

 

ETRN10_PCX.png.42e140ecf9d757ccd15d3833ad202a1a.png

 

Sick, is that UMAPINFO?

 

One thing that carried over from Ye Olde Eternity's "improvements" is the changing of the A_CPosAttack to play DSPISTOL instead of DSSHOTGN, do you plan to change that back?

 

Also, and this is a more long-term idea, but have you consdered eventually replacing Allegro with the reconstructed DMX from gamesrc-ver-recreation, or with a different sound driver entirely, assuming one exists? I have always thought Allegro was a weakness in all the Boom ports.

 

E: I've been stress-testing with modern wads, and both Avactor (avactor.wad) and Ancient Aliens (aaliens.wad) "crash" (quit to main menu/console) on loading map01. Avactor vomits forth a large number of texture errors and Ancient Aliens gives a midi error.

Edited by Woolie Wool

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...