Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
fawtytoo

A new port: Omega

Recommended Posts

Janizdreg said:

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?

The original idea was not necessarily to create a new port, but to provide a 'fixed' linuxdoom source code. Apart from bug fixing, things like midi doesn't work. Some of the command line parameters are a little difficult to use or didn't work properly/as expected. 24 bit colour support. 64 bit architecture support.
It's not so much brainstorming as describing it.

Share this post


Link to post
Quasar said:

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.

How do you know I'm not making backups or diffs? I've been doing exactly that from the start.
But who benefits from using Git or SVN? Me or you? I wouldn't.

Share this post


Link to post
fawtytoo said:

The original idea was not necessarily to create a new port, but to provide a 'fixed' linuxdoom source code.


Trust me, as soon as you start "fixing" all that is wrong with the linuxdoom code, the temptation to provide your own incremental enhancements and "borrow" or reimplement functionality from other ports is very high. It's hard to both "keep it down" and fixing "just the wrong bits".

Share this post


Link to post
fawtytoo said:

But who benefits from using Git or SVN? Me or you? I wouldn't.

I think the point is to have a backup system that's easy to maintain. I find that having to create new ZIP files, give them easy names, storing them somewhere and copying the project into them is cumbersome.

Beware of SVN: I've experienced and been told in several pages (forums and articles) that it's not possible to permanently delete files. This is an issue when you accidentally or unknowingly add copyrighted data that shouldn't be distributed. It will remain there for anyone to download if they find the revision numbers containing it. I had to do a deletion command in the terminal to reset my SVN project back to 0, because I had accidentally copied Doom.wad there (now there isn't).

Share this post


Link to post

I haven't tried the port yet, I'll switch over to Linux later and try it out. I would concur with others that you should pick a goal for your port and try to fill some empty niche.

Anyway I'll go ahead and throw in my 2ยข (just my perspective obviously)

Even if you are the only one working on a project and never release the source code - I would still use version control. Obviously in your case this will be open source, but I want to stress that version control is important regardless.

There are several benefits to version control. Here are a few assuming you are the only author:

* Backing up code just in case, as previously described.
* Comments on your check-ins at arbitrary granularity (always comment check-ins).
* Branches in order to work on large features, experiments, etc. while keeping the core code base functioning. This allows you to experiment and work on big systems safely and allows you to fix important issues without worrying about disabling your new code, etc.
* File history, allowing you to make diffs between files at different arbitrary times. Check in some bad code but not sure when or where? Go through your file history and figure out which change caused the issue, for example (good comments help).
* Allows you to easily work on multiple computers and operating systems - assuming your host is online and accessible.
* Fast and convenient - no large backups, ftp, etc. required.

If you are collaborating the advantages are even more numerous.

Share this post


Link to post
fawtytoo said:

But who benefits from using Git or SVN? Me or you? I wouldn't.

