Jump to content
The Dark Mod Forums

Autotools build system

OrbWeaver
 Share

Recommended Posts

OrbWeaver

OrbWeaver

Posted
Posted

The Autoconf/Automake-based build system I have been working on is now in a state ready for general testing. There are no doubt many subtle bugs, but the application runs and gets to the main screen now.

 

To use the new build system, you will need to have the autoconf and automake packages installed. You must then run the autogen.sh script at the top-level darkradiant directory, which will invoke the necessary tools to build the configure script. Once this is done, run

 

$ ./configure --prefix=/tmp/some_test_dir --enable-debug
$ make
$ make install

 

Then darkradiant can be run simply as

 

$ /tmp/some_test_dir/bin/darkradiant

 

The current configure script will test for necessary libraries and headers, and will optionally enable/disable the sound module if the OpenAL libraries are installed (although if the module is disabled the application will probably crash, I haven't implemented the optional module code yet).

DarkRadiant homepage ⋄ DarkRadiant user guide ⋄ OrbWeaver's Dark Ambients ⋄ Blender export scripts

Link to comment
Share on other sites
Tels

Tels

Posted
Posted
The Autoconf/Automake-based build system I have been working on is now in a state ready for general testing. There are no doubt many subtle bugs, but the application runs and gets to the main screen now.

 

To use the new build system, you will need to have the autoconf and automake packages installed. You must then run the autogen.sh script at the top-level darkradiant directory, which will invoke the necessary tools to build the configure script. Once this is done, run

 

$ ./configure --prefix=/tmp/some_test_dir --enable-debug
$ make
$ make install

 

Then darkradiant can be run simply as

 

$ /tmp/some_test_dir/bin/darkradiant

 

The current configure script will test for necessary libraries and headers, and will optionally enable/disable the sound module if the OpenAL libraries are installed (although if the module is disabled the application will probably crash, I haven't implemented the optional module code yet).

 

Nice work. However, in other applications that use this, configure is prebuild, so you can skip the very first step. Is it possible to do the same for darkradiant?

 

On my PC I am missing many packages just to run autogen.sh so I'd be grateful if that could be run and configure just checked into the SVN :)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites
OrbWeaver

OrbWeaver

Posted
  • Author
Posted
Nice work. However, in other applications that use this, configure is prebuild, so you can skip the very first step. Is it possible to do the same for darkradiant?

 

Yes, the "correct" way to distribute software is to pre-build the configure, Makefile.in and config.h.in files on the developer's machine so that the end user does not need to have autotools installed. I plan to do this later in the process, but at this stage the build system is too new and subject to change to make this worthwhile.

 

All of the necessary autotools packages are in the repositories, so I suggest installing these in any case ("sudo apt-get install autoconf automake libtool" should be more or less all that is required); this would enable you to fix any problems with the build scripts that arise from your own machine's configuration.

DarkRadiant homepage ⋄ DarkRadiant user guide ⋄ OrbWeaver's Dark Ambients ⋄ Blender export scripts

Link to comment
Share on other sites
Tels

Tels

Posted
Posted
Yes, the "correct" way to distribute software is to pre-build the configure, Makefile.in and config.h.in files on the developer's machine so that the end user does not need to have autotools installed. I plan to do this later in the process, but at this stage the build system is too new and subject to change to make this worthwhile.

 

Ah, ok, this wasn't clear to me.

 

All of the necessary autotools packages are in the repositories, so I suggest installing these in any case ("sudo apt-get install autoconf automake libtool" should be more or less all that is required); this would enable you to fix any problems with the build scripts that arise from your own machine's configuration.

 

I will do so in a minute and give it a whirl :)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites
Tels

Tels

Posted
Posted
Ah, ok, this wasn't clear to me.

I will do so in a minute and give it a whirl :)

 

Neede to install m4, too. Then:

 

te@te:~/src/darkmod/darkradiant$ ./autogen.sh
libtoolize: `config.guess' exists: use `--force' to overwrite
libtoolize: `config.sub' exists: use `--force' to overwrite
libtoolize: `ltmain.sh' exists: use `--force' to overwrite
configure.ac:2: installing `./missing'
configure.ac:2: installing `./install-sh'
libs/ddslib/Makefile.am: installing `./depcomp'
Makefile.am: installing `./INSTALL'
Makefile.am: required file `./README' not found
Makefile.am: installing `./COPYING'

 

