Message Boards

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: https://cmake.org/download/.  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.

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.

Not much to say - it's back!  Thanks much to ryan of slipgate.org for the help out of perl hell!

http://odamex.net/bugs/open

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:  http://imgur.com/5kkW9Sb,GsBTFof (You should probably be able to tell which is which!)

Download:
For windows users only: http://odamex.net/dev/rend32/odamex.exe
For other platforms, please svn checkout http://odamex.net/svn/root/branches/rend32 and build the client

Usage:

• 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.

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.

What version of wx do you have installed? 

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...

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 irc.oftc.net.

So long, and thanks for all the fish.