Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Trouble-Person

New source port

Recommended Posts

I'm writing a new source port for linux (though it may run on other *NIX systems) based on the original source.

I have made several small modifications to the original source, so it compiles on a modern system, as well as add always running and removing the turn ticks.

This is v0.01 (I threw it together in an hour or two), more stuffs coming!

http://www.megaupload.com/?d=IVUCJUEH

I have the slightly modified sndserver hosted here:

http://www.megaupload.com/?d=W1DLIGQN

If you have any features you want added, just PM me.

It is under the GPL. If you make any major mod's, please send them to me as a patch, so that I may include them.

PLEASE NOTE: It can only run in X with 256 colors (8 depth). To run it, quickly change your xorg config, so it reads "DefaultDepth 8", instead of "DefaultDepth 24"

INSTALLING:

run `make` in both linuxdoom and sndserver. Copy the binaries (linuxdoom and sndserver) from linux/ to /usr/local/bin . Run linuxdoom in a directory with a wad file.

Share this post


Link to post

Before someone says "lol why bother when there are a million source ports already" I will say that it's cool you're playing around with the original codebase, you will have fun trying to fix all the problems all the other coders ran into :P

Share this post


Link to post

Thanks. I'm happy that someone gets it :)

I'm having a lot of fun messing around with the code. I get the feeling most source ports aren't from the original code.

Share this post


Link to post
Trouble-Person said:

I'm having a lot of fun messing around with the code. I get the feeling most source ports aren't from the original code.

Share this post


Link to post

There should be an explanation as to why Final DOOM's engine is placed separately from the released source. Is there some statement or evidence that indicates this? Evidently Kreimeier had the sources used for v1.9, v1.9u, and v1.9f to build the release ready source. The fact that the teleporter code has a note doubting the usefulness of the line without which the teleporter bug appears would indicate he compared each to make sure all the games would work correctly and that the released source is based on files from all three variants.

Share this post


Link to post
myk said:

There should be an explanation as to why Final DOOM's engine is placed separately from the released source. Is there some statement or evidence that indicates this? Evidently Kreimeier had the sources used for v1.9, v1.9u, and v1.9f to build the release ready source. The fact that the teleporter code has a note doubting the usefulness of the line without which the teleporter bug appears would indicate he compared each to make sure all the games would work correctly and that the released source is based on files from all three variants.

Ummmm. OK. Anything about the port?...

Share this post


Link to post

I haven't tried your source port yet, but I want to make a quick note.

Have you looked at Chocolate Doom? I'm not sure of what your goals are, but Chocolate Doom fixes a *ton* of things from the original source release, and makes a very nice base for people wanting to make new source ports with vanilla-like source code. Chocolate Doom has pretty much everything switched over to SDL, is highly portable, and doesn't require users to change their system configuration to use it.

Share this post


Link to post

It should be stated, that my port is nowhere near done.

As for Chocolate Doom, I'd like to start from the original doom code, to get the full experience.

Share this post


Link to post

Trouble-Person said:
Anything about the port?...

Nope, nothing. And, since you're new here, I'll tip you off on that when you start a thread, you have to expect that it is not unlikely that people will in turn start branching conversations within "your" thread that are only related to what you are talking about, perhaps even distantly so. Only admins and mods dictate what can or can't be said in any thread or area, while regular members merely start threads and post (or at most they can close a thread, if they started it and feel it's done its course... as long as any admins or mods don't disagree, of course).

Share this post


Link to post
myk said:

Nope, nothing. And, since you're new here, I'll tip you off on that when you start a thread, you have to expect that it is not unlikely that people will in turn start branching conversations within "your" thread that are only related to what you are talking about, perhaps even distantly so. Only admins and mods dictate what can or can't be said in any thread or area, while regular members merely start threads and post (or at most they can close a thread, if they started it and feel it's done its course... as long as any admins or mods don't disagree, of course).

I didn't mean it that way. I was just trying to keep things on topic. If this isn't one of those forums that is really crazy about that, that's OK, I respect that.

I wasn't telling you to say anything. I was just wondering if you had any thoughts.

Share this post


Link to post

This all brings back memories of when I was getting Chocolate Doom up and running a couple of years ago :-)

You might want to check the Chocolate Doom Subversion history at least. Even if you're not interested in the code itself it would probably be useful as a list of things you may need to fix. The subversion history goes all the way back to the original source code.

