Omega (fawtytoo.org)

Based directly on the linuxdoom source code. Binaries for Linux only, and the code needs work to compile on Windows or OSX. Patches gratefully received.

Not sure what direction to take it in, but for now is to fix it up so it all works. Plenty of work to do yet, but it does work.

One idea I've had: I'm thinking of introducing a new text lump called GAMEID that identifies the wad rather than the executable trying to guess. The lump will also have a Title string, and all the map strings. The lump can be external, and can also be applied to PWADS.

And also, to introduce new way of loading .lmp files. By appending the lumpname to the file, e.g. doomdemo.lmp=DEMO1, it's possible to specify what lump that file is rather than relying on the filename.

Love it? Hate it? Don't see the point? I'm listening.

Share this post


Link to post

No IWAD specified:
Error: No IWAD specified
Segmentation fault (core dumped)

IWAD specified:
I_InitSound: Could not open /dev/dsp
ioctl(dsp,-1073459190,arg) failed
errno=9

Share this post


Link to post

Ok. Partially my fault. With the source code is a list of commands. I should include that with the binary.

Example: omega -iwad doom1.wad

Share this post


Link to post

If it wasn't clear, my post included errors for when i did and did not use the -iwad parameter.

Share this post


Link to post

The first is just the game not exiting smoothly.

The 2nd is due to either no OSS support, or another program using sound is running. Something that will be looked into in the future.

Share this post


Link to post
_bruce_ said:

Great news - any chance for a win binary?

Nope. I don't have Windows. But, I'm hoping someone will patch the code and provide me with a binary. Until then, no can do.

Share this post


Link to post

Will this preserve the original limits?
I'd love a choco-style source port that is nevertheless limit removing; I don't think there's a port that really fills that niche right now, either (PrBoom+ with the respective complevel set doesn't really count, and as far as I know Strawberry Doom is dead).

Share this post


Link to post
Lance MDR Rocket said:

Will this preserve the original limits?
I'd love a choco-style source port that is nevertheless limit removing; I don't think there's a port that really fills that niche right now, either (PrBoom+ with the respective complevel set doesn't really count, and as far as I know Strawberry Doom is dead).

There is a lot of work to do, but yes, I do want to remove limits.

Share this post


Link to post

I haven't tried the port yet, but I noticed the apparent lack of version control besides manually doing it yourself. If I may make a suggestion, I think git is wonderful and GitHub makes hosting (among a few other things) a breeze. Subversion is still quite common, too, but I don't recommend using it except for projects that already use it.

Share this post


Link to post
chungy said:

I haven't tried the port yet, but I noticed the apparent lack of version control besides manually doing it yourself. If I may make a suggestion, I think git is wonderful and GitHub makes hosting (among a few other things) a breeze. Subversion is still quite common, too, but I don't recommend using it except for projects that already use it.

Because I already pay enough for the hosting I have, I'm making use of it. When it runs out, then maybe.

Share this post


Link to post

Always use version control, always always always always always. There is zero reason not to.

Share this post


Link to post

That cannot be stressed enough.

Developing software without any version control is like driving a car without seatbelt. As long as everything goes smooth it's all seems to be fine - but beware of any kind of mishap - and you are totally screwed.

There's enough free services where you can host a project (e.g. github or bitbucket) so there is absolutely no reason whatsoever not to do it.

And if it's just a local Mercurial/git repository on your computer which you regularly backup - that's still better than nothing. I do that for a few private project I don't intend to release to the public - but I still got everything in a relatively safe place.

Share this post


Link to post
Graf Zahl said:

That cannot be stressed enough.

Developing software without any version control is like driving a car without seatbelt. As long as everything goes smooth it's all seems to be fine - but beware of any kind of mishap - and you are totally screwed.

There's enough free services where you can host a project (e.g. github or bitbucket) so there is absolutely no reason whatsoever not to do it.

And if it's just a local Mercurial/git repository on your computer which you regularly backup - that's still better than nothing. I do that for a few private project I don't intend to release to the public - but I still got everything in a relatively safe place.

I drive a bus without a seatbelt. And yeah, shit happens. But I'm still doing it.

Why can't I host it myself? If you have suggestions to improve the site or version control, please do. But I don't see why I MUST use Git or SVN.

I have plenty of copies of every single revision backed up. It's all safe.

Share this post


Link to post

If you want to host it yourself, nothing wrong with that, but I'd recommend seeing if you can run git-daemon on your host. You can just have the bare git repository available somewhere on HTTP, but it puts quite a bit of strain on the web server and is a bit more difficult to manage if you don't have ssh access to the files on the host.