Then I did ./configure --prefix=/home/te/tools/darkradiant-test/ --enable-debug and got:

 

te@te:~/src/darkmod/darkradiant$ ./configure --prefix=/home/te/tools/darkradiant-test/ --enable-debug
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for g++... g++
checking for C++ compiler default output file name... a.out
checking whether the C++ compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for style of include used by make... GNU
checking dependency style of g++... gcc3
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for gcc... gcc
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for /usr/bin/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm -B
checking whether ln -s works... yes
checking how to recognise dependent libraries... pass_all
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking how to run the C++ preprocessor... g++ -E
checking for g77... no
checking for xlf... no
checking for f77... no
checking for frt... no
checking for pgf77... no
checking for cf77... no
checking for fort77... no
checking for fl32... no
checking for af77... no
checking for xlf90... no
checking for f90... no
checking for pgf90... no
checking for pghpf... no
checking for epcf90... no
checking for gfortran... no
checking for g95... no
checking for xlf95... no
checking for f95... no
checking for fort... no
checking for ifort... no
checking for ifc... no
checking for efc... no
checking for pgf95... no
checking for lf95... no
checking for ftn... no
checking whether we are using the GNU Fortran 77 compiler... no
checking whether  accepts -g... no
checking the maximum length of command line arguments... 32768
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for objdir... .libs
checking for ar... ar
checking for ranlib... ranlib
checking for strip... strip
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... cat: /etc/ld.so.conf.d/*.conf: No such file or directory
GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
configure: creating libtool
appending configuration tag "CXX" to libtool
checking for ld used by g++... /usr/bin/ld -m elf_x86_64
checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking for g++ option to produce PIC... -fPIC
checking if g++ PIC flag -fPIC works... yes
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... cat: /etc/ld.so.conf.d/*.conf: No such file or directory
GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
appending configuration tag "F77" to libtool
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for GLIB... yes
checking for GTK... yes
checking for GTKGLEXT... yes
checking for XML... yes
checking GL/glew.h usability... yes
checking GL/glew.h presence... yes
checking for GL/glew.h... yes
checking for main in -lGLEW... yes
checking for main in -lGL... yes
checking for main in -lboost_regex... yes
checking for main in -lboost_filesystem... yes
checking AL/alut.h usability... yes
checking AL/alut.h presence... yes
checking for AL/alut.h... yes
checking for main in -lalut... yes
checking for ov_clear in -lvorbisfile... yes
configure: creating ./config.status
config.status: error: cannot find input file: Makefile.in

 

Hm, might be because this is a 64bit system. Gonna try on my laptop next.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites
Tels

Tels

Posted
Posted

Laptop (32bit Ubuntu 8.04):

 

te@te-laptop:~/src/darkradiant$ ./autogen.sh
/usr/share/aclocal/libmcrypt.m4:17: warning: underquoted definition of AM_PATH_LIBMCRYPT
/usr/share/aclocal/libmcrypt.m4:17:   run info '(automake)Extending aclocal'
/usr/share/aclocal/libmcrypt.m4:17:   or see [url="http://sources.redhat.com/automake/automake.html#Extending-aclocal"]http://sources.redhat.com/automake/automak...tending-aclocal[/url]
configure.ac:2: installing `./install-sh'
configure.ac:2: installing `./missing'
libs/ddslib/Makefile.am: installing `./depcomp'
Makefile.am: installing `./INSTALL'
Makefile.am: required file `./README' not found
Makefile.am: installing `./COPYING'

 

Then I did ./configure --prefix=/home/te/tools/darkradiant-test/ --enable-debug and got some error about glew.h not found. Installed libglew1.5 and libglew1.5-dev and got basically the same error as above:

 

...
configure: creating ./config.status
config.status: error: cannot find input file: Makefile.in

 

Hope this helps.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites
OrbWeaver

OrbWeaver

Posted
  • Author
Posted

Automake is complaining because you don't have a README file, and I didn't commit one into Subversion. I have now modified autogen.sh to pass the --foreign argument to automake, which should prevent this sort of error.

DarkRadiant homepage ⋄ DarkRadiant user guide ⋄ OrbWeaver's Dark Ambients ⋄ Blender export scripts

Link to comment
Share on other sites
Tels

Tels

Posted
Posted
Automake is complaining because you don't have a README file, and I didn't commit one into Subversion. I have now modified autogen.sh to pass the --foreign argument to automake, which should prevent this sort of error.

 

(<rant>Who would have guess that --foreign fixes that error? Certainly not someone reading the manpage, which states "--foreign - Set the global strictness to foreign"</rant>)

 

./configure worked now on my laptop, now running make. Will take some time.

 

Edit: Could you please set autogen.sh to executable in the repo? Otherwise I need to change it back manually each time. Thanx!

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites
Tels

Tels

Posted
Posted

Wooohoo! You are da man! :wub:

 

DarkRadiant compiled and installed and run successfully on my Ubuntu 8.04 laptop - for the very first time ever! :wub:

 

*does a little victory dance*

 

I can even move the camera around in litmode - the only real problem is the lack of memory - one Gbyte is not enough.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites
OrbWeaver

OrbWeaver

Posted
  • Author
Posted

Good to know that the work wasn't all in vain. :)

 

Once any problems with the autotools build script are ironed out, I will retire the scons build system altogether, since it will not be needed and has only ever caused problems.

DarkRadiant homepage ⋄ DarkRadiant user guide ⋄ OrbWeaver's Dark Ambients ⋄ Blender export scripts

Link to comment
Share on other sites
Tels

Tels

Posted
Posted
Good to know that the work wasn't all in vain. :)

 

Once any problems with the autotools build script are ironed out, I will retire the scons build system altogether, since it will not be needed and has only ever caused problems.

 

Cool. Would be a good idea to make this for TDM source, too, since I can't build it either on Ubuntu 8.04 due to some scons error (it builds fine, then links, then bails out with scons error)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites
Tels

Tels

Posted
Posted
The Debian build stuff should now be sorted out as well, so you can build a .DEB package just by entering the darkradiant directory and running "dpkg-buildpackage -rfakeroot".

 

I would add a README with all this info but I don't have commit rights.

 

Good job, tho! :wub:

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites
Tels

Tels

Posted
Posted

Edit: cleaned up post:

 

I updated the automake files to get the changes from the Namespace refactor branch to compile on my end (Ubuntu 7.10). I assume it's working at your end too, OrbWeaver?

 

I am not OrbWeaver, but I answer too :)

 

Yesterday, a compile on Ubuntu 7.04 failed (unfortnately, forgot to capture the error message). The system now runs Ubuntu 8.04 (yeah!), so a new compile is just running.

 

Will report back in a few mins how it goes. Nah, it is the same error:

 

g++ -DHAVE_CONFIG_H -I. -I..  -DPKGLIBDIR='"/home/te/tools/darkradiant-test//lib
/darkradiant"' -DPKGDATADIR='"/home/te/tools/darkradiant-test//share/darkradiant"' -I../libs 
-I../include -DPNG_NO_MMX_CODE -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include
/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-
2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/pixman-1   
-DPNG_NO_MMX_CODE -I/usr/include/gtkglext-1.0 -I/usr/lib/gtkglext-1.0/include -I/usr/include
/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-
2.0/include -I/usr/include/cairo -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include
/pixman-1 -I/usr/include/atk-1.0   -I/usr/include/libxml2      -g -O0  -DPOSIX -MT darkradiant-
main.o -MD -MP -MF .deps/darkradiant-main.Tpo -c -o darkradiant-main.o `test -f 'main.cpp' || echo './'`main.cpp
In file included from main.cpp:75:
map/Map.h:43: error: extra qualification 'map::Map::' on member 'getName'
map/Map.h:44: error: extra qualification 'map::Map::' on member 'getDependencies'
map/Map.h:45: error: extra qualification 'map::Map::' on member 'initialiseModule'
make[2]: *** [darkradiant-main.o] Error 1
make[2]: Leaving directory `/home/te/src/darkmod/darkradiant/radiant'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/te/src/darkmod/darkradiant'
make: *** [all] Error 2

 

Did:

 

./autogen.sh && ./configure && make

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites
Tels

Tels

Posted
Posted
You need to update to latest SVN. I've fixed these arrows a few hours ago. :)

 

Dang, sorry, I am a religious SVN updater and did so this morning - but apparently forgot to do it again before compiling :blush:

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites
OrbWeaver

OrbWeaver

Posted
  • Author
Posted
I updated the automake files to get the changes from the Namespace refactor branch to compile on my end (Ubuntu 7.10). I assume it's working at your end too, OrbWeaver?

 

Working fine here (except for the weird issue I get whereby DarkRadiant locks up the second time I start it, something to do with the AutoSaver firing during the splash screen update, but I was getting this issue before).

 

Thanks for doing this, I wasn't sure whether you had tried the autotools build system yet. Since it seems like the configure script is more or less there now, I think the time has come to start putting the generated configure and Makefile.in files into SVN so that autogen.sh does not have to be used.

DarkRadiant homepage ⋄ DarkRadiant user guide ⋄ OrbWeaver's Dark Ambients ⋄ Blender export scripts

Link to comment
Share on other sites
greebo

greebo

Posted
Posted

OrbWeaver, how are the autotools handling the user.xml files? Do they still support two separate user.xml trees (one in the install/ folder and one in the user's config folder)? I seem to run into issues when starting DarkRadiant the second time, as the toolbar manager complains about not finding any toolbar info. Looking at the file /darkradiant_install/share/user.xml, they are indeed missing, so could it be that DarkRadiant is overwriting the default tree user.xml?

 

Another thing I noticed is that the EntityList module is missing and the Menu Manager cannot find the command.

Link to comment
Share on other sites
OrbWeaver

OrbWeaver

Posted
  • Author
Posted
OrbWeaver, how are the autotools handling the user.xml files? Do they still support two separate user.xml trees (one in the install/ folder and one in the user's config folder)? I seem to run into issues when starting DarkRadiant the second time, as the toolbar manager complains about not finding any toolbar info. Looking at the file /darkradiant_install/share/user.xml, they are indeed missing, so could it be that DarkRadiant is overwriting the default tree user.xml?

 

The two files should still be supported, since the only change was to redirect the search path from install/user.xml to a compiled-in absolute path of $(PREFIX)/share/user.xml. I guess there is a possibility I failed to update one of the paths in the code (since they do appear in more than one place), which might be the cause of some of the problems.

 

Another thing I noticed is that the EntityList module is missing and the Menu Manager cannot find the command.

 

Yes, I haven't added makefiles for all of the optional plugins yet, I think S/R and Objectives editors are the only ones so far.

DarkRadiant homepage ⋄ DarkRadiant user guide ⋄ OrbWeaver's Dark Ambients ⋄ Blender export scripts

Link to comment
Share on other sites
  • 2 weeks later...
OrbWeaver

OrbWeaver

Posted
  • Author
Posted
OrbWeaver, how are the autotools handling the user.xml files? Do they still support two separate user.xml trees (one in the install/ folder and one in the user's config folder)? I seem to run into issues when starting DarkRadiant the second time, as the toolbar manager complains about not finding any toolbar info. Looking at the file /darkradiant_install/share/user.xml, they are indeed missing, so could it be that DarkRadiant is overwriting the default tree user.xml?

 

This is now fixed; I had made a incorrect change to the destructor of XMLRegistry without properly checking what I was doing, and attempting to save the user-modified user.xml to /usr/share/darkradiant rather than in the user's home directory.

 

This solves the lockup when starting the second time, although I still can't understand why. If user.xml did not exist the first time, why should it matter that it isn't there the second time?

DarkRadiant homepage ⋄ DarkRadiant user guide ⋄ OrbWeaver's Dark Ambients ⋄ Blender export scripts

Link to comment
Share on other sites
  • 1 month later...
OrbWeaver

OrbWeaver

Posted
  • Author
Posted

I'm pretty sure that -fPIC is used already for all of the static libraries, which suggests the real problem might be the portability warning about linking static libraries into shared libraries. I suspect the solution is to make all of the temporary libraries into shared objects which are installed into the /usr/lib/darkradiant directory as private libraries, which Automake does support.

DarkRadiant homepage ⋄ DarkRadiant user guide ⋄ OrbWeaver's Dark Ambients ⋄ Blender export scripts

Link to comment
Share on other sites
  • 4 months later...
greebo

greebo

Posted
Posted

I got DarkRadiant to compile on my end again, after running the ./autogen.sh shell script. I have two questions now:

 

- Should I commit the Makefile.in files? All seem to have changed on my end, although I just touched two of the Makefile.am files.

 

- How would I proceed with creating a .deb package for Ubuntu 8.10? Will this work for others when I'm on x64 Linux here?

 

Also, the dpkg-buildpackage script shows me the version 0.9.9.1, where can this be changed?

Link to comment
Share on other sites
OrbWeaver

OrbWeaver

Posted
  • Author
Posted
I got DarkRadiant to compile on my end again, after running the ./autogen.sh shell script. I have two questions now:

 

- Should I commit the Makefile.in files? All seem to have changed on my end, although I just touched two of the Makefile.am files.

 

Yes, use

 

$ automake --foreign

 

to regenerate them if necessary. The idea of committing the generated Makefile.in and configure (but NOT the Makefile or config.h themselves) is so that end users can do ./configure && make && make install to build the software without having to have Automake and Autoconf installed on their system.

 

- How would I proceed with creating a .deb package for Ubuntu 8.10? Will this work for others when I'm on x64 Linux here?

 

All DEB package creation should work the same way, just run dpkg-buildpackage in the top darkradiant directory. Of course there may be unresolved issues on other platforms, but the process should end up being the same.

 

Also, the dpkg-buildpackage script shows me the version 0.9.9.1, where can this be changed?

 

There are two places the version needs to be set -- the first line of configure.ac (which only includes 0.9.9, not the -1 release number), and debian/changelog which should have a new entry added to it in the given format (and I mean exactly the given format, DPKG is very picky about this).

DarkRadiant homepage ⋄ DarkRadiant user guide ⋄ OrbWeaver's Dark Ambients ⋄ Blender export scripts

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to topic listing

  • Recent Status Updates

    • taffernicus

      taffernicus

      i am so euphoric to see new FMs keep coming out and I am keen to try it out in my leisure time, then suddenly my PC is spouting a couple of S.M.A.R.T errors...
      tbf i cannot afford myself to miss my network emulator image file&progress, important ebooks, hyper-v checkpoint & hyper-v export and the precious thief & TDM gamesaves. Don't fall yourself into & lay your hands on crappy SSD
       
      · 2 replies
    • OrbWeaver

      OrbWeaver

      Does anyone actually use the Normalise button in the Surface inspector? Even after looking at the code I'm not quite sure what it's for.
      · 7 replies
    • Ansome

      Ansome

      Turns out my 15th anniversary mission idea has already been done once or twice before! I've been beaten to the punch once again, but I suppose that's to be expected when there's over 170 FMs out there, eh? I'm not complaining though, I love learning new tricks and taking inspiration from past FMs. Best of luck on your own fan missions!
      · 4 replies
    • The Black Arrow

      The Black Arrow

      I wanna play Doom 3, but fhDoom has much better features than dhewm3, yet fhDoom is old, outdated and probably not supported. Damn!
      Makes me think that TDM engine for Doom 3 itself would actually be perfect.
      · 6 replies
    • Petike the Taffer

      Petike the Taffer

      Maybe a bit of advice ? In the FM series I'm preparing, the two main characters have the given names Toby and Agnes (it's the protagonist and deuteragonist, respectively), I've been toying with the idea of giving them family names as well, since many of the FM series have named protagonists who have surnames. Toby's from a family who were usually farriers, though he eventually wound up working as a cobbler (this serves as a daylight "front" for his night time thieving). Would it make sense if the man's popularly accepted family name was Farrier ? It's an existing, though less common English surname, and it directly refers to the profession practiced by his relatives. Your suggestions ?
      · 9 replies
×
×
  • Create New...