|Posted by aguirRe [22.214.171.124] on 2007/08/16 13:33:24|
|at http://user.tninet.se/~xir870k . All engines are updated with many features/fixes, e.g. better support for Quoth add-ons, GL-engines have several improvements in external texture handling and NehQuake has an important fix for coloured dynamic lights.
All engines have many small improvements for visual anomalies, better compatibility and more support for troubleshooting maps or QC issues.
ConvDem can now join several demos into one and TreeQBSP has a minor crash fix. Please see readmes for details.
Any comments are welcome.
Three Thumbs Up
In a few years it is playable on a 486
the kind words, guys!
I'd also like to grab the opportunity to demonstrate two features of my engines.
The first is smooth demo-playback, if you enjoy watching skilled players mow or trick their way through maps, try out the recommended engine settings described in the readmegl file near the end. Set also chase_active 1 and host_framerate 0.015 before starting a demo to watch it in 3rd person and in slow-motion.
Adjust host_framerate for desired speed (higher is faster and 0 to reset), you can bind keys to do this more easily. Notice especially how the player and monsters are rendered while moving and how their shadows follow smoothly. For best results, use one of the many great demos at SDA (e.g. Quake Done 100% Quick Lite 2
or Scourge Done Slick
The other is capacity and playability in entity-intensive maps. For a good example, check out the amazing demo by Sielwolf in one of my test maps Larger Room
, originally made by Andrey Kulsha of SDA and then modified by me. In this demo, you'll see Sielwolf taking on 1200 monsters on Nightmare skill and wiping them all out :)
The LRB map can also be played in other mods, e.g. Warp with Quoth monsters. Just put the map in id1/maps as usual, run Warp with its normal settings on the start map, set coop 2 and then "map lrb". If you want to see even higher intensity, set nomonsters 3 and restart map.
You may notice some slowdown and you'd better enter godmode quickly unless you're going to try to beat Sielwolf's record ...
Surprise surprise: Tyrquake crashes and Darkplaces runs it with ~1fps. I miss your engine in Linux, I really do.
Qudos ( http://qudos.quakedev.com/linux/quake1/
)made a linux port of the Nehahra part once but I didn't grab the file and now it's gone. Does anyone have it?
I support neg!ke's request, that always was a mess. ;)
YAY! And ARGH!
My hopes were high but they weren't satisfied by it. I wanted to use it for normal id1 and mod playing but apparently there is some evil trick necessary to do that (aguirRe, help me :) ). It is some older version 3.04. :(
I mailed the guys about the sourcecode though. Will try to diff against the old source and port the changes to glquake. Maybe it won't be too hard.
NehQ engines, make sure to add -game id1 if you're playing std maps. For other mods, set -game xxx as usual. If the mod directory doesn't contain a progs (a bit unusual), then copy the id1 progs (or possibly also other resources) to the mod folder.
In my NehQ, there's an -id1 option that helps a lot to improve compatibility. It's also automatically enabled when you use any of the -hipnotic, -rogue or -quoth options.
If you have the source, you can pretty easily add the basic -id1 behaviour in file common.c. There'll still be issues with cheat codes and other stuff, but at least the resource search order will be OK.
an easier way would be to copy the Warp pak2 file (very small - 19k) to the nehahra directory (move the original stuff somewhere else beforehand) and rename it to pak0.
If I'm not mistaken, this should enable older NehQ to run, but all resources will be taken from std dirs. Then you don't even need to fuss with the source. Let me know if this works.
Is there no chance of there ever being Linux versions of your engines and tools? Tools,compilers etc are OK, they do work fine under Wine, but the Engines, hmmm, that would be nice.
no plans for that.
-id1, -game id1, -id1 -game id1 yesterday and start.bsp always was the Nehahra one. Let's hope they got the source code. I'll contact Qudos too.
linux-user: If the chances Qudos made are not too deep (which I hope), it might be possible to apply them to glquake too (which I want to try).
and I'll try that Warp trick!
-game id1 should work pretty well, at least for std id1 stuff. The start map in Nehahra is called nehstart, so you shouldn't enter that by typing "map start".
I'd assume that you went via the menu "New map", that'll probably lead you nehstart in older NehQ.
But definitely try the "Warp trick", that worked fine here in my old NehQ 3.04 version. It should be the simplest solution.
Do you keep your changes in any kind of source control system?
I Keep All
released versions, one zip for each. I guess you could call that a simple source control system ... ;)
Pak2 just has a couple of graphics that the Nehahra engine searches for and crashes if the player doesn't have Nehahra installed.
It's a dummy that tricks the engine into thinking Nehahra is there, weather it is or not. Thanks to Mindcrime for giving the ok for that.
And AguirRe for making it, of course ;)
AguirRe�s Engines > *
I like especially how AguirRe adds eye-candy features like hires-textures, model intepolation etc. without compromising in regards to faitfulness and stability.
Iike that they run faster than any other engines with a 4MB onboard gfx-card
That they run stable
That they add a lot of eye-candy features and that they are turned off on default
Linux, BSD, Mac
Looking around for tools that run at least on Linux, preferably also on Mac and BSD, I came across disenchant.net and found Tyrutils.
Tyrann's compiling tools run on Linux, Windows and BSD and version 2 now also contains Treeqbsp, so it's a complete set of tools running natively on Linux (he deserves huge thanks for that.)
His engine, Tyrquake is also multi-platform, rock solid, contains NQ and QW clients as well as a QW server, and has raised limits for bigger maps. I also get higher FPS in Tyrquake than in Joe or Proquake, and the mouse input feels much more precise.
The tools and the engine are actively developed and I'm highly inclined to switch away from AguirRe's tools at least. I'm no longer bothering with software that's not Linux-native.
Tyrann's compiling tools seem to be the only actively developed ones still working on non-M$ systems.
It's ridiculous if you consider that the original id tools and engines were cross-platform ten years ago, yet some of their "improved" descendants have become OS-dependant because of MS-induced blindness on the part of their developers.
Your tools are good AguirRe, but I just can't justify having to use an emulator just for them.
For possibly interested parties, there are very good command-line PAK and WAD tools for Linux, too. They're called QEU. There's also at least two map converters, as well as bsp2map and bsp2wad utils.
Map editors - at least GTKRadiant and Quest run on Linux.
I don't know of a way to edit and display .mip files (textures) yet, though. A GIMP plugin would be nice. Also a model editor would be cool, perhaps just an exporter for existing 3D modellers.
If someone knows other cross-platform Quake tools, please share any infos.
yet some of their "improved" descendants have become OS-dependant because of MS-induced blindness on the part of their developers.
Everyones entitled to their opinion, but that's a bit harsh don't you think? People like aguirRe etc do a tremendous work updating and improving the tools, there may be many reasons they choose not to support anything other than Windows,they may not have access to other platforms, they may not be, or, don't have any desire to become familiar with them, the list goes on and on. And at the end of the day it's there choice, if they decide they don't wish to pursue porting the tools to other platforms, well that's that, end of story.
I myself would love if aguirRe's tools and engines were available as native progies for Linux, they aren't, and as stated, there are no plans to do so. The good part is that, at least as far as the tools are concerned, they run damn fine in Linux via Wine. I don't like using Wine, would rather not have it installed, but I chose to use Linux, so the choice is easy, either use Wine for the few things I need to, or find replacements, I choose the former.
Texmex and Wally also run fine via Wine
I think you are being a little unfair in your critique. I mean, I know where you are coming from, but everyone who helps contribute things to Quake has finite time and resources.
I'll tell you what ...
Can you assist me in instructions on how to compile ProQuake 3.50 on Linux from A to Z (preferably in a post @ QuakeOne.com) and I will use that information to also compile aguirRe's engine if possible and I will thoroughly document and package any changes.
I have a Linux machine, have a very thorough understanding of the code of both FitzQuake and aguirRe's engines (I've read every single line of code in both engines) and can identify code that is not Linux friendly (FitzQuake has a little, I have not seen any in aguirRe's engines).
However, I am somewhat of a Linux newbie. I have used Linux servers and the command line for years, but need some hand holding to get down to business with the OS (help locating/installing SVGA lib/OpenGL stuff, etc.)
I believe you are correct to want this. Help me and I'll help everyone ;)
Yes, I use it too. It's a bit buggy sometimes and got problems with some limits still. Tyrann is very active indeed though and grateful (& fast) for bug reports. :)
This is the great Quake in Linux FAQ: http://tldp.org/HOWTO/Quake-HOWTO.html
For mapping I use QuArK running in VirtualBox, shame on me. ;)
Qudos made some weird changes to the code (like playing some sound on startup, in his nehquake the mouse settings are screwed etc) but they compile fine on Linux. Maybe you can find help here.
golden_boy sounds like he needs to be sent to bed without any dinner!
Here's a thought, the source is available for those tools, why don't you port it to linux?
Website copyright © 2002-2017 John Fitzgibbons. All posts are copyright their respective authors.