PDA

View Full Version : Compiling legacy 2.0


rabbit
March 18th, 2007, 04:19 AM
Hi,

I am trying to compile legacy 2.0 on Debian Unstable, and was successful at building a Legacy binary, but I can not make the updated legacy.wad, period. From the latest revision (442) I get: g++ -c -g -O0 -I../../tnl -I/usr/include/SDL -Wall -DLINUX -DSDL -I../include convert_deh.cpp -o ../objs/convert_deh.o
convert_deh.cpp:1189: error: prototype for ‘bool dehacked_t::LoadDehackedLump(const char*, int)’ does not match any in class ‘dehacked_t’
../include/dehacked.h:54: error: candidate is: bool dehacked_t::LoadDehackedLump(int)
I even went back to revision 166, where make wad was supposedly introduced. Still I get an error about some resources missing: cp: cannot stat `../resources/*.lmp': No such file or directory

How do I get a new shine legacy.wad for my newer and shinier 2.0? :)

By the way I stumbled across a number of obstacles along the way. I will describe them below and provide a patch against 442. Feel free to apply it if you find it useful.


Some systems (mine for instance) have the SDL header files in a separate directory. I inserted an additional -I option to take care of this.
The order of $(grammar_objects) in the Makefile is wrong - ntexture expects decorate to be already there.
I really disliked the compilation instructions sending me to dig in the tnl source tree to find the compiled libraries. I modified the Makefile to look for them on its own, and updated compiling.html accordingly

All these improvements can be found here (http://rabbit.us/pool/legacy/442_makefile.diff)

Last but not least I had to revert back to revision 440. The GLSL support introduced in 441 bombs on me with this error (http://rabbit.us/pool/legacy/442_link_error.txt) during the linking stage. Which of my libraries is at the wrong version? Should the requirements listed in compiling.html be updated?

Cheers

Peter

smite-meister
March 18th, 2007, 09:27 AM
How do I get a new shine legacy.wad for my newer and shinier 2.0? :)

I fixed the LoadDehackedLump compilation error, try again now.


Some systems (mine for instance) have the SDL header files in a separate directory. I inserted an additional -I option to take care of this.

Yes, /usr/include/SDL/ is where my SDL is located as well.
All #include clauses for SDL headers are supposed to take this into account, along the lines of "#include <SDL/SDL_types.h>", except for some weird nonstandard systems.


The order of $(grammar_objects) in the Makefile is wrong - ntexture expects decorate to be already there.

How so? They should be independent of each other.


I really disliked the compilation instructions sending me to dig in the tnl source tree to find the compiled libraries. I modified the Makefile to look for them on its own, and updated compiling.html accordingly

It's admittedly annoying, but you only have to do it once. What OpenTNL should have is a working installation option so that "cd tnl; make install" would take care of both the libraries and headers.


Last but not least I had to revert back to revision 440. The GLSL support introduced in 441 bombs on me with this error (http://rabbit.us/pool/legacy/442_link_error.txt) during the linking stage. Which of my libraries is at the wrong version? Should the requirements listed in compiling.html be updated?

Sorry about that. The shader code is a crude testing version, later on I'll make it handle older OpenGL versions more gracefully. Basically you either need to have OpenGL 2.0 (maybe even 2.1?) headers, or to comment oglshaders.o away from the Makefile.

rabbit
March 18th, 2007, 10:09 AM
I fixed the LoadDehackedLump compilation error, try again now.
Yes it works! However when starting Legacy the last line in stdout.txt is Couldn't load music lump:
Is this normal?

Yes, /usr/include/SDL/ is where my SDL is located as well.
All #include clauses for SDL headers are supposed to take this into account, along the lines of "#include <SDL/SDL_types.h>", except for some weird nonstandard systems.

You are absolutely right. I looked closely and the reason this happens is that Debian Unstable does not have mixer 1.2.7 so I installed it in /usr/local/lib. Well /usr/local/include/SDL/SDL_mixer.h thinks it is in /usr/include/SDL, so it includes everyone as include "SDL_xxx", which of course does not work. Modifying SDL_mixer.h solved the problem.

How so? They should be independent of each other.
trunk/grammars/ntexture.parser.y includes decorate.parser.h on line 48. It is not in the svn repository since it is generated further down the Makefile.

It's admittedly annoying, but you only have to do it once. What OpenTNL should have is a working installation option so that "cd tnl; make install" would take care of both the libraries and headers.

Reason I did it this way (and believe is the right way to go) is that installing a non-mainstream library for systemwide use only in order to compile a single binary leads to unnecessary system clogging. If dependencies are laid out my way I just delete the entire working dir and I am done both with legacy and tnl. All in the eye of the beholder I guess :)

Sorry about that. The shader code is a crude testing version, later on I'll make it handle older OpenGL versions more gracefully. Basically you either need to have OpenGL 2.0 (maybe even 2.1?) headers, or to comment oglshaders.o away from the Makefile.
This does the trick, thanks.

After your valuable input I have a legacy.wad (md5sum b7e9834d332a3cb3f73633aa2ebde0c7). However once I try to run it in conjunction with doom2.wad (the only wad I have, md5sum 30e3c2d0350b67bfbf47271970b74b2f) Legacy flashes the screen and exits with "Floating point exception" printed on the command line. stderr.txt is empty (o bytes) and stdout.txt is here (http://rabbit.us/pool/legacy/stdout.txt). Any suggestions? Anything I can provide to track it down?

Thanks

Peter

smite-meister
March 18th, 2007, 02:29 PM
Yes it works! However when starting Legacy the last line in stdout.txt is
Couldn't load music lump:
Is this normal?


Legacy flashes the screen and exits with "Floating point exception" printed on the command line. stderr.txt is empty (o bytes) and stdout.txt is here (http://rabbit.us/pool/legacy/stdout.txt). Any suggestions?
Hmm. You have a /usr/local installation of SDL_mixer 1.2.7, which in turn requires SDL 1.2.10 if I remember correctly. Are you sure the dynamic linker links the Legacy executable against the /usr/local/lib libs and not the system default ones? Do a "ldd Legacy" and see what it says.

rabbit
March 18th, 2007, 02:45 PM
Yes, since I don't have a system instalation of SDL_mixer (I took it away so such a mix up would not happen). My SDL is 1.2.11

smite-meister
March 19th, 2007, 04:06 AM
I_SetVideoMode: fullscreen 2560 x 1024 (8 bpp)

This seems a bit suspect to me, Legacy should not at present allow fullscreen modes larger than 1600x1200. Try editing ~/.legacy/config.cfg or ~/.legacy/glconfig.cfg and switch to a smaller resolution and/or non-fullscreen mode.

rabbit
March 19th, 2007, 04:31 AM
This seems a bit suspect to me, Legacy should not at present allow fullscreen modes larger than 1600x1200. Try editing ~/.legacy/config.cfg or ~/.legacy/glconfig.cfg and switch to a smaller resolution and/or non-fullscreen mode.

Yes this was the culprit. Adding fulscreen "No" or setting a different resolution in autoexec.cfg did the trick. It is rather strange that neither config.cfg nor glconfig.cfg were consulted (stdout.txt was still showing 2560x1024). Only once I created an autoexec.cfg did the change take place. Probably adding a line in the documentation, or even better exitting with a sensible error message would be a good idea.

So now the game runs fine in software mode. No music though, probably because of the message I am getting in stdout.txt. Is there any way to remedy this?

However OpenGL does not work. I get the following in stdout.txt:
OpenGL video mode has not been set
Level MAP01 has no GL nodes.
Trying to use OpenGL renderer without GL nodes. Exiting.


The same .wad works fine (albeit slow) under opengl with legacy1.42 on windows. Any suggestions?

Thanks for all the great help so far!
Peter

rabbit
March 19th, 2007, 04:43 AM
It is rather strange that neither config.cfg nor glconfig.cfg were consulted (stdout.txt was still showing 2560x1024). Only once I created an autoexec.cfg did the change take place.

Disregard this, I didn't realize that configs are kept in ~/.legacy instead of the game dir (although you specifically stated that). Sorry about that.

smite-meister
March 19th, 2007, 06:15 AM
So now the game runs fine in software mode. No music though, probably because of the message I am getting in stdout.txt. Is there any way to remedy this?

SDL_mixer 1.2.6 had a bug which broke MIDI music, but 1.2.7 fixed it at least for me.
You do have timidity (and the instrument patches) installed, don't you?

However OpenGL does not work. I get the following in stdout.txt:
Level MAP01 has no GL nodes.
Trying to use OpenGL renderer without GL nodes. Exiting.

The new OpenGL renderer requires maps to have "GL-nodes", which are built using this here little program: http://glbsp.sourceforge.net/
At some point we'll probably integrate glbsp into Legacy.

rabbit
March 19th, 2007, 10:59 AM
You do have timidity (and the instrument patches) installed, don't you?
Nope :) Never had to play midi on linux before. Music now plays flawlesly

Passed the wad both through glbsp and glvis - OpenGL works! You guys kick unprecedented amount of ass *bang*

Just some quick questions, and I will go play. Maybe those belong in the feature requests - feel free to move them there if you deem so appropriate:


When in OpenGL the map does not work. It switches to the mode all right but the screen is blank. Not critical at all, just making sure I didn't do something wrong. Map works correctly in software mode.
In OpenGL the bottom part of the screen is rendered as well, causing the weapons (especially fists) to float in the middle of the scene in a sense. It is a very minor annoyance, but maybe there is a way to get the border back?
On my resolution (1280/1024) the console font is nearly unreadable. Is there a way to remedy this?
I was unable to link with a legacy 1.42 client for network play. The server bombed saying it received two unknown packets. Did the network protocol change between the two or this is a bug?


Once again thanks a ton smite-meister. You are my new cyber-daemon-hero *thumbs*

smite-meister
March 20th, 2007, 06:50 AM
On my resolution (1280/1024) the console font is nearly unreadable. Is there a way to remedy this?

Not yet.

I was unable to link with a legacy 1.42 client for network play. The server bombed saying it received two unknown packets. Did the network protocol change between the two or this is a bug?

Legacy 2.0 does not yet have working netcode, and when it will, it will be completely different from 1.42. So no cross-version netgames, sorry.

shinobi
May 26th, 2007, 09:19 AM
I've downloaded legacy with SVN, and TNL via CVS. TNL is now in a tnl/ directory under the legacy source.

In the docs, it says that i must apply a patch , so i do the following


shinobi@linux:/legacy/tnl$patch < ../libtnl_patch.diff
can't find file to patch at input line 8
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|Index: libtomcrypt/makefile
|================================================= ==================
|RCS file: /cvsroot/opentnl/tnl/libtomcrypt/makefile,v
|retrieving revision 1.3
|diff -d -U0 -r1.3 makefile
|--- libtomcrypt/makefile 28 Apr 2005 17:29:26 -0000 1.3
|+++ libtomcrypt/makefile 24 Jan 2007 09:11:43 -0000
--------------------------
File to patch:


Now this is where i get stuck. How can i choose which file will be patched? (i would choose the older)

Or maybe, i'm using patch the wrong way. Is my first time using this tool, and the documentation for patch is not that complete anyway.

I really don't know.

BTW, i have ubuntu7.04, g++ 4, and SDL installed.