You definitely will as soon as someone else starts contributing code (OK I'll admit I have some bias against Subversion -- but even that is probably better than manual patches/zip files).

lucius also hinted at being able to find bad code but he seemed to suggest it in a somewhat brute-force manner. If you use git and run into this situation, you will probably find git bisect immediately helpful. Rather than going through each revision one by one, git bisect lets you tell it your known-good and known-bad versions (though iirc it defaults to the current HEAD for the known-bad one); it then checks out a point in the middle of those commits, and you can answer whether or not it still has the bug/bad behavior. If yes, it'll pick a point further back and repeat; if no, it'll pick a point further ahead and repeat. It is usually much much faster than checking out revisions one at a time.

Additionally when using git, the "assuming your host is online and accessible" part is simply not true -- it's not a distributed version control for no reason. You clone a repo and do pretty much everything offline.

Anyway, a little more on topic: I'm a sided with Gez's opinion of "don't see the point", but I don't mean it to be offensive; and until there's 64-bit support I'm not likely to be able to run it -- I haven't had a 32-bit OS installed in years. Additionally, I don't entirely understand the motivation to "clean up" the linuxdoom code but ignore Chocolate Doom -- Choco is already basically a perfect replication of vanilla, and I'm sure you can just as easily add enhancements to it and benefit from not having to reinvent all the porting work (eg, Choco already runs on 64-bit Linux, BSDs, Mac OS X, Windows, etc). Of course it's entirely your choice, but that's my two cents.

Share this post


Link to post

Just thinking about those ancient times when I had to work without a safety net still gives me the creeps.

Just take ZDoom's progress. The 2.0.x phase - before using SVN was more or less a huge mess and one important development branch got completely lost.

No such problems with 2.1.x and later. The amounts of bug reports greatly shrunk because experienced people were able to test the code 'live'. And since everything is safely stored somewhere with a detailed changelog it's much much easier to find out when stuff broke.

In contrast, just recently an old bug was discovered but the motivation why the bug was introduced is lost in obscurity and nobody knows for sure if it was just some leftover testing code or a deliberate change to address something. If it's the latter - we don't know anymore and therefore can't adjust the code to just be used for that specific case.

The bottom line:
Sorry, I can't take programmers seriously which refuse to use version control. They are only shooting themselves in the foot and do neither themselves nor the public nor their project a favor.

Share this post


Link to post
Maes said:

Trust me, as soon as you start "fixing" all that is wrong with the linuxdoom code, the temptation to provide your own incremental enhancements and "borrow" or reimplement functionality from other ports is very high. It's hard to both "keep it down" and fixing "just the wrong bits".

I've already done that. My original idea stands, but now I'll maintain 2 ports. One: simply a fixed linuxdoom, and two: my own port that I can do whatever I want with.

Share this post


Link to post
Graf Zahl said:

The bottom line:
Sorry, I can't take programmers seriously which refuse to use version control. They are only shooting themselves in the foot and do neither themselves nor the public nor their project a favor.

Shame you feel that way. A programmers merit is also based on their work. It's not like I'm not tracking it at all, or have no backups.

Share this post


Link to post

Bad experience from work. I've met your kind there and they've always been trouble, no matter how good their programming skills were.

Share this post


Link to post
Graf Zahl said:

Bad experience from work. I've met your kind there and they've always been trouble, no matter how good their programming skills were.

See? These are the digs I was referring to.

Share this post


Link to post

Graf Zahl is being overly harsh but he has a point. I would find it hard to take a programmer seriously who refused to use version control as well. It's a sign of maturity and experience.

lucius actually missed what I would say is the best feature of all of using version control: it makes you a better programmer. It's been about 12 years now since I first started using CVS for storing SMMU's code. When I first started using it, it was kind of painful, not least because CVS was kind of tedious to set up and I was using it on DOS where it didn't run very well. But after a while of using it, I would never go back.

When you don't use version control, your source code is ephemeral: basically just a bunch of files that you sometimes perhaps make "backup copies" of, if you remember to. After a while of using version control, I found that the way I thought about programming changed: more disciplined and precise. Your work becomes a procession of small changes, each documented, explained and justified (and the justification is as much for yourself as for others). It gives you greater confidence in your work.

I think I'm doing a poor job of explaining what I'm trying to say. Sorry to ramble on, I'm sure you're fed up of the whole subject by now, and it doesn't seem like you're likely to change your views at this point anyway. It's something I've wanted to write about for a while.

Share this post


Link to post

Version control makes it way easier to track down which change introduced a bug.

Share this post


Link to post
fraggle said:

lucius actually missed what I would say is the best feature of all of using version control: it makes you a better programmer. It's been about 12 years now since I first started using CVS for storing SMMU's code. When I first started using it, it was kind of painful, not least because CVS was kind of tedious to set up and I was using it on DOS where it didn't run very well. But after a while of using it, I would never go back.

When you don't use version control, your source code is ephemeral: basically just a bunch of files that you sometimes perhaps make "backup copies" of, if you remember to. After a while of using version control, I found that the way I thought about programming changed: more disciplined and precise. Your work becomes a procession of small changes, each documented, explained and justified (and the justification is as much for yourself as for others). It gives you greater confidence in your work.

I honestly never thought of it quite that way but you do have a point. Another item to add to the already large list of reasons to use source control. :) There has been enough arguments for source control already though so I won't make anymore comments about it.

Anyway good luck with the port, have fun with it. Ultimately that's more important then what others think of "yet another port" anyway.

Share this post


Link to post
fraggle said:

When you don't use version control, your source code is ephemeral: basically just a bunch of files that you sometimes perhaps make "backup copies" of, if you remember to. After a while of using version control, I found that the way I thought about programming changed: more disciplined and precise. Your work becomes a procession of small changes, each documented, explained and justified (and the justification is as much for yourself as for others). It gives you greater confidence in your work.

