Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Bringing Build Engine games to Doomsday

edited 2014 Oct 11 in Developers
Hello Doomsday team,

Rather than spamming the other thread with off-topic discussion I decided to create a separate thread. Basically, I would like to see the Build Engine games, most notably Duke Nukem 3D and Shadow Warrior, supported in the Doomsday engine. Primarily Shadow Warrior, because that one has no proper port at all, but Duke Nukem 3D would be a first stepping stone because it lacks a few features found in Shadow Warrior (transparent water and voxels for instance).

As I understood there is no interest from the developer team to go for this issue in the foreseeable future, so I thought I could try my hand at it and see how far I can get. From what I gathered the Build engine is very much like a technical superset of the Doom engine, both work with 2D sectors for level design and sprites for world objects. What Build adds is sloped surfaces (different heights within a single sector), room-over-room (by "teleporting" the player to another sector), under water parts (similar to room over room), destructible terrain (achieved by altering sector data on the fly during runtime) and being able to look and walk into sectors that aren't adjacent on the map (this creates the seamless room-over-room experience).

The first step would be to allow Doomsday to load GRP files (like Doom WADs); that should be simple enough, GRP files consist just of a list of files and then the files themselves glued together in sequence, there is no compression. The next step would be loading the assets and expanding Doomsday's capabilities the handle the new features (slopes and so on). Unless of course Doomsday can already do that, I don't know, otherwise this would be the hard part. Once we can walk around in the levels it's time to code the actual game mechanics (would this be libduke then?).

What level of programming expertise would I need for these tasks and does it even make sense to start now or should I wait until Doomsday gets closer to version 2.0? If this were successful we could even think about supporting Blood, which would be awesome.
«1

