Future plans for DoomsDay Engine & some *nix-related bugs.

edited 2009 Jul 29 in General
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:
...
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.
«1

Comments

  • Here is quick'n'dirty patch for deng 1.8.6 which fixes md2 with bad embeded skins names on load.
    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:
    --- deng-1.8.6.orig/Src/r_model.c	2005-01-08 01:39:05.000000000 +0300
    +++ deng-1.8.6/Src/r_model.c	2009-06-26 06:30:07.000000000 +0400
    @@ -393,6 +407,7 @@
     	byte   *frames;
     	int     i, k, c;
     	int     axis&#91;3&#93; = { 0, 2, 1 };
    +	char    *cur;
     
     	// Read the header.
     	F_Read(&oldhd, sizeof(oldhd), file);
    @@ -459,8 +474,13 @@
     	// Load skins.
     	mdl-&gt;skins = calloc(sizeof(dmd_skin_t), inf-&gt;numSkins);
     	F_Seek(file, inf-&gt;offsetSkins, SEEK_SET);
    -	for(i = 0; i &lt; inf-&gt;numSkins; i++)
    +	for(i = 0; i &lt; inf-&gt;numSkins; i++) {
     		F_Read(mdl-&gt;skins&#91;i&#93;.name, 64, file);
    +		// Fix broken MD2 with leading forward and backslashes.
    +		cur = mdl-&gt;skins&#91;i&#93;.name;
    +		while((*cur == '/') || (*cur == '\\')) cur++;
    +		strcpy(mdl-&gt;skins&#91;i&#93;.name, cur);
    +	}
     }
     
     //===========================================================================
    

    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.
  • As to your assessment of the state of the project, I mostly agree. Currently things are a bit of a mess, but fortunately we (the deng team) are working on improving both the engine code and the dengine.net website as a whole. Such is life with hobby projects -- sometimes the motivation (and time) is there and sometimes it isn't.

    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.
  • skyjake wrote:
    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.
    Ok, it makes a point. And what about current 1.8.x so-called "stable" release? Maybe It would be wise to maintain it to the some extent. I.e. let's give it a "future-freeze", but try to fix most major bugs, so while 1.9.x BETA branch will be on it's way to the successful 2.0 STABLE release there will be available playable, maintained and working good DoomsDay branch 1.8.x STABLE.

    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).
    skyjake wrote:
    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...
    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]
    Feel free to email me (skyjake@dengine.net) and danij (danij@dengine.net) for any extra information you need.
    Got it. Will give it a chance in a future.
    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.
    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!).
  • 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.
    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?
  • KuriKai wrote:
    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
    I had had no experience with dpkg package creation also, but it seems to me that it shouldn't be much more different from making SRPMs. In a any case, prior to packaging any addons as DEBs or RPMs we must assure that there's some king of a standard for *nix systems concerning where to place addon files for deng to got them found automatically by Snowberry (or any other deng startup manager that might be out there to replace snowberry). Without such a standard it is impossible to tell where should packages place the addon files, and that means that making DEBs/RPMs of such kind will be worthless - they just would not "work just at once from a box" thus failing in their primary goal.
    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.
  • Perhaps I'm missing an important part of the argument given my complete lack of experience with *nix but what would be the point in packaging an addon? WAD, PK3/ZIP are already "packages".
  • LeXa2 wrote:
    KuriKai wrote:
    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
    I had had no experience with dpkg package creation also, but it seems to me that it shouldn't be much more different from making SRPMs. In a any case, prior to packaging any addons as DEBs or RPMs we must assure that there's some king of a standard for *nix systems concerning where to place addon files for deng to got them found automatically by Snowberry (or any other deng startup manager that might be out there to replace snowberry). Without such a standard it is impossible to tell where should packages place the addon files, and that means that making DEBs/RPMs of such kind will be worthless - they just would not "work just at once from a box" thus failing in their primary goal.
    Hm do you think the packages should be instelled into "/opt/deng" ?

    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.[/quote] cool. I will link to your site on the new download page
    DaniJ wrote:
    Perhaps I'm missing an important part of the argument given my complete lack of experience with *nix but what would be the point in packaging an addon? WAD, PK3/ZIP are already "packages".
    Easy installation and maintenance for all users of the distribution.
  • Let me relate my experiences to you.

    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.
  • DaniJ wrote:
    Perhaps I'm missing an important part of the argument given my complete lack of experience with *nix but what would be the point in packaging an addon? WAD, PK3/ZIP are already "packages".
    It's obvious that you hadn't ever used linux distros like Ubuntu. The most surprising thing that a newcomer from a windows world encounters in Ubuntu is the concept of "global software bank" - the repository. Installing any peace of a software is as easy as going to "Add/remove programs" (Synaptic package manager in case of Ubuntu), opening up global list of all software available for download and install, selecting the needed peace and clicking install. That's magical: all the task of downloading distribution and all of its dependencies, unpacking em, installing files at appropriate places and defining initial configuration settings gets handled automatically!

    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.
  • Yagisan wrote:
    Let me relate my experiences to you.
    ...
    Thanks for clarification. Well, all that you're talking about isn't new, and, unfortunately, often happens for hobbist projects. From your story I can conclude that the main problem was main development process got handled by windows-only-aware programmer, whose code wasn't well-suited for POSIX/GNU. Another problem was the project leader - skyjake - not caring much about *nix compliance. And you know, despite that it is bad for us - people living in a GNU world - it is totally normal for skyjake as a project leader to do it the way he did. As fas as I can remember, DoomsDay initially was a 'just for fun' project by skyjake for skyjake. Back on that time Windows was the main and only development platform skyjake had been using. Later on skyjake moved to Apple world, and partially retired himself from head development of deng. So there are huge historical reasons for DoomsDay engine to be windows-oriented, with some quick and dirty hacks to let it work reasonably on OSX.

    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.
  • LeXa2 wrote:
    Yagisan wrote:
    Let me relate my experiences to you.
    ...
    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.
    You'd have the 3rd fork in that case. Branch around 1.9.0beta6.2.
  • Yagisan wrote:
    You'd have the 3rd fork in that case. Branch around 1.9.0beta6.2.
    Yeah? So there are two forks out there already? Where are their homepages? Who is their maintainer? It'd be wiser to help in development of already established fork than creating another one.
  • LeXa2 wrote:
    Yagisan wrote:
    You'd have the 3rd fork in that case. Branch around 1.9.0beta6.2.
    Yeah?
    Yes.
    LeXa2 wrote:
    So there are two forks out there already?
    Indeed.
    LeXa2 wrote:
    Where are their homepages?
    Risen3D is at http://risen3d.drdteam.org/
    Shinka is at http://shinka.bpa.nu
    LeXa2 wrote:
    Who is their maintainer? It'd be wiser to help in development of already established fork than creating another one.
    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.
  • Doomsday does in fact, build, and play under my Debian-based setup, even built for x86_64. But I get the occasional problem that doesn't exist on other platforms. So, I grab a copy now and again to see how it progresses, but that's about all.

    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. :)
  • g6672D wrote:
    Doomsday does in fact, build, and play under my Debian-based setup, even built for x86_64. But I get the occasional problem that doesn't exist on other platforms. So, I grab a copy now and again to see how it progresses, but that's about all.
    It is my understanding that the save game code is (still) broken under amd64. It also seems to miscompile with Intel compilers. I didn't build any version past 1.9.0beta6.2 with Sun Studio - that didn't build, although I think DaniJ may have fixed that, I stopped sending build logs into DaniJ after I was told that *NIX is not supported and they would like to drop it (yes - I have the logs).
    g6672D wrote:
    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.
  • LeXa2 wrote:
    And what about current 1.8.x so-called "stable" release? Maybe It would be wise to maintain it to the some extent. I.e. let's give it a "future-freeze", but try to fix most major bugs, so while 1.9.x BETA branch will be on it's way to the successful 2.0 STABLE release there will be available playable, maintained and working good DoomsDay branch 1.8.x STABLE.
    I would absolutely like to see some refinement in the 1.8 series. However, myself I have zero motivation to work on that. Someone else needs to step up for anything to happen for 1.8.
    LeXa2 wrote:
    that second main and ultimate goal for DoomsDay project should be good end-user experience
    The end-user experience is extremely important, I agree. (I switched to OS X and haven't looked back, which should tell you something. ;) )
    LeXa2 wrote:
    But it would be even wiser if addons would also be available for download/install through yum and apt-get repositories.
    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.
    KuriKai wrote:
    Hm do you think the packages should be instelled into "/opt/deng" ?
    I would opt for "/usr/share/deng/addons/". We could then also put other kinds of stuff under subdirectories of "/usr/share/deng/".
    Yagisan wrote:
    Let me relate my experiences to you.
    ... Skyjake recycling my patches for his new branch ...
    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.
  • Yagisan wrote:
    I stopped sending build logs into DaniJ after I was told that *NIX is not supported and they would like to drop it (yes - I have the logs).
    Would you be so kind and post this logs here? In case this is the real position of doomsday devteam - well, looks like that soon it'll be time to move on from DoomsDay. Possibly, in the direction of your fork.

    skyjake, DaniJ! Is that truth that the DoomsDay devteam is really going to drop *nix support?
  • Yagisan, I'm becoming increasingly tired of you taking things I say over IM completely out of context. I'm beginning to wonder whether I am mistaken in my belief that we can continue useful, open and candid discussion on deng-related matters.

    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.
  • DaniJ wrote:
    There are no plans to drop *nix support in Doomsday.
    Thanks for clarification.
  • skyjake wrote:
    LeXa2 wrote:
    But it would be even wiser if addons would also be available for download/install through yum and apt-get repositories.
    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.
    That sounds like a good idea.
    skyjake wrote:
    KuriKai wrote:
    Hm do you think the packages should be instelled into "/opt/deng" ?
    I would opt for "/usr/share/deng/addons/". We could then also put other kinds of stuff under subdirectories of "/usr/share/deng/".
    yeah yagisan also said that would be the right place to do it. so there it will be
  • DaniJ wrote:
    Yagisan, I'm becoming increasingly tired of you taking things I say over IM completely out of context.
    I do not believe I have taken the logs out of context. I went over multiple days of logs to double check before I made my assertions.
    DaniJ wrote:
    I'm beginning to wonder whether I am mistaken in my belief that we can continue useful, open and candid discussion on deng-related matters.
    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.
    DaniJ wrote:
    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.
    Indeed, you don't even notice breakage on *NIX unless someone like myself or KuriKai emails you to tell you it's broken.
    DaniJ wrote:
    There are no plans to drop *nix support in Doomsday.
    You can't drop what doesn't exist. It builds (sometimes) is not support.
    skyjake wrote:
    I may be now implementing some of your suggestions, but I wouldn't call it recycling your patches.
    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.
    skyjake wrote:
    I am doing what seems necessary and suitable -- the same thing I was doing back then.
    It's very hard to know what seems necessary and suitable when you never reply to people.
    skyjake wrote:
    And yes, I am making up the plan mostly as I go. That's in fact a big part of the motivation for me.
    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.
    skyjake wrote:
    I hope your fork will live long and prosper, as Doomsday has.
    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.
    LeXa2 wrote:
    In case this is the real position of doomsday devteam - well, looks like that soon it'll be time to move on from DoomsDay. Possibly, in the direction of your fork.
    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.
    LeXa2 wrote:
    Would you be so kind and post this logs here?
    They will be rather large posts, as I need to include the context.
    (21:53:05) DaniJ: hey
    (21:53:12) hentaiyagi: G'day
    (21:53:24) DaniJ: so, 32bit builds on a 64bit debian os are pain to accomplish?
    (21:54:17) hentaiyagi: cleanest way is a chroot
    (21:54:24) hentaiyagi: debian based are pure64
    (21:54:32) hentaiyagi: fedora based are mixed 32/64 bit
    (21:54:39) DaniJ: hmm
    (21:54:40) hentaiyagi: brb
    (21:55:00) DaniJ: that would explain the influx of linux issues recently
    (21:55:02) hentaiyagi: there are pros and cons to both approaches
    (21:55:16) hentaiyagi: I do prefer the debian way
    (21:55:27) hentaiyagi: as sometimes on systems like fedora
    (21:55:44) hentaiyagi: it tries to link 64bit and 32bit libraries into the same file
    (21:56:01) hentaiyagi: solaris is a 32bit userland, with a 64bit kernel
    (21:56:09) hentaiyagi: which linux issues ?
    (21:56:31) DaniJ: various odd issues that seem to stem from the save game loader
    (21:56:55) hentaiyagi: well yes - not 64bit clean
    (21:57:01) DaniJ: which is pretty much the only system with 64bit issues remaing
    (21:57:38) DaniJ: the report I have is "save games don't work under linux"
    (21:58:16) DaniJ: so I want to try and better define the problem by getting confirmation on whether the issue is limited to 64bit builds
    (21:58:45) hentaiyagi: hmm
    (21:59:02) hentaiyagi: I haven't ever tried save games under *nix
    (21:59:12) hentaiyagi: rather redundant with warp and give commands
    (21:59:45) hentaiyagi: I do know that path mapping is broken with regards to /home/<user name>/.deng after skyjake fiddled with the code
    (21:59:53) DaniJ: heh
    (22:00:06) hentaiyagi: so eg addon paths there try to get loaded in all games
    (22:00:07) DaniJ: can you email skyjake about that please
    (22:00:27) DaniJ: or better yet, just post a report
    (22:02:00) ***hentaiyagi presumes you saw my analysis of some of your ati troubles
    (22:02:14) DaniJ: yeah I did
    (22:02:23) DaniJ: I've known about those issues for a while now
    (22:02:46) hentaiyagi: I know - but flipping the logic branch would make them more likely to appear
    (22:02:59) DaniJ: I haven't touched them because I have plans to rewrite that whole logic chain soon
    (22:03:07) ***hentaiyagi knows
    (22:03:11) hentaiyagi: I think I mentioned that
    (22:03:45) DaniJ: but still, I don't that is related to the problem with the mid textures
    (22:03:59) DaniJ: which is a fairly recent problem
    I have removed a portion of the log where I complain about the Windows XP restore dvd that came with my eeepc not working.
    (22:16:26) hentaiyagi: spent the day working out how portable the codebase is
    (22:16:47) hentaiyagi: answer - not very.
    (22:16:58) DaniJ: looks pretty portable to me
    (22:17:27) DaniJ: windows, OSX, various strains of nix, BSD...
    (22:17:38) hentaiyagi: it's expecting windows semantics on the *NIXS
    (22:17:40) hentaiyagi: oh
    (22:17:51) hentaiyagi: it failed on almost every non-linux I tried
    (22:18:28) DaniJ: not sure I know what you mean by expecting windows semantics
    (22:18:51) hentaiyagi: for example look at the file routines
    (22:19:13) DaniJ: whats the problem?
    (22:20:03) hentaiyagi: it's a thin reimplementation of windows system headers
    (22:20:49) DaniJ: the only windows semantic I can see is the drive letter stuff and that is ignored on other platforms
    (22:21:57) DaniJ: as I've said before, my knowledge of any non-microsoft os is near zero, so you'll have to spell it out for me
    (22:24:15) hentaiyagi: I see a lack of error handling with it - an assumption that like on windows you can actually access the files - which isn't true on posix systems
    (22:24:34) hentaiyagi: just because the file may exist - doesn't mean you can read it
    (22:25:10) hentaiyagi: I have concerns over thee mixed unix/osx stuff
    (22:25:53) hentaiyagi: I wonder why every other posix system needs to reimplement system libraries that may have beeen broken on some version of osx
    (22:26:27) DaniJ: ok so other than a lack read/write checking any other problems?
    (22:26:37) ***DaniJ adds to todo list
    (22:27:24) DaniJ: why isn't skyjake picking up on this stuff? I assume its the same under osx(?)
    (22:28:04) hentaiyagi: I don't know why skyjake doesn't pick up this
    (22:28:21) hentaiyagi: a lot of it starts appearing as the osx port appears in svn hisstory
    (22:28:34) DaniJ: and if the home handling is broken then *surely* that will affect osc
    (22:28:40) DaniJ: osx
    (22:28:41) hentaiyagi: there is the broken path handling
    (22:28:59) hentaiyagi: well - he special cased osx issues
    (22:29:09) DaniJ: ah ok
    (22:29:19) hentaiyagi: at the expense of the generic routines
    (22:29:39) hentaiyagi: which he shouldn't have - but as his comments state - he is a lazy coder
    (22:29:59) hentaiyagi: otoh - you guys aren't that keen on a *nix port that you won't use
    (22:30:28) DaniJ: the problem is that neither of us really care much about the *nix platforms in general
    (22:30:29) hentaiyagi: it interferes with your plans about the editing system for starters
    (22:30:39) hentaiyagi: yes - the code shows that
    (22:30:54) hentaiyagi: easiest thing is to be upfront and state it
    (22:31:05) DaniJ: I thought I did
    (22:31:23) hentaiyagi: no - the project as a whole
    (22:31:29) DaniJ: however skyjake says he has taken over the nix support but clearly, thats not happening
    (22:31:46) hentaiyagi: no mate - I think he builds it less that I do
    (22:31:51) hentaiyagi: and to be honest mate
    (22:32:05) hentaiyagi: his track record of looking at things I've sent him
    (22:32:11) hentaiyagi: it's piss poor
    (22:32:32) hentaiyagi: even those with attached patches :/
    (22:32:40) DaniJ: I'm also somewhat concerned about what I've seen commited to the new-order branch
    (22:32:54) DaniJ: it currently assumes SDL at a fundamental level
    (22:33:21) DaniJ: something which I am absolutely not happy to live with
    (01:35:03) ***hentaiyagi waves
    (01:35:25) DaniJ: hey
    (01:35:40) ***hentaiyagi has been pwning headers
    (01:36:07) ***hentaiyagi removed *one* include
    (01:36:17) hentaiyagi: the cascade of changes so far is:
    (01:37:00) hentaiyagi: # modified: engine/portable/include/con_decl.h
    # modified: engine/portable/include/dd_wad.h
    # modified: engine/portable/include/gl_defer.h
    # modified: engine/portable/include/gl_pcx.h
    # modified: engine/portable/include/p_players.h
    # modified: engine/portable/include/r_main.h
    # modified: engine/portable/include/rend_halo.h
    # modified: engine/portable/include/ui_main.h
    # modified: engine/portable/src/con_busy.c
    # modified: engine/portable/src/con_config.c
    # modified: engine/portable/src/con_data.c
    # modified: engine/portable/src/dd_loop.c
    # modified: engine/portable/src/dd_main.c
    # modified: engine/portable/src/dd_wad.c
    # modified: engine/portable/src/gl_main.c
    # modified: engine/portable/src/gl_pcx.c
    # modified: engine/portable/src/m_args.c
    # modified: engine/portable/src/net_buf.c
    # modified: engine/portable/src/net_main.c
    # modified: engine/portable/src/rend_console.c
    # modified: engine/portable/src/sys_timer.c
    # modified: engine/portable/src/ui_panel.c
    # modified: engine/unix/src/sys_audiod_loader.c
    (01:37:06) hentaiyagi: >.>
    (01:37:54) hentaiyagi: *one* #include "a_header.h" did all that
    (01:38:22) DaniJ: understandable really
    (01:39:02) DaniJ: most all headers are included in every source file as a side effect of including de_base, de_platform, de_system etc
    (01:39:22) hentaiyagi: the de_* files no longer exist.
    (01:39:44) hentaiyagi: there are still some deeply chained dependincies
    (01:39:56) hentaiyagi: it's both awesome, and scary at the same time
    (01:40:31) DaniJ: to be honest I really don't think the problem is anywhere near as bad as you seem to think it is
    (01:41:36) DaniJ: the vast majority of dependencies are trivial ones for type definitions or some other such minor reason (which was only done to improve maintainability)
    (01:42:16) DaniJ: further, they were doing more than just convenience imo
    (01:43:01) DaniJ: they set up logical sub system divisions (even if the systems themselves were not entirely self contained yet)
    (01:44:58) hentaiyagi: that's not what I see
    (01:45:49) hentaiyagi: I see a truckload of sloppy include use (especially with skyjakes code) that depends on includes, including further includes
    (01:46:20) DaniJ: the main issue is the map data
    (01:47:04) DaniJ: because we are still in the process of shifting everything around, where p_mapdata.h is included creates a cyclic dependency problem
    (01:48:02) hentaiyagi: that hasn't been much of an issue really
    (01:48:05) DaniJ: I'd just about finished removing the outward dependencies in that file but then focus shifted
    (01:48:23) DaniJ: we of course not, now that you've removed the de_* headers...
    (01:48:28) DaniJ: we/well
    (01:49:00) DaniJ: the other semi issue is the way SDL has been shoe horned in
    (01:49:47) DaniJ: the header hierarchy depended upon some logical divisions possible under windows but not with SDL
    (01:50:16) DaniJ: the arrangement of the source files should have been changed imo
    (01:51:46) ***hentaiyagi removed #include "con_main.h" from con_decl.h tonight for that big pile of header mess.
    (01:52:38) DaniJ: if it was me, I'd simply remove ALL #includes and then build back up
    (01:53:19) DaniJ: at least in the engine there is no order dependent stuff like macros rewriting stuff
    (01:53:26) hentaiyagi: try it. You'll stop after a few days when you realise how intertwined they are.
    (01:53:41) hentaiyagi: it's easier to pull them out one by one
    (01:53:51) DaniJ: maybe
    (01:54:07) DaniJ: but you'll end up with zero division between subsystems
    (01:54:09) hentaiyagi: you even have files that depend on defines declared with 2 levels of indirection
    (01:54:43) DaniJ: yes but thats not a problem because they are constant (never replaced)
    (01:54:59) ***hentaiyagi is of the opinion if you use it - you include the header directly.
    (01:55:45) DaniJ: that is all well and good in a small program
    (01:55:55) DaniJ: or when playing in C++
    (01:56:18) hentaiyagi: it's all well and good in a maintainable program.
    (01:56:43) DaniJ: how is Doomsday not easily maintainable?
    (01:57:08) DaniJ: thats the whole point in the convenience headers...
    (01:57:11) hentaiyagi: why do changes on one area affect other apparently unrelated parts ?
    (01:57:24) DaniJ: they don't unless they use it
    (01:57:38) DaniJ: just including a file makes no difference if nothing in it is used
    (01:57:48) DaniJ: the only difference is compile time
    (01:58:32) DaniJ: because we are careful not to macro waterfall or other such things we can work like that
    (01:59:26) hentaiyagi: you include includes that include further include, that include the functionality you actually use. It makes a difference.
    (01:59:38) DaniJ: in what way?
    (01:59:44) hentaiyagi: You can't easily see what your changes will affect
    (01:59:55) DaniJ: but you know what it will affect
    (02:00:50) DaniJ: what was the point in doxygenating if you don't use it?
    (02:01:30) hentaiyagi: I do use it. Have you looked at the output from it recently ?
    (02:01:42) DaniJ: no in all honesty
    (02:01:51) hentaiyagi: have a look.
    (02:02:01) DaniJ: I haven't even rebuilt it recently
    (02:03:23) hentaiyagi: it shows up interesting issues with the multiple levels of indirection, your (doomsdays) shadowing of variables,
    (02:03:38) DaniJ: thats only a problem under nix
    (02:04:10) hentaiyagi: you still offically support *nix
    (02:04:19) hentaiyagi: so it's a problem you should be aware of
    (02:04:22) hentaiyagi: and fix
    (02:04:57) DaniJ: I know. That wasn't the point I was making.
    (02:05:18) DaniJ: but how am I to know about those issues and fix them on an entirely different platform?
    (02:05:28) hentaiyagi: you don't have to agree with me that the headers in their current form seem broken
    (02:05:34) hentaiyagi: you sound like GZ
    (02:05:34) DaniJ: they are
    (02:05:46) DaniJ: just not to the extent at which you make out
    (02:05:56) hentaiyagi: to which I'd reply - so don't claim support for platforms you don't run
    (02:06:37) DaniJ: personally, my idea of linux support is releasing the source
    (02:06:52) DaniJ: I have no idea about the platform
    (02:07:06) hentaiyagi: releasing source is not support
    (02:07:24) hentaiyagi: you can drop a source .zip and say knock yourself out
    (02:07:32) hentaiyagi: it's not supporting linux
    (02:07:52) DaniJ: yes I know
    (02:07:59) DaniJ: again, not the point I was making
    (02:08:38) DaniJ: if it were my project I would official abandon *nix support
    (02:09:10) hentaiyagi: do it
    (02:09:14) DaniJ: I personally believe that you can't support a platform which non of the developers use
    (02:09:46) hentaiyagi: # modified: engine/unix/src/sys_audiod_loader.c
    (02:09:54) hentaiyagi: the problem with that ^^
    (02:10:42) hentaiyagi: it depended on a chain of includes going all the way back to dd_share.h for a define that redfines a windows function name, to the correct name on linux
    (02:11:21) DaniJ: like I said, the move to support nix in the first place was botched
    (02:12:02) DaniJ: the whole system layer should have been redesigned but instead, deep hooks were added all over the place
    (02:12:31) DaniJ: from my pov as the windows platform dev, the layout is well structured
    (02:12:56) DaniJ: but from your pov on *nix... I can appreciate that it might *look* worse than it is
    (02:13:05) hentaiyagi: on *nix
    (02:13:06) hentaiyagi: ha
    (02:13:18) hentaiyagi: I have a roadmap here
    (02:13:26) hentaiyagi: it says drop osx/win32
    (02:13:30) hentaiyagi: fix *nix
    (02:13:42) hentaiyagi: then port to whatever I have also running
    (02:13:51) hentaiyagi: *nix looks really fucking bad
    (02:13:57) DaniJ: sorry but that sounds to me like:
    (02:14:09) hentaiyagi: looks a bit better without the osx specfic hooks
    (02:14:11) DaniJ: * reduce functionality to the lowest common denominator
    (02:14:19) hentaiyagi: probally does
    (02:14:59) DaniJ: which in our case, would mean a userbase mostly comprised of very unhappy windows users
    (02:15:26) DaniJ: they are already pissed off about the whole sdl_mixer thing...
    (02:15:43) hentaiyagi: sdl_mixer isn't my fuck up
    (02:15:50) hentaiyagi: it WORKS with mp3 and ogg
    (02:15:58) DaniJ: what about sfx?
    (02:16:05) hentaiyagi: if your supplied lib was built without support - not my fault
    (02:16:17) DaniJ: music volume resets every time it loops
    (02:16:29) DaniJ: sfx distance attentuation is broken
    (02:16:38) DaniJ: mp3 support only worked after I fixed it
    (02:16:40) hentaiyagi: you can pull fmod back
    (02:16:50) hentaiyagi: mp3 support worked before the :fix"
    (02:17:14) DaniJ: maybe on your platform but I don't know how it ever worked to be blunt
    (02:17:17) hentaiyagi: it worked *if* the sdl lib was built with mp3 support
    (02:18:31) DaniJ: removing FMOD to replace with sdl_mixer was a fine idea in principal
    (02:18:33) hentaiyagi: are you trying to compete with gzdoom ? it feels likeit.
    (02:18:39) DaniJ: eh?
    (02:18:45) hentaiyagi: pull fmod back from the svn archive
    (02:18:52) DaniJ: its too late
    (02:19:00) DaniJ: far too much has changed since then
    (02:19:03) hentaiyagi: a lot of your windows stuff is like gzdoom
    (02:19:09) hentaiyagi: it's not too late
    (02:19:14) DaniJ: of course it is
    (02:19:33) DaniJ: I've nearly rewritten most of the audio driver abstraction layer
    (02:19:57) DaniJ: which I had to do to fix the problems with sdl_mixer and MIDI
    (02:20:04) hentaiyagi: well - you claim sdl_mixer doesn't work - you claim fmod does
    (02:20:13) DaniJ: yep
    (02:20:23) DaniJ: sdl_mixer sounds terrible
    (02:20:23) hentaiyagi: so - change it
    (02:20:31) DaniJ: I don't need to
    (02:20:40) DaniJ: under windows we have direct sound
    (02:21:00) DaniJ: so I get full 5.1 audio, eax etc etc
    (02:21:09) hentaiyagi: then what is the point about windows users complaining ?
    (02:21:48) DaniJ: because until very recently audio was broken beyond all recognition under windows
    (02:22:11) DaniJ: basically since fmod was removed and replaced with sdl_mixer
    (02:22:53) hentaiyagi: and you could have pulled fmod back once you stopped supporting *nix
    (02:23:32) hentaiyagi: because - really - doomsday hasn't supported *nix in a long time
    (02:23:33) DaniJ: I wanted to use sdl_mixer as the lowest common
    (02:23:48) hentaiyagi: you don't like lowest common - you made that very clear
    (02:24:16) DaniJ: provided that we can do better on each platform as an override
    (02:25:25) DaniJ: what happened is that we moved sdl_mixer into the engine thinking "its a common standard and has already been implemented as a Doomsday plugin; it will work for everyone"
    (02:25:55) DaniJ: upon moving it into the engine I found that it simply didn't work correctly
    (02:28:08) DaniJ: so, where I was thinking that although windows would have to give up use of the other platform specific audio plugins for a while but it was OK because we had sdl_mixer we in fact ended up with no mp3, broken MIDI, no surround sound, no eax, broken distance attenuation, broken channel selection and more
    (02:31:12) DaniJ: so, look at that situation from the (common) pov of a windows Doomsday user
    (02:31:55) DaniJ: "we lost all that for license reasons!?WTF!!!?"
    (02:34:30) DaniJ: I understand why you had problems implementing it as plugin
    (02:35:50) DaniJ: when I sat down to fix the problems I believe I ran into many of the problems you were trying to overcome but in order to resolve them the "Right Way" it meant redesigning the audio plugin interface
    (02:36:31) DaniJ: most of that work has now been completed, it just remains to implement support for use of multiple plugins at once
    (02:45:12) DaniJ: thinking about it, I'm guessing that this probably has a lot to do with skyjake wanting to go back to fmod
    (02:46:38) DaniJ: I intend to keep sdl_mixer as the lowest common but it will mean a lot of work to support both cleanly
    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.
  • As much as i hate to say it, the *NIX port is "working", but that's about all you can say about it.
    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.
    Yagisan wrote:
    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.

    A DooM engine which genuinely cares about *NIX? Which one would that be then? :p
    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 )
  • LeXa2 wrote:
    skyjake, DaniJ! Is that truth that the DoomsDay devteam is really going to drop *nix support?
    Given that the OS X build is 99% equal to having "standard" Unix support, it wouldn't make much sense to drop it now would it? Doomsday will continue to have support for Windows, OS X, and Linux builds.

    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.
    GuntherDW wrote:
    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.
    No offense taken. Please just understand that any plans related to the project will have to be treated as "flexible". :) As in, should they remain underchanged long enough to be implemented, it may take anything from a couple of weeks to a few years. There's plenty of higher priority matters in the lives of the team members.
    GuntherDW wrote:
    Is there any intention of supporting boom any time?
    If danij wants to go for it, maybe, but I couldn't care less about Boom myself, sorry.
  • i meant to edit but since you've already quoted it i'll say it in another post

    What i mean to say was "I still like jdoom"* :)

    Skyjake, what about UDMF then? :p
    Why do you dislike boom? There are a lot of maps that are almost playable in jdoom but only require a few boom linedefs.
  • GuntherDW wrote:
    Skyjake, what about UDMF then? :p
    DaniJ is on the record over at doomworld as saying he won't support it at this stage. I'd agree with him right now as it appears to focus on gzdoom and eternity, and the lack of maps in the wild would make it a low priority.
    skyjake wrote:
    Given that the OS X build is 99% equal to having "standard" Unix support, it wouldn't make much sense to drop it now would it? Doomsday will continue to have support for Windows, OS X, and Linux builds.
    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.
    skyjake wrote:
    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.
    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.
    skyjake wrote:
    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.
    Presumably that would include both build and run tests, on at least 32bit and 64bit builds right ?
    skyjake wrote:
    If danij wants to go for it, maybe, but I couldn't care less about Boom myself, sorry.
    I have a sudden flash of insight as to why Risen3d was created now.
  • GuntherDW wrote:
    Skyjake, what about UDMF then? :p
    From the looks of the spec it seems doable. However, there's a huge list of more important things to do, so I wouldn't expect it added any time soon. (A.k.a., "standard RFE reply #3" ;))
    GuntherDW wrote:
    Why do you dislike boom? There are a lot of maps that are almost playable in jdoom but only require a few boom linedefs.
    I don't dislike Boom. I've just never used it and never played any Boom-specific maps -- it simply doesn't interest me.
    Yagisan wrote:
    (... opinions about Doomsday and skyjake sucking so bad ...)
    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."
  • Yagisan wrote:
    (... opinions about Doomsday and skyjake sucking so bad ...)
    If I thought Doomsday sucked so bad, I wouldn't push so hard for problems to be addressed. Doomsday had a lot of potential, it was the only cross platform port that looked good and played with classic and not zdoom style gameplay. User experience is important, as you yourself say - that's why you use OSX. Well, the user experience of Doomsday is that it works well on Windows, OK on OSX, and is piss poor on *NIX. If your response is to stick you head in the sand and pretend it doesn't happen, then fine - why would the users waste time on Doomsday. Do I think you suck ? no. I do think however, you are unreliable, are unable to do what you say, and give false expectations to people. I think DaniJ deserves some sort of an award for being able to work out what to implement based on your lack of leadership. You might be the project leader, but DaniJ is the guy to go to to fix problems in Doomsday - he does what he says he will do, and the community knows that. I would like to think that the community also thinks that when I open my mouth, I often have a good point behind it, even if I am abrasive and prone to telling you exactly what I think.
    skyjake wrote:
    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.)
    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..
    skyjake wrote:
    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."
    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.
  • Yagisan wrote:
    the user experience of Doomsday is that it works well on Windows, OK on OSX, and is piss poor on *NIX. If your response is to stick you head in the sand and pretend it doesn't happen, then fine. (...) 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.
    That is not my response. I agree that you describe there accurately the current situation, which I why I said in the beginning of this thread that the current situation is a bit of a mess.
    Yagisan wrote:
    I do think however, you are unreliable, are unable to do what you say, and give false expectations to people. (...) I would like to think that the community also thinks that when I open my mouth, I often have a good point behind it, even if I am abrasive and prone to telling you exactly what I think.
    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.
    Yagisan wrote:
    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
    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.
    Yagisan wrote:
    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.
    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.
  • skyjake wrote:
    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.
    Understandable - although as you can see, some of us have become quite jaded by the experience.
    skyjake wrote:
    Yagisan wrote:
    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
    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.
    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.
    skyjake wrote:
    Yagisan wrote:
    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.
    Our definitions for the word "support" are evidently different.
    Clearly!
    skyjake wrote:
    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.
    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.
  • Yagisan wrote:
    PRO TIP = int != pointer

    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.
    reinterpret_cast< T > (arg)

    Description

    In the statement, reinterpret_cast< T > (arg), T must be a pointer, reference, arithmetic type, pointer to function, or pointer to member.

    A pointer can be explicitly converted to an integral type.

    An integral arg can be converted to a pointer. Converting a pointer to an integral type and back to the same pointer type results in the original value.

    A yet undefined class can be used in a pointer or reference conversion.

    A pointer to a function can be explicitly converted to a pointer to an object type provided the object pointer type has enough bits to hold the function pointer. A pointer to an object type can be explicitly converted to a pointer to a function only if the function pointer type is large enough to hold the object pointer.

    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 :).
Sign In or Register to comment.