Marty2Doom

Ok.. the argument with the illegal reference does not apply to me now. I own the original retail version of Quake (PC and Amiga), and Mission Packs 1 and 2 including Shrak, Malice, Xmen etc ... Ripping the soundtrack doesn't take long. a few minutes. It took longer to download the game and i'm more a Singleplayer. I'm looking for technical advantages / improvements over the ports. :)

Hmm... I can not decide... What advantages does Quake Remasteres (Kex Engine) have over QuakeDOS / 3DFX Darkplaces (I Build the latest changes wit Msys) EzQuake Fitzquake / MarkV JoeQuake / reQuiem Quakespasm RMQ engine UQE (Ultimate Quake Engine) Is there a list with differences to the engines. So far, QDOS (3DFX) in Dosbox and Darkplaces is my favorite. No Idea what is better Quake Remastered.

I have tried out the Steam Version Enanced Version. I must Wonder. An extended port with poorer downscaled OGG Music soundtrack quality. Back in the 90s the graphics weren't that good, but the soundtrack from the CD was top quality. Why doesn't Kex Engine support a wave/Flac soundtrack?

Hey :) Thanks for 0.8.0 Release. I think you forgot the mouse up and down controls. :p .Is there a chance that it will still be implemented as an option/Optional?.

I have to contradict that. I replaced that as standard in your last version and recompiled the Psydoom not in Appdata searches but in the directory where it is located. Wiki entry: Unfortunately, it is a convention that is often overlooked by programmers that the special directory should only be used for data relating to the computer on which the directory of the application itself is located. Whereas the "application data" should contain the information that is related to the logged in user and his / her settings. This is particularly disregarded by the fact that other virtual directories are used and added to Windows Explorer. Many just don't understand the special directory concept that Microsoft is introducing. It has nothing to do with "modern". It is actually just laziness because the given API has already given the special directory as the global configuration directory. So you don't have to program anything except insert CSIDL and you're done. But not everything can be crammed into Appdata. The directory is not used well by many other programs anyway and it is becoming more and more confusing. The best negative example are mods from games that have to stay with appdata. They didn't understand anything anymore. One of the big ones is Unity, Unreal who didn't hear the shot. Unless the configuration is user-dependent. Sensitive data and so on. The configuration has nothing to do with Appdata. But 90% of programmers don't understand that. I have to recompile most of the open source programs. i don't want to search through appdata.

The Commit 714 "Backported SDL joystick code from Legacy2" make me crazy. https://sourceforge.net/p/doomlegacy/svn/714/tree/ From here on all joystick types and other definitions for DOS have been removed. E.g. cv_usejoystick.value and other definitions still exist in the latest version for DOS, which were removed at the time. What would be the better approach if I want to compile the commit 714 but don't want to leave the commit path because the m_menu.c and other main sources are constantly being touched and changed?

O o ... Im now at Commit 700. damn it. With the commit from 700 you have apparently completely removed the support for buttons and joystick under DJGPP/DOS because SDL . Will that be corrected in the upcoming commits? Edit: Ok, i see .. ui .. at commit 1065 it has been changed ..

Good Morning, Sir. Yes, at some point there will come a time when these old things are obsolete. Ironically, even when programming for an "old" system. :). Take it easy, I also have complete booxed sets for Amiga (complete assembler packs). :) Yes, the stdint.h under DJGPP looks good. I guess that's my fault. I didn't have an Arch type in the makefile and I still had the specs file from DJGPP. At some point I changed the arch type because the commando of gcc regarding the Cpu type had changed. I deleted the specs file and set the -march = type to i468 in combination with -mtune = i586. I let Doom run for a few hours earlier and also played a few maps myself. No freeze. I'm at commit r682. Had to change the Colourmaps and Transmap at tmap.nas and compiled. Furthermore the #include <stdlib.h> in m_fixed.h - For DOS must be included, not only for Linux. Otherwise gives implicite abs warning. As I said, I'm a noob in things but can now play wonderfully. :)

yep, doom3.wad was renamed to legacy.dat and then they decided to rename it to legacy.wad. Changes were made from 594 to 595 in r_draw8.c, r_plane.c, r_segs.c and r_things.c with the comment "Draw window clipping protection".

Somehow something seems to have happened from r594 to r595. Since r595 and I'm now at r632 and Doom (Ultimate) (i test it permantly with these Games) freezes under DOS during gameplay. I can not fully understand now that this could be. Edit: hmm.. does'nt happpend in Play/Time Demo Mode. Its running without Freeze.

Yes. I know the Binary. Its old. I compiled with GCC 3.81 r561 without Errors :). There was minimal Errors in Code in the Commit path to compile a DOS version and the CD Music works too. (I use a 35 Track Audio CD (CHD) )...

Because Doom Legacy still supports the DOS version. Just not checked. Because I think it's a shame that the code exists but can no longer be compiled and I would like it for Dosbox and at the same time want to see how it all works. Just hobby ..

So ... was able to compile up to r554. For some of them, I had to fix the DOS version source without major changes to the actual sources. With GCC 381. I have few warnings. With GCC 432 there are tons of warnings and crashes but not with GCC 381.

Hello @wesleyjohnson Big Thank for the Info. :) I was able to update my version to r543. Compiled from and with the r543 now also with GCC 4.32. The 1.43 is MacOS only. I can not extract the *.sitx file. I found unar but this doesnt work beacause extract error with "Tag 1". Edit: Definitely. With the header files byteptr.h and m_swap.h and gcc432.zip in the revision https://sourceforge.net/p/doomlegacy/svn/543/tree/ with the comment "Compiles now GCC 4.3", Doom Legacy crashes at the the beginning of entering a Level (but not a Demo play) completely with a SIGFAULT... I'll leave the two header files like that for now and keep checking ...

@wesleyjohnson Where is Legacy.dat 1.43 ? I found only 1.42 and 1.44 alpha1.?