You might also want to consider replacing the X code with SDL code - the X code is pretty nasty and I see you've already encountered the 256 color limit. X is a pretty complicated mess to support and SDL just takes care of it all for you.

Best of luck, feel free to ask any questions!

Share this post


Link to post

myk said:
There should be an explanation as to why Final DOOM's engine is placed separately from the released source.

Didn't TeamTNT have access to the real source for Doom, including the DOS-specific code that wasn't in the released source, in order to fix some bugs for Boom?

I suppose if that image were expanded upwards, the Linux source would branch from all of the 1.9 variants. Heretic would be somewhere in there too, I guess...

Share this post


Link to post
fraggle said:

You might also want to consider replacing the X code with SDL code - the X code is pretty nasty and I see you've already encountered the 256 color limit. X is a pretty complicated mess to support and SDL just takes care of it all for you.

Yea. I'm working on that now.


Best of luck, feel free to ask any questions!

Thanks.

CODOR said:

Didn't TeamTNT have access to the real source for Doom, including the DOS-specific code that wasn't in the released source, in order to fix some bugs for Boom?

I suppose if that image were expanded upwards, the Linux source would branch from all of the 1.9 variants. Heretic would be somewhere in there too, I guess...

I THINK that idgames didn't actually have the rights to the sound code for the DOS version (this is according to the README file), and thus couldn't license it under the GPL.


I'll post the next version as soon as SDL is complete.

Share this post


Link to post
Trouble-Person said:

I THINK that idgames didn't actually have the rights to the sound code for the DOS version (this is according to the README file), and thus couldn't license it under the GPL.

Thus, they removed it. SDL has sound support, so what? And as the sound code was for DOS, it doesn't matter anyway, unless you're doing another DOS port.

Share this post


Link to post

LogicDeLuxe said:
Thus, they removed it. SDL has sound support, so what? And as the sound code was for DOS, it doesn't matter anyway, unless you're doing another DOS port.

It appears to me he was just mentioning what he had heard was the reason why they released it without DOS support and alternate Linux only sound stuff, not that he has anything against SDL or putting (its) sound support in.

Share this post


Link to post

Trouble-Person said:
I THINK that idgames didn't actually have the rights to the sound code for the DOS version (this is according to the README file), and thus couldn't license it under the GPL.

The Condensed Genealogy agrees with you. The released Linux source seems to descend from 1.9u and 1.9f, probably with changes from Bernd Kreimeier (I was probably thinking of that article when I wrote my previous comment)...

And:

Although it was unknown to the community for several years, it was later revealed that John Carmack gave the BOOM team limited, temporary access to the original DOS DOOM source, in part to help remedy these problems. So BOOM is actually a hybrid between DosDOOM v0.2 and the original MS-DOS DOOM source.

Share this post


Link to post
LogicDeLuxe said:

Thus, they removed it. SDL has sound support, so what? And as the sound code was for DOS, it doesn't matter anyway, unless you're doing another DOS port.

The point of using SDL is not for DOS, but so the game can be rendered outside of X11 in 256 color mode.

Share this post


Link to post

Well if that's all that you're going to use SDL for, then fine. But many other developers use other features of SDL as well; input, sound, and networking code can be abstracted to SDL for high portability (the SDL team does the hard work of keeping things cross-platform).

Share this post


Link to post
MikeRS said:

Well if that's all that you're going to use SDL for, then fine. But many other developers use other features of SDL as well; input, sound, and networking code can be abstracted to SDL for high portability (the SDL team does the hard work of keeping things cross-platform).

My source port is for linux (and any other *NIX it happens to compile on), portability isn't a goal.

I have heard that linuxdoom can use svgalib. Anybody know anything about that?

Share this post


Link to post

Trouble-Person said:
I have heard that linuxdoom can use svgalib. Anybody know anything about that?

SDL will speak to svgalib, if run on Linux. Along with a pile of other video drivers (not just X11)...

Share this post


Link to post

My genealogy may be incorrect in assuming that the DOS source the BOOM team was given access to was the Final Doom source. BOOM itself, as of v2.01 at least, had no support for Final Doom. The Linux 1.10 source wasn't based off that fork.

Basically there are three known internal forks of the Doom code:

* Doom 2
* Ultimate Doom
* Final Doom

