Message Boards

 Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Manc

Pages: [1] 2 3 ... 8

Developer's Corner / Re: Visual Studio 2013

« on: December 12, 2015, 10:07:45 »
Those are most likely out of date and no longer supported.  The best thing to do is to use CMake to generate fresh copies of visual studio project files.  You can get the windows cmake software here:  You'll choose your odamex source dir as the base, and then it will show which types of project files you can generate. This will ensure it will use the actual files available.

Technical Support / Re: Odamex 0.7.0 build error

« on: September 25, 2014, 12:16:02 »
It looks like you're using wx version 2.8, which is pretty old at this point.  The launcher requires 3.0 or newer to build.

Technical Support / Re: Launcher protocol question

« on: April 07, 2014, 18:40:58 »
There is also an updated query protocol document on the source tree @ trunk/documentation/tech/query_protocol.odt.

We are working on making this something you obviously shouldn't need to search the source for.

Technical Support / Re: Launcher protocol question

« on: April 01, 2014, 18:27:28 »
Our launcher protocol document is woefully out of date, but below are all the cvars marked CVAR_SERVERINFO, which are the ones that get sent.  Note also that for the time being those with a value of empty or 0 are not sent.

This list reflects 0.7.0 and is subject to change in upcoming versions:

Code: [Select]










Devoblog / Bug Tracker Is Back

« on: July 13, 2013, 16:41:53 »
Not much to say - it's back!  Thanks much to ryan of for the help out of perl hell!


Devoblog / Odamex 0.6.3 Released

« on: April 26, 2013, 11:08:26 »
** This is a required update **

* The Release * (for experimental 32bpp client, see below)

While coding away at version 0.7, the team agreed that many great changes have been made to the main source that should get out to the public. Most of the 0.6.2 server hosts had updated their server builds to revisions that had numerous code fixes to the physics and co-op behavior. 0.6.3 is a release to get every server up to par with with these enhancements. The most notable of these features are:

* Numerous fixes to the behavior of co_zdoomphys and co_realactorheight to bring them up to par with zdoom 1.23b33.

* Iwads with alternate hashes can now join servers that allow them. Exceptions have been made to allow Doom and Doom 2 from Doom 3: BFG Edition to join any server that uses the 1.9 vanilla "DOS" version of Doom and Doom 2 and vice versa. Additionally, Freedoom and Ultimate Freedoom can now join Doom and Doom 2 servers as long as they are named "doom.wad" and "doom2.wad".

* Due to ancient CSDoom sound code, sounds were cut off from a very short distance when online. This has been found and remedied.

* Various improvements to the renderer, including horizontal and vertical texture scaling for high resolution textures (zdoom 1.23 compatible), fixes to issue where animated sprites appeared to jiggle, the fixing of animated textures on slopes, and the fixing of texture offsets on various maps that were built with a buggy nodebuilder.

* Users can now mute spectators via "mute_spectators", enemies via "mute_enemies", and private message other uses with the "say_to" command.

* Users can now switch between the classic Doom gamma levels and ZDoom gamma levels via the command "vid_gammatype"

You can view the full list of changes here and you can grab Odamex for your system today!

* The Experimental Client *
We had initially decided to include the client with the windows distribution, but later thought it would be better to include it here on the message boards for people to grab at their leisure.  There is a download available for Windows users, and for other platforms you can build the rend32 svn branch.

Download along with more information and instructions
NOTE: Please back up your odamex.cfg config file before attempting to use this client binary!

Coinciding with the release of Odamex 0.6.3, we are very pleased to showcase an experimental Odamex executable featuring a newly rewritten renderer. This renderer is in the separate source-code branch rend32 and will be replacing our standard renderer in future releases. This renderer is not entirely optimized and may have a small quirk here or there but we were too excited about it to keep it under wraps until its official debut in our forthcoming 0.7 version!
Wall rendering and view clipping has been rewritten in the rend32 branch to be dramatically more accurate than the ZDoom 1.22 renderer used in previous versions. This prevents integer overflow bugs that occur in really tall sectors, textures that appear to wiggle or jump on long linedefs, and walls that appear to move when you look along their length.
The rend32 branch also features 32-bit color rendering, allowing proper shading of colors in dark areas of the map instead of colors becoming washed-out due to palette limitations. Also dramatically improved is translucency, making blue text on the HUD much more clear. We can't thank James Dunne enough for his contribution of the 32-bit color feature!

