Future plans for DoomsDay Engine & some *nix-related bugs.
Good day.
I've been tracking the DoomsDay project progress for a long time, IIRK - for more than five years, and I'm a bit disappointed with the state the project is now at.
There was no stable release for years, and I hadn't found any source for up to date roadmap for the 1.9.0 release series. Also, the documentation in the wiki is incomplete and partially outdated when it comes to the description of building and installing latest betas on the linux platform.
Additional resources collection is in chaos state: looks like that some new models and textures for jHexen, showed up on NewDoom forums were lost - i.e. there's no any place, where they can be fetched for download and play. Dengine.Net file hosting portal looks like a big trash can - there are a lot of good downloads in there, but they are not categorized and it is very hard even for experienced one to determine "what is what".
All above is no good, but, thanks to devteam, the project itself is still alive.
It gives volunteers a possibility to try their best and to bring things to a better state.
As for me, I've got several things to offer devteam help at:
1. Here in Moscow I've got two dedicated servers, and I can mirror downloads section of dengine on them. To do it I will need additional information from current Dengine.net filesection maintainer (what to mirror, how to mirror - rsync? SVN/WebDAV? dropbox? - when to mirror, e.t.c). Internet bandwidth for this servers isn't very fast - 50Mbit max (nowdays traffic is not so cheap as it used to be before), but it seems reasonable to me, that it's better to have several low-speed alive file servers, than the only fast one that had gone down for any reason.
2. Wiki stuff. Wiki instructions for building dengine are outdated. I can try to update them a bit, including Snowberry-related installation problems on non-deb linux systems, but my written English is far from perfect, so it be hardly needed/recommended to find someone willing to fix spelling and grammar errors in edits by me. Another thing that I'm able to do is to provide some Russian translations, either for snowberry and for wiki pages.
3. Linux-distros packaging stuff. I'm using Fedora Linux atm., and it's a pitty that there are no Fedora RPM packages for doomsday, even for stable 1.8.6 version of it. I can make some SRPM/RPM packages for fedora myself and provide the results to devteam, so it would be possible for Fedora gamers all over the world to simply yum install/rpm -ivh packages to give DoomsDay a try. In my opinion, separate packages must be provided for deng, snowberry and each and every snowberry addon out there. Also, it would be reasonable to provide official RPM specfile templates for addons packages, to ease life a bit for third parties willing to RPM-package their favorite hand-made snowberry addon.
So, the basic question is: are there any need in my help concerning any of the above three points? If yes, whom (and where) should I contact for additional information concerning implementation details for any task in question?
P.S. Last, but not least.
Recently I've been debugging deng 1.8.6 hand-built with gcc34 on my Fedora box. Initial problem was lack of skin for skippy-formersergeant legacy model (i.e. sergeants showed up in all white in game), that was re-released as a Snowberry Add-On.
To track it down I had decided to unpack PK3 contents and to place unpackaged files directly to deng basedir in appropriate locations. Unpacked model looked good (i.e. with normal skin) when opened in mm3d (Misfit Model 3d), so I went on to deng. I had placed skippy-formersergeant.ded to {deng_data}/Defs/jDoom/Auto/, and the rest model stuff to {deng_data}/Data/jDoom/models/monsters/formersergeant/*. Before launching deng I had checked that skippy-formersergeant.ded includes correct ModelPath:
Result was surprising: totally invisible sergeants! It was obvious that *.md2 files for ded were not found for some strange reason, and no notion of it had shown on console.
Ok, looks like it's time to increase verbosity I thought.
Merely adding "-verbose -verbose" to command line leaded to a huge BOOM! - SIGSEGV and core dump for DoomsDay.
After some time spent with hacking source (I was too lazy to re-configure project with gcc -ggdb, so my decision was to simply add some debug printfs to see, where the SIGSEGV happens) I came to a fact that merely changing
to
in dd_main.c makes SIGSEGV go away. I wasn't interested in the real cause of this sugsegv at that moment, as I was tracking down another issue. It might be reasonable for devteam to check if this bug is still in place for 1.9.0-beta6.x.
Well, after all I had managed to increase verbosity, and to got some messages in console about md2 models not found. But there was no obvious reason for that, except for some bugs in deng with case sensitive filesystems handling. After about an hour of investigations (and huge debug-print additions to deng code) it became obvious that the initial guess that the problem was in engine filesystem paths case handling was right:
As you can see, in spite that in search path directory with the model looks like "Data/jDoom/models/monsters/formersergeant", the deng filesystem hash-builder subsystem tries to add lowercase version of it to hash: "FH_AddDirectory: Adding data/jdoom/models.". Result is obvious: model files not found later on, as there is no real filesystem path "/misc/Raid0/Games/DoomsDay/share/deng/data/jdoom/models/monsters/formersergeant/*".
Just to be sure, I had created two symlinks:
Thereafter deng managed to locate md2 files and I finally got a possibility to debug, why the hell legacy skippy-sergeant model was displayed without the skin in deng.
I think that it would be reasonable for devteam to check if the same filesystem paths case handling bugs are still in place for 1.9.0-beta6.x.
As for latest stable 1.8.6 - I can write a patch for it correcting this bug, but I'm not sure that it's needed. If the final 1.9.0 release is soon to be done, than it's better to wait a bit for it to come out. If not - I think that it would be good to update old-good stable 1.8.x to let it be a bit more stable ;-D.
P.P.S. As for no skin loaded - hadn't tracked down it yet, but looks like there are some bugs in locating PNG skins inside zip/pk3 archives in 1.8.6 - just the same files unpacked to a real file system (with symlinks added I mentioned earlier) works perfectly. Now I'm going to hunt for this bug, hope it wouldn't take longer than an hour.
Edit. Well, it was somewhat hard to find, but finally got it. The problematic file is skippy_sarge.md2 itselt. It has got MD2_PATH=/ metadata embeded, and skin filename embeded as /skippy_sarge.png instead of skippy_sarge.png. This leading slash is ok for filesystems full paths, but it is unacceptable inside ZIPs for deng 1.8.6 (maybe this also applies to 1.9.0-beta6.x).
IIRK, original Quake2 MD2 loader was acting in a such way:
1. First try to load skin file, specified inside MD2. If not found/unsuccessful - proceed to step 2.
2. Try to load any (first one found) <modelname>*.pcx within the same dir as model.
Looks like DoomsDay loader acts more strictly in that it only tries to load skin file specified in a model itself, but does it in a slightly different way:
1. Try to load <modeldir>/<name of the skin file from md2 with extension stripped>.png, on failure proceed to step 2.
2. Try to load <modeldir>/<name of the skin file from md2 with extension stripped>.tga, on failure proceed to step 3.
3. Try to load <modeldir>/<name of the skin file from md2 with extension stripped>.pcx.
So, as for skippy_sarge - correct solution would be to edit md2 to strip excess forward slash from skin file path.
Another way to solve it is to patch md2 loader engine to automatically fix such types of errors by stripping all leading forward slashes from skin files paths.
I've been tracking the DoomsDay project progress for a long time, IIRK - for more than five years, and I'm a bit disappointed with the state the project is now at.
There was no stable release for years, and I hadn't found any source for up to date roadmap for the 1.9.0 release series. Also, the documentation in the wiki is incomplete and partially outdated when it comes to the description of building and installing latest betas on the linux platform.
Additional resources collection is in chaos state: looks like that some new models and textures for jHexen, showed up on NewDoom forums were lost - i.e. there's no any place, where they can be fetched for download and play. Dengine.Net file hosting portal looks like a big trash can - there are a lot of good downloads in there, but they are not categorized and it is very hard even for experienced one to determine "what is what".
All above is no good, but, thanks to devteam, the project itself is still alive.
It gives volunteers a possibility to try their best and to bring things to a better state.
As for me, I've got several things to offer devteam help at:
1. Here in Moscow I've got two dedicated servers, and I can mirror downloads section of dengine on them. To do it I will need additional information from current Dengine.net filesection maintainer (what to mirror, how to mirror - rsync? SVN/WebDAV? dropbox? - when to mirror, e.t.c). Internet bandwidth for this servers isn't very fast - 50Mbit max (nowdays traffic is not so cheap as it used to be before), but it seems reasonable to me, that it's better to have several low-speed alive file servers, than the only fast one that had gone down for any reason.
2. Wiki stuff. Wiki instructions for building dengine are outdated. I can try to update them a bit, including Snowberry-related installation problems on non-deb linux systems, but my written English is far from perfect, so it be hardly needed/recommended to find someone willing to fix spelling and grammar errors in edits by me. Another thing that I'm able to do is to provide some Russian translations, either for snowberry and for wiki pages.
3. Linux-distros packaging stuff. I'm using Fedora Linux atm., and it's a pitty that there are no Fedora RPM packages for doomsday, even for stable 1.8.6 version of it. I can make some SRPM/RPM packages for fedora myself and provide the results to devteam, so it would be possible for Fedora gamers all over the world to simply yum install/rpm -ivh packages to give DoomsDay a try. In my opinion, separate packages must be provided for deng, snowberry and each and every snowberry addon out there. Also, it would be reasonable to provide official RPM specfile templates for addons packages, to ease life a bit for third parties willing to RPM-package their favorite hand-made snowberry addon.
So, the basic question is: are there any need in my help concerning any of the above three points? If yes, whom (and where) should I contact for additional information concerning implementation details for any task in question?
P.S. Last, but not least.
Recently I've been debugging deng 1.8.6 hand-built with gcc34 on my Fedora box. Initial problem was lack of skin for skippy-formersergeant legacy model (i.e. sergeants showed up in all white in game), that was re-released as a Snowberry Add-On.
To track it down I had decided to unpack PK3 contents and to place unpackaged files directly to deng basedir in appropriate locations. Unpacked model looked good (i.e. with normal skin) when opened in mm3d (Misfit Model 3d), so I went on to deng. I had placed skippy-formersergeant.ded to {deng_data}/Defs/jDoom/Auto/, and the rest model stuff to {deng_data}/Data/jDoom/models/monsters/formersergeant/*. Before launching deng I had checked that skippy-formersergeant.ded includes correct ModelPath:
...
ModelPath "Data/jDoom/models/monsters/formersergeant"
...
Result was surprising: totally invisible sergeants! It was obvious that *.md2 files for ded were not found for some strange reason, and no notion of it had shown on console.
Ok, looks like it's time to increase verbosity I thought.
Merely adding "-verbose -verbose" to command line leaded to a huge BOOM! - SIGSEGV and core dump for DoomsDay.
After some time spent with hacking source (I was too lazy to re-configure project with gcc -ggdb, so my decision was to simply add some debug printfs to see, where the SIGSEGV happens) I came to a fact that merely changing
// The -userdir option sets the working directory.
if(ArgCheckWith("-userdir", 1))
{
Dir_MakeDir(ArgNext(), &ddRuntimeDir);
userdir_ok = Dir_ChDir(&ddRuntimeDir);
}
to
// The -userdir option sets the working directory.
if(ArgCheckWith("-userdir", 1))
{
//Dir_MakeDir(ArgNext(), &ddRuntimeDir);
//userdir_ok = Dir_ChDir(&ddRuntimeDir);
}
in dd_main.c makes SIGSEGV go away. I wasn't interested in the real cause of this sugsegv at that moment, as I was tracking down another issue. It might be reasonable for devteam to check if this bug is still in place for 1.9.0-beta6.x.
Well, after all I had managed to increase verbosity, and to got some messages in console about md2 models not found. But there was no obvious reason for that, except for some bugs in deng with case sensitive filesystems handling. After about an hour of investigations (and huge debug-print additions to deng code) it became obvious that the initial guess that the problem was in engine filesystem paths case handling was right:
...
R_InitModels: Initializing MD2 models.
Search path: Data/jDoom/Models;;Data/jDoom/models/monsters/formersergeant
FH_AddDirectory: Adding data/jdoom/models.
FH_AddDirectory: Got unprocessed dirs, going to process.
FH_AddDirectory: Searching for: /misc/Raid0/Games/DoomsDay/share/deng/data/jdoom/models/*
F_ForAll: Starting search for /misc/Raid0/Games/DoomsDay/share/deng/data/jdoom/models/*
F_ForAllDescend: Starting up with /misc/Raid0/Games/DoomsDay/share/deng/data/jdoom/models/* spec.
F_ForAllDescend: Starting up with /misc/Raid0/Games/DoomsDay/share/deng/data/jdoom/models/monsters/* spec.
F_ForAllDescend: Starting up with /misc/Raid0/Games/DoomsDay/share/deng/data/jdoom/models/monsters/formersergeant/* spec.
...
As you can see, in spite that in search path directory with the model looks like "Data/jDoom/models/monsters/formersergeant", the deng filesystem hash-builder subsystem tries to add lowercase version of it to hash: "FH_AddDirectory: Adding data/jdoom/models.". Result is obvious: model files not found later on, as there is no real filesystem path "/misc/Raid0/Games/DoomsDay/share/deng/data/jdoom/models/monsters/formersergeant/*".
Just to be sure, I had created two symlinks:
# cd /misc/Raid0/Games/DoomsDay/share/deng/
# ln -s Data data
# cd Data
# ln -s jDoom jdoom
Thereafter deng managed to locate md2 files and I finally got a possibility to debug, why the hell legacy skippy-sergeant model was displayed without the skin in deng.
I think that it would be reasonable for devteam to check if the same filesystem paths case handling bugs are still in place for 1.9.0-beta6.x.
As for latest stable 1.8.6 - I can write a patch for it correcting this bug, but I'm not sure that it's needed. If the final 1.9.0 release is soon to be done, than it's better to wait a bit for it to come out. If not - I think that it would be good to update old-good stable 1.8.x to let it be a bit more stable ;-D.
P.P.S. As for no skin loaded - hadn't tracked down it yet, but looks like there are some bugs in locating PNG skins inside zip/pk3 archives in 1.8.6 - just the same files unpacked to a real file system (with symlinks added I mentioned earlier) works perfectly. Now I'm going to hunt for this bug, hope it wouldn't take longer than an hour.
Edit. Well, it was somewhat hard to find, but finally got it. The problematic file is skippy_sarge.md2 itselt. It has got MD2_PATH=/ metadata embeded, and skin filename embeded as /skippy_sarge.png instead of skippy_sarge.png. This leading slash is ok for filesystems full paths, but it is unacceptable inside ZIPs for deng 1.8.6 (maybe this also applies to 1.9.0-beta6.x).
IIRK, original Quake2 MD2 loader was acting in a such way:
1. First try to load skin file, specified inside MD2. If not found/unsuccessful - proceed to step 2.
2. Try to load any (first one found) <modelname>*.pcx within the same dir as model.
Looks like DoomsDay loader acts more strictly in that it only tries to load skin file specified in a model itself, but does it in a slightly different way:
1. Try to load <modeldir>/<name of the skin file from md2 with extension stripped>.png, on failure proceed to step 2.
2. Try to load <modeldir>/<name of the skin file from md2 with extension stripped>.tga, on failure proceed to step 3.
3. Try to load <modeldir>/<name of the skin file from md2 with extension stripped>.pcx.
So, as for skippy_sarge - correct solution would be to edit md2 to strip excess forward slash from skin file path.
Another way to solve it is to patch md2 loader engine to automatically fix such types of errors by stripping all leading forward slashes from skin files paths.
Comments
I was trying to attach it, but was told by forum engine that "The extension patch is not allowed.".
So here it is in "Code" block:
Brave one who knows how to build up deng from sources should also know how to use this patch, so I suppose no instructions are needed.
When it comes to a roadmap, there has been enough random fluctuation of the plans that I haven't bothered to keep much of them written up anywhere. I can say that the general plan is best described in the future release pages in the wiki. At the moment I see the 1.9 series as being BETAs through and through -- we're at a stage when the code has to evolve in order to stay alive much longer, and that means the next release that is given the Stable designation is 2.0.
Your offer for help is exemplary and appreciated. However, as far as the mirroring is concerned, I don't think we have a need for that right now. We would be glad to have help from the community in updating the wiki, though, so anything you can do there is much appreciated. Also, Linux packages are welcome as well. Personally I care only about .debs (being a casual Ubuntu-ist), maybe I'll get around to preparing official .debs myself at some point...
Feel free to email me (skyjake@dengine.net) and danij (danij@dengine.net) for any extra information you need.
For the record, I would like to state that my personal preference for the third-party addons/files management would be a CMS hosted here at dengine.net, so that addon authors would be able to submit their work directly to the site. I would imagine such a CMS would be superior to the Addons forums for addon releases and managing the community resources as a whole.
PS. When it comes to Snowberry, I'm currently thinking of getting rid of it. Just a heads up.
It is questionless that devteam is working on DoomsDay "just for fun", "to entertain themselves" (just like any other open-source hobbist project). But I seem to think that second main and ultimate goal for DoomsDay project should be good end-user experience. I mean that it would be great to have dozens of people all over the world playing in DoomsDay quite regularly. It would be great if DoomsDay will be "the most popular and user-friendly doom port ever". And one of the key points on the way to this goal is to always provide good and stable version of engine available for end-user to play with.
All the work that is going on in 1.9.x branch is priceless and by no doubts extremely needed for project to be alive (I had taken a look into both sources from SVN trunk and 1.8.6 - differences are HUGE!), but it would be unwise to stack only with development branch and totally ignore latest stable (IMHO, of course).
Well, then I'll try to make RPMs for Fedora in a near future. [offtopic]As for Ubuntu - it is very good "linux desktop" distro, I've got it installed on my girlfriends' notebook ;-D. Another cool Ubuntu derivate I had given a try is the Linux Mint distro. My choice for Fedora on home box was inspired by my work: almost all server boxes I had to administer drive under different versions of RHEL/CentOS, so it seems easier to me to administer home box using just the same skills I use to administer server boxes.[/offtopic]
Got it. Will give it a chance in a future.
Well, having addons hosted on deng site is a wise choice. But it would be even wiser if addons would also be available for download/install through yum and apt-get repositories. Just imagine how widespread DoomsDay may become if installing fully working copy of it would be just a matter of several clicks in Synaptic, Smart Package Manager or YumEx! And we've got all the required peaces for it. Freedoom WADs may serve as a good open source starter kit, shareware doom game files are also available out there (I had even seen them pre-packaged in RPM for Fedora on rpmfusion!).
I have always thought of having all the addons in at least a PPA for ubuntu. But unfortunately I don't know how to package things for synaptic or make .deb's
Also the new site will have separate links for each distro that we have packages for. you are more than welcome to package deng for fedora and I will link to your site/repo? or we might be able to get them hosted on sourceforge?
As for sourceforge - you should ask skyjake about it. What I'm able to do (and that is what I'm going to do) is to create SRPM spec file, build up RPMs for different Fedora versions, and then provide resulting (S)RPMs for download usind hosting on any of my servers. Yum repo is also possible.
As for sourceforge - you should ask skyjake about it. What I'm able to do (and that is what I'm going to do) is to create SRPM spec file, build up RPMs for different Fedora versions, and then provide resulting (S)RPMs for download usind hosting on any of my servers. Yum repo is also possible.[/quote] cool. I will link to your site on the new download page
Easy installation and maintenance for all users of the distribution.
Once upon a time, I found this cool little game called The Doomsday Engine. I thought it would be nice to package this for my operating system which was Debian. That version I foind was the 1.8.6 version. I Duely packaged it and started running into some of the same problems you have noticed. I tried making patches and sending the to Skyjake. Some were accepted, others were not. Eventually I asked to join the team to keep the *NIX port working.
Shortly after, I discovered the the *NIX port is a very poor cousin to the Windows and OSX ports. It became apparent that to fix long standing issues on *NIX some major changes were needed. It would result in some short term pain, but it was the 1.9.0.x development time and we could afford to make this change in 2006. Except apparently we could not. 1.9.0 release was "imminent" we could not make any major changes until after the release. I was repeatedly told by both skyjake and DaniJ not to make these changes (which if anyone is folowing svn can see - 4 years after I started proposing and preparing patches - skyjake is finally doing it. Thanks for the lack of acknowledgement). Instead I was relegated to fixing low hanging fruit.
Meanwhile on Windows, DaniJ continued making large scale changes to the engine, breaking the *NIX port, and Skyjake would make his large changes to to OSX port breaking the *NIX port. Apparently the 1.9.0 release was not "imminent" for them. Attempts to contact skyjake to clarify what was to be done with the engine proved fruitless.
I consulting several linux legal teams about the licenses of the doomsday code. It was not able to be distributed due to the licenses. It failed the Debian Free Software Guidelines test. At the time, it also was not eligible to be hosted on sourceforge due to a large amount of non-opensource code.
Because of the insistence I could not fix *NIX due to a release that still has not happened, I started a full license audit of the code base, and structured it so that at the very least the engine and jdoom could be distributed by linux distributions. At this point I discovered the lzss code was not DFSG free, and it was embedded in the engine. It was clear this would never be acceptable to a linux distribution that cared about licenses. Again I pushed to have fixes for *NIX included, and to replace code with non-gpl compatible licenses removed. The only concession to me was the removal of FMOD and replacement of it with sdlmixer.
Herein started a long saga that the windows maintainer still blames me for. See - sdlmixer worked perfectly on *NIX. On Windows it apparently did not - it was clear that on Windows the windows maintainer was using a prebuilt sdlmixer that did not have support for mp3 and didn't test before release. This led to a large amount of complaints and instead of fixing his build system (or letting the *NIX fixes in which would have commonised the build system on all 3 platforms) the windows maintainer decided to refactor the audio system to work around this.
I am no longer part of the team. I decided I had enough providing support for a project where I was told we can't fix your platform without being told why - the release was never "imminent". The Windows maintainer recently told me point blank they don't care about *NIX. I wish I was told that many years ago.
You can see this with things like the Windows specific Window management code, and the clear migration away from cross-platform code (the exact opposite of what I wanted to achieve).
Why am I telling you this - I don't think you should waste your time supporting Doomsday on *NIX. You won't be told any future plans - hell, even the Windows maintainer wasn't told about Skyjake recycling my patches for his new branch. *NIX support contains a lot of OSX specific hacks - you'll see them as you look at newer code. There is no interest in security support of the game, and it is still remotely exploitable.
Go find a Doom engine that genuinely cares about a *NIX port - not one that only pays lip service. They don't even try building it in a virtual machine - and you can't say it costs to much to try - it's simply they don't care. Their *NIX port is broken, they have no will or desire to fix it. It's like their attitude to 64bit systems - they pretend they don't exist unless someone like me bugs them. As nice as Doomsday is to play - it's Windows and OSX only. That is the truth of the matter.
Easiest example: imagine, that you want to install OpenOffice on your home box. If you're using windows - then you have first to fetch installation package somehow (either by bying CD/DVD with if from local store or downloading package from Openoffice.org site), then run this package with correct administrative permissions (in Vista, and - in some cases - in XP/2000), get accustomed with installer wizard (yeah, they tend nowdays to become more and more similar to each other for different software installers, but still differ) and finally install OpenOffice. In Ubuntu this would be as easy as running one standard utility - Synaptic package manager, selecting OpenOffice.org from the list of packages and clicking "install". The rest will be done automatically.
So, when it comes to DoomsDay, packaging DoomsDay packages inside distro-specific packages is required step to let end-users utilize this installation auto-magic on *nix systems.
As for now situation is as following: DoomsDay (either 1.8.6 and the latest 1.9.x branch) can be built on linux. And it works (more or less). This is the FACT.
In case of DoomsDay licensing status it is not the thing that bothers me much - devteam hadn't been sued by any third side for license issues, while they've been providing binaries for Windows for more than five years.
Me personally liked to play DoomsDay back to that times when I've been using Windows 2000, liked to play it on Windows XP, and nowdays I like to play DoomsDay on OSX and on my Fedora box.
And - as long as DoomsDay hadn't been broken by its windows maintainer to a state when it's impossible for it to work in linux - I think that it would be great to share cool play experience with other people out there using Fedora or Ubuntu. I'm not the GNU/FSF orthodox, I'm not R.S. fan, and I see no point in demands to devteam to "care about *nix port" and a to "care about license status". Come on, it is hobbyst project, it is their free time in each and every peace of code. It is some part of their life that they voluntarily decided to spend working on the project instead of going to a pub to have some beer. So it is up for them to drive a project in a way that is suitable for them.
As long as DoomsDay builds and works on linux - I will build it and play it. And I'm sure that I'm not the only one with such opinion.
When it will come to a state when it is not working anymore - I will take the latest working sources and use them as a base for a new fork.
Shinka is at http://shinka.bpa.nu Risen3D is done by Graham Jackson, Abbs, Hawkwind, and Sitters as far I can tell.
Shinka is done by myself. http://shinka.bpa.nu/roadmap is the current best place to get an idea as to the goals of my port.
And, to respond to your earlier statement about licensing issues, there should be none, otherwise it makes the devs look less credible, and harder to enforce the GPL should the code be misused. Additional constraints are that Sourceforge requires hosted code to be under an OSI-approved license, and if they ever want Doomsday included in, say, Ubuntu, they have their own requirements. Very stringent ones. So, it does matter.
I know - I went through this with both Debian and Ubuntu - in person as well as online. It is the lzss code that is the outstanding issue. There was (and still is) extreme reluctance to remove it.
The end-user experience is extremely important, I agree. (I switched to OS X and haven't looked back, which should tell you something.
It would make sense to set up an apt/yum repository on dengine.net, to facilitate addon distribution. If it could be automatically linked to an addon/community CMS, all the better.
I would opt for "/usr/share/deng/addons/". We could then also put other kinds of stuff under subdirectories of "/usr/share/deng/".
I may be now implementing some of your suggestions, but I wouldn't call it recycling your patches. I am doing what seems necessary and suitable -- the same thing I was doing back then.
And yes, I am making up the plan mostly as I go. That's in fact a big part of the motivation for me. I hope your fork will live long and prosper, as Doomsday has. Let it be a shining example for FOSS games. Myself, I just want to have some fun.
skyjake, DaniJ! Is that truth that the DoomsDay devteam is really going to drop *nix support?
I said that if it was my project then I would drop support for *nix because I have no interest in doing the support myself.
There are no plans to drop *nix support in Doomsday.
yeah yagisan also said that would be the right place to do it. so there it will be
I've always be very candid. I tell you when I think you are doing something stupid. I really don't know why you and Skyjake like to give so much false hope to *NIX users that you will support their platform when in fact you don't. The fact that it occasionally builds, is not support. This thread is full of false promises on the future of the *NIX port. I think it is very stupid of you and Skyjake to do this. I don't have a problem if you don't want to support *NIX, but at least be honest to the users and clearly state it. Stop giving them false hope that you care about Doomsday on the *NIX platform. I enjoy talking to you on technical (and other matters) but just because I like you and respect your opinion doesn't mean I won't blast you with both barrels when I think you are doing something wrong. In this case, I honestly believe you are wrong and are doing the users a huge disservice.
Indeed, you don't even notice breakage on *NIX unless someone like myself or KuriKai emails you to tell you it's broken.
You can't drop what doesn't exist. It builds (sometimes) is not support.
I would, but that one sentence is probably the biggest acknowledgement you given me on anything Doomsday related in a long long time. It's feels nice to know I was on the right path when you and danij kept shooting me down.
It's very hard to know what seems necessary and suitable when you never reply to people.
Making up the plan as you go wasn't the problem. It was never being told what the plan was. There are so many parts of Doomsday that are broken under *NIX that I've been tracking for 4 years that I kept getting told "don't touch that 1.9.0 will be out soon - you can't make that sort of change now". In hindsight it seems there was enough time - had that been communicated adequately I'd have been happier, and the *NIX port would be in much better shape then it is.
It works for me, on my platform, which makes me happy. I'm not so sure that Doomsday is prospering as to me it needs a lot of love, and a clear direction on where to go - and I don't think you or DaniJ have a clear direction right now. Your new order branch was quite a surprise to DaniJ, and makes much of his work in the last 6 months no longer relevant.
My fork will make no attempt to preserve classic doom AI. I have a request for classic doom ai, which I may try to emulate with my new AI system. If that floats your boat, great, if not, there are plenty of other ports.
They will be rather large posts, as I need to include the context.
I have removed a portion of the log where I complain about the Windows XP restore dvd that came with my eeepc not working. With full context, make up your own mind. I know what I see there is an acknowledgement that *NIX isn't supported.
Again to restate my case - I have no problem if they choose not to support *NIX. I have a problem with them giving false hope to *NIX users that their platform is supported.
It's got a shitload of bugs, it's even got bugs i contacted danij about a couple of years ago.
I Never used snowberry though, so I can't comment on that one.
Now, doomsday used to be my favourite DooM port, my Newdoom signature still "notifies" me of that. Simply because it was just about the only "decent", up to date linux port with good performance.
zdoom compiles, but performs terribly. ZdoomGL didn't even compile once, and GZDooM, the port i currently use constantly has breakage on linux. I try to fix what i'm able to fix and send patches back to graf,
but there sadly still are some showstopper bugs, altough in general it's performing a lot better than doomsday.
As Yagisan was saying : 1.9.0 was "imminent", so i decided i should wait and see what happens whenever 1.9.0 beta6 was released. In the meantime i used to checkout the SVN repos and see if it worked.
Most of the time it compiled and running, but as i said in the beginning of my post, it was riddled with bugs. For example the resolution bug i've mentioned about a couple of years ago.
A DooM engine which genuinely cares about *NIX? Which one would that be then?
even ZDooM has/had it's enormous flaws and performs like hell in *NIX, but at least it works.
Now, DaniJ/skyjake, please don't take my post as offensive, i still jdoom, i'm still waiting for the "enormous enhancements" skyjake promised etc. But i recon you guys don't have all too much time on your hands these days.
But one fix that i always wanted but never seemed to arrive was boom support. Is there any intention of supporting boom any time? What about UDMF?
I would also love to see jdoom back up to paste with the other ports, these interbuilds could help, but implementing features that were "promised" a couple years ago could help dramatically.
But iirc DaniJ was working on the renderer because a lot of the code was still written for something like the 3DFX Voodoo, am i correct?
edit: @DaniJ: only supporting linux doesn't mean that we'll have a small userbase. There are a lot of us out there who know that these ports exists, but either don't want to post, aren't able to code/program or just don't know where to get support outside of their distribution forums.
(I for one use gentoo, doomdsay was supported in portage, but now it's hardmasked + has a keyword, even though it's "up to date", (1.9.0 b6.2) because of a remote exploit bug-
https://bugs.gentoo.org/show_bug.cgi?id=190835 )
In practice, during the 1.9 betas, I'm expecting that Linux, being the platform that has no developer in the deng team using as the primary work environment, will continue to see less than stellar performance. I will be checking in on it every now and then, and it'll definitely be improving over time, but I can see it lagging behind the others a bit. Of course, when it comes time for an actual stable release, full attention and polish will have to be put on the Linux build as well.
No offense taken. Please just understand that any plans related to the project will have to be treated as "flexible".
If danij wants to go for it, maybe, but I couldn't care less about Boom myself, sorry.
What i mean to say was "I still like jdoom"*
Skyjake, what about UDMF then?
Why do you dislike boom? There are a lot of maps that are almost playable in jdoom but only require a few boom linedefs.
A zip of the source code is not support. Nor was butchering the internals with reimplemented hacks to work around brokenness on osx that don't work as they should on *NIX. I do not say Linux - I state *NIX for a reason.
Even when you had a developer that used it as a primary system it suffered - it was too hard to support something that needed big changes that you would either not be around for to discuss, or would veto as the release was "imminent". You could have communicated your intentions far better, but you did not. You still don't, and to be fair, fail at project management. Why even have other people working on doomsday if you can't be bothered to tell them what is going on.
Presumably that would include both build and run tests, on at least 32bit and 64bit builds right ?
I have a sudden flash of insight as to why Risen3d was created now.
I don't dislike Boom. I've just never used it and never played any Boom-specific maps -- it simply doesn't interest me.
Let's be clear about the *nix thing. I'm talking about 32-bit (x86) Linux (Ubuntu) support, and PowerPC/Intel OS X 10.4/10.5. It's not even feasible for me at this moment to try support the gazillion varietes of *nix out there. Nor do I really see the point of 64-bit builds. It can't be about the amount of memory so it must be about the performance: does anyone's 64-bit CPU really run Doomsday so slowly as a 32-bit build that it warrants a native 64-bit binary? (Seriously, someone tell me a good motivation for native 64-bit Doomsday builds.)
And by "*nix support" I mean "it runs as nicely as on the other platforms", not that "it follows the UNIX philosophy and fits in 100% perfectly into a UNIX environment in every aspect."
It's because the native ABI for some 64bit systems, amd64 included is 64bit. Why do I have to install a full 32bit compatibility library to support Doomsday - I did that, and had to support that for over 2 years while DaniJ and myself to be frank, fixed your code. On amd64 you do get a performance increase, on sparc64 and ppc64 you do not - it performs just them same as 32bit (some cases slower). If the code is so badly written, it can not run as written when built for 64bit mode there is a problem, PRO TIP = int != pointer, But hey - we do know your code is broken, and you sit on remote security exploits for such a long time, that people release working exploits for them. You don't really care about the honestly extremely minimal changes needed to target any *NIX out there - because they all follow the same standard - step one is remove your unneeded shims..
You fail hard at the "it runs as nicely as on the other platforms" bit, and have done so for a long time. That was the entire gist of my complaint. I don't know why you want to insist you support a platform you a) don't use, b) don't care about, c) don't understand, d) don't support.
Most *NIX users won't even bother to contact you to say there is a problem with Doomsday, they will just quietly change ports. I'm not quiet, I'm loud and irritating and I get attention. It is a shame that I can't suggest Doomsday as a good looking, working cross-platform port anymore, as it isn't - it has lost the one thing that mad it stand out from the other ports with graphical enhancements, and that is truly a shame, and a loss for the users.
DaniJ - if you ever want to talk about the logistics of fixing the cross-platform parts of Doomsday, and are willing to force the changes through, you know where to find me. Just poke me and I'm happy to help.
You're welcome to speak your mind, as far as I'm concerned. And I would say your assessment of my working style with deng in the recent years is quite accurate. The reason is very simple: I just don't care about Doomsday as much as I did in the beginning. I work on it when I feel like it's fun, and don't when it isn't. I hope everyone understands this. Does this make me a less than stellar leader? Sure.
Do I understand this correctly: this is an issue for developers (who compile the code) on a 64-bit Unix (Linux?) platforms. Assuming that a 32-bit build of Doomsday is packaged so that it depends on the requisite 32-bit support libraries it's not a problem for the end-user to install the package and have the dependencies pulled in automatically. Right? I'm just trying to assess how significant this issue is.
Our definitions for the word "support" are evidently different. Also, I've never claimed to be a Unix expert. I just want to be able to play Doomsday on *nix systems.
While this discussion is fun, and hopefully helps you and everyone understand better what's going on, I do think actions are more valuable than words. Anyone who wants to make a difference, submit a patch. Maybe they'll be used or maybe not; without them nothing happens until the "Eye of Sauron" of me or danij touches on the issue.
It is fairly significant. Taking Linux for example, there are two ways to support 64bit applications, both of which are "right" depending on the cpu architecture and your politics. The first is to do what Red Hat did for systems like amd64 that can run mixed 32bit and 64bit binaries, and supports installing both. The second is to do what Debian did and only install the native size, which is 64bit on amd64, and not ship compatibility libraries (some libraries are shipped in a hacked up ia32 libs package, but this is an exception and not well supported). It appears at a glance the BSD's do native size as well, and SnowLeopard is going 64bit as well.
Clearly!
I got burned last time - I can point you towards issues I see if you really want, but if I'm going to do that, I'd be wanting to see the issues addressed. I no longer want to write patches that get rejected out of hand because the release is "imminent", or that it caters to "the lowest common denominator and disadvantages windows users" and similar.
I've never programmed to 64bit cpus, but I thought the standart definition for 'int' was the size of the biggest register.
Well, that was true with a 16bit cpu I worked.
I also thought that a casting from a pointer to an int was always possible, as it was written in 'reiterpret_cast' definition.
That was exactly the pain in memory allocation on that 16bit. I had to use some extended memory allocation functions that returned a 'long' and that 'long' was basically used as the 'pointer' to access that extended memory through functions. Well, only 24 bits of that 'long' were used actualy