Doom 2 was built on top of the original Doom source code. Ultimate Doom was forked off of the Doom 2 project while it was still in progress. Final Doom was then based off Ultimate Doom. I *assumed* since Final Doom was id's last version of the source, that this is the source to which the BOOM team was given access. But since there was no effort to introduce Final DOOM support into that codebase, I have to call that into question now. Joel Murdoch might know, because he helped Lee Killough restore Final Doom support to MBF... You around Joel?

Share this post


Link to post
Quasar said:

Doom 2 was built on top of the original Doom source code. Ultimate Doom was forked off of the Doom 2 project while it was still in progress. Final Doom was then based off Ultimate Doom.

Nothing that I would call a fork. It looks rather one way to me. A fork has at least two direct offsprings by definition.

Share this post


Link to post

It seems to me that it was indeed a fork, because Linux Doom is evidently based on the Doom 2 fork of the code, despite being created at around the same time or even after Ultimate Doom. I believe id maintained two separate versions of the source after forking Ultimate off of the Doom 2 project, and the games continued to have executables built from different source up to v1.9. It is likely that they have several versions locked away in their old development stuff.

Share this post


Link to post
Trouble-Person said:

My source port is for linux (and any other *NIX it happens to compile on), portability isn't a goal.

If you ever use any other Unix-like OS, especially developing on them, you'll quickly find that developing only for Linux is a sure-fire way to ensure incompatibility with everything else.

Linux is extremely unlike any other operating system, and it really only vaguely resembles Unix.

Share this post


Link to post
Quasar said:

My genealogy may be incorrect in assuming that the DOS source the BOOM team was given access to was the Final Doom source. BOOM itself, as of v2.01 at least, had no support for Final Doom. The Linux 1.10 source wasn't based off that fork.

What are you talking about? The released source code (Linux Doom 1.10) had Final Doom support.

Share this post


Link to post

Quasar said:
It seems to me that it was indeed a fork, because Linux Doom is evidently based on the Doom 2 fork of the code, despite being created at around the same time or even after Ultimate Doom. I believe id maintained two separate versions of the source after forking Ultimate off of the Doom 2 project, and the games continued to have executables built from different source up to v1.9. It is likely that they have several versions locked away in their old development stuff.

Perhaps they do, but check this thread.

If anything is wrong with the tree, from what I see now, is that there should be a line from Final DOOM v1.9 to the released source. You can speculate whether perhaps another copy was used primarily, but at the very least the Final DOOM one was inspected by Kreimeier.

If Romero was the guy who gave the original source to the Boom programers, I'm pretty sure he'd have given them the one for Final DOOM (I don't see why not, since he put that project together). The only one who might (but by no means certainly) have given them an older copy would be Carmack, who didn't really seem to have participated in neither The Ultimate DOOM nor Final DOOM.

Share this post


Link to post
fraggle said:

What are you talking about? The released source code (Linux Doom 1.10) had Final Doom support.

Geez I could have sworn it didn't. But if that's the case, why then did Joel need to do work on MBF to get Final Doom working properly? Was there anything wrong with the Final Doom support in Linux Doom? And if Linux Doom has Final Doom support, why does it not have the teleporter bug? Or does it? Because I had to *add* the teleporter bug for Final Doom demo compatibility in EE, indicating that it either wasn't there already, or somebody in the BOOM team had already "fixed" it.

This is confusing.

EDIT: I see in the other thread that the teleporter bug is not in Linux Doom. So Linux Doom may have Final Doom support, but it is *not* the same source that was used to build the commercial Final Doom executables. So yes, Linux Doom should evidently be another fork coming from Final Doom. I wish I had taken more time to thoroughly research that when doing the genealogy, but I had to spend most of my time looking up stuff about the source ports ;)

EDIT 2: Actually my genealogy is correct after all. It's my memory since then that has lapsed (I AM getting older, after all).

Share this post


Link to post

If you look through Chocolate Doom's svn commit log, there are a few entries for fixing Final Doom support. The Doom source release says that it's from a January 10th, of 1997 presumably, which would mean that id had kept developing the Doom engine after Final Doom's release (perhaps for an official DOS v1.10); perhaps there were some incompatibilities with Final Doom at that snapshot.

Maybe fraggle can shed some light on the matter, he probably has a clearer memory of what was wrong in the Linux Doom source release.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×