I think I'm doing a poor job of explaining what I'm trying to say. Sorry to ramble on, I'm sure you're fed up of the whole subject by now, and it doesn't seem like you're likely to change your views at this point anyway. It's something I've wanted to write about for a while.

For the umpteenth time (or maybe the first depending on how you view it):
My code is not a bunch of files that I occasionally make backups of. I religiously make a copy of the project and make changes to that copy only. That copy gets a revision number. When I wish to make more changes, I make another copy and repeat the process. I have separate copies of my project for each revision. Hence, the patch files: they show the difference between, not just each revision, but each revision copy. It's not random or occasional, it's religiously done. There may be little evidence on my web site of this, but I am using version control. I can track every change to a revision easily, using both the changelog and the patch files. If someone gave me a patch for a specific revision, I can keep it with that revision only. Same with branching. My system is crude, perhaps a bit time consuming, but it does have version control.

Perhaps you are not the only one who is explaining poorly. But the reason I'm not changing is because I'm already doing it. Just not some where you can see.

Share this post


Link to post
lucius said:

Anyway good luck with the port, have fun with it. Ultimately that's more important then what others think of "yet another port" anyway.

Thanks. I'm thinking of doing 2 separate ports as the temptation to add new stuff is overwhelming. One is to continue adding new features/support and create as I see fit/ others suggestions. The other will be a fixed linuxdoom. "Fixed" defined here is: coding bugs/errors without breaking/changing the gameplay/demos, improving the code for efficiency/better methods, and to add missing features present in the DOS versions.

Share this post


Link to post
fawtytoo said:

Just not some where you can see.

I respect your choice, but with regards to that part, do note that the Doom code is GPL, which means that when you release the port, you'll have to release the source too.

Your idea of a port with new features sounds pretty interesting.

Share this post


Link to post
printz said:

I respect your choice, but with regards to that part, do note that the Doom code is GPL, which means that when you release the port, you'll have to release the source too.

If he's starting with the original source release with the educational license, he doesn't have to release source code. Granted, this would be a sleazy move, and he wouldn't be able to take code from any of the GPL ports.

Share this post


Link to post

Nothing about the GPL mandates a version control repository to be accessible, merely that the source code for available versions also remains available (well, more than that; the source code access must not require any extra fees aside from media cost -- but I doubt this guy is trying to sell his port commercially).

Share this post


Link to post
chungy said:

(well, more than that; the source code access must not require any extra fees aside from media cost -- but I doubt this guy is trying to sell his port commercially).

Off topic, but if that is true, then it makes trying to sell GPL products even less feasible. Why should the source code be free even if the binary would be priced? Why not simply have this rule: if you can get the executable, then you can also get the source? [/offtopic]

Share this post


Link to post

Who said anything about the source code being required to be free of charge?

Your simple rule is exactly what the GPL does.

Share this post


Link to post

Deliberately ignoring the advice of several programmers in here and continuing to use a huge kludge, manual system of backups and patches is not a good thing. It is very liable to turn around and bite you in the ass with the slightest mistake you make. I'm sure you're tired of having your preferences criticized but people wouldn't do it if it didn't matter.

As for the port, it seemed to run fine, if a bit sluggish. Requiring users to load a lump that lets the engine know what game you're trying to play seems like a horrible idea, to be quite honest. If you're set on keeping the engine from automatically detecting such a thing, at least add command line parameters for this (such as -doom1, -doom, -doom2, -tnt)? X11 wasn't able to grab my mouse, so I had to use keyboard for testing, perhaps switching to SDL would be worthwhile, at this point you could probably be an early adopter of SDL 2.0, even, since you don't have SDL 1.2 in your codebase to deal with.

While I don't have much use for single-player source ports, it will be interesting to see where you take this. Good luck with it. :)

Share this post


Link to post
fawtytoo said:

For the umpteenth time (or maybe the first depending on how you view it):
My code is not a bunch of files that I occasionally make backups of. I religiously make a copy of the project and make changes to that copy only. That copy gets a revision number. When I wish to make more changes, I make another copy and repeat the process. I have separate copies of my project for each revision. Hence, the patch files: they show the difference between, not just each revision, but each revision copy. It's not random or occasional, it's religiously done. There may be little evidence on my web site of this, but I am using version control. I can track every change to a revision easily, using both the changelog and the patch files. If someone gave me a patch for a specific revision, I can keep it with that revision only. Same with branching. My system is crude, perhaps a bit time consuming, but it does have version control.

