ZDoom

Has anyone else tried getting the 2.0 betas running in Linux? I've managed to get a b47 codebase (the diffs didnt work until I stripped all the files of CRs), but I'm a little clueless about how to proceed.





I'd like to know which libraries are currently needed. I see there's a barebones FLAC and zlib included in the source, but I'm assuming fmod still needs to be provided, I don't know what else.





Randy, can you give me some pointers as to what's required for this?



Edit: How much editing is the code in Linux/ going to need? How about the Makefile?

Edit: What was the last version that was successfully compiled? Were there any tricks?

I'm not even sure if it would work in Linux right now since the wad handling changed around 2.0.47 and I'm not sure if a Linux version of it has been made yet.

timmie, thats exactly the sort of information i'm looking for.

I asked Randy to fix it up, but he had not the time, so he just sent me 2.0.47j-win32. Lots of compiling errors were in there, I fixed those which I could, but the hardware dependent stuff is still from 1.23b33 and I dunno how to update it to 2.0.x. This concerns Linux/hw_*.cpp and some others in there.

i was wondering the same thing. i emailed randy awhile back and got a reply that was something like "i haven't tried to compile zdoom in linux for a long time, my linux installation is currently broken so i won't be building it for awhile". but if you could figure it out i'd be grateful the last thing i successfully compiled was 123beta33, and i just tried it again today and it won't work. i really need to learn to code.

- ryan

timmie: Wad handling code... is the least problem. The real problems are in the
architecture dependent directories (Linux/). hw_*.cpp from there is totally out
of date and uh, you know what is the result compile error heh.

Anyway I think the file handlings in general should be changed. Currently, the
FindFirstFile, FindNextFile behavior is emulated on Linux. IMO, the other way
round is easier (that is, emulating opendir() on Windows). [advert - I already
have those funcs ready needed them myself]

Hey there everyone.

That's right, ZDoom's Linux code is way outdated. I contacted Randy a few months ago and proposed him to take over the task of handling the Linux port and he gladly accepted, but I'm waiting for the next version to really start, since he told me a lot of changes will be occuring in the main WAD code, most notably the removal of mmap'd WAD files. Also, my main Linux dev box (my laptop) is currently under maintenance for almost a month now so I couldn't work on it lately. Anyway, expect a release eventually (you know, when it's done)

My ultimate long term goal is to rip out ZDoom's annoyingly unportable and closed-source fmod core and replace it with SDL_mixer, which pretty much covers everything fmod does (on non-Windows platforms at least) with the advantage of being portable to every single platform SDL already supports. What that in mind, ZDoom will become one of the most portable Doom ports ever (evil laugh).

Hirogen2 wrote:timmie: Wad handling code... is the least problem. The real problems are in the
architecture dependent directories (Linux/). hw_*.cpp from there is totally out
of date and uh, you know what is the result compile error heh.

Anyway I think the file handlings in general should be changed. Currently, the
FindFirstFile, FindNextFile behavior is emulated on Linux. IMO, the other way
round is easier (that is, emulating opendir() on Windows). [advert - I already
have those funcs ready needed them myself]

Another very critical problem is that the Makefiles are completely outdated, so the compiling isn't even done correctly.

I'm working on implementing a autoconf/automake compiling mechanism (you know, ./configure). That will be much better than Randy's messy Makefiles.

IntergalacticWalrus wrote:most notably the removal of mmap'd WAD files

Why shall WAD files not be mmap()ed? AFAIK mmap()ing is a good thing if it serves your purpose (i.e. direct writing w/o file I/O).
On the other hand, what mmap shall be removed, there is no mmap for Windows ...

Windows can do memory mapped I/O. In fact, NT was designed heavily around the use of memory mapped files. Even something as common as running a program or loading a DLL uses memory mapping. That's twice in two days that I've corrected your misconceptions about Windows. If you want to bash Windows, next time please make sure what you are claiming is actually true. Just because Microsoft made something, that does not make it bad; some of the design decisions that were made for NT are very cool.

Anyway, the reason I plan to remove it is because its benefits are no longer present with the new texture system, so there's no reason to pollute the process's address space with it. No memory mapped I/O means less system-dependant code.

I said "AFAIK" which implies the disclaimer that that fact may be wrong. Well ok seems like I need to change thoughts about Windows a bit... there is worse OS than Win actually. However I leave the Windows functions (mostly those in win.h and not in "libc") to you(s).

The way you have it worded, AFAIK only applies to mmap being a good thing. You state Windows not supporting it as if it were fact.

Heh, I remember in the Systems Architecture class I took in school, the prof would bash Windows mercilessly, but then always finish up with "but Windows NT is ok" WinNT actually took many design elements from BSD (I think) and OS/2. In fact, the prof even mentioned that the threading model in NT was one of the best threading models in modern operating systems.

Actually, I think VMS was used for many of the ideas in NT, since most of the original NT team also worked on VMS. Not sure of the source for that, though, but I remember reading it somewhere. It certainly wasn't designed by the same people responsible for MS-DOS or Windows 3.x (thankfully).

If the low-level D3D rendering stuff was replaced by SDL, another big chunk of OS dependent code would be gone. (BTW SDL itself just calls D3D on Win32)

Edit: right, found this

randy wrote:I already have perfectly usable Windows code. Why should I dump that for SDL, which has already shown itself to be much slower with the Duke 3D ports? I did convert the Linux source to SDL for 1.23, which is a move I somewhat regret.

Why, is there any other choice than SDL for Linux?