RISEN3D SOURCE

At the outset Risen3D was developed under the original iD license as this was the one that prevailed at the start of development. Following issues surrounding its validity the author decided to pull the plug. This was done, however, following a misunderstanding within the Risen3D team which led to yet more problems. On realising this the author attempted to resurrect the source but could only do so with a slightly earlier development build.

The author has now managed to update this build to incorporate the functions that were present in the build 60/61 bins. In order to try to satisfy everyone the source has been changed by the author to allow its release under the GPL. The author lost most of his changelogs when the plug was pulled and, given the thousands of changes that were made, it has not been possible to annotate them. In many ways the author feels that Risen3D has diverged to an extent that would have made annotating the changes difficult, if not impossible, in any event. In particular moving the Doomsday game dll and OpenGL dll into the main engine would have necessitated thousands of comments alone which was just not feasible.

Where any .c file uses code from another port then its header makes this clear. If anyone feels they have not been correctly represented by omission or otherwise then please let us know so that files can be amended as required.

As such this source is released in good faith and with the hope that others may find it useful.


Abbs - Risen3D site maintainer.

Note from the author (G Jackson);

Risen3D has been developed as a hobby and for the fun of so doing. Lately this has been no fun at all thanks to the bile on the doom forum following its release. This led me to calling it a day and deleting all the Risen3D main source code which was done, I thought, with the agreement of the Risen3D team. I then found, too late, that this wasn't the case. There followed much wailing and gnashing of teeth. By the sheerest good fortune I was able to resurrect a slightly earlier build made when v2.1.0 was in development else it really would be dead. Since the r3dglbsp and r3dgfiles sources were stored elsewhere on my system they had escaped deletion, so at least I was saved the trouble trying to retrieve these. I have now combined them all into one main file.

After a good deal of mucking about I was able to drag the main Risen3D source back up to give the same functionality as build 61. I then fixed a few other things and have now marked it build 62. I have have not included the original id license (as they released it under the GPL in 1999) so there is no licensing conflict. I have used the American spelling of 'license' deliberately so don't send emails about it.

With regard to the main Risen3D code I have further endeavoured to meet the terms of the GPL (GNU General Public License - LICENSE.txt) by heading all c files with the contributing authors' names and stating the ports used where applicable. As far as the date of changes made within the Risen3D code is concerned I have based it on the date of updating the c files headers for this build (62) and all references to 'R3D' or 'Risen3D' within these files assume the date in the header.

All the imported code used to develop Risen3D originates from Doom, Boom v2.10, ZDoom123beta33-src. Note that in the zdoom.txt contained in the 123beta33-src it is stated as being ZDOOM v1.22 December 12, 1999 (all released in the period 1998 to 1999) or code in Doomsday v1.7.08 which provides the main base. In the case of Doomsday it has been assumed that where no accreditation has been stated within a .c file and where that file's code is not based on functionality within the original Doom source (e.g. sound, models, particles) that the sole author is Jaakko Keränen. This exercise was undertaken in order to ensure that all 3rd party code contained in the source is licensed under the GPL or can be freely used with no restriction to prevent it being placed under the GPL (as this is a condition of the GPL) and that authors are properly accredited using a copyright notice (which is also required by the GPL). This has meant that being able to edit maps with a BEHAVIOR lump is no longer supported.

In general files named r3d_*.c and the m_winmem.c file contain code that has been developed from scratch without recourse to any other code base unless otherwise stated. In going through the source I also discovered there was barely a file I hadn't altered, amended or extended in some way which is testament to the amount of work that has been put into this port.

At the current time the multiplayer and networking code is either disabled or absent. Demos can only be recorded and played with maps not using the new Risen3D scripting extensions. It may be that someone else would like to have a go at rectifying this.

Certain areas of the code are somewhat obscure since I was never able to finish them.

In particular the analyser code will make grown men weep. When I started this project I was totally (blissfully as I now realise) unaware of the myriad of problems caused by the freeform nature of Doom. It happily runs with ill-designed maps and has very few rules imposed. This additionally causes problems for nodes builders.

As such I just ran into more and more problems the more maps I tried.

So, no matter which way I turned, all I could see were intractable problems. As such I decided to use an heuristic method, i.e. one that sent an unknown set of conditions through a series of filters, which I would add as required, to try and correct an indeterminate starting point as I came across them when testing maps. I also decided on this route because I found that if there's one way of fiddling something to look right in a Doom map then other authors would find a dozen other ways to do the same thing. I had some success with this but I (much) later realised that this should only be used as the last resort not the first. As such, over the last 18 months or so, I have been slowly adding a boundary based method where a boundary is traced and all subsectors contained within it are processed.

Progress has been slow because there is so much knowledge locked up in the heuristic routines that I felt that starting again (given one only retains 20% of what one has learnt) was not an option. As such I decided to implement a gradual changeover as a boundary trace cannot fix everything. With the benefit of hindsight I should have started again.

The result of the above is that the analyser is now an unholy mix poised somewhere between one method and the other. This has been made worse because I felt I knew what flags would be required to make the transition work but, as ever, underestimated the problems which led to yet more and more flags creeping in. I now reckon I know how this should be done, if starting again, but have run out of steam. Given the analyser works 99% of the time with difficult map constructions, with an acceptable error rate, I've decided it's not worth spending another year or more in starting again. If someone else can suss out what's what, and given the requisite boundary routines have all been written and tested and are contained in the trace routines in the source, and feels they can sort this out, then be my guest!

I have also tried to maintain the best frame rates by having pre-calculated steps done in the analyser before rendering is started. Thus in rend_main.c it might look horrifyingly complicated but in practice the lines' types set in the analyser (R3D_xx) work together with the additional subsector entries to provide a quick route through for awkward situations. This could now be simplified but would have to be done hand-in-hand with the analyser code.

With regard to other Risen3D specific features viz; slopes, scripting, sliding model doors and 3D lines (but not flats) then these are all fairly straight forward with slopes probably having the most changes implemented. The scripting could probably benefit from having a single, common, thinker but only if wanting to extend these to demo support etc.

GENERAL NOTES FOR COMPILATION

Risen3D has been written to compile with MSVC 6.0++ SP3 and is Windows specific.

In MSVC the analyser c files are in the source\r3d_analyse,
the slopes and 3D line main c files are in the source\r3d_extensions,
and the new scripting stuff is in the source\r3d_script.

Tabbing uses a value of 4.

There's also an unsigned __int64 problem with MSVC 6.0 SP3 which might indicate other issues as well. I installed an upgrade from MS;

http://msdn.microsoft.com/vstudio/downloads/tools/ppack/download.aspx

so this might also be required (assuming the link's still valid as I did this in Oct/04).


VC98 lib and include files;

You'll need the fmod sdk available from; http://www.fmod.org/

and;

eax.h, eaxguid.lib from Creative Labs,
libpngd.lib, libz.lib, lzexpand.h from Microsoft, I believe, if not already in VC98

OpenGL headers, libs etc. from SGI also in NVidia's SDK.

NOTE: I can't be any more helpful, I'm afraid, as I installed these ages ago and cannot find my links.

Please don't ask me to send any of the above files as distribution by 3rd parties is not allowed.

If you've got any queries then please send them via the Risen3D site.

G. M. Jackson Oct 2006