Perhaps you are not the only one who is explaining poorly. But the reason I'm not changing is because I'm already doing it. Just not some where you can see.

Yeah, I kind of got that impression that was the case. Sorry - as I said, my previous comment was basically a bunch of stuff about version control that I'd been meaning to write something about for a while. I probably should have posted it to my blog or something, but the discussion about version control here prompted me to use this thread as an outlet. I wasn't trying to have a go at you.

It sounds like what you have is at least better than nothing, which is good, but when you say you do this "religiously", the way I read that is "manually and in a way that is unnecessarily time consuming and prone to human error".

I'm not going to comment on this any further at this point because it sounds like you're fed up of hearing about the whole subject and I don't want to offend you any more than I already have.

Share this post


Link to post

Hey, he would be catching just as much flak if he was using CVS ;-)

Share this post


Link to post
fraggle said:

It sounds like what you have is at least better than nothing, which is good, but when you say you do this "religiously", the way I read that is "manually and in a way that is unnecessarily time consuming and prone to human error".

I'm not going to comment on this any further at this point because it sounds like you're fed up of hearing about the whole subject and I don't want to offend you any more than I already have.

The way you read "religiously" is not quite right. Manual? I don't have a problem with that. Time consuming? A couple of minutes, which I can live with. Human error? I don't jump straight in to a new version. I have plenty of backups, including on my website. There's a copy of everything somewhere.

Offended? No. Annoyed that the thread was derailed? Yes. But there are plenty of comments (not just fraggle) here also that show an assuming attitude. Assuming that I'm not using version control. Assuming I'm not backing up.

Now. Back to the port.

Share this post


Link to post

There's nothing wrong with not going mainsteam. Practically every web developer I know had, at some point in time, devised his own "CMS" which consisted of little more than a script that pieced together blocks of HTML code in order to assemble webpages ;-) Which is exactly what CMS systems do, on the other hand....just in a way that's more likely to get an employer to hire you ;-)

Share this post


Link to post
Maes said:

There's nothing wrong with not going mainsteam. Practically every web developer I know had, at some point in time, devised his own "CMS" which consisted of little more than a script that pieced together blocks of HTML code in order to assemble webpages ;-) Which is exactly what CMS systems do, on the other hand....just in a way that's more likely to get an employer to hire you ;-)

That's very intuitive of you. I have no wish to stay a bus driver for the rest of my life, but it currently pays better than being a programmer.

I'm not a mainstream kind of guy. Not because I'm stubborn, but I won't learn anything if I do it the "easy way", or using "what's already there". Hell, if I was going to do it the easy way, I wouldn't be creating this port. There's plenty already out there.

I have many reasons why I'm doing it the way I am. I just didn't realise I have to explain it.

Share this post


Link to post
Maes said:

There's nothing wrong with not going mainsteam. Practically every web developer I know had, at some point in time, devised his own "CMS" which consisted of little more than a script that pieced together blocks of HTML code in order to assemble webpages ;-)

Haha, I used a Perl script that called the C preprocessor! Good times, good times. :)

A source page basically looked like this:

HEADER

TITLE(Lorem Ipsum)
Dolores sit amet yadda yadda.

FOOTER
Then I was told I'd better use some newfangled thing that was starting to get some steam, and that was still called Personal HomePage at the time.

Share this post


Link to post

I once wrote a 6-th order Chebychev filter simulation. In Excel. Using double sets of columns to emulate complex numbers, and broke down formulas into real and complex part BY HAND before entering them in cells, so that I could "chain" the various stage's responses.

I had additional columns for modulo and phase next to every "output stage", and used them to make Bode plots using standard Excel plots. And all that because I was too lazy to install Matlab. The scariest thing of all? It worked ;-)

Share this post


Link to post
Maes said:

I once wrote a 6-th order Chebychev filter simulation. In Excel. Using double sets of columns to emulate complex numbers, and broke down formulas into real and complex part BY HAND before entering them in cells, so that I could "chain" the various stage's responses.

I had additional columns for modulo and phase next to every "output stage", and used them to make Bode plots using standard Excel plots. And all that because I was too lazy to install Matlab. The scariest thing of all? It worked ;-)

That's disgusting.

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
×