Message Boards

Ah yeah sorry about the .gitattributes. I was trying to make it forcibly check in LF line endings that way to be compliant with the coding standards. I'm pretty sure it does.

In order to clean things up do a `git reset --hard`. That should hopefully check out the line endings in a clean way. I think do it without the core.autocrlf set to true. The git documentation does not make things clear.

Latest 32bpp builds:
http://bittwiddlers.org/ftp/jim/software/odamex/odamex-32bpp-2c26fdf-x64.zip
http://bittwiddlers.org/ftp/jim/software/odamex/odamex-32bpp-2c26fdf-x86.zip

Try running without the launcher. Just double-click the odamex.exe in the folder.

Read the original post. You probably need the VC2012 C++ redistributable for x86 installed. Link is in the original post.

Please describe the exact error message when reporting errors; just saying "some error" is not helpful. FYI, Windows message boxes (e.g. OK/Cancel) can usually have their contents copied to the clipboard with CTRL-C while the box is showing.

Thanks for that. Already discovered and fixed most of that.

Latest Win32 build:
http://bittwiddlers.org/ftp/jim/software/odamex/odamex-32bpp-28182dd.zip

Yeah I can't get the server EXE to build either.

There are only 32 distinct light levels. I'd like to make the lighting more smooth. This concept of light levels is spread throughout the code and would be tough to factor out.

Latest build should fix most of those issues listed above:

http://bittwiddlers.org/ftp/jim/software/odamex/odamex-32bpp-31a372f.zip

Remaining issues are:

• Scoreboard colors
• Translucent parts have bright/dark vertical stripes in them

GCC does not impress me with its performance. I really don't have much to tell you on that one.

Hey everyone,

I've been working on the 32bpp color port of the Odamex client for the last week or so. I just wanted to "officially" throw this out there for everyone to help test out. Let us know what you think!

This 32bpp port only enhances the rendering portion of the game; i.e. it does not affect how textures or sprites are loaded. 32bpp removes the need for color-mapping which is what the 8bpp mode uses to find the "best" color among the 256 available colors for the lighting effect. 32bpp mode just uses the raw RGB value of the darkened color for lighting and thus you won't see any aliasing effects (e.g. colors shifting hue from red to brown).

Latest binary (Win32) is here:
http://bittwiddlers.org/ftp/jim/software/odamex/odamex-32bpp-71dcc38.zip

You can find future binaries (check Last Modified date stamp) here, and the required SDL dlls:
http://bittwiddlers.org/ftp/jim/software/odamex/

In order to use these binaries you'll need the VC2012 C++ redistributable for x86 platform installed. You can download it here. Be sure to pick x86!

http://www.microsoft.com/en-us/download/details.aspx?id=30679

I have all the code up on my GitHub repository at:
https://github.com/JamesDunne/odamex

There is a README-32bpp file included in the ZIP package which documents what has changed and what issues are known.

If you're looking for a quick test, just go to the Video Options menu screen and flip "32-bit color" to "Yes". The change should take effect immediately. For an even quicker way, use the console (~) and type "vid_32bpp 1" to enable and "vid_32bpp 0" to disable (i.e. go back to 8bpp).

All vanilla DOOM and DOOM 2 maps are working.

Please help by testing out custom PWADs with extra BOOM effects enabled, e.g. ACS scripting, custom lighting, translucency, etc.

Also, please report any significant performance loss while in 32bpp compared to the 8bpp mode. Use `vid_fps 1` to show the FPS counter in the lower-left corner of the screen and report those numbers, along with which PWAD and map.