The issue with your manual storing-a-bunch-of-patches approach is that it's not easy to browse or see the changes between arbitrary versions; and $DEITY help you if someone gives you patches or you want to do branching. And what if both your public hosting and your local hard disk disappear? Are you able to reliably fetch the entire history from someone else and verify that it's intact (git's cloning and use of sha1 hashes does both of these)? Just save some headaches and use git :)

Share this post


Link to post

I could improve the layout so it's easier to follow. Add a means to browse the code, and download. And improve readability of revisions showing associated patches.
The web site is written in PHP, so making it more interactive can be done.

Share this post


Link to post
fawtytoo said:

Why can't I host it myself? If you have suggestions to improve the site or version control, please do. But I don't see why I MUST use Git or SVN.



Nobody says you can't. But why do the hassle if you can get it for free elsewhere?

Share this post


Link to post
Graf Zahl said:

Nobody says you can't. But why do the hassle if you can get it for free elsewhere?

Because: I'm also learning PHP. This is the perfect excuse to see what I can do. And, I already said this web site is paid for. But not specially for this. It has a generic use, even if you can't see it. Plus, it gives me something to do. I don't consider it a hassle.

Share this post


Link to post

Hosting has nothing to do with version control. You don't need a server or a website to set up a Subversion repository or a Git repository. A repository can be stored in a directory on your local disk.

Always always always use version control. Always.

On your website it looks like you're experimenting with some kind of "patch archive" system. That's better than nothing, at least. A proper ("mainstream") version control system will do this, but better.

Share this post


Link to post

Out of all the feedback thus far, hardly anything encouraging about the game. Just one big dig at the web site and version control.
Here's me trying to make a go at this, and give others a new Doom port, and all you've done is patronize me.

Share this post


Link to post

I don't think anyone means to patronize by suggesting the importance of version control. We all use it because we all, as programmers, have found it vital to our work.

Until you are ready to transition into using it, I'd keep frequent backups of your code, at least. You can always do manual diffs between different backup versions for a sort of crude facsimile of what you get with SVN tags.

Share this post


Link to post
fawtytoo said:

Binaries for Linux only, and the code needs work to compile on Windows or OSX.



Sorry, can't comment on what I can't run.

Share this post


Link to post

It's less like patronizing you and more like derailing the thread. :p

As for the original subject, I'm mostly in the "don't see the point" category. I mean, I do see the point for yourself, since tinkering with the Doom engine is an interesting thing to do; but I think there are enough ports out there that most everybody has already found what they needed.

The GAMEID thing, I don't know. In a large part, it's redundant with DEHACKED/BEX string support. It also reminds me of ZDoom's GAMEINFO lump; though it's not exactly that.

The "doomdemo.lmp=DEMO1" thing is more interesting IMO, but you should generalize it. E.g., how about foobar.dat=TEXTURE1 ? IMPY*=S_[TROO*] ? Could be useful.

Share this post


Link to post
fraggle said:

Always use version control, always always always always always. There is zero reason not to.


How about not to engage in Holy Wars about which system to use? CVS vs SVN vs GIT etc.

But hey, even plain old zipping the entire workspace into a datestamped file at the end of the day will do ;-)

Share this post


Link to post
fawtytoo said:

Out of all the feedback thus far, hardly anything encouraging about the game. Just one big dig at the web site and version control.
Here's me trying to make a go at this, and give others a new Doom port, and all you've done is patronize me.

Sorry!

Share this post


Link to post
Maes said:

But hey, even plain old zipping the entire workspace into a datestamped file at the end of the day will do ;-)



That's debatable. Most people doing that end up with a mess inevitably.
I still wish I had used version control in the early GZDoom days. I did exactly what you described but today all this stuff is close to worthless.

And at work convincing a certain group of developers to use the version control at hand was not an easy task. For some it's still an inconvenient hassle but fortunately the bosses insist... :)

Share this post


Link to post
Graf Zahl said:

That's debatable. Most people doing that end up with a mess inevitably.


It's better than nothing for small/medium scale personal projects, but of course a total joke if we're talking about working on the same project with other people.

Again, it might depend on personal style/language used. If you're like the author of SLIGE that has everything in one big-ass .c file, then yeah, maybe source control is probably a frill. OTOH, any medium-sized Java or C++ project is a mess of files, and without source control you'll pretty much have to save/restore everything in case something goes wrong.

Share this post


Link to post

I'd say there's still room for a new port. Assuming you can come up with a long-term purpose and goal to aim for, one which doesn't step overly much on the toes of existing ports and is interesting enough to keep yourself motivated. It's hard for me to say what that could be, but maybe you can try a little of bit of brainstorming on it yourself and see what you come up with. Reading your comments and the port description on the site gives the impression you essentially want to make another PrBoom. So maybe try to come up with a unique goal to set Omega apart from it?

Also, I'd suggest using Chocolate Doom as the basis to build on. It's essentially a replica of the original game, but with built-in compatibility with modern operating systems. Unless of course the core porting development is what you want to do.

Share this post


Link to post
Gez said:

It's less like patronizing you and more like derailing the thread. :p

Yes, I think that's what I meant to say.

Gez said:
As for the original subject, I'm mostly in the "don't see the point" category. I mean, I do see the point for yourself, since tinkering with the Doom engine is an interesting thing to do; but I think there are enough ports out there that most everybody has already found what they needed.

The point was to simply bring the original Doom source code 'up to date'. By that, I mean to fix any obvious bugs/error messages, and to create something more flexible, which is where the GAMEID and '.lmp=' comes in. Might make a better base for others to use.

Gez said:
The GAMEID thing, I don't know. In a large part, it's redundant with DEHACKED/BEX string support. It also reminds me of ZDoom's GAMEINFO lump; though it's not exactly that.

Just to take the guess work out of what wad you're using. Open to improvement.

Gez said:
The "doomdemo.lmp=DEMO1" thing is more interesting IMO, but you should generalize it. E.g., how about foobar.dat=TEXTURE1 ? IMPY*=S_[TROO*] ? Could be useful. [/B]

That's very specific. Would you have a use for that? Perhaps an example? And wouldn't that create a very long command line? I don't want to over-complicate things.

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