Comments

  • I am very glad to hear that you would be willing to take a look at this.

    However, it will be quite challenging due to the issues you've mentioned. Doomsday indeed lacks support for slopes and portal-based rendering. However, this would provide an excellent opportunity to enhance Doomsday's renderer.
    • As you guessed, a "libduke" would be needed for all the game logic, physics, etc. The existing Duke sources would have to be heavily modified, though, to work with Doomsday's runtime APIs and renderer instead of its own.
    • Doomsday handles map data in its own internal format, and we import the Doom/Hexen maps into it using the wadmapconverter plugin. This is DaniJ's area of expertise. Support for importing Duke format maps would have to go either into wadmapconverter or another map conversion plugin.
    • The internal map data would have to be extended to handle the more advanced concepts of the Build engine, such as slopes. However, extending the internal map format long been the plan anyway — we've isolated it from the game plugins, meaning that the internal map data structures can be radically altered without breaking any of the games, as long as the map APIs stay the same toward the plugins.
    • There is one specific exception to internal map data that might provide problematic for now: mobjs are not fully internal to the engine, but are instead treated as POD data structures with a predefined set of common fields in the beginning. I don't know how Duke handles objects, but it might clash with this approach. We've been long planning to handle objects internally as C++ objects and provide some sort of API to manipulate them, so that the "raw data" is not exposed and game plugins could be freed to handle objects in any way they please, as long as they inform the engine about their common properties (like position, speed, etc.)
    • And of course, the world renderer itself would need improving (for slopes, etc.). We are planning to rewrite most of it, however it doesn't do much good to wait until the entire renderer has been updated, as it might take years. The wisest course of action might be to start modifying the current renderer, and incorporate the added features in such as a way that they can be integrated into the new renderer (i.e., well decoupled and written using C++/Doomsday 2 APIs).
    This would be a huge undertaking, but at least I could provide assistence as needed.


    In practice, I would like to see this developed at Github (or some other public git repository) as a separate branch that periodically merges to the main Doomsday master branch with new stuff as it gets implemented.
  • Thanks for the quick reply. Yes, this will be a huge undertaking, I really don't expect to get Duke up and running within even a year, but we'll what comes out of it. Even if I fail, at least there will be a starting ground and I'll have learned something in the process ;)

    I am working on OS X 10.9 (Mavericks), so what do I need to get started. According to the Getting Started page I need XCode, which I already have. The Compiling and Running page list a whole bunch of other dependancies, do I need all of those as well? Can I use XCode as my IDE? That's the one I'm already used to.
    skyjake wrote:
    As you guessed, a "libduke" would be needed for all the game logic, physics, etc. The existing Duke sources would have to be heavily modified, though, to work with Doomsday's runtime APIs and renderer instead of its own.
    Yes, I expected that. Honestly I don't really want to actually port the source itself, just make the game compatible with Doomsday and make it as faithful as it makes sense. If people want a 1:1 faithful port they can use DOSBox or Chocolate Duke Nukem 3D. In fact, I think using that port as a reference instead of the original code would be a better idea because it's more readable.
    skyjake wrote:
    Doomsday handles map data in its own internal format, and we import the Doom/Hexen maps into it using the wadmapconverter plugin. This is DaniJ's area of expertise. Support for importing Duke format maps would have to go either into wadmapconverter or another map conversion plugin.
    Another plugin (grpmapconverter), the Duke 3D level format has (to my knowledge) nothing to do with the Doom level format, so it would just be bloating the code.
  • Indeed a separate map converter plugin for Build engine maps in general would be the better option.

    I have some familiarity with the Duke 3D map format and there are indeed some fundamental design differences that will require some extensive changes to Doomsday's internal map data format. However, I plan to continue work on expanding the map data format for Doomsday 1.15

    You are right to begin this task by supporting the GRP container format. We can introduce data format interpreters as and when they become viable. Accurately interpreting the map data is however impossible at present. For now I would suggest you focus on the myriad graphic and sound formats.
  • HiPhish wrote:
    I am working on OS X 10.9 (Mavericks), so what do I need to get started. According to the Getting Started page I need XCode, which I already have. The Compiling and Running page list a whole bunch of other dependancies, do I need all of those as well? Can I use XCode as my IDE? That's the one I'm already used to.
    I use a Mac as my main development machine. Xcode is needed for the compiler. Being a Qt project, I'm not aware of a way to convert Doomsday into a "native" Xcode project; compilation will anyway be done via external Makefiles. I suppose you could just add the whole Doomsday source tree into an Xcode project, run qmake manually when needed, and set up an external build target.


    However, I still would recommend using Qt Creator as the IDE — I've tried setting up an Xcode project like this a few times but the builds never worked quite as fluently as with Qt Creator. I also recall Xcode having some issues indexing all the symbols in the project, as some of the sources are currently being compiled several times but with different preprocessor definitions.

    About the other dependencies: Qt is of course mandatory (4.8.5 is what we're using currently), SDL is used only for joystick input (but is required for compilation). SDL_mixer is optional (if using "CONFIG += deng_nosdlmixer"). I recommend getting the FMOD Ex SDK for audio.

    The FluidSynth audio plugin (for playing midi music using SF2 soundfonts) needs Homebrew, because you need to install GLib 2.0. Homebrew can also provide ccache to speed up your compilation, Doomsday is quite a large project and can take a while to compile from scratch.
  • OK, I'll switch to Qt Creator for this, no need to try squeezing a square peg into a round hole with XCode. I use Macports as my package manager, do I have to switch to Homebrew? It's no problem, but I'd rather not have two package managers running if I don't have to. I don't even know if one is better than the other, I just picked one. About SDL, are you using SDL 2 or still SDL 1? Do I have to get the framework version or is the Unix-style from Macports (stores the libraries at /opt/lical/lib) OK as well? I'll also need to read up on Git before I can get started...
    DaniJ wrote:
    You are right to begin this task by supporting the GRP container format. We can introduce data format interpreters as and when they become viable. Accurately interpreting the map data is however impossible at present. For now I would suggest you focus on the myriad graphic and sound formats.
    How would I go about testing whether the graphics and sounds are properly read?
  • Testing the interpreted graphic and sound formats is straight forward providing they have been incorporated at the correct level. Sounds can be played back from the console and graphics can be displayed in an InFine script. I would personally begin with the audio interpreters as graphics are a little more involved (from what I recall, that is).

    However the first step is of course supporting the GRP container itself. In practice this will mean a parallel component to the other ZIP/WAD containers. I should point out that we are currently transitioning to a new "FS2" file system implemented in libdeng2. Presently this means that in order for such resources to be available to the majority of the engine it is necessary to implement the GRP container in the old "FS1" file system.

    Without wishing to discourage you, I wonder if extending support to such a significantly different game is perhaps a little too soon, considering the current state of the architecture. While some parts are new and clean, with some decent documentation. The older parts have some fairly quirky behavior and the design of which isn't up to the same standard.
  • GRP files are simple enough that I should be able to hook it up to your FS2 when the time comes. Here is its description:
    The ".grp" file format is just a collection of a lot of files stored into 1 big one. I tried to make the format as simple as possible: The first 12 bytes contains my name, "KenSilverman". The next 4 bytes is the number of files that were compacted into the group file. Then for each file, there is a 16 byte structure, where the first 12 bytes are the filename, and the last 4 bytes are the file's size. The rest of the group file is just the raw data packed one after the other in the same order as the list of files.
    http://advsys.net/ken/build.htm

    We can see about the rest as we go along, if certain aspects have to be put on hold then so be it. But first I'll need to get everything set up on my side, then we'll see. As I said, I am in no hurry to get this done soon.
  • HiPhish wrote:
    I use Macports as my package manager, do I have to switch to Homebrew?
    Likely not, I would assume Macports has many of the same software packages. I find Homebrew to be more up to date, though.
    About SDL, are you using SDL 2 or still SDL 1? Do I have to get the framework version or is the Unix-style from Macports
    The project has been configured for the SDL 1 frameworks (see dep_sdl.pri).
    DaniJ wrote:
    Presently this means that in order for such resources to be available to the majority of the engine it is necessary to implement the GRP container in the old "FS1" file system.
    I would advise against relying on FS1 at all. As DaniJ says we're migrating to FS2 and other libdeng2 based classes, so any new code that handles GRP containers should be built around the latter. The FS1 based implementation heavily relies on conventions and quirks unique to Doom WADs; mixing any of it with GRP container logic does not seem like a good idea.

    We will soon need a way to bypass or otherwise get rid of the FS1 classes so that development of the resource subsystem can proceed unhindered and — quite crucially — outside of the client app, in a library of its own.
    HiPhish wrote:
    We can see about the rest as we go along
    I think the wisest way forward is to start collecting smaller-scope classes, like a GRP container for FS2, and image/sound importers for the Duke formats, and keep them as decoupled as possible from any existing Doomsday functionality except the SDK libraries (libdeng2, libgui, libappfw, libshell). Initially these could be developed in test apps that just verify that the components are working, e.g., open a GRP file and save the images as .png for instance. Later on, when the client's internal architecture has been cleaned up, these can then be incorporated in the revised resource management system.
  • I need help setting up Qt Creator on OS X: I downloaded Qt 4.8.5 from the official website and installed it using their installer. Then I downloaded Qt Creator 3.1.0, but it won't recognise my Qt installation. From what I understand I need to go to Preferences -> Build & Run -> Qt Version and add my qmake binary. However, I cannot add it in the file browser, it's greyed out. The location where qmake lies is /usr/bin and the qmake there is a symlink to qmake-4.8 which lies in the same folder. What am I doing wrong here?
  • HiPhish wrote:
    I need help setting up Qt Creator on OS X: I downloaded Qt 4.8.5 from the official website and installed it using their installer. Then I downloaded Qt Creator 3.1.0, but it won't recognise my Qt installation. From what I understand I need to go to Preferences -> Build & Run -> Qt Version and add my qmake binary. However, I cannot add it in the file browser, it's greyed out. The location where qmake lies is /usr/bin and the qmake there is a symlink to qmake-4.8 which lies in the same folder. What am I doing wrong here?
    You have run into an known bug in Qt Creator: https://bugreports.qt-project.org/brows ... ORBUG-6222

    I've encountered this in the past a few times. I got around it by creating a hard link to /usr/bin/qmake and then using that as the qmake binary.
    ln /usr/bin/qmake ~/bin/qmake
    
  • Thanks for the link, I have an easier fix: rename the symlink in /usr/bin to something else (like qmake_x) and rename the binary qmake-4.8 to qmake. Now you can choose it in Qt Creator. Once done the files can be renamed back to normal.

    However, now when I want to click on Build->Build Project "doomsday" I get an error "Unspecified SDK configuration" and general message "Project ERROR: Unspecified SDK configuration.". What does that mean? Also, do you guys have any code formatting rules I should stick to? (new lines, spaces, indentation, tab VS space,...)
  • HiPhish wrote:
    However, now when I want to click on Build->Build Project "doomsday" I get an error "Unspecified SDK configuration" and general message "Project ERROR: Unspecified SDK configuration.". What does that mean?
    It means config_macx.pri needs to know which Mac OS X SDK to use. You could first try putting this in your config_user.pri:
    CONFIG += deng_macx8_64bit
    
    That's what I'm using on Mavericks for now.
    Also, do you guys have any code formatting rules I should stick to? (new lines, spaces, indentation, tab VS space,...)
    Yes, we do follow our own code formatting rules. The source files of libdeng2 are a pretty good style reference. Indentation is 4 spaces, never tabs.

    One rather non-standard convention is that we put const after the typename, for instance "String const &name" instead of "const String& name". & and * therefore are always attached to the identifier:
    void *a;
    void const *a;
    

    We of course would prefer that you try to match our style, although changing it with a reformatting utility is also pretty straightforward.
  • Thanks, now for the next question: how do I set properly the various dependency paths? For instance, now it's choking on "dep_sdl: SDL framework path not defined, check your config_user.pri". Obviously the file has Windows paths , but what's the right format for Mac paths? I already tried "/Library/Frameworks/SDL.framework/Headers" but that doesn't so it. Also, what about the other dependencies, how do I set them and should I comment away the ones I won't use (DirectX, Oculus Rift and so on)? Which ones can I ignore? I only want the project to compile with the bare minimum of what I need.

    [EDIT: maybe it would be best if you copy-pasted you config_user.pri or PMed it to me]
    skyjake wrote:
    Indentation is 4 spaces, never tabs.
    I could never understand the reasoning behind this. I always use tabs for indentation and spaces for alignment, but I will stick to your rules.
  • Here is my config_user.pri:
    SDK_PREFIX = $$(HOME)/SDK/Doomsday
    
    # Custom configuration options.
    SDL_FRAMEWORK_DIR = $$(HOME)/Library/Frameworks
    LIBOVR_DIR = $$(HOME)/SDK/OculusSDK/LibOVR
    
    CONFIG += deng_macx8_64bit
    
    # Use FMOD instead of SDL_mixer.
    FMOD_DIR = "$$(HOME)/SDK/FMOD Programmers API"
    CONFIG += deng_fmod deng_nosdlmixer
    CONFIG += deng_fluidsynth
    
    CONFIG += deng_ccache
    
    The SDK_PREFIX determines where an SDK build will be installed, so you can ignore that (that is only used when building with CONFIG+=deng_sdk).
    HiPhish wrote:
    I could never understand the reasoning behind this. I always use tabs for indentation and spaces for alignment, but I will stick to your rules.
    It's mostly for simplicity and consistency. This basically sums it up: http://programmers.stackexchange.com/a/657

    A good IDE like Qt Creator of course makes this a non-issue, though.
  • edited 2014 Apr 24
    Now I am getting two new errors:
    rm: No such file or directory
    library not found for -ldeng2
    
    rm is the command to delete files, but what is it trying to delete? my config_user.pri looks like this (everything else is commented away)
    SDL_FRAMEWORK_DIR = $$(HOME)/Library/Frameworks
    CONFIG += deng_macx8_64bit
    
    # Use FMOD instead of SDL_mixer.
    FMOD_DIR = "$$(HOME)/Library/Frameworks/FMOD Programmers API"
    CONFIG += deng_fmod deng_nosdlmixer
    CONFIG += deng_fluidsynth
    
    CONFIG += deng_ccache
    
    I have the SDL framework both in /Library /Frameworks and in ~/Library/Frameworks if hat matters. Also, these are the general messages I'm getting:
    Project MESSAGE: Debug build.
    Project MESSAGE: 64-bit architecture detected.
    Project MESSAGE: Using Mac OS 10.8 SDK.
    Project MESSAGE: Architectures: intel64
    Project ERROR: DirectSound is only available on Windows.
    /bin/sh: ls: command not found
    /bin/sh: pkg-config: command not found
    /bin/sh: pkg-config: command not found
    Project ERROR: dep_fmod: FMOD SDK path not defined, check your config_user.pri (FMOD_DIR)
    Project ERROR: Windows Multimedia Mixing is only available on Windows.
    Project ERROR: wadtool is currently only for Windows
  • HiPhish wrote:
    Now I am getting two new errors:
    When are these printed? Is there a more complete compile log these are part of?


    You shouldn't need pkg-config on Mac unless you are building the FluidSynth plugin.

    Note that the general messages tab is somewhat useless as it also prints messages that occur during the background re-evaluation of the .pro/.pri files for the purposes of the IDE knowing which files are part of the project, and during that processing it doesn't seem to respect the CONFIG variable. This means all kinds of errors might get printed.
  • The errors get printed when I click the build button (lower let button with the hammer). The build progress bar in the lower right-hand conrner appears and stops somewhere halfway and I get only those two errors, nothing else, in my issues. Do I maybe have to tell the IDE where to look for the dependencies I installed via MacPorts? Homebrew puts them under "/usr/local", but MacPorts creates its own "/opt/local" directory in order to not clash with something that might have been installed by something else.

    (BTW, I updated my config_user.pri, see above, to look more like yours; I hadn't realised the code field was scrollable)
  • HiPhish wrote:
    The errors get printed when I click the build button (lower let button with the hammer). The build progress bar in the lower right-hand conrner appears and stops somewhere halfway and I get only those two errors, nothing else, in my issues.
    The full compile output is in its own output tab, which you might have to make visible manually (via the popup menu on the right edge of this picture):
    qtcreator_tabs.png

    You could also try rerunning qmake (via Build -> Run qmake).
    Do I maybe have to tell the IDE where to look for the dependencies I installed via MacPorts? Homebrew puts them under "/usr/local", but MacPorts creates its own "/opt/local" directory in order to not clash with something that might have been installed by something else.
    Everything that is accessed from Homebrew or another external package system is configured via pkg-config. So as long as pkg-config is in the path you should be fine.
  • Ah, here we go then:
    10:11:07: Running steps for project doomsday...
    10:11:07: Configuration unchanged, skipping qmake step.
    10:11:07: Starting: "/usr/bin/make" 
    cd build/ && /Applications/Xcode.app/Contents/Developer/usr/bin/make -f Makefile 
    make[1]: Nothing to be done for `first'.
    cd libdeng2/ && /Applications/Xcode.app/Contents/Developer/usr/bin/make -f Makefile 
    make[1]: Nothing to be done for `first'.
    cd libdeng1/ && /Applications/Xcode.app/Contents/Developer/usr/bin/make -f Makefile 
    rm -f libdeng1.1.15.0.dylib libdeng1.dylib libdeng1.1.dylib libdeng1.1.15.dylib
    make[1]: rm: No such file or directory
    g++ -L/Users/hiphish/XCode/Doomsday/build-doomsday-Desktop-Debug/libdeng1/../libdeng2 -headerpad_max_install_names -arch x86_64 -Wl,-syslibroot,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -single_module -dynamiclib -compatibility_version	1.15 -current_version	1.15.0 -install_name	libdeng1.1.dylib -Xarch_x86_64 -mmacosx-version-min=10.5 -o libdeng1.1.15.0.dylib animator.o binangle.o concurrency.o fixedpoint.o libdeng.o kdtree.o mathutil.o memory.o memoryblockset.o memoryzone.o point.o reader.o rect.o size.o smoother.o stack.o str.o stringarray.o strutil.o timer.o vector1.o writer.o findfile_unix.o moc_concurrency.o  -F/Library/Frameworks -L/Library/Frameworks -ldeng2 -framework QtNetwork -framework QtCore  
    make[1]: [libdeng1.1.15.0.dylib] Error 1 (ignored)
    ld: library not found for -ldeng2
    clang: error: linker command failed with exit code 1 (use -v to see invocation)
    make[1]: *** [libdeng1.1.15.0.dylib] Error 1
    make: *** [sub-libdeng1-make_default-ordered] Error 2
    10:11:08: The process "/usr/bin/make" exited with code 2.
    Error while building/deploying project doomsday (kit: Desktop)
    When executing step 'Make'
    10:11:08: Elapsed time: 00:00.
    
    I was quite confused that the log was so short, but now it's complete. Can you make something out from this?
  • If you go to "/Users/hiphish/XCode/Doomsday/build-doomsday-Desktop-Debug/libdeng2", is there any libdeng2.*.dylib files there?

    If not, try rebuilding libdeng2 and see if it failed for some reason.
  • libdeng2.2.0.0.dylib is there
  • I just noticed the log says you're using g++ — on Mac you should use the (64-bit) clang compiler. First check that your built kit is using the correct compiler: Preferences -> Build & Run -> Kits.

    You may have to specify "unsupported/macx-clang" as the Qt mkspec. This can also be given to qmake as a command line option "-spec unsupported/macx-clang".
  • I did what you said and I get this error:
    :-1: error: Missing dependency: FluidSynth requires GLib 2.0 development files
    
    10:49:45: Running steps for project doomsday...
    10:49:45: Starting: "/usr/bin/qmake" /Users/hiphish/XCode/Doomsday/doomsday/doomsday.pro -r -spec unsupported/macx-clang CONFIG+=x86_64
    Reading /Users/hiphish/XCode/Doomsday/doomsday/build/build.pro [/Users/hiphish/XCode/Doomsday/build-doomsday-Desktop-Debug/build]
    Project MESSAGE: Debug build.
    Project MESSAGE: 64-bit architecture detected.
    Project MESSAGE: Using Mac OS 10.8 SDK.
    Project MESSAGE: Architectures: intel64
    Created /Users/hiphish/XCode/Doomsday/build-doomsday-Desktop-Debug/doomsday.pk3 (with 103 files).
    Created /Users/hiphish/XCode/Doomsday/build-doomsday-Desktop-Debug/defaultstyle.pack (with 38 files).
    Created /Users/hiphish/XCode/Doomsday/build-doomsday-Desktop-Debug/renderer.pack (with 20 files).
    Created /Users/hiphish/XCode/Doomsday/build-doomsday-Desktop-Debug/libdoom.pk3 (with 129 files).
    Created /Users/hiphish/XCode/Doomsday/build-doomsday-Desktop-Debug/libheretic.pk3 (with 35 files).
    Created /Users/hiphish/XCode/Doomsday/build-doomsday-Desktop-Debug/libhexen.pk3 (with 90 files).
    Created /Users/hiphish/XCode/Doomsday/build-doomsday-Desktop-Debug/libdoom64.pk3 (with 24 files).
    Reading /Users/hiphish/XCode/Doomsday/doomsday/libdeng2/libdeng2.pro [/Users/hiphish/XCode/Doomsday/build-doomsday-Desktop-Debug/libdeng2]
    Reading /Users/hiphish/XCode/Doomsday/doomsday/libdeng1/libdeng1.pro [/Users/hiphish/XCode/Doomsday/build-doomsday-Desktop-Debug/libdeng1]
    Reading /Users/hiphish/XCode/Doomsday/doomsday/libshell/libshell.pro [/Users/hiphish/XCode/Doomsday/build-doomsday-Desktop-Debug/libshell]
    Reading /Users/hiphish/XCode/Doomsday/doomsday/libgui/libgui.pro [/Users/hiphish/XCode/Doomsday/build-doomsday-Desktop-Debug/libgui]
    Reading /Users/hiphish/XCode/Doomsday/doomsday/libappfw/libappfw.pro [/Users/hiphish/XCode/Doomsday/build-doomsday-Desktop-Debug/libappfw]
    Reading /Users/hiphish/XCode/Doomsday/doomsday/client/client.pro [/Users/hiphish/XCode/Doomsday/build-doomsday-Desktop-Debug/client]
    Reading /Users/hiphish/XCode/Doomsday/doomsday/server/server.pro [/Users/hiphish/XCode/Doomsday/build-doomsday-Desktop-Debug/server]
    Reading /Users/hiphish/XCode/Doomsday/doomsday/plugins/plugins.pro [/Users/hiphish/XCode/Doomsday/build-doomsday-Desktop-Debug/plugins]
     Reading /Users/hiphish/XCode/Doomsday/doomsday/plugins/dehread/dehread.pro [/Users/hiphish/XCode/Doomsday/build-doomsday-Desktop-Debug/plugins/dehread]
     Reading /Users/hiphish/XCode/Doomsday/doomsday/plugins/savegameconverter/savegameconverter.pro [/Users/hiphish/XCode/Doomsday/build-doomsday-Desktop-Debug/plugins/savegameconverter]
     Reading /Users/hiphish/XCode/Doomsday/doomsday/plugins/wadmapconverter/wadmapconverter.pro [/Users/hiphish/XCode/Doomsday/build-doomsday-Desktop-Debug/plugins/wadmapconverter]
     Reading /Users/hiphish/XCode/Doomsday/doomsday/plugins/example/example.pro [/Users/hiphish/XCode/Doomsday/build-doomsday-Desktop-Debug/plugins/example]
     Reading /Users/hiphish/XCode/Doomsday/doomsday/plugins/doom/doom.pro [/Users/hiphish/XCode/Doomsday/build-doomsday-Desktop-Debug/plugins/doom]
     Reading /Users/hiphish/XCode/Doomsday/doomsday/plugins/heretic/heretic.pro [/Users/hiphish/XCode/Doomsday/build-doomsday-Desktop-Debug/plugins/heretic]
     Reading /Users/hiphish/XCode/Doomsday/doomsday/plugins/hexen/hexen.pro [/Users/hiphish/XCode/Doomsday/build-doomsday-Desktop-Debug/plugins/hexen]
     Reading /Users/hiphish/XCode/Doomsday/doomsday/plugins/doom64/doom64.pro [/Users/hiphish/XCode/Doomsday/build-doomsday-Desktop-Debug/plugins/doom64]
     Reading /Users/hiphish/XCode/Doomsday/doomsday/plugins/fmod/fmod.pro [/Users/hiphish/XCode/Doomsday/build-doomsday-Desktop-Debug/plugins/fmod]
     Reading /Users/hiphish/XCode/Doomsday/doomsday/plugins/fluidsynth/fluidsynth.pro [/Users/hiphish/XCode/Doomsday/build-doomsday-Desktop-Debug/plugins/fluidsynth]
    sh: pkg-config: command not found
    Project ERROR: Missing dependency: FluidSynth requires GLib 2.0 development files
    10:49:59: The process "/usr/bin/qmake" exited with code 2.
    Error while building/deploying project doomsday (kit: Desktop)
    When executing step 'qmake'
    10:49:59: Elapsed time: 00:14.
    

    So I commented away the part about fluidsynth:
    :-1: error: ccache: No such file or directory
    
    10:52:10: Running steps for project doomsday...
    10:52:10: Configuration unchanged, skipping qmake step.
    10:52:10: Starting: "/usr/bin/make" 
    cd build/ && /Applications/Xcode.app/Contents/Developer/usr/bin/make -f Makefile 
    make[1]: Nothing to be done for `first'.
    cd libdeng2/ && /Applications/Xcode.app/Contents/Developer/usr/bin/make -f Makefile 
    ccache clang++ -Qunused-arguments -c -pipe -mmacosx-version-min=10.7 -g -gdwarf-2 -arch x86_64 -Wall -W -Wno-c++11-long-long -Wno-unused-private-field -Wno-self-assign -Wextra -pedantic -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -fPIC -D_DEBUG -DDENG_64BIT_HOST -DUNIX -DMACOSX -DMACOS_10_7 -DDENG_NO_FIXED_ASM -DDENG_DISABLE_SDLMIXER -DLIBDENG2_RELEASE_LABEL=\"Dev\" -DLIBDENG2_MAJOR_VERSION=2 -DLIBDENG2_MINOR_VERSION=0 -DLIBDENG2_PATCHLEVEL=0 -DLIBDENG2_VERSION=\"2.0.0\" -D__DENG2__ -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/local/Qt4.8/mkspecs/unsupported/macx-clang -I../../doomsday/libdeng2 -I/Library/Frameworks/QtCore.framework/Versions/4/Headers -I/usr/include/QtCore -I/Library/Frameworks/QtNetwork.framework/Versions/4/Headers -I/usr/include/QtNetwork -I/usr/include -I../../doomsday/libdeng2/include -I/Users/hiphish/XCode/Doomsday/build-doomsday-Desktop-Debug/libdeng2/. -I../../doomsday/libdeng2 -I. -F/Library/Frameworks -o guard.o ../../doomsday/libdeng2/src/concurrency/guard.cpp
    make[1]: ccache: No such file or directory
    make[1]: *** [guard.o] Error 1
    make: *** [sub-libdeng2-make_default-ordered] Error 2
    10:52:10: The process "/usr/bin/make" exited with code 2.
    Error while building/deploying project doomsday (kit: Desktop)
    When executing step 'Make'
    10:52:10: Elapsed time: 00:00.
    

    Commenting away ccache:
    :-1: error: rm: No such file or directory
    
    http://pastebin.com/QageG9Dz

    I always trashed the build-doomsday-Desktop-Debug folder after each failed attempt.
  • It looks like "rm" and "ln" are not found, which suggests the system bin path is not used during compilation. Check that Projects -> Build & Run -> Build Environment is set to "System Environment".
    skyjake wrote:
    The FluidSynth audio plugin (for playing midi music using SF2 soundfonts) needs Homebrew, because you need to install GLib 2.0. Homebrew can also provide ccache to speed up your compilation
    You should look for and install pkg-config, GLib 2.0 development files, and ccache from Macports (or Homebrew), if you wish to compile FluidSynth and use caching.
  • Setting to System environment fixed at least the problems with rm and cp, but it still won't compile with FluidSynth, ccache or even FMod. After commenting away those it builds but crashes. Here is the debug log, something about the console font:
    http://pastebin.com/zRmnAE8t

    BTW, do we have a proper documentation of the GRP format somewhere? I've started digging through the source, but if there was already something properly written that would be better.
  • HiPhish wrote:
    Setting to System environment fixed at least the problems with rm and cp, but it still won't compile with FluidSynth, ccache or even FMod. After commenting away those it builds but crashes. Here is the debug log, something about the console font:
    Have you set up the Run settings of the project as described here: http://dengine.net/dew/index.php?title= ... Qt_Creator ?

    Note that the "-appdir . -vdmap .. }data -bd Doomsday.app/Contents/Resources" options are mandatory, as they instruct the engine where the resources are located in the developer directory layout.

    The "ccache" package has to be installed from Macports/Homebrew, if you wish to use it.

    I've checked our post-build script and it turns out that for FluidSynth, Homebrew actually is required as it assumes the libraries can be found under /usr/local/Cellar and copies them from there to the Doomsday.app bundle. So you might wish to not build the FluidSynth plugin for now.

    What's the issue with FMOD?
  • skyjake wrote:
    HiPhish wrote:
    Setting to System environment fixed at least the problems with rm and cp, but it still won't compile with FluidSynth, ccache or even FMod. After commenting away those it builds but crashes. Here is the debug log, something about the console font:
    Have you set up the Run settings of the project as described here: http://dengine.net/dew/index.php?title= ... Qt_Creator ?
    Thanks, that was the problem. Although, I can only launch the binary directly (%{buildDir}/client/Doomsday.app/Contents/MacOS/Doomsday), setting "%{buildDir}/client/Doomsday.app" as the exectuable gives me this error:
    Starting /Users/hiphish/XCode/Doomsday/build-doomsday-Desktop-Debug/client/Doomsday.app...
    /bin/sh: /Users/hiphish/XCode/Doomsday/build-doomsday-Desktop-Debug/client/Doomsday.app: is a directory
    /Users/hiphish/XCode/Doomsday/build-doomsday-Desktop-Debug/client/Doomsday.app exited with code 126
    

    Also, there is no Snowberry, it takes me straight to the homes screen (ring zero?), is that intended?

    I do have ccache installed via MacPorts, but it won't recognise it, might that be the same problem as with FluidSynth and glib2? The problem with FMOD is the following:
    cp: /Users/hiphish/Library/Frameworks/FMOD Programmers API/api/lib/libfmodex.dylib: No such file or directory
    make[1]: *** [Doomsday.app/Contents/MacOS/Doomsday] Error 1
    make: *** [sub-client-make_default-ordered] Error 2
    18:41:59: The process "/usr/bin/make" exited with code 2.
    Error while building/deploying project doomsday (kit: Desktop)
    When executing step 'Make'
    18:41:59: Elapsed time: 19:41.
    
    I downloaded the FMOD Programmer's API from the website and there is no "lib" folder inside "api" it, just "lowlevel" and "studio". It builds fine without FMOD, so I'm not really concerned about it, I just ant the compiler to get working. Having ccache would be nice though, compilation really takes a long time.
  • In the meantime I have been dissecting the GRP file format and here is what I have written down:
    Duke Nukem 3D .grp file format
    ==============================

    The GRP file format is used to store a Build Engine game's assets, such as graphics, sounds or levels. The file consists of a *header* that contains information on the included files and a *body* containing the files themselves with no compression.

    Versions of GRP files
    Duke Nukem 3D has had the following versions released:
    - **1.3:** Shareware release
    - **1.3d:** Full version
    - **1.4 & 1.5** Atomic Edition

    We could use this information to determine what version of the game the player is using.

    Data formats
    Characters are ASCII-encoded and strings are not terminated, but filled up if necessary. This means a string like TILES004.ART (12 octets long) is immediately followed by whatever data is supposed to come next, while a shorter string like SW.ANM is followed by six NUL characters (00 in hex).

    Integers are encoded as little-endian 32-Bit integers. It is unclear whether they are signed or unsigned, but it makes more sense to assume unsignedness since they represent files sizes or amounts of files where negative values make no sense.

    The file head
    The first 12 octets are an ASCII-encoded string that spells out "KenSilverman". The next four-octet block contains the total number of files inside the GRP file. That block is followed by a sequence of 16-octet blocks. Inside each block the first 12 octets represent the ASCII-encoded file name string and the next four octets the size of the file.

    The file body
    asdf
    I suggest that we add that sort of information as Markdown pages to the doxygen documentation. Would that be OK? (this forum could use spoiler tags that fold and unfold to hide information, those keep post short)
  • HiPhish wrote:
    there is no Snowberry, it takes me straight to the homes screen (ring zero?), is that intended?
    That is correct. Snowberry has never been incorporated into our developer builds.
    I downloaded the FMOD Programmer's API from the website and there is no "lib" folder inside "api" it, just "lowlevel" and "studio".
    Perhaps you downloaded the wrong one? Note that you need the FMOD Ex Programmer's API, under FMOD Ex, not the Studio one.
    I suggest that we add that sort of information as Markdown pages to the doxygen documentation. Would that be OK? (this forum could use spoiler tags that fold and unfold to hide information, those keep post short)
    Having this as part of the Doxygen documentation would be fine, although we also have the wiki for information like this. Markdown is also ok, as we're using Doxygen 1.8.6.
  • Ah, it was indeed FMOD Ex, that solved the problem. OK, I'll write down my findings in the Wiki then; do I need a separate account for that as well? Now all I need is to get ccache working, then I'm good to go. I'll try compiling its source directly, maybe that will work.

    If I'm not posting often here it doesn't mean that I have lost interest already, I'm currently juggling my time between being part-time at the hospital and renovating, so I can't devot much time to this at the moment. I'm definitely interested in continuing though.
Sign In or Register to comment.