Compiling in Linux

Discuss anything ZDoom-related that doesn't fall into one of the other categories.

Compiling in Linux

Postby mewse » Thu Aug 14, 2003 3:42 pm

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?
mewse
 

Postby timmie » Thu Aug 14, 2003 6:15 pm

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.
User avatar
timmie
OH YEAH!
 
Joined: 15 Jul 2003
Location: Vancouver, BC

Postby mewse » Thu Aug 14, 2003 7:01 pm

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

Postby Hirogen2 » Fri Aug 15, 2003 2:16 am

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.
User avatar
Hirogen2
 
Joined: 19 Jul 2003
Location: Central Germany
Github ID: jengelh
Operating System: RedHat-like Linux (RHEL, Fedora, CentOS, etc) 64-bit
Graphics Processor: Intel (Modern GZDoom)

Postby ryan » Tue Aug 26, 2003 7:10 pm

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 :P 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
ryan
*nix luser
 
Joined: 26 Aug 2003
Location: Duncan, BC, Canada

Postby Hirogen2 » Wed Aug 27, 2003 6:20 am

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 :P needed them myself]
User avatar
Hirogen2
 
Joined: 19 Jul 2003
Location: Central Germany
Github ID: jengelh
Operating System: RedHat-like Linux (RHEL, Fedora, CentOS, etc) 64-bit
Graphics Processor: Intel (Modern GZDoom)

Postby IntergalacticWalrus » Mon Sep 01, 2003 2:26 pm

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. :evil: 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).
Last edited by IntergalacticWalrus on Wed Sep 03, 2003 3:11 pm, edited 1 time in total.
User avatar
IntergalacticWalrus
Baka ne...
 
Joined: 01 Sep 2003
Location: E2M2, among the many UAC boxes

Postby IntergalacticWalrus » Mon Sep 01, 2003 2:30 pm

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 :P 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.
User avatar
IntergalacticWalrus
Baka ne...
 
Joined: 01 Sep 2003
Location: E2M2, among the many UAC boxes

Postby Hirogen2 » Tue Sep 02, 2003 6:51 am

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 ...
User avatar
Hirogen2
 
Joined: 19 Jul 2003
Location: Central Germany
Github ID: jengelh
Operating System: RedHat-like Linux (RHEL, Fedora, CentOS, etc) 64-bit
Graphics Processor: Intel (Modern GZDoom)

Postby randi » Tue Sep 02, 2003 4:08 pm

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.
User avatar
randi
Site Admin
 
Joined: 09 Jul 2003

Postby Hirogen2 » Wed Sep 03, 2003 2:01 pm

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).
User avatar
Hirogen2
 
Joined: 19 Jul 2003
Location: Central Germany
Github ID: jengelh
Operating System: RedHat-like Linux (RHEL, Fedora, CentOS, etc) 64-bit
Graphics Processor: Intel (Modern GZDoom)

Postby randi » Wed Sep 03, 2003 8:01 pm

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.
User avatar
randi
Site Admin
 
Joined: 09 Jul 2003

Postby timmie » Wed Sep 03, 2003 8:47 pm

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.
User avatar
timmie
OH YEAH!
 
Joined: 15 Jul 2003
Location: Vancouver, BC

Postby randi » Wed Sep 03, 2003 8:59 pm

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).
User avatar
randi
Site Admin
 
Joined: 09 Jul 2003

Postby Hirogen2 » Tue Sep 09, 2003 10:37 am

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?
User avatar
Hirogen2
 
Joined: 19 Jul 2003
Location: Central Germany
Github ID: jengelh
Operating System: RedHat-like Linux (RHEL, Fedora, CentOS, etc) 64-bit
Graphics Processor: Intel (Modern GZDoom)

Next

Return to General

Who is online

Users browsing this forum: No registered users and 9 guests