32bpp example:,GsBTFof (You should probably be able to tell which is which!)

For windows users only:
For other platforms, please svn checkout and build the client

  • vid_32bpp: Set to 1 for 32bpp renderering, 0 for standard 8bpp.  Default is 0.
  • vid_capfps: While you will not find truly uncapped fps, setting this to 1 will unblock the renderer and allow it to process as many frames as possible.  It will still however be locked to display 35fps.  Default is 0.

Maps, Wads and Mods / Re: Classic1on1

« on: February 16, 2013, 18:34:18 »
Apologies for your post being flagged as spam, certainly not intentional at all.  Our spam filters might be a little too strict given our past spam issues.  I will try to make sure future posts are approved promptly or not flagged to begin with.

Technical Support / Re: Sloped Water

« on: February 05, 2013, 20:16:57 »
It might be something we could look at, but for now I would file it as an enhancement or as a "trivial bug" as I am not sure when we will be able to look at that.

Technical Support / Re: need help compiling on Linux

« on: January 13, 2013, 03:19:53 »
There are two components to wx, the main build and wxrc.  If you are installing these all from packages, perhaps wxrc is a separate package. 

Technical Support / Re: launcher on OSX..

« on: March 11, 2012, 09:45:34 »
What version of wx do you have installed? 

Nitro Zone / Re: Odamex Nitro #18 - IDDM18 FFA

« on: December 16, 2011, 09:39:15 »
Thanks to bones and hex for their continuing support to bring nitro to the masses!

General Discussion / Re: i set up arm based server for odamex server

« on: October 17, 2011, 10:35:27 »
Awesome stuff - keep us posted on performance and/or any bugs and other issues that you notice.

With this interest in ARM increasing, I wonder how much this work will translate to getting this working on android...

Devoblog / Re: Odamex 0.5.4 Released!

« on: August 11, 2011, 11:12:50 »
what are commands to record/play netdemos? do demofiles have specific names/extensions? where do you guys hide all this vital for odamex info?
Commands should be the standard commands, -netplay and -netrecord.  Demo files have .odd extension.  Netdemos are considered experimental and there is no complete documentation for them currently.  We are working on documentation and expect it to be done soon.

Devoblog / Manc Out

« on: January 31, 2011, 15:38:42 »
EDIT: Damnit...

After over 5 years of working on this project, I am afraid things have gotten to the point where I can no longer balance a support and passion against the community and where it sees efforts best spent.  It has become increasingly clear to me that people in the doom multiplayer community would much rather stick with their tried and true, yet broken or fascist port of choice rather than participating in an effort for a truly community-driven, open project.  

It is no secret that we have been and still are looking for someone to take the reins from denis after his departure, and we have not had much luck.  Granted, we have picked up some wonderful folks like Hyper Eye and Ladna.  These guys show a twinkle of what could have been possible.  Unfortunately, we are still grappling with problems that have existed since day 1, and we still to this day do not have a cohesive community-driven discussion and participation on any but the most basic level.  

This is not my only frustration.  There are certain areas in which I have asked for support beyond programming, and it is hard to come by.  While I mentioned we've picked up some developers with chops, progress has not been made at the speed that I would like, and as I have no repercussions to implement, it's hard to command such things get done.  Being at the whim of others who come and go is not going to work for this project.

To be clear, this is not about getting or not getting "credit" or lack thereof for anything.  Far better programmers than I have implemented a majority of what Odamex is.  I do not feel that I am being forced out, "overworked" or anything like that.  In fact, it is the lack of such progress that plays a role, albeit a small one.

Perhaps at this point in Doom's life, there is not enough room for 3 port choices that are all based on the same seeds.  I am not entirely sure at this point.  I suppose it will remain to be seen.  My departure does not signal the end of Odamex.  Since it's an open source project it will continue, though what "continue" means is up in the air.  Without a lead developer, things will continue to stagnate.  Without serious effort, information is stale and interest is lost.  If there is someone in the shadows waiting that suddenly has an interest in providing real coding leadership and direction, you're more than welcome to join #odamex-dev on

So long, and thanks for all the fish.
Pages: [1] 